Excellent page. Only thing missing is the GPL vs LGPL issue about viral and non-viral copyleft. I am not saying that being viral is a good or bad thing, it is just a choice a developer must make when picking a license.
I'd argue that omitting such important differences like the differences between LGPLv3, GPLv3 and AGPLv3 is detrimental to the effort of making licensing "less scary". Given the summaries for GPLv3 and AGPLv3 for example, somebody might think they have identical terms. The only additional information they give is a link to the license text (which is a terrible light grey font on white background). The original license text is what might be scary about licensing: because people struggle to read the legalese.
There needs to be a concise summary of how these licenses differ, one that they can comprehend without reading the whole license text. Website is a good idea, but IMO, needs a lot of work, and may even be harmful in it's current state.
I'm also not sure why they promote the GPLv2 (without + clause) over the GPLv3 either. That may convince someone that people will always share their code, and doesn't mention tivoization. Seems like a deliberate ploy from someone who dislikes the strong copyleft of GPLv3 family to prevent people using them.
I think an improvement would be to have multiple options and to filter down licenses until only a few remain: so eg, when I click "I care about sharing improvements" on the front page, it gives me another few options, like "I want people to share their modifications for hosted websites", or "I want people to be able to use in commercial apps" - which would filter to AGPL and LGPL respectively.
The GPL is not more "viral" than any other software license.
To distribute a product that uses GPL'd code, the rest of that product must also be under an open-source license, but there is no requirement that everything be licensed under the GPL.
There are plenty of licenses that are less viral than the GPL, such as BSD, MIT, etc. Furthermore, if you're pulling code from multiple sources, there are licenses, such as CDDL, that are mutually incompatible with the GPL. So yes, looking at virality very much does matter.
For most discussions about the GPL, people call the GPL "viral" from a misconception that it can't be combined with or depended on by non-GPL code. This belief is obviously wrong, but it persists.
Both the GPL and LGPL can be combined with and depended on by non-GPL code, so if the LGPL is not "viral", then neither is the GPL.
Viral as in requiring my code to be compatible with the GPL ecosystem, and in restricting my choice of licenses.
As I gave as my example, I can use a library licensed under the LGPL, and link it with code licensed under the CDDL. I cannot do that with a library licensed under the GPL. With that GPLed library, I'd have to use a license that the GPL is compatible with. So, if I had a product that I wanted to link with both sides, I would need to license my code under a license that is mutually compatible, such as BSD or MIT; I would be restricted from using certain other copyleft licenses.
> Viral as in requiring my code to be compatible with the
> GPL ecosystem, and in restricting my choice of licenses.
By that reasoning, all software licenses are viral. Even the 2-clause BSD license would be viral, because you're not permitted to distribute it combined with code that it's incompatible with.
> As I gave as my example, I can use a library licensed
> under the LGPL, and link it with code licensed under
> the CDDL. I cannot do that with a library licensed
> under the GPL.
That's simple license incompatibility. There are many licenses that are incompatible with the LGPL, and you wouldn't be able to distribute the combined work any more than you could a combined CDDL/GPL work.
> So, if I had a product that I wanted to link with both
> sides, I would need to license my code under a license
> that is mutually compatible
Again, this is true of every copyright license ever created. That's what "incompatible" means.
> By that reasoning, all software licenses are viral. Even the 2-clause BSD license would be viral, because you're not permitted to distribute it combined with code that it's incompatible with.
You're reinventing definitions to suit your argument. The BSD license creates no restrictions on what you can combine it with. The restrictions are defined by to the GPL.
All licenses (except, in some jurisdictions, the public domain) have restrictions. They may be minor, they may be "common sense", but they are still restrictions. The BSD license has restrictions on how code may be redistributed, in particular its requirements regarding attribution and non-endorsement.
If I released some code with a license that said:
This work may not be combined with any work which has a
license containing more than twenty capitalized letters.
Then that license would be incompatible with the BSD license, and it would be illegal to combine the two works.
So if you define "viral" to mean "a license which can be incompatible with other licenses", then the GPL would fit that definition, but so would many other licenses (including the BSD license). Thus, it is not a useful definition.
There is no useful definition of "viral" which covers the GPL but excludes the LGPL.
You're engaging in standard GPL goal-post moving; somehow if you redefine all the words we'll all accept that the GPL isn't a restrictive viral license.
> For most discussions about the GPL, people call the GPL "viral" from a misconception that it can't be combined with or depended on by non-GPL code. This belief is obviously wrong, but it persists.
Debian obviously thinks this is a problem, or else they would not have any problems with the GPL incompatible OpenSSL license.
The problem of license incompatibility isn't unique to the GPL. You could have software under a license that's incompatible with 2-clause BSD, but that doesn't mean the BSD license is "viral".
For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?
> For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?
I am not anti-GPL. My original and only point was that the distinction between GPL and LGPL is important to explain, and the situation with PostgreSQL at Debian shows there are real world implications of this.
> For example, the OpenSSL license is also incompatible with the LGPL; does that mean the LGPL is "viral"?
You have any source for this? LGPL was created to allow linking with any software. If you just copy paste source they are not compatible.
> My original and only point was that the distinction
> between GPL and LGPL is important to explain
It's actually pretty easy. The most important difference is that the LGPL permits bundling of your code with the LGPL'd code into a single combined work. The GPL would require your code to be open-sourced, but the LGPL has special provisions to permit bundling.
This is most relevant when using static linking, but also applies if you're distributing your program with a bunch of included dynamic libraries. The LGPL is important for proprietary applications because it lets them (for example) bundle a version of GTK+ that they know will work properly, so they don't have to depend on whatever version is installed on the user's system.
> You have any source for this? LGPL was created to allow
> linking with any software. If you just copy paste
> source they are not compatible.
"Compatibility" is typically considered when there's going to be works under two licenses combined into a derived work. The OpenSSL license is incompatible with the GPL and LGPL because it has requirements (the advertising clause) that the GPL/LGPL prohibit. So if you want to take some OpenSSL code and some LGPL'd code and compile them both together, you wouldn't be permitted to distribute the result.
The LGPL offers a workaround, which is to separate out the LGPL'd code entirely into a separate library, and then set up your build system so users can relink against a modified version of the LGPL'd code. In this case, the OpenSSL code is being treated as if it were a proprietary blob. So it solves the problem of distribution, but with the hassle of maintaining that clean library separation.
There's only one way compatibility where combination is concerned w.r.t the GPL. You can combine several different licenses, but the end result must be GPL licensed if it depends on GPL code.
I'm afraid you are wrong. I implore you to read section 5 of the GPL text. Particularly:
> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
> If a library is released under the GPL (not the LGPL),
> does that mean that any software which uses it has to
> be under the GPL or a GPL-compatible license?
>
> Yes, because the software as it is actually run
> includes the library.
For this argument, the relevant part is "or a GPL-compatible license". The BSD license is GPL-compatible, therefore I can license my work under the BSD license, and not under the GPL.
For section 5, consider the implications of your quote, especially the final sentence:
> This License [...] does not invalidate such permission
> if you have separately received it.
Section 5 means that anyone who obtains a copy of the work is automatically entitled to a license under the terms of the GPL. It does not prevent additional licenses from being offered, and does not replace additional licenses present on a combined work.
This isn't wholly true - the compatibility is only one way, which was back to my original point. "Compatibility" with the GPL is, according to the FAQ:
> In order to combine two programs (or substantial parts of them) into a larger work, you need to have permission to use both programs in this way. If the two programs' licenses permit this, they are compatible. If there is no way to satisfy both licenses at once, they are incompatible.
A BSD work which depends on a GPL work therefore, cannot be "Compatible" with the GPL because it fails to meet the criteria previously quoted: "You must license the entire work, as a whole, under this License ...".
What you are trying to claim is that you can write BSD code which is API compatible with readline, but if you are not distributing readline with it, it is not a dependent work. (ie, there are other works which are API compatible with readline). The condition here is that APIs cannot be copyrighted. In that case, you can distribute only your code which uses the API under your license of choice, but you cannot distribute the work as a whole under anything but the GPL.
The only point that matters about Readline is that if you link your BSD program to it, then when you distribute the binary, you also have to provide the source to your entire program. This makes it effectively GPL, because the BSD license has no such requirement. That is what the term "viral" refers to.
That's not the case: you cannot distribute the linked binary under any license other than GPL. You can only distribute the BSD code (or compiled, unlinked object code) which calls readline functions, only if you do not distribute readline with it.
If your code makes calls to readline functions, and you distribute readline with it, it is undoubtedly a "covered work" as described by the GPL, and is subject to section 5.c of the license which states that the whole work must be GPL if distributed
5.c says "This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it."
So you can distribute a BSD project with readline, and recipients are free to choose the BSD license for the BSD part and then distribute a closed source binary linked against a compatible readline replacement. The GPL does not invalidate the permissions granted by the BSD license.
The only goal of the FSF here is that the source code for anything distributed linked with readline be made available under the GPL. They don't stipulate that it only be made available under the GPL and not any other license.
The use of the term "viral" is generally considered inflammatory and unhelpful. An uninformed reader might be led to believe that the act of linking with GPL software can somehow "infect" proprietary software, causing it to be open source. This is incorrect. The GPL restricts distribution (i.e. the combined work may not be legally distributable to anyone), it doesn't "infect" things.
"Viral" was the only word which sprung to my mind when looking for the right word. And personally I think viral is a mostly neutral word (see viral marketing) which describes the situation. Would "share alike" be a better word perhaps?
But isn't LGPL is copyleft too, but not viral on linking. The only reason I used "viral" is because that is the clearest word I could think of, and still is.
