licensing stuff: GPL "version 2" vs. "2 or later"

[jcfp]

Just noticed that in COPYRIGHT.txt and at the top of LICENSE.txt it is claimed that sabnzbd+ is under GPL version 2 (only), while all the headers in the *.py files say "v2 or later". The latter (v2 or later) seems to be intended, and is imho strongly preferred or even necessary for reasons of compatibility with various other licenses (templates!).

[shypike]

I think the source code is in error.
Given that GPL3 is quite controversial, I doubt if most authors actually mean claims about "GPL2 or later".
We'll take up a position and clear up this problem in a later release, it's too late now for 0.4.0.

Thanks as usual for your licensing scrutiny.

[jcfp]

With 0.4.2 sabnzbd's license has changed to GPL "v2 only" from "v2 or any later version", forcing me to look into this stuff once more.

Unfortunately this license change seems to cause a conflict with interfaces/smpl/templates/static/excanvas/excanvas.js which is subject to the Apache license, v2. That license is apparently incompatible with GPL v2 but okay with GPL v3 (and thus with v2 or later); see the statements here (FSF) and here (ASF). Now I'm not a legal expert, but a quick google search reveals that the general consensus is that combining these licenses is not possible, i.e. doing so makes a work undistributable.

[shypike]

excanvas.js is used as-is, we don't embed it in our sources.
I don't understand your remark about "makes a work undistributable".
If so, all Linux distributions would be undistributable, since the Linux kernal uses GLP2
and Apache server uses Apache.
So, why can this combination be distributed?

[jcfp]

Reading the GPL, version 2, section 2 you find the following:

These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.  But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.

take note of: "distribute the [same] sections as part of a whole which is a work based on the Program" - the templates (incl. excanvas.js) as included in the sabnzbd+ releases - and "the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."; i.e. every other license used in the 'work' must give at least the same amount of freedom in order for the license to "exercise the right to control the distribution of derivative or collective works";

and that's where the problem is, I think, since Apache v2 imposes some additional restrictions (even though these actually do make some sense, and GPL v3 was designed to be compatible with this or even have similar terms). Similarly, section 6 may be of relevance. But anyway, I'm not a solicitor, when the FSF claims it's not compatible and a google search agrees that's good enough for me. I can't give legal advise, just point out the (potential) issues.

As to why you can still distribute Linux distributions with the Apache web server, that's because these are different 'works' (from GPL v2, end of section 2):

In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

Unfortunately, a release tarball probably doesn't qualify as "a volume of a storage or distribution medium" such as a cd-rom.

[shypike]

"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.

In my opinion, the SMPL skin is not a "Derivative Work" of excanvas.js, since
we have it in its original separate file, so the term "remain separable from" is valid.
There are no "editorial revisions, annotations, elaborations, or other modifications" at all.

The SABnzbd distribution is a collection of FOSS packages each with its own
licensing, all carefully documented (thanks to your efforts).

I think you are taking licensing concerns too far in this case.

BTW, SMPL comes with its own CC3.0 license.
Given that you have chosen to create separate packages for the skins, you need only
to look at compatibility between CC3.0 and Apache.
So, your idea of breaking the package up might turn out to be a good idea after all.

[jcfp]

In my opinion, the SMPL skin is not a "Derivative Work" of excanvas.js, since
we have it in its original separate file, so the term "remain separable from" is valid.
There are no "editorial revisions, annotations, elaborations, or other modifications" at all.

I agree, and never claimed otherwise. But the license you are quoting here is the Apache license 2.0, whereas the problem lies on the side of the GPL. For example in GPL v2 section 2(b):

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

Now, "work that you distribute or publish" (meaning the sabnzbd+ release tarball), containing the "Program or any part thereof" (that's the GPL v2-only licensed sabnzbd python files) must be licensed as a whole [...] under the terms of this License (=GPL v2). You can see how this is very different from the Apache License which applies itself only to "its own files", and how this includes all files in the release tarball, incl excanvas.

Next, sections 6 and 7 come into play:

6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
[...]

7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. [...]

A license such as the Apache v2.0 insisting on adding, as the FSF calls it, "certain patent termination and indemnification provisions", breaches the requirement as set in section 6 of not imposing additional restrictions, thus invoking section 7 and forbidding distribution whenever anyone wants to use their rights under section 2.

The SABnzbd distribution is a collection of FOSS packages each with its own
licensing, all carefully documented (thanks to your efforts).

That's in sharp contrast to what you said earlier in the discussion following the include statements stuff. And even then, in 2(b) merely "containing" GPL v2 licensed stuff suffices. I think that chair throwing microsoft guy called it "a cancer" or something along these lines .

BTW, SMPL comes with its own CC3.0 license.
Given that you have chosen to create separate packages for the skins, you need only
to look at compatibility between CC3.0 and Apache.
So, your idea of breaking the package up might turn out to be a good idea after all.

While breaking the release up might at least theorethically be an option for the project, it isn't going saving my rear end. Whilst the binary packages are indeed split, the source package is also distributed. Included in that comes the original release as-is + packaging and patches...

Just curious, what's the big issue with "v2 or later" prompting this change in the first place?

[shypike]

Just curious, what's the big issue with "v2 or later" prompting this change in the first place?

You pointed out an inconsistency, I corrected it.

Each time you redistribute the Program

All the parts of the SABnzbd distribution that have simply been included (excanvas.js, cherrypy2, etc) are NOT PART OF THE PROGRAM.
The company I work for has very strict rules about including Open Source in their products.
In the past I have had no problems at work in getting permission from the Intellectual Property department
to use GPL2 stuff, as long as it was used as-is. So as in using EXE files, DLLs and unmodified Java web stuff.
The fact that it was embedded in the product (but still clearly separable) was no problem.
Clipping code parts from a GPL2 packages is obviously forbidden by our IP guys.

I would have to look more carefully to the GPL3 license, maybe it's not so bad.
On the other hand, isn't it strange (or even possible) to stick a new licence on software?
The fact that any version before 0.4.2 is also covered by GPL2, doesn't that imply that it can never be decoupled from GPL2?
Saying "GPL2 or later" is a bit odd since GPL2 and GPL3 are not compatible.

[jcfp]

You pointed out an inconsistency, I corrected it.

Good to know it's not some principal issues with the GPL v3.

Each time you redistribute the Program

All the parts of the SABnzbd distribution that have simply been included (excanvas.js, cherrypy2, etc) are NOT PART OF THE PROGRAM.

I know, and I agree. But there is a fairly strong case to say the "Program" is released as part of a single work, which would be a cause of trouble for anybody attempting to make changes downstream. And depending on whether the current developers actually own the copyright to every line of code in the Program, or that you're using your rights under the GPL to modify a previously existing open source project, it could also affect the sabnzbd+ team (in the latter case, every release would be a modified versions under the terms of...).

The company I work for has very strict rules about including Open Source in their products.
In the past I have had no problems at work in getting permission from the Intellectual Property department
to use GPL2 stuff, as long as it was used as-is. So as in using EXE files, DLLs and unmodified Java web stuff.
The fact that it was embedded in the product (but still clearly separable) was no problem.
Clipping code parts from a GPL2 packages is obviously forbidden by our IP guys.

Not modifying may be key here. The problematic stuff quoted above all comes from the terms in section 2 dealing with distributing modified copies; those are superimposed on section 1 that only deals with verbatim copies.

I would have to look more carefully to the GPL3 license, maybe it's not so bad.
On the other hand, isn't it strange (or even possible) to stick a new licence on software?
The fact that any version before 0.4.2 is also covered by GPL2, doesn't that imply that it can never be decoupled from GPL2?
Saying "GPL2 or later" is a bit odd since GPL2 and GPL3 are not compatible.

The program had always been "GPL v2 or later" before, until to my surprise in the 0.4.0-RC's the two little notices as described in the start post appeared and in 0.4.2 is was actually changed over to version-2-only.

Sticking on a new license shouldn't be a problem: if you are the copyright holder you can change the license as you like, if you weren't you couldn't have changed the license from v2-or-later to v2-only in the first place unless with permission from the actual copyright holder(s); a change back would thus require similar permission once again.

Compatibility between GPL 2 and 3 is not an issue as long as there's nothing in the mix that is under one specific version only; with "v2 or any later version" there's obviously no need to fullfill the requirements of both/all version. I would still prefer to see things changed back to "v2-or-later", since it gives maximum flexibilty. And of course the compatibilty issue with the Apache license would be history.

[shypike]

OK, you convinced me.
I will restore the original copyright statement in all SABnzbd sources.

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.

The at your option clause will likely solve all problems,
since one can assume that GPL3 is OK too.
For clarity I'll add the GPL3 full licence text too.

Does this settle your issue?

[jcfp]

The at your option clause will likely solve all problems,
since one can assume that GPL3 is OK too.
For clarity I'll add the GPL3 full licence text too.

Does this settle your issue?

Certainly does, thanks.

"You" or "Your" (like in 'at your option') in the GPL simply refers to the licensee, so indeed the licensee can choose any GPL version >=2 and fullfill the requirements of that version to be in compliance. Inclusion of the full text of version 3 doesn't hurt a bit but is probably not required either since no one can expect a licensor (i.e., the sabnzbd+ team) to include the full text of "any later version" in software released today.