Implications of a Dependency on a GPLed Package

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Implications of a Dependency on a GPLed Package

Christian Sigg
I intend to submit a newly developed package to CRAN (to be licensed under the GPL), which prompted me to re-read the GPL FAQ. The following section caught my attention:

> If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
>
>     When the interpreter just interprets a language, the answer is no.
>
> (...)
>
>     Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
>
>     A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.


(from http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL)

My understanding of this section is the following:

1. If I develop and distribute an R package which depends on another package that is released under the GPL, I have to release my package in a GPL-compatible way.

2. Given that R itself is distributed as a set of base packages (released under the GPL), and a distinction between making use of the R "language" and making use of functionality provided by the base packages seem impossible, the above section could also imply that it is not possible at all to release R code under a license that is not GPL-compatible.

Yet, there exist several packages on CRAN which seem to violate the GPL, according to the FSF interpretation quoted above. For example, the SDDA package prohibits commercial use of the package (a restriction that is incompatible with the GPL), but states an explicit dependency on the MASS package (which is not a "base" package and released under the GPL). Furthermore, several packages also prohibit commercial use, but list an explicit dependency on the methods package (e.g. gpclib, isa2, optmatch).

As all of these packages are on CRAN, and at least one author is also a core R contributor (Duncan Murdoch for gpclib), I assume that the CRAN maintainers and/or the R Foundation do not consider these packages to violate the GPL, and therefore also do not agree with the FSF interpretation of the GPL quoted above (provided that they share my understanding of the quote). On the other hand, R is an official part of the FSF GNU project, so I would expect the R Foundation to agree with GNU policy in general.

I have not found a statement by the CRAN maintainers and/or the R Foundation that addresses this issue (e.g. it is neither addressed in doc/COPYRIGHTS nor the R FAQ nor the CRAN repository policy). I have also searched the archives and there are at least three references to the above quoted section of the GPL FAQ on R-devel:

https://stat.ethz.ch/pipermail/r-devel/2011-August/061907.html
https://stat.ethz.ch/pipermail/r-devel/2009-April/053159.html
https://stat.ethz.ch/pipermail/r-devel/2006-September/042715.html

and one reference on R-help:

https://stat.ethz.ch/pipermail/r-help/2008-November/179846.html

While several list members provide their personal opinion on the matter, I could not find any statement that could be considered the agreed upon position of the CRAN maintainers and/or the R Foundation. The closest I could find are several replies by Duncan Murdoch where he writes that a package author is free in his choice of license if no actual copying of GPLed code takes place

https://stat.ethz.ch/pipermail/r-devel/2006-September/042716.html
https://stat.ethz.ch/pipermail/r-help/2010-June/240945.html

and where he takes a critical stand against the quoted FSF interpretation of the GPL:

> By your line of reasoning (which I
> don't agree with), if you write an R script, making use of features of R
> that are not present in other S dialects, then the only way to make it
> work would be to use R.  So if you want to distribute it, you would need
> to GPL it.  So lots of the R packages on CRAN that do not have GPL
> compatible licenses would be in violation of the GPL, and since CRAN is
> distributing them, CRAN is in violation of the GPL.  That's nonsense.

(from https://stat.ethz.ch/pipermail/r-help/2008-November/179908.html)

and an email by Prof. Leisch

https://stat.ethz.ch/pipermail/r-devel/2009-April/053141.html

where he mentions ongoing discussions in R Core and the R Foundation. However, these discussions might have only considered Revolution Analytic's ParallelR (the main topic of that thread), and I could not find a follow-up email where the result of that discussion was published.

Did the CRAN maintainers and the R Foundation publish an agreed upon position on the FSF interpretation of the GPL quoted above, and I simply missed it? If yes, could it be added to the R FAQ and/or the CRAN repository policy, such that it is easier to find? If not, may I kindly ask them to explain their position?

Note that I am not asking for legal advice, nor am I advocating for a specific change of the current practices of the R project.

Thank you,
Christian

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Duncan Murdoch-2
On 13-01-24 12:22 PM, Christian Sigg wrote:

> I intend to submit a newly developed package to CRAN (to be licensed under the GPL), which prompted me to re-read the GPL FAQ. The following section caught my attention:
>
>> If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
>>
>>      When the interpreter just interprets a language, the answer is no.
>>
>> (...)
>>
>>      Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
>>
>>      A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
>
>
> (from http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL)
>
> My understanding of this section is the following:
>
> 1. If I develop and distribute an R package which depends on another package that is released under the GPL, I have to release my package in a GPL-compatible way.
>
> 2. Given that R itself is distributed as a set of base packages (released under the GPL), and a distinction between making use of the R "language" and making use of functionality provided by the base packages seem impossible, the above section could also imply that it is not possible at all to release R code under a license that is not GPL-compatible.
>
> Yet, there exist several packages on CRAN which seem to violate the GPL, according to the FSF interpretation quoted above. For example, the SDDA package prohibits commercial use of the package (a restriction that is incompatible with the GPL), but states an explicit dependency on the MASS package (which is not a "base" package and released under the GPL). Furthermore, several packages also prohibit commercial use, but list an explicit dependency on the methods package (e.g. gpclib, isa2, optmatch).
>
> As all of these packages are on CRAN, and at least one author is also a core R contributor (Duncan Murdoch for gpclib), I assume that the CRAN maintainers and/or the R Foundation do not consider these packages to violate the GPL, and therefore also do not agree with the FSF interpretation of the GPL quoted above (provided that they share my understanding of the quote). On the other hand, R is an official part of the FSF GNU project, so I would expect the R Foundation to agree with GNU policy in general.
>
> I have not found a statement by the CRAN maintainers and/or the R Foundation that addresses this issue (e.g. it is neither addressed in doc/COPYRIGHTS nor the R FAQ nor the CRAN repository policy). I have also searched the archives and there are at least three references to the above quoted section of the GPL FAQ on R-devel:
>
> https://stat.ethz.ch/pipermail/r-devel/2011-August/061907.html
> https://stat.ethz.ch/pipermail/r-devel/2009-April/053159.html
> https://stat.ethz.ch/pipermail/r-devel/2006-September/042715.html
>
> and one reference on R-help:
>
> https://stat.ethz.ch/pipermail/r-help/2008-November/179846.html
>
> While several list members provide their personal opinion on the matter, I could not find any statement that could be considered the agreed upon position of the CRAN maintainers and/or the R Foundation. The closest I could find are several replies by Duncan Murdoch where he writes that a package author is free in his choice of license if no actual copying of GPLed code takes place
>
> https://stat.ethz.ch/pipermail/r-devel/2006-September/042716.html
> https://stat.ethz.ch/pipermail/r-help/2010-June/240945.html
>
> and where he takes a critical stand against the quoted FSF interpretation of the GPL:

I don't think my point contradicts the FSF interpretation.  I think they
were talking about using GPL modules in a program you distribute, with
the implication that you are distributing the modules along with your
program.  However, I could be wrong.  If I am wrong and the FSF agrees
with your strong interpretation, then I do think they are wrong.

If you write something that incorporates nothing of mine, I can't see
how my copyright could influence you at all.  If a user needs my code to
make yours useful, I don't see how any of that changes.  The GPL is
quite clear that it doesn't restrict people in how they use the code, it
just gives them rights to copy it (possibly in a modified form, if they
follow the rules).

>
>> By your line of reasoning (which I
>> don't agree with), if you write an R script, making use of features of R
>> that are not present in other S dialects, then the only way to make it
>> work would be to use R.  So if you want to distribute it, you would need
>> to GPL it.  So lots of the R packages on CRAN that do not have GPL
>> compatible licenses would be in violation of the GPL, and since CRAN is
>> distributing them, CRAN is in violation of the GPL.  That's nonsense.
>
> (from https://stat.ethz.ch/pipermail/r-help/2008-November/179908.html)
>
> and an email by Prof. Leisch
>
> https://stat.ethz.ch/pipermail/r-devel/2009-April/053141.html
>
> where he mentions ongoing discussions in R Core and the R Foundation. However, these discussions might have only considered Revolution Analytic's ParallelR (the main topic of that thread), and I could not find a follow-up email where the result of that discussion was published.
>
> Did the CRAN maintainers and the R Foundation publish an agreed upon position on the FSF interpretation of the GPL quoted above, and I simply missed it? If yes, could it be added to the R FAQ and/or the CRAN repository policy, such that it is easier to find? If not, may I kindly ask them to explain their position?

No, CRAN and the R Foundation have not published that.  I don't think
either group will publish a position.  You can guess the current beliefs
of the folks at CRAN by seeing what they do (under the reasonable
assumption that they do not think they are doing anything illegal), but
those beliefs might change.  The R Foundation does almost nothing, so
it's a little more inscrutable.

> Note that I am not asking for legal advice,

You should be.  If you really want to know whether they are using your
code illegally, or about whether your proposed use of other peoples code
is legal, you really should get legal advice.

 > nor am I advocating for a specific change of the current practices of
the R project.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Marc Schwartz-3

On Jan 25, 2013, at 6:32 AM, Duncan Murdoch <[hidden email]> wrote:

> On 13-01-24 12:22 PM, Christian Sigg wrote:
>> I intend to submit a newly developed package to CRAN (to be licensed under the GPL), which prompted me to re-read the GPL FAQ. The following section caught my attention:
>>
>>> If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
>>>
>>>     When the interpreter just interprets a language, the answer is no.
>>>
>>> (...)
>>>
>>>     Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
>>>
>>>     A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
>>
>>
>> (from http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL)
>>
>> My understanding of this section is the following:
>>
>> 1. If I develop and distribute an R package which depends on another package that is released under the GPL, I have to release my package in a GPL-compatible way.
>>
>> 2. Given that R itself is distributed as a set of base packages (released under the GPL), and a distinction between making use of the R "language" and making use of functionality provided by the base packages seem impossible, the above section could also imply that it is not possible at all to release R code under a license that is not GPL-compatible.
>>
>> Yet, there exist several packages on CRAN which seem to violate the GPL, according to the FSF interpretation quoted above. For example, the SDDA package prohibits commercial use of the package (a restriction that is incompatible with the GPL), but states an explicit dependency on the MASS package (which is not a "base" package and released under the GPL). Furthermore, several packages also prohibit commercial use, but list an explicit dependency on the methods package (e.g. gpclib, isa2, optmatch).
>>
>> As all of these packages are on CRAN, and at least one author is also a core R contributor (Duncan Murdoch for gpclib), I assume that the CRAN maintainers and/or the R Foundation do not consider these packages to violate the GPL, and therefore also do not agree with the FSF interpretation of the GPL quoted above (provided that they share my understanding of the quote). On the other hand, R is an official part of the FSF GNU project, so I would expect the R Foundation to agree with GNU policy in general.
>>
>> I have not found a statement by the CRAN maintainers and/or the R Foundation that addresses this issue (e.g. it is neither addressed in doc/COPYRIGHTS nor the R FAQ nor the CRAN repository policy). I have also searched the archives and there are at least three references to the above quoted section of the GPL FAQ on R-devel:
>>
>> https://stat.ethz.ch/pipermail/r-devel/2011-August/061907.html
>> https://stat.ethz.ch/pipermail/r-devel/2009-April/053159.html
>> https://stat.ethz.ch/pipermail/r-devel/2006-September/042715.html
>>
>> and one reference on R-help:
>>
>> https://stat.ethz.ch/pipermail/r-help/2008-November/179846.html
>>
>> While several list members provide their personal opinion on the matter, I could not find any statement that could be considered the agreed upon position of the CRAN maintainers and/or the R Foundation. The closest I could find are several replies by Duncan Murdoch where he writes that a package author is free in his choice of license if no actual copying of GPLed code takes place
>>
>> https://stat.ethz.ch/pipermail/r-devel/2006-September/042716.html
>> https://stat.ethz.ch/pipermail/r-help/2010-June/240945.html
>>
>> and where he takes a critical stand against the quoted FSF interpretation of the GPL:
>
> I don't think my point contradicts the FSF interpretation.  I think they were talking about using GPL modules in a program you distribute, with the implication that you are distributing the modules along with your program.  However, I could be wrong.  If I am wrong and the FSF agrees with your strong interpretation, then I do think they are wrong.
>
> If you write something that incorporates nothing of mine, I can't see how my copyright could influence you at all.  If a user needs my code to make yours useful, I don't see how any of that changes.  The GPL is quite clear that it doesn't restrict people in how they use the code, it just gives them rights to copy it (possibly in a modified form, if they follow the rules).
>
>>
>>> By your line of reasoning (which I
>>> don't agree with), if you write an R script, making use of features of R
>>> that are not present in other S dialects, then the only way to make it
>>> work would be to use R.  So if you want to distribute it, you would need
>>> to GPL it.  So lots of the R packages on CRAN that do not have GPL
>>> compatible licenses would be in violation of the GPL, and since CRAN is
>>> distributing them, CRAN is in violation of the GPL.  That's nonsense.
>>
>> (from https://stat.ethz.ch/pipermail/r-help/2008-November/179908.html)
>>
>> and an email by Prof. Leisch
>>
>> https://stat.ethz.ch/pipermail/r-devel/2009-April/053141.html
>>
>> where he mentions ongoing discussions in R Core and the R Foundation. However, these discussions might have only considered Revolution Analytic's ParallelR (the main topic of that thread), and I could not find a follow-up email where the result of that discussion was published.
>>
>> Did the CRAN maintainers and the R Foundation publish an agreed upon position on the FSF interpretation of the GPL quoted above, and I simply missed it? If yes, could it be added to the R FAQ and/or the CRAN repository policy, such that it is easier to find? If not, may I kindly ask them to explain their position?
>
> No, CRAN and the R Foundation have not published that.  I don't think either group will publish a position.  You can guess the current beliefs of the folks at CRAN by seeing what they do (under the reasonable assumption that they do not think they are doing anything illegal), but those beliefs might change.  The R Foundation does almost nothing, so it's a little more inscrutable.
>
>> Note that I am not asking for legal advice,
>
> You should be.  If you really want to know whether they are using your code illegally, or about whether your proposed use of other peoples code is legal, you really should get legal advice.
>
> > nor am I advocating for a specific change of the current practices of the R project.
>
> Duncan Murdoch


With the caveat that I am not a lawyer, you have not really provided enough information here to formulate even an informal (definitely non-binding) response specifically as it pertains to your package, much less the broad issue of packages on CRAN in general.

There are some questions that need to be answered, since these types of questions have to be answered within specific contexts. For example:

1. Is your package "pure R" code and contains only code that you have written?

2. Does your package contain code requiring compilation (eg. C, C++, FORTRAN) that links against other GPL libraries, R or otherwise?

3. Are you including any other source code, not written by you, that is GPL?


If your package is "pure R" (no compiled code and no R code from someone else that is GPL) and contains no linking (in the compiler sense of the term) to R's libraries or the libraries of other GPL licensed code, you are free to distribute your package under any license you wish and even restrict use. Note that I am focusing on the GPL here and not other "looser" open source licenses.

The same applies if you include a DEPENDS line in your DESCRIPTION file, where other GPL packages are listed. That has no implication for the licensing of your package unless you are linking against libraries in the other GPL packages.

The so-called viral part of the GPL largely comes into play when you link against other GPL code or possibly embed other GPL code within yours and distribute that product. In that case, your code, at least the part that specifically links against other GPL libraries, would have to be licensed under the GPL or a GPL compatible license as well. Albeit, even there, we are talking about distribution, not use. You could develop a package for "internal" use only, in which case, the license used is irrelevant.

The GPL really only comes into play when distributing/copying software beyond yourself or perhaps your organization and even in that case, there are scenarios that would allow for multiple licenses to be used and there is a fair amount of commercial software that is distributed in that fashion. The GPL components are distributed intact and source is made available, while it is possible that "proprietary" components are also packaged together as part of the "whole".

There are non-GPL and non-GPL compatible packages on CRAN and this topic has come up for [heated] discussion in the past. The CRAN maintainers have not placed GPL or GPL compatible only restrictions on the packages on CRAN. That there are such packages on CRAN is not a legal issue vis-a-vis the GPL, but a philosophical one, which is where the heated discussions tend to arise from.

I would also point out that there are R packages not on CRAN that have been made available and the same licensing parameters apply.

Regards,

Marc Schwartz

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Matthew Dowle
In reply to this post by Christian Sigg

Christian,

In my mind, rightly or wrongly, it boils down to these four points :

1. CRAN policy excludes closed source packages; i.e., every single
package on CRAN includes its C code, if any. If an R package included a
.dll or .so which linked at C level to R, and that was being distributed
without providing the source, then that would be a clear breach of R's
GPL. But nobody is aware of any such package. Anyone who is aware of
that should let the R Foundation know. Whether or not the GPL applies to
R only interpreted code (by definition you cannot "close-source"
interpreted code) is important too, but not as important as distribution
of closed source binaries linking to R at C level.

2. Court cases would never happen unless two lawyers disagreed. Even
then two judges can disagree (otherwise appeals would never be
successful).

3. There are two presidents of the R Foundation. And it appears they
disagree. Therefore it appears very unlikely that the R Foundation would
bring a GPL case against anyone. Rather, it seems to be up to the
community to decide for themselves. If you don't mind about close source
non free software linking to R at C level then buy it (if that exists),
if you don't, don't.

4. As a package author it is entirely up to you how to approach this
area. Yes, seek legal advice. And I'd suggest seeking the advice of
several lawyers, not just one. Then follow the advice that you like the
best.

Matthew

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Christian Sigg
In reply to this post by Duncan Murdoch-2
Dear Duncan

> I don't think my point contradicts the FSF interpretation.  I think they were talking about using GPL modules in a program you distribute, with the implication that you are distributing the modules along with your program.  However, I could be wrong.  If I am wrong and the FSF agrees with your strong interpretation, then I do think they are wrong.

Let me again quote parts of the GPL FAQ:

> Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
>
> A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.

The second paragraph (applied to R) says that if I use a GPL'd R package, I must release the program in a GPL-compatible way. It makes no mention of distributing the GPLed modules along with the program.

I think that this FAQ entry precisely exists because in an interpreted environment, it is possible to make use of the functionality of a GPLed package without copying code (in source or binary form) from that package into my program (beyond the API calls), as it would happen in static linking. The last sentence of the first paragraph unambiguously asserts that calling functionality from an R package is equivalent to dynamic linking of my program with the package.

The preceding entry of the GPL FAQ has this to say:

> 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? (#IfLibraryIsGPL)
>
>     Yes, because the software as it is actually run includes the library.

There exist several licenses which modify the GPL explicitly to allow for dynamic linking to a GPLed library without having to release the program under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. The following section again states that dynamic linking implies that a program and the package become effectively a single program, which needs to be released under the GPL:

> Can I release a non-free program that's designed to load a GPL-covered plug-in? (#NFUseGPLPlugins)
>
>    (...)
>
>     If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.


I see nothing in the FAQ which would indicate that these points were only valid if the GPLed R package is distributed along with my program.


> If you write something that incorporates nothing of mine, I can't see how my copyright could influence you at all.  If a user needs my code to make yours useful, I don't see how any of that changes.  The GPL is quite clear that it doesn't restrict people in how they use the code, it just gives them rights to copy it (possibly in a modified form, if they follow the rules).

I think I understand your position, and personally applied the same reasoning when reading the GPL. But the above quoted sections unambiguously concern usage and dynamic linking, and make no mention of copying code.

> No, CRAN and the R Foundation have not published that.  I don't think either group will publish a position.  You can guess the current beliefs of the folks at CRAN by seeing what they do (under the reasonable assumption that they do not think they are doing anything illegal), but those beliefs might change.  The R Foundation does almost nothing, so it's a little more inscrutable.

I already mentioned in my first email what I assume is the position of the CRAN maintainers and the R Foundation, i.e. that they believe that distributing non GPL-compatible packages which depend on GPL packages is not a violation of the GPL. But if my reading of the GPL FAQ has any merit, then the FSF has a different position. And because the R project is an official GNU project, the FSF interpretation of the GPL is important for the R project. A clarification of the position of the CRAN maintainers and the R Foundation would therefore be helpful.

Prof. Leisch explicitly mentions that discussions concerning such issues (e.g. combining R with non-free functionality) are taking place, and that a common position is sought with the intent of publishing it:

> Just a short clarification (by no means intended to stop the thread):
> as you can imagine we are discussing the matter internally in R Core
> and the Foundation, but there are different views and we want to
> consolidate before we make a public statement.  If all of us were of
> the same opinion we would already have made one.




>> Note that I am not asking for legal advice,
>
> You should be.  If you really want to know whether they are using your code illegally, or about whether your proposed use of other peoples code is legal, you really should get legal advice.

This issue has been brought up several times, making it a frequently asked question (for some definitions of frequently :-). A clarification of the position of the CRAN maintainers and the R Foundation is valuable, and does not have to constitute legal advice.

Best regards,
Christian
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Christian Sigg
In reply to this post by Marc Schwartz-3
Dear Marc

The GPL FAQ section that I quoted addresses all the points that you raise:

> There are some questions that need to be answered, since these types of questions have to be answered within specific contexts. For example:
>
> 1. Is your package "pure R" code and contains only code that you have written?

The quoted section of the GLP FAQ concerns purely interpreted R code. Issues of authorship are not part of the argument, but they of course have to be fully resolved.

> 2. Does your package contain code requiring compilation (eg. C, C++, FORTRAN) that links against other GPL libraries, R or otherwise?

See 1.

> 3. Are you including any other source code, not written by you, that is GPL?

No inclusion of third party source code, only making use of functionality of a GPLed R package.


> If your package is "pure R" (no compiled code and no R code from someone else that is GPL) and contains no linking (in the compiler sense of the term) to R's libraries or the libraries of other GPL licensed code, you are free to distribute your package under any license you wish and even restrict use. Note that I am focusing on the GPL here and not other "looser" open source licenses.
>
> The same applies if you include a DEPENDS line in your DESCRIPTION file, where other GPL packages are listed. That has no implication for the licensing of your package unless you are linking against libraries in the other GPL packages.

It is my understanding of the quoted GPL FAQ section that the FSF does not agree with this interpretation of the GPL.

> The so-called viral part of the GPL largely comes into play when you link against other GPL code or possibly embed other GPL code within yours and distribute that product. In that case, your code, at least the part that specifically links against other GPL libraries, would have to be licensed under the GPL or a GPL compatible license as well. Albeit, even there, we are talking about distribution, not use. You could develop a package for "internal" use only, in which case, the license used is irrelevant.

I provided examples of packages that are already published on CRAN, which are in violation of the GPL according to the FSF interpretation, provided I understood the GPL FAQ correctly.

> There are non-GPL and non-GPL compatible packages on CRAN and this topic has come up for [heated] discussion in the past. The CRAN maintainers have not placed GPL or GPL compatible only restrictions on the packages on CRAN. That there are such packages on CRAN is not a legal issue vis-a-vis the GPL, but a philosophical one, which is where the heated discussions tend to arise from.

I am aware of those discussions, and am not advocating for a change of the current practices of the CRAN maintainers. But I if the current practices of the R project are in conflict with the FSF interpretation of the GPL, they need to be addressed.

Best regards,
Christian

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Christian Sigg
> I am aware of those discussions, and am not advocating for a change of the current practices of the CRAN maintainers. But if the current practices of the R project are in conflict with the FSF interpretation of the GPL, they need to be addressed.

Let me correct my last sentence to "..., this issue should be addressed." to avoid a possible misunderstanding. I am only asking for a clarification of the position of the CRAN maintainers and the R Foundation on this issue.

Best regards,
Christian
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Duncan Murdoch-2
In reply to this post by Christian Sigg
On 25/01/2013 1:16 PM, Christian Sigg wrote:

> Dear Duncan
>
> > I don't think my point contradicts the FSF interpretation.  I think they were talking about using GPL modules in a program you distribute, with the implication that you are distributing the modules along with your program.  However, I could be wrong.  If I am wrong and the FSF agrees with your strong interpretation, then I do think they are wrong.
>
> Let me again quote parts of the GPL FAQ:
>
> > Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
> >
> > A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
>
> The second paragraph (applied to R) says that if I use a GPL'd R package, I must release the program in a GPL-compatible way. It makes no mention of distributing the GPLed modules along with the program.

I still find that paragraph to be ambiguous, but I'm willing to believe
that they are making claims with no legal basis for them.

Duncan Murdoch

>
> I think that this FAQ entry precisely exists because in an interpreted environment, it is possible to make use of the functionality of a GPLed package without copying code (in source or binary form) from that package into my program (beyond the API calls), as it would happen in static linking. The last sentence of the first paragraph unambiguously asserts that calling functionality from an R package is equivalent to dynamic linking of my program with the package.
>
> The preceding entry of the GPL FAQ has this to say:
>
> > 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? (#IfLibraryIsGPL)
> >
> >     Yes, because the software as it is actually run includes the library.
>
> There exist several licenses which modify the GPL explicitly to allow for dynamic linking to a GPLed library without having to release the program under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. The following section again states that dynamic linking implies that a program and the package become effectively a single program, which needs to be released under the GPL:
>
> > Can I release a non-free program that's designed to load a GPL-covered plug-in? (#NFUseGPLPlugins)
> >
> >    (...)
> >
> >     If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
>
>
> I see nothing in the FAQ which would indicate that these points were only valid if the GPLed R package is distributed along with my program.
>
>
> > If you write something that incorporates nothing of mine, I can't see how my copyright could influence you at all.  If a user needs my code to make yours useful, I don't see how any of that changes.  The GPL is quite clear that it doesn't restrict people in how they use the code, it just gives them rights to copy it (possibly in a modified form, if they follow the rules).
>
> I think I understand your position, and personally applied the same reasoning when reading the GPL. But the above quoted sections unambiguously concern usage and dynamic linking, and make no mention of copying code.
>
> > No, CRAN and the R Foundation have not published that.  I don't think either group will publish a position.  You can guess the current beliefs of the folks at CRAN by seeing what they do (under the reasonable assumption that they do not think they are doing anything illegal), but those beliefs might change.  The R Foundation does almost nothing, so it's a little more inscrutable.
>
> I already mentioned in my first email what I assume is the position of the CRAN maintainers and the R Foundation, i.e. that they believe that distributing non GPL-compatible packages which depend on GPL packages is not a violation of the GPL. But if my reading of the GPL FAQ has any merit, then the FSF has a different position. And because the R project is an official GNU project, the FSF interpretation of the GPL is important for the R project. A clarification of the position of the CRAN maintainers and the R Foundation would therefore be helpful.
>
> Prof. Leisch explicitly mentions that discussions concerning such issues (e.g. combining R with non-free functionality) are taking place, and that a common position is sought with the intent of publishing it:
>
> > Just a short clarification (by no means intended to stop the thread):
> > as you can imagine we are discussing the matter internally in R Core
> > and the Foundation, but there are different views and we want to
> > consolidate before we make a public statement.  If all of us were of
> > the same opinion we would already have made one.
>
>
>
>
> >> Note that I am not asking for legal advice,
> >
> > You should be.  If you really want to know whether they are using your code illegally, or about whether your proposed use of other peoples code is legal, you really should get legal advice.
>
> This issue has been brought up several times, making it a frequently asked question (for some definitions of frequently :-). A clarification of the position of the CRAN maintainers and the R Foundation is valuable, and does not have to constitute legal advice.
>
> Best regards,
> Christian

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Marc Schwartz-3
In reply to this post by Christian Sigg

On Jan 25, 2013, at 12:16 PM, Christian Sigg <[hidden email]> wrote:

> Dear Duncan
>
>> I don't think my point contradicts the FSF interpretation.  I think they were talking about using GPL modules in a program you distribute, with the implication that you are distributing the modules along with your program.  However, I could be wrong.  If I am wrong and the FSF agrees with your strong interpretation, then I do think they are wrong.
>
> Let me again quote parts of the GPL FAQ:
>
>> Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
>>
>> A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
>
> The second paragraph (applied to R) says that if I use a GPL'd R package, I must release the program in a GPL-compatible way. It makes no mention of distributing the GPLed modules along with the program.
>
> I think that this FAQ entry precisely exists because in an interpreted environment, it is possible to make use of the functionality of a GPLed package without copying code (in source or binary form) from that package into my program (beyond the API calls), as it would happen in static linking. The last sentence of the first paragraph unambiguously asserts that calling functionality from an R package is equivalent to dynamic linking of my program with the package.
>
> The preceding entry of the GPL FAQ has this to say:
>
>> 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? (#IfLibraryIsGPL)
>>
>>    Yes, because the software as it is actually run includes the library.
>
> There exist several licenses which modify the GPL explicitly to allow for dynamic linking to a GPLed library without having to release the program under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. The following section again states that dynamic linking implies that a program and the package become effectively a single program, which needs to be released under the GPL:
>
>> Can I release a non-free program that's designed to load a GPL-covered plug-in? (#NFUseGPLPlugins)
>>
>>   (...)
>>
>>    If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
>
>
> I see nothing in the FAQ which would indicate that these points were only valid if the GPLed R package is distributed along with my program.
>
>
>> If you write something that incorporates nothing of mine, I can't see how my copyright could influence you at all.  If a user needs my code to make yours useful, I don't see how any of that changes.  The GPL is quite clear that it doesn't restrict people in how they use the code, it just gives them rights to copy it (possibly in a modified form, if they follow the rules).
>
> I think I understand your position, and personally applied the same reasoning when reading the GPL. But the above quoted sections unambiguously concern usage and dynamic linking, and make no mention of copying code.
>
>> No, CRAN and the R Foundation have not published that.  I don't think either group will publish a position.  You can guess the current beliefs of the folks at CRAN by seeing what they do (under the reasonable assumption that they do not think they are doing anything illegal), but those beliefs might change.  The R Foundation does almost nothing, so it's a little more inscrutable.
>
> I already mentioned in my first email what I assume is the position of the CRAN maintainers and the R Foundation, i.e. that they believe that distributing non GPL-compatible packages which depend on GPL packages is not a violation of the GPL. But if my reading of the GPL FAQ has any merit, then the FSF has a different position. And because the R project is an official GNU project, the FSF interpretation of the GPL is important for the R project. A clarification of the position of the CRAN maintainers and the R Foundation would therefore be helpful.
>
> Prof. Leisch explicitly mentions that discussions concerning such issues (e.g. combining R with non-free functionality) are taking place, and that a common position is sought with the intent of publishing it:
>
>> Just a short clarification (by no means intended to stop the thread):
>> as you can imagine we are discussing the matter internally in R Core
>> and the Foundation, but there are different views and we want to
>> consolidate before we make a public statement.  If all of us were of
>> the same opinion we would already have made one.
>
>
>
>
>>> Note that I am not asking for legal advice,
>>
>> You should be.  If you really want to know whether they are using your code illegally, or about whether your proposed use of other peoples code is legal, you really should get legal advice.
>
> This issue has been brought up several times, making it a frequently asked question (for some definitions of frequently :-). A clarification of the position of the CRAN maintainers and the R Foundation is valuable, and does not have to constitute legal advice.
>
> Best regards,
> Christian



Some additional points, if I may:

1. The discussion that Christian points to which references Fritz' comments is now going on 4 years old. I have seen nothing, to my recollection, that represents a formal position being taken by the R Foundation on this issue. Thus, I would not have any expectation that they will. If something has been decided, it appears to be a default position to not change anything vis-a-vis CRAN without sufficient motivation to do so, which would logically be legally based at some level.

2. As Christian notes, R is a GNU project and is therefore a high profile project within the open source community. I take a certain level of comfort that none of the FSF, any other open source advocacy organization or RMS himself (who as we all know is not shy on these issues and who has spoken at a useR meeting), has elected to take a negative position on this issue, resulting in any change in the behavior of CRAN. In other words, there has been no cease and desist communication regarding the distribution of non-GPL compatible packages on CRAN or elsewhere for that matter. If there was, I have no doubt that we all would have heard about it and those packages would be off CRAN or other points of distribution by now. Given some of the "energy" contained in prior communications on this issue, I would envision that one or more of those previous participants would have taken it upon themselves to proactively communicate their concerns to the FSF. Just saying.

3. There are for-profit commercial vendors of R distributions who have built proprietary components on top of R, who distribute R and other components, including add-on packages, under multiple licensing scenarios. I have absolutely no doubt that those vendors' corporate legal counsel have rendered formal legal opinions suitable to the respective companies and their boards of directors/investors/shareholders that a clear separation can be made between R as a GPL application and other components that do not need to be released under a GPL compatible license, given appropriate parameters.

So there appear to be two issues here:

1. Should CRAN, as a distribution network for a GPL application, contain non-GPL compatible packages. As I noted, that appears to be a philosophical issue, with at least a de facto position being held by the R Foundation at this time.

2. Can non-GPL compatible packages for R even be created (even if "pure R"), based upon the interpretation of the GPL that Christian has postulated? Any third party R program is certainly going to call at minimum, base R functions who's source code and/or compiled binaries are not contained in the user's package/code. Thus there is an implicit dependency on base R functionality other than the interpreter/parser itself. Given this, it seems to me that this possible interpretation of the GPL applies even in the scenario where I create an R package that does not depend upon someone else's CRAN package for functionality. The significant and long standing precedent in the marketplace would seem to indicate that the answer is Yes.

Regards,

Marc

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Simon Urbanek

On Jan 25, 2013, at 3:32 PM, Marc Schwartz wrote:

>
> On Jan 25, 2013, at 12:16 PM, Christian Sigg <[hidden email]> wrote:
>
>> Dear Duncan
>>
>>> I don't think my point contradicts the FSF interpretation.  I think they were talking about using GPL modules in a program you distribute, with the implication that you are distributing the modules along with your program.  However, I could be wrong.  If I am wrong and the FSF agrees with your strong interpretation, then I do think they are wrong.
>>
>> Let me again quote parts of the GPL FAQ:
>>
>>> Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
>>>
>>> A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
>>
>> The second paragraph (applied to R) says that if I use a GPL'd R package, I must release the program in a GPL-compatible way. It makes no mention of distributing the GPLed modules along with the program.
>>
>> I think that this FAQ entry precisely exists because in an interpreted environment, it is possible to make use of the functionality of a GPLed package without copying code (in source or binary form) from that package into my program (beyond the API calls), as it would happen in static linking. The last sentence of the first paragraph unambiguously asserts that calling functionality from an R package is equivalent to dynamic linking of my program with the package.
>>
>> The preceding entry of the GPL FAQ has this to say:
>>
>>> 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? (#IfLibraryIsGPL)
>>>
>>>   Yes, because the software as it is actually run includes the library.
>>
>> There exist several licenses which modify the GPL explicitly to allow for dynamic linking to a GPLed library without having to release the program under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. The following section again states that dynamic linking implies that a program and the package become effectively a single program, which needs to be released under the GPL:
>>
>>> Can I release a non-free program that's designed to load a GPL-covered plug-in? (#NFUseGPLPlugins)
>>>
>>>  (...)
>>>
>>>   If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
>>
>>
>> I see nothing in the FAQ which would indicate that these points were only valid if the GPLed R package is distributed along with my program.
>>
>>
>>> If you write something that incorporates nothing of mine, I can't see how my copyright could influence you at all.  If a user needs my code to make yours useful, I don't see how any of that changes.  The GPL is quite clear that it doesn't restrict people in how they use the code, it just gives them rights to copy it (possibly in a modified form, if they follow the rules).
>>
>> I think I understand your position, and personally applied the same reasoning when reading the GPL. But the above quoted sections unambiguously concern usage and dynamic linking, and make no mention of copying code.
>>
>>> No, CRAN and the R Foundation have not published that.  I don't think either group will publish a position.  You can guess the current beliefs of the folks at CRAN by seeing what they do (under the reasonable assumption that they do not think they are doing anything illegal), but those beliefs might change.  The R Foundation does almost nothing, so it's a little more inscrutable.
>>
>> I already mentioned in my first email what I assume is the position of the CRAN maintainers and the R Foundation, i.e. that they believe that distributing non GPL-compatible packages which depend on GPL packages is not a violation of the GPL. But if my reading of the GPL FAQ has any merit, then the FSF has a different position. And because the R project is an official GNU project, the FSF interpretation of the GPL is important for the R project. A clarification of the position of the CRAN maintainers and the R Foundation would therefore be helpful.
>>
>> Prof. Leisch explicitly mentions that discussions concerning such issues (e.g. combining R with non-free functionality) are taking place, and that a common position is sought with the intent of publishing it:
>>
>>> Just a short clarification (by no means intended to stop the thread):
>>> as you can imagine we are discussing the matter internally in R Core
>>> and the Foundation, but there are different views and we want to
>>> consolidate before we make a public statement.  If all of us were of
>>> the same opinion we would already have made one.
>>
>>
>>
>>
>>>> Note that I am not asking for legal advice,
>>>
>>> You should be.  If you really want to know whether they are using your code illegally, or about whether your proposed use of other peoples code is legal, you really should get legal advice.
>>
>> This issue has been brought up several times, making it a frequently asked question (for some definitions of frequently :-). A clarification of the position of the CRAN maintainers and the R Foundation is valuable, and does not have to constitute legal advice.
>>
>> Best regards,
>> Christian
>
>
>
> Some additional points, if I may:
>
> 1. The discussion that Christian points to which references Fritz' comments is now going on 4 years old. I have seen nothing, to my recollection, that represents a formal position being taken by the R Foundation on this issue.

I'm somewhat baffled that the one official statement that the R Foundation made specifically for this purpose is apparently being overlooked:

https://stat.ethz.ch/pipermail/r-devel/2009-May/053248.html

Cheers,
Simon




> Thus, I would not have any expectation that they will. If something has been decided, it appears to be a default position to not change anything vis-a-vis CRAN without sufficient motivation to do so, which would logically be legally based at some level.
>
> 2. As Christian notes, R is a GNU project and is therefore a high profile project within the open source community. I take a certain level of comfort that none of the FSF, any other open source advocacy organization or RMS himself (who as we all know is not shy on these issues and who has spoken at a useR meeting), has elected to take a negative position on this issue, resulting in any change in the behavior of CRAN. In other words, there has been no cease and desist communication regarding the distribution of non-GPL compatible packages on CRAN or elsewhere for that matter. If there was, I have no doubt that we all would have heard about it and those packages would be off CRAN or other points of distribution by now. Given some of the "energy" contained in prior communications on this issue, I would envision that one or more of those previous participants would have taken it upon themselves to proactively communicate their concerns to the FSF. Just saying.
>
> 3. There are for-profit commercial vendors of R distributions who have built proprietary components on top of R, who distribute R and other components, including add-on packages, under multiple licensing scenarios. I have absolutely no doubt that those vendors' corporate legal counsel have rendered formal legal opinions suitable to the respective companies and their boards of directors/investors/shareholders that a clear separation can be made between R as a GPL application and other components that do not need to be released under a GPL compatible license, given appropriate parameters.
>
> So there appear to be two issues here:
>
> 1. Should CRAN, as a distribution network for a GPL application, contain non-GPL compatible packages. As I noted, that appears to be a philosophical issue, with at least a de facto position being held by the R Foundation at this time.
>
> 2. Can non-GPL compatible packages for R even be created (even if "pure R"), based upon the interpretation of the GPL that Christian has postulated? Any third party R program is certainly going to call at minimum, base R functions who's source code and/or compiled binaries are not contained in the user's package/code. Thus there is an implicit dependency on base R functionality other than the interpreter/parser itself. Given this, it seems to me that this possible interpretation of the GPL applies even in the scenario where I create an R package that does not depend upon someone else's CRAN package for functionality. The significant and long standing precedent in the marketplace would seem to indicate that the answer is Yes.
>
> Regards,
>
> Marc
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Marc Schwartz-3

On Jan 25, 2013, at 2:45 PM, Simon Urbanek <[hidden email]> wrote:

>
> On Jan 25, 2013, at 3:32 PM, Marc Schwartz wrote:
>
>>
>> On Jan 25, 2013, at 12:16 PM, Christian Sigg <[hidden email]> wrote:
>>
>>> Dear Duncan
>>>
>>>> I don't think my point contradicts the FSF interpretation.  I think they were talking about using GPL modules in a program you distribute, with the implication that you are distributing the modules along with your program.  However, I could be wrong.  If I am wrong and the FSF agrees with your strong interpretation, then I do think they are wrong.
>>>
>>> Let me again quote parts of the GPL FAQ:
>>>
>>>> Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.
>>>>
>>>> A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.
>>>
>>> The second paragraph (applied to R) says that if I use a GPL'd R package, I must release the program in a GPL-compatible way. It makes no mention of distributing the GPLed modules along with the program.
>>>
>>> I think that this FAQ entry precisely exists because in an interpreted environment, it is possible to make use of the functionality of a GPLed package without copying code (in source or binary form) from that package into my program (beyond the API calls), as it would happen in static linking. The last sentence of the first paragraph unambiguously asserts that calling functionality from an R package is equivalent to dynamic linking of my program with the package.
>>>
>>> The preceding entry of the GPL FAQ has this to say:
>>>
>>>> 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? (#IfLibraryIsGPL)
>>>>
>>>>  Yes, because the software as it is actually run includes the library.
>>>
>>> There exist several licenses which modify the GPL explicitly to allow for dynamic linking to a GPLed library without having to release the program under the GPL (e.g. LGPL, Classpath Licence, GCC Runtime Library Exception. The following section again states that dynamic linking implies that a program and the package become effectively a single program, which needs to be released under the GPL:
>>>
>>>> Can I release a non-free program that's designed to load a GPL-covered plug-in? (#NFUseGPLPlugins)
>>>>
>>>> (...)
>>>>
>>>>  If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.
>>>
>>>
>>> I see nothing in the FAQ which would indicate that these points were only valid if the GPLed R package is distributed along with my program.
>>>
>>>
>>>> If you write something that incorporates nothing of mine, I can't see how my copyright could influence you at all.  If a user needs my code to make yours useful, I don't see how any of that changes.  The GPL is quite clear that it doesn't restrict people in how they use the code, it just gives them rights to copy it (possibly in a modified form, if they follow the rules).
>>>
>>> I think I understand your position, and personally applied the same reasoning when reading the GPL. But the above quoted sections unambiguously concern usage and dynamic linking, and make no mention of copying code.
>>>
>>>> No, CRAN and the R Foundation have not published that.  I don't think either group will publish a position.  You can guess the current beliefs of the folks at CRAN by seeing what they do (under the reasonable assumption that they do not think they are doing anything illegal), but those beliefs might change.  The R Foundation does almost nothing, so it's a little more inscrutable.
>>>
>>> I already mentioned in my first email what I assume is the position of the CRAN maintainers and the R Foundation, i.e. that they believe that distributing non GPL-compatible packages which depend on GPL packages is not a violation of the GPL. But if my reading of the GPL FAQ has any merit, then the FSF has a different position. And because the R project is an official GNU project, the FSF interpretation of the GPL is important for the R project. A clarification of the position of the CRAN maintainers and the R Foundation would therefore be helpful.
>>>
>>> Prof. Leisch explicitly mentions that discussions concerning such issues (e.g. combining R with non-free functionality) are taking place, and that a common position is sought with the intent of publishing it:
>>>
>>>> Just a short clarification (by no means intended to stop the thread):
>>>> as you can imagine we are discussing the matter internally in R Core
>>>> and the Foundation, but there are different views and we want to
>>>> consolidate before we make a public statement.  If all of us were of
>>>> the same opinion we would already have made one.
>>>
>>>
>>>
>>>
>>>>> Note that I am not asking for legal advice,
>>>>
>>>> You should be.  If you really want to know whether they are using your code illegally, or about whether your proposed use of other peoples code is legal, you really should get legal advice.
>>>
>>> This issue has been brought up several times, making it a frequently asked question (for some definitions of frequently :-). A clarification of the position of the CRAN maintainers and the R Foundation is valuable, and does not have to constitute legal advice.
>>>
>>> Best regards,
>>> Christian
>>
>>
>>
>> Some additional points, if I may:
>>
>> 1. The discussion that Christian points to which references Fritz' comments is now going on 4 years old. I have seen nothing, to my recollection, that represents a formal position being taken by the R Foundation on this issue.
>
> I'm somewhat baffled that the one official statement that the R Foundation made specifically for this purpose is apparently being overlooked:
>
> https://stat.ethz.ch/pipermail/r-devel/2009-May/053248.html
>
> Cheers,
> Simon


Well, clearly my recollection is faulty. Thanks for that Simon. Now that you point that out, I do recall Robert's post, albeit, I think it got lost in the traffic on R-Devel, which contributes to the lack of recall.

Perhaps it would be reasonable to add something to the R FAQs which at least points to that post.

As noted, it implies that the position of the R Foundation is that non-GPL compatible packages are suitable for distribution via CRAN. Note that I am not disagreeing with that position, nor advocating any change.

Regards,

Marc


>
>> Thus, I would not have any expectation that they will. If something has been decided, it appears to be a default position to not change anything vis-a-vis CRAN without sufficient motivation to do so, which would logically be legally based at some level.
>>
>> 2. As Christian notes, R is a GNU project and is therefore a high profile project within the open source community. I take a certain level of comfort that none of the FSF, any other open source advocacy organization or RMS himself (who as we all know is not shy on these issues and who has spoken at a useR meeting), has elected to take a negative position on this issue, resulting in any change in the behavior of CRAN. In other words, there has been no cease and desist communication regarding the distribution of non-GPL compatible packages on CRAN or elsewhere for that matter. If there was, I have no doubt that we all would have heard about it and those packages would be off CRAN or other points of distribution by now. Given some of the "energy" contained in prior communications on this issue, I would envision that one or more of those previous participants would have taken it upon themselves to proactively communicate their concerns to the FSF. Just saying.
>>
>> 3. There are for-profit commercial vendors of R distributions who have built proprietary components on top of R, who distribute R and other components, including add-on packages, under multiple licensing scenarios. I have absolutely no doubt that those vendors' corporate legal counsel have rendered formal legal opinions suitable to the respective companies and their boards of directors/investors/shareholders that a clear separation can be made between R as a GPL application and other components that do not need to be released under a GPL compatible license, given appropriate parameters.
>>
>> So there appear to be two issues here:
>>
>> 1. Should CRAN, as a distribution network for a GPL application, contain non-GPL compatible packages. As I noted, that appears to be a philosophical issue, with at least a de facto position being held by the R Foundation at this time.
>>
>> 2. Can non-GPL compatible packages for R even be created (even if "pure R"), based upon the interpretation of the GPL that Christian has postulated? Any third party R program is certainly going to call at minimum, base R functions who's source code and/or compiled binaries are not contained in the user's package/code. Thus there is an implicit dependency on base R functionality other than the interpreter/parser itself. Given this, it seems to me that this possible interpretation of the GPL applies even in the scenario where I create an R package that does not depend upon someone else's CRAN package for functionality. The significant and long standing precedent in the marketplace would seem to indicate that the answer is Yes.
>>
>> Regards,
>>
>> Marc
>>
>>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

S Ellison-2
In reply to this post by Christian Sigg

>
>
>
> 1. If I develop and distribute an R package which depends on another package that is released under the GPL, I have to release my package in a GPL-compatible way.
It is probably worth remembering that declaring a 'dependency' of package foo on package bar in the R inter-package sense and then distributing package foo does not of itself constitute distribution, propagation or conveying of package bar.

And if a user of non-gpl  code you have distributed  downloads gpl code themselves,  that would not constitute gpl-forbidden distribution on your part even if they needed to do so to run your code - for the simple reason that you have not distributed the gpl code as part of your software. Nor does the gpl prevent a user from doing that.



> 2. Given that R itself is distributed as a set of base packages (released under the GPL), and a distinction between making use of the R "language" and making use of functionality provided by the base packages seem impossible, the above section could also imply that it is not possible at all to release R code under a license that is not GPL-compatible.

That would be nonsense, as I understand matters. You can distribute R (or any other) code under any license you like provided it does not include GPL'd code (though you can even include gpl'd code if you have due permission - and thereby a different license - from the copyright holder. Assuming you can find them, of course).
Besides, the language is S. The R software is just a system that implements it. The distinction seems pretty clear to me.


Caveat: I'm a chemist, and the above is an opinion. Like the man said, if yer needs advice on a point of law, yer should get yerself a lawyer.


*******************************************************************
This email and any attachments are confidential. Any use...{{dropped:8}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Christian Sigg
In reply to this post by Simon Urbanek
Dear Simon

Thank you for the link. This is exactly the kind of statement that I was looking for.

I searched the archives for any mention of the GPL, for posts by Prof. Leisch and some other keywords before posting to the list. Could this statement be added to the R FAQ and/or the CRAN repository policy, such that it is easier to find in the future?

Best regards,
Christian
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Christian Sigg
In reply to this post by Marc Schwartz-3
Dear Marc

> 2. Can non-GPL compatible packages for R even be created (even if "pure R"), based upon the interpretation of the GPL that Christian has postulated?

I am not trying to offer my own interpretation of the GPL, which is entirely irrelevant. (If anyone is interested, I fall on the "pragmatic" side of the spectrum). I tried to give an accurate rendition of the interpretation of the FSF as stated in the GPL FAQ, which is relevant for the R project. Even though the legal basis of their reasoning seems unclear, to me, the argumentation as given in the GPL FAQ is quite clear and can be summarised as:

1. In an interpreted environment, using library/module/package functionality in a program implies dynamic linking of the library and the program.

2. Because of the dynamic linking, the library and the program effectively form a single program.

3. Therefore, if the library is released under the GPL (without any linking exception), the program has to be released under a GPL-compatible license.

Of course, others can disagree with my understanding the argument given in the GPL FAQ, and I might not have stated the FSF position correctly.

If others read the same sections of the GPL FAQ and come to a different conclusion w.r.t. the FSF interpretation of the GPL, I would be interested to hear their reasoning, unless this is considered off-topic for R-devel.

Best regards,
Christian
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implications of a Dependency on a GPLed Package

Matthew Dowle
Christian Sigg <christian <at> sigg-iten.ch> writes:
>
> Dear Marc
>
> > 2. Can non-GPL compatible packages for R even be created (even if "pure R"),
based upon the interpretation
> of the GPL that Christian has postulated?
>
> I am not trying to offer my own interpretation of the GPL, which is entirely
irrelevant. (If anyone is
> interested, I fall on the "pragmatic" side of the spectrum). I tried to give
an accurate rendition of the
> interpretation of the FSF as stated in the GPL FAQ, which is relevant for the
R project. Even though the
> legal basis of their reasoning seems unclear, to me, the argumentation as
given in the GPL FAQ is quite
> clear and can be summarised as:
>
> 1. In an interpreted environment, using library/module/package functionality
in a program implies
> dynamic linking of the library and the program.
>
> 2. Because of the dynamic linking, the library and the program effectively
form a single program.
>
> 3. Therefore, if the library is released under the GPL (without any linking
exception), the program has to
> be released under a GPL-compatible license.
>
> Of course, others can disagree with my understanding the argument given in the
GPL FAQ, and I might not have
> stated the FSF position correctly.
>
> If others read the same sections of the GPL FAQ and come to a different
conclusion w.r.t. the FSF
> interpretation of the GPL, I would be interested to hear their reasoning,
unless this is considered
> off-topic for R-devel.
>
> Best regards,
> Christian
>

Ok here's a possible different conclusion and reasoning. Here's the 1st
paragraph of the FAQ, in full :

    http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

   " When the interpreter just interprets a language, the answer is no. The
interpreted program, to the interpreter, is just data; a free software license
like the GPL, based on copyright law, cannot limit what data you use the
interpreter on. You can run it on any data (interpreted program), any way you
like, and there are no requirements about licensing that data to anyone. "

Therefore, R only packages (no C code) are just data. The GPL doesn't apply to
them. R only packages depending on other R only packages are just data depending
on data.

You appear to have been concentrating on the 2nd paragraph onwards of that FAQ.
The 2nd paragraph starts :

   " However, when the interpreter is extended to provide “bindings” to other
facilities... "

There, "bindings" could be seen as related to "linking" at C level. Especially
since later in the same paragraph the distinctions "statically" and
"dynamically" are made. Therefore that FAQ's 1st paragraph could be interpreted
as the only relevant one from that FAQ, for R only packages.

The view that R code is just data is quite widespread and agreed upon, iiuc.

Does that help?

Matthew

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel