Generalization in this case is really unhelpful, since there is almost no diversity in SSL libraries. There is 3 of them, but almost everyone uses openssl.
One case do not make a trend at all, and two cases is the worst statistical proof there is for trends.
On the positive side, open source model of development do allow projects to use not only what is common, but also the exciting fronter regarding security models. My project has used gnutls with pgp for 6 years now, nicely avoiding all those 2 major vulnerabilities, and that was only possible because someone found themselves wanting to implement the new TLS standard that supported pgp keys.
The same license that some libraries inside Starcraft 2 has.
But blizzard must be one of those small companies that do not care about profits, or have no lawyers. No "serious company" or serious software would dare to use LGPL, right?
But instead of arguing license religion, I suggest we move back to the topic of OpenSSL and vulnerabilities.
I would actually be interested in hearing some of the issues related to LPGL in video games and other projects. Are there stories / write ups on this that you could link to or would you mind explaining it some?
I'm not aware of any long form text on this, but the issue is relatively straightforward.
A publisher hires a studio to make a game, which then gets published on platforms that actively prevent users from (compiling and) running their own software (consoles, iOS).
Since the user is not provided with the tools to replace a library used in a game, the terms of the LGPL cannot be met even if the studio were to release the source to their version of the library.
In fact, even if they released the source to their whole game (something the publisher would never allow) the LGPLv3 still cannot be met because of the anti-Tivoisation clause, which stipulates that users must be able to run their own compiled version of the software.
Would a clause in LGPLv3 that exempts the publisher/distributor from limitations beyond their control (console/iOS restrictions) help?
Also, I think the the user isn't prevented from recompiling and running altogether; a user can get a developer account. Although, I guess that presents an additional cost, something (L)GPL might be against.
>Would a clause in LGPLv3 that exempts the publisher/distributor from limitations beyond their control (console/iOS restrictions) help?
I doubt very much that RMS would want to add such a clause. Remember, the GPL and LGPL are political tools as much as software licences. They exist to move the world in a certain direction. Adding such clauses would reduce their reason for existing.
A linking exception from the library authors could accomplish that, I believe it's what GCC uses. LGPLv2 may also be ok, but GPL licenses in general are complex enough that no one is entirely certain.
If the library is statically linked (which is the case at least on consoles), the user would also need the game's source code. I think the restriction is enough to trigger the (L)GPL clauses anyway.
> Would a clause in LGPLv3 that exempts the publisher/distributor from limitations beyond their control (console/iOS restrictions) help?
Tivo would just create a complicated enough corporate structure to provide the same shroud for themselves and will then be able to satisfy all requirements.
Based on some informal research I did ~10 years ago (i.e. I ready the LGPL as a high school student), the LGPL requires, among other things, an end-user license allowing reverse engineering. The LGPL isn't just "my code is GPL, the rest of the program is whatever"; it puts forth some requirements for the entire finished product that are either impractical (must include source code) or illegal (would violate NDA or other license terms for the console libraries) for console games.
Only reverse engineering for debugging modifications of the LGPL code in derivative works.
if you try to reverse engineer the protocol starcraft 2 uses with battlenet, you will have a hard time arguing in court that the LGPL license gives you permission to do so. If I recall right, starcarft 2 has some heavy restrictions on reverse engineering for this specific purpose, and I trust their lawyers to actually understand this difference.
For console games (which starcraft 2 is not), the console environment is incompatible with LGPL. If adaption of a security library depend on the console market, then such adaption won't happen.
One case do not make a trend at all, and two cases is the worst statistical proof there is for trends.
On the positive side, open source model of development do allow projects to use not only what is common, but also the exciting fronter regarding security models. My project has used gnutls with pgp for 6 years now, nicely avoiding all those 2 major vulnerabilities, and that was only possible because someone found themselves wanting to implement the new TLS standard that supported pgp keys.