[R-pkg-devel] Licensing of an R package
Martyn Plummer
plummerm at iarc.fr
Tue Jan 23 18:50:25 CET 2018
On Tue, 2018-01-23 at 08:28 +0000, Chris Brien wrote:
> Hi Martyn,
>
> Thanks for your very clear explanation. I now understand the point
> that Duncan was making.
>
> However, just to clarify point 4).
>
> I understand that a GPL license means that I cannot distribute a
> binary that combines both asreml and asremlPlus, which asreml would
> not allow anyway.
>
> However, under a GPL license, can I distribute a binary of asremlPlus
> on its own as long as the source for asremlPlus is available, which
> it is from the same web site as the binary and from Github?
Nobody knows.
The GPL is based on a creative application of copyright law. Many
aspects of this application remain untested in court and thus remain
controversial. I will give you the two extremes of opinion.
In the red corner, the FSF claims that any form of linking creates a
derivative work of both your package and the asreml library. With this
interpretation, a dynamically linked package can only be distributed if
the terms of the GPL apply to the whole work, i.e. the terms extend to
the asreml library. Since these terms cannot be satisfied, the binary
package cannot be distributed.
In the blue corner, Lawrence Rosen of the law firm Rosenlaw &
Einschlag, denies that linking creates a derived work, e.g.
http://www.linuxjournal.com/article/6366
The link is from 2003 but his position has not changed.
There is no algorithmic answer to this question. The answer depends on
human factors, the details of each specific case, and the
interpretation of existing copyright law in a given legal domain.
Even if you take the restrictive interpretation of the FSF, then they
don't have a problem with the distribution of dynamically linked
binaries if you put an explicit linking exception in your license,
which is why I pointed you to this in my previous email.
> I would have thought so because this is exactly what CRAN does in
> distributing Windows binaries of packages.
I would say that it is the responsibility of the package maintainer to
verify that CRAN is legally entitled to distribute Windows and MacOS
binaries. In any case, the vast majority of CRAN packages are not
problematic as they are licenced under GPL or a GPL-compatible license
without linkage to a non-free library.
Martyn
> Cheers,
>
> Chris
>
>
> -----Original Message-----
> From: Martyn Plummer [mailto:plummerm at iarc.fr]
> Sent: Tuesday, 23 January 2018 4:26 AM
> To: Chris Brien; edd at debian.org; murdoch.duncan at gmail.com
> Cc: r-package-devel at r-project.org
> Subject: Re: [R-pkg-devel] Licensing of an R package
>
> On Fri, 2018-01-19 at 20:28 +0000, Chris Brien wrote:
> > Hi Dirk & Duncan,
> >
> > I too like GPL and I had thought that the situation was as Duncan
> > outlines. Consequently, I had licensed `foo' as GPL >= 2.
> >
> > However, because I have been unable to find a discussion of my
> > case,
> > in spite of the extensive material about GNU licensing on the web,
> > I
> > have had difficulty deciding whether or not I was mistaken in
> > applying
> > a GPL license.
> >
> > It does seem that the open source philosophy is that all software
> > should be open source and GPL licensing is to promote this, which
> > it
> > does by restricting how you can apply GPL licensing. It would be
> > consistent with this philosophy that GPL does not allow one to
> > `link'
> > with a commercial package. However, somewhat reluctantly it seems,
> > an
> > exception is made under GPL licensing for linking to commercial
> > `system libraries' because it is necessary to allow this for
> > things
> > like R etc.
> >
> > If Bloomberg API is a system library then it also qualifies as an
> > exception. (I have seen the license file and note that you are able
> > to
> > distribute the API.)
> >
> > In my case `bar' is asreml and I don't believe that it qualifies as
> > a
> > system library. However, I can use it to build my library
> > (asremlPlus) and the maintainers and license owners know that I do
> > this. As a result I am still unsure that GPL can be applied in my
> > case.
> >
> > Ugh! It is a minefield.
>
> It is not as bad as you think.
>
> The FSF admits that sometimes you need to link to a non-free library.
> They just ask you not to do it if a free replacement is available:
> https://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs
>
> As Duncan points out, your choice of license does not affect what you
> can do with it. As copyright holder, you can do what you like (modulo
> restrictions placed on you by the asreml license). The question is
> what rights you want to confer to other people.
>
> GPL is based on copyright law, so the rights and obligations it
> confers come into effect only when the software is distributed (or
> "conveyed"
> in the updated language of GPL 3) to a third party. These rights and
> obligations also apply to any derived works, which means both
> modified source code and binary packages created from the source
> code.
>
> With a GPL license, anyone has the right to do the following with
> your asremlPlus package:
>
> 1) Distribute the source package.
>
> 2) Distribute modified versions of the source package under the same
> GPL conditions.
>
> 3) Install and use the asremlPlus package linked to the asreml
> library.
>
>
> What they cannot do with a standard GPL license is:
>
> 4) Distribute a binary package of asremlPlus linked to asreml
>
> Distributing a binary package of asremlPlus under the GPL comes with
> the obligation to provide the source code to asreml which, of course,
> cannot be done.
>
> It should also be noted that the license terms of asreml itself may
> prevent distribution of a binary package of asremlPlus.
>
> However, if there are no such restrictions then nothing prevents you
> as sole copyright holder from creating your own (dynamically linked)
> binaries and distributing them to your users.
>
> If you do want to give your users rights to distribute binary
> packages then you may add an explicit exception to the GPL to your
> software license. The FSF provides a template to add this exception
> to your
> license:
>
> https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs
>
> Martyn
>
>
> > Thanks muchly for your input.
> >
> > Cheers,
> >
> > Chris
> >
> >
> > -----Original Message-----
> > From: Dirk Eddelbuettel [mailto:dirk.eddelbuettel at gmail.com] On
> > Behalf
> > Of Dirk Eddelbuettel
> > Sent: Saturday, 20 January 2018 2:30 AM
> > To: Duncan Murdoch
> > Cc: Chris Brien; r-package-devel at r-project.org
> > Subject: Re: [R-pkg-devel] Licensing of an R package
> >
> >
> > Chris,
> >
> > I am with Duncan here.
> >
> > You can license _your_ package any way you want and prefer. I like
> > GPL.
> >
> > You seem to imply that the GPL license prohibits linking against
> > commercial code. If that were the case we'd never have R, Emacs,
> > gcc/g++, ... on Windows or macOS or any of the now-essentially-
> > extinct commercial Unux flavours. We alway link against their
> > system
> > libraries too.
> >
> > Also look eg at our Rblpapi package. The Bloomberg API is not
> > open
> > source, but they allow distribution of the (pre-built) library and
> > headers. Our package, building on top, is GPL-2+. No
> > issues. (This
> > example is extra fun because CRAN can't distribute the API, but
> > can
> > use it for building our package. Using the package requires having
> > a
> > commercial and expensive Bloomberg terminal license and
> > installation.)
> >
> > Dirk
> >
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> >
> > ______________________________________________
> > R-package-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
More information about the R-package-devel
mailing list