Skip to content

[R-pkg-devel] Relicense to GPL-3?

8 messages · Lenth, Russell V, Duncan Murdoch, Dirk Eddelbuettel +1 more

Original
Lenth, Russell V
# 
Dear all,

I received an email from a user telling me that another package that depends on my package is licensed GPL(>=3), whereas mine is licensed GPL-2; and that therefore, the other package is in violation of its GPL-3 license. This apparently causes an issue with the Debian packaging system, throwing that other package into the "unstable" category.

Moreover, the correspondent asks me if I would consider changing the license for my package. To what is not specified, but I guess it would be to GPL-3.

I don't really understand why this isn't the other developer's problem and not mine. But on the other hand, I don't want to cause problems for others. The licensing stuff is hard for me to understand - in large part because of low motivation to dig into it; I really would rather think about providing better code and features than all sorts of legal gobble-de-gook. Nonetheless, I guess this stuff is important to some people (e.g., Debian) so I suppose I had better get it right.

My decision to put GPL-2 in the first place was primarily expedience: it seemed like what people wanted. So is GPL-3 "better"? Do I risk anything by changing it? Do I risk anything by not changing it? How much does it matter, really?

Thanks

Russ

Russell V. Lenth? -? Professor Emeritus
Department of Statistics and Actuarial Science?? 
The University of Iowa ?-? Iowa City, IA 52242? USA?? 
Voice (319)335-0712 (Dept. office)? -? FAX (319)335-3017
Dirk Eddelbuettel
#
On 6 November 2016 at 02:28, Lenth, Russell V wrote:
| I received an email from a user telling me that another package that
| depends on my package is licensed GPL(>=3), whereas mine is licensed GPL-2;
| and that therefore, the other package is in violation of its GPL-3 license.  

That is apparently so, but most easily fixed by relicensing as "GPL (>= 2)"
which CRAN expands to "GPL-2 | GPL-3" as you can see on _many_ CRAN package pages.

For what it is worth, I was in the same situation with package 'digest' which
was created so long ago that its license was also "GPL-2" (whereas most my
other packages tend to be "GPL (>= 2)" ).  I was asked by a commercial
downstream redistributor to change the license, contacted all eighteen (18)
other copyright holders (as the package had a number of patches and pull
request) as one has to.  By the time the final 'ok' was given the original
was request was withdrawn after some refactoring.  I still went ahead and
changed this in the sources which will be reflected in the next upload. See
https://github.com/eddelbuettel/digest/issues/36 for the full thread.

| This apparently causes an issue with the Debian packaging system, throwing
| that other package into the "unstable" category. 

That is confused. "Unstable" is the normal staging area for new uploads, and
presumes nobody has an issue with the license. 

| Moreover, the correspondent asks me if I would consider changing the
| license for my package. To what is not specified, but I guess it would be
| to GPL-3.

I'd say "GPL (>= 2)"

| I don't really understand why this isn't the other developer's problem and not mine.

To the license lawyers, your package imposes a constraint by being GPL-2 not
allowing use with eg GPL-3.

Hope this helps, I am sure others will chip in too.

Dirk
Lenth, Russell V
# 
A correction and clarification...

It is MY package's GPL-2 license that is being violated by the other package -- not its GPL-3 license.

Let me lay it out with some generic names:
  * The 'foo' package specifies a GPL-2 license
  * The 'bar' package depends on 'foo', but specifies a GPL-3 license. That violates foo's GPL-2 license.

More details:
  * 'foo' provides a particular type of analysis embodied in a function named 'manchoo', 
     and provides methods for various classes.
  * 'bar' provides an S3 method for 'manchoo', via statements like this in its NAMESPACE file:
        importFrom(foo, manchoo)
        S3method(manchoo, bar)
  * The developer of 'foo' welcomes such expanded availability of 'manchoo' methods.

So there seem to be two ways to resolve this:
  1. The developer of 'foo' changes its license to GPL-3 (does that indeed resolve the license issue?)
      -- OR --
  2. The developer of 'bar' removes the dependency on 'foo', by not importing 'manchoo' or its
      S3method; instead, it simply exports the function 'manchoo.bar' and moves 'foo' to Suggests

Thanks for any suggestions

Russ

-----Original Message-----
From: Lenth, Russell V 
Sent: Saturday, November 5, 2016 9:28 PM
To: 'r-package-devel at r-project.org' <r-package-devel at r-project.org>
Subject: Relicense to GPL-3?

Dear all,

I received an email from a user telling me that another package that depends on my package is licensed GPL(>=3), whereas mine is licensed GPL-2; and that therefore, the other package is in violation of its GPL-3 license. This apparently causes an issue with the Debian packaging system, throwing that other package into the "unstable" category.

Moreover, the correspondent asks me if I would consider changing the license for my package. To what is not specified, but I guess it would be to GPL-3.

I don't really understand why this isn't the other developer's problem and not mine. But on the other hand, I don't want to cause problems for others. The licensing stuff is hard for me to understand - in large part because of low motivation to dig into it; I really would rather think about providing better code and features than all sorts of legal gobble-de-gook. Nonetheless, I guess this stuff is important to some people (e.g., Debian) so I suppose I had better get it right.

My decision to put GPL-2 in the first place was primarily expedience: it seemed like what people wanted. So is GPL-3 "better"? Do I risk anything by changing it? Do I risk anything by not changing it? How much does it matter, really?

Thanks

Russ

Russell V. Lenth? -? Professor Emeritus
Department of Statistics and Actuarial Science The University of Iowa ?-? Iowa City, IA 52242? USA Voice (319)335-0712 (Dept. office)? -? FAX (319)335-3017
Dirk Eddelbuettel
#
On 6 November 2016 at 09:11, Lenth, Russell V wrote:
| A correction and clarification...
| 
| It is MY package's GPL-2 license that is being violated by the other package -- not its GPL-3 license.

No, let's stop here.  I don't think that is legally (or conceptually !!)
possible. Your code, your repo, ... are all self-contained and "fine".  But,
and the big but, is that GPL-3 stipulates no mixing with GPL-2.
 
| Let me lay it out with some generic names:
|   * The 'foo' package specifies a GPL-2 license
|   * The 'bar' package depends on 'foo', but specifies a GPL-3 license. That violates foo's GPL-2 license.

"violate" is IMHO not the correct terms.  More like "prohibits use" per terms in GPL-3.
See eg

   https://www.gnu.org/licenses/gpl-faq.en.html

   https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html


| More details:
|   * 'foo' provides a particular type of analysis embodied in a function named 'manchoo', 
|      and provides methods for various classes.
|   * 'bar' provides an S3 method for 'manchoo', via statements like this in its NAMESPACE file:
|         importFrom(foo, manchoo)
|         S3method(manchoo, bar)
|   * The developer of 'foo' welcomes such expanded availability of 'manchoo' methods.
| 
| So there seem to be two ways to resolve this:
|   1. The developer of 'foo' changes its license to GPL-3 (does that indeed resolve the license issue?)

Yes as said yesterday. "GPL (>= 2)" aka "GPL-2 | GPL-3" does.  You can of
course use _only_ GPL-3 (but there are a lot of people around R who keep
GPL-2, including R itself (!!) -- see 'license()' as the startup prompt
suggests and numerous packages written by R Core and others).

|       -- OR --
|   2. The developer of 'bar' removes the dependency on 'foo', by not importing 'manchoo' or its
|       S3method; instead, it simply exports the function 'manchoo.bar' and moves 'foo' to Suggests

Maybe -- but moving to Suggests, as easy as it seems, is probably not a real
solution as you still have co-use. Spirit of the law, letter of the law. In
any event that applies only to 'bar', and you are 'foo'.

Dirk
 
| Thanks for any suggestions
| 
| Russ
| 
| -----Original Message-----
| From: Lenth, Russell V 
| Sent: Saturday, November 5, 2016 9:28 PM
| To: 'r-package-devel at r-project.org' <r-package-devel at r-project.org>
| Subject: Relicense to GPL-3?
| 
| Dear all,
| 
| I received an email from a user telling me that another package that depends on my package is licensed GPL(>=3), whereas mine is licensed GPL-2; and that therefore, the other package is in violation of its GPL-3 license. This apparently causes an issue with the Debian packaging system, throwing that other package into the "unstable" category.
| 
| Moreover, the correspondent asks me if I would consider changing the license for my package. To what is not specified, but I guess it would be to GPL-3.
| 
| I don't really understand why this isn't the other developer's problem and not mine. But on the other hand, I don't want to cause problems for others. The licensing stuff is hard for me to understand - in large part because of low motivation to dig into it; I really would rather think about providing better code and features than all sorts of legal gobble-de-gook. Nonetheless, I guess this stuff is important to some people (e.g., Debian) so I suppose I had better get it right.
| 
| My decision to put GPL-2 in the first place was primarily expedience: it seemed like what people wanted. So is GPL-3 "better"? Do I risk anything by changing it? Do I risk anything by not changing it? How much does it matter, really?
| 
| Thanks
| 
| Russ
| 
| Russell V. Lenth? -? Professor Emeritus
| Department of Statistics and Actuarial Science The University of Iowa ?-? Iowa City, IA 52242? USA Voice (319)335-0712 (Dept. office)? -? FAX (319)335-3017
| 
| ______________________________________________
| R-package-devel at r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel
Duncan Murdoch
#
On 06/11/2016 4:11 AM, Lenth, Russell V wrote:
And a third way is for the developer of 'bar' to allow it to be dual 
licensed as GPL 2 or 3, or something else more permissive than GPL 3. 
They may not be able to do that if they are not the sole copyright 
holder, just as you won't be able to do 1 without the permission of all 
other copyright holders.

Duncan Murdoch
Lenth, Russell V
# 
Permission of "all other copyright holders" as in developers of all packages that depend on 'foo'?

Russ

Sent from my iPhone
Dirk Eddelbuettel
#
On 6 November 2016 at 16:53, Lenth, Russell V wrote:
| Permission of "all other copyright holders" as in developers of all packages that depend on 'foo'?

Please do have a look at the two FAQs I referenced before:

   https://www.gnu.org/licenses/gpl-faq.en.html

   https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html

In particular this last question of yours is addressed in

   https://www.gnu.org/licenses/gpl-faq.html#HeardOtherLicense

Dependent packages are of cause NOT the copyright holders. Rather, the
authors of a package (ie you, and whoever worked with you) are.

Dirk
Henrik Bengtsson
# 
What's already been said is good advice.  At first, it may be a bit
tricky to under copyright and licenses.  When I started out, I for the
longest held back on releasing software / packages because I somehow
thought I basically had to make a final decision on the license at
that moment and that the license was stuck forever.  I was wrong.  It
will stick forever, but only per release.

Here is how *I* think of copyright and software licenses these days:

* The copyright holder of a piece of software is the one who can
decide on what license he or she would like to distribute that
software.

* If there are multiple copyright holders of your software, then all
of you need to agree on the license.

* If someone contributed a non-trivial part of code to your software,
then that person holds copyright to that piece of code.  From this
point in time, your software has two copyright holders.

* For you to remain the sole copyright holder, you need to make an
explicit agreement with the other person that s/he transfer the
copyright to you.  Some maintainers (private person and / or
companies) do this in order to keep full control of the decision on
software licenses (for monetary and / or practical purposes).

* When releasing a software under a specific license, then you give
the users the rights specified in that license.

* It is not possible to revoke licenses retroactively because then you
would break the rights you have already given the users.  If version
1.0 was released with license A, you cannot go back a say it now
should be license B instead.

* At any time, the copyright holder may choose to use a different
license of a _future_ version of the software.  Even if version 1.0
was released with license A, version 1.1 can be with license B (and
license A can be dropped).

* Software can be release with multiple licenses.  You can choose to
release version 1.1 under license A and license B.  Then it is up to
the user to choose which one s/he wish to follow / agree to.  Moving
from GPL 2 to GPL (>= 2) == GPL 2 | GPL 3 would be such an example.

* If you're not the sole copyright holder, and you cannot agree with
the others or you fail to get in touch with the others (e.g. person
passed away), then the only way for you to become the sole copyright
holder is to remove the parts of the code that you don't have
copyright to.  When the remaining code is truly yours, i.e. you are
the sole copyright holder, then you have all the rights to choose
license going forward.

So, in your case, it is only people who have contributed to your piece
of software ("foo") that can make copyright claims to it.  Any
software that depends on your software is completely irrelevant to
this.  If you're the only one who contributed to your package, then
you can choose whatever licenses you want going forward (=next
version).  Also, the license of your software "foo" sets the rules for
any software that depends on it, and not the other way around (unless
you have a circular dependency, which is extremely rare).

Hope this helps

Henrik
On Sun, Nov 6, 2016 at 9:10 AM, Dirk Eddelbuettel <edd at debian.org> wrote: