[R-pkg-devel] Licensing of an R package

Chris Brien Chris.Brien at unisa.edu.au
Tue Jan 23 09:28:57 CET 2018

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? I would have thought so because this is exactly what CRAN does in distributing Windows binaries of packages.



-----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:

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



> 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