search

hadley / r-pkgs

Building R packages
https://r-pkgs.org
Other
882 stars 628 forks source link

Address dependencies (e.g. Imports) in licensing chapter #715

Closed jennybc closed 2 years ago

jennybc commented 3 years ago

Create a short section expanding on the bold bit:

Generally, taking a dependency on another package is the right thing to do because you don’t need to worry about licensing, and you’ll automatically get bug fixes.

hadley commented 3 years ago

Could be called "Code you import" to match the other sections, and focus on why the licenses of packages in your description don't affect your license. (With a little more explanation about LinkingTo; will need to re-remember what the situation is there.)

rfaelens commented 2 years ago

The following could be used as inspiration: https://thinkr-open.github.io/licensing-r/rlicense.html

jennybc commented 2 years ago

That resource is indeed already linked:

https://github.com/hadley/r-pkgs/blob/23e3947f00572bb1dcb90a7e7e5022f0f151ccdf/license.Rmd#L29

~This issue may be addressed; I'm at the tail end of a PR that affects the chapters on metadata/DESCRIPTION and licensing.~ Yeah, I think we really do still need a section like "Code you import / link to" section .

matdoering commented 2 years ago

To add to the comment from Hadley made on Issue 829: R being a GPL licensed interpreter doesn't mean that all R packages need to be GPLed, see this section from the FSF FAQ. The question of "how to license my R package" comes down to whether you follow the FSF interpretation (dynamic linking = modification) or the OSI interpretation (dynamic linking != modification), which either means you need to GPL your R package when linking to GPLed code or not. It seems that tidyverse follows the OSI interpretation. I think it should be made clear that this is just one way to interpret the GPL and users should make up their own mind which approach is reasonable because by interpreting the GPL in a lax manner you maybe be unadvertently acting against the intention of the creators from the packages you are depending on.

Also, if the software you're releasing is not commercial, it's unlikely that there will be lawsuit or anything along those lines but there are also companies that use R, including GPLed packages, where potential legal implications should be considered.

hadley commented 2 years ago

If you are not copying anything (as when simply adding the name of a package to your DESCRIPTION), copyright doesn't come into play, and hence it's hard to see how an open source license can have any bearing. Obviously, the end user still has to comply with the licenses of all the packages that they install, but they must already be ok the GPL at some level because they're using R.

Dynamic linking is a specific technical term that applies to C libraries, not generically to all programming languages.

hadley commented 2 years ago

We do need to say something along the lines of “the end user creates the derivative work”, and the license of that derivative work is going to be more complicated than the individual pieces.

rfaelens commented 2 years ago

It seems that tidyverse follows the OSI interpretation.

I think that is precisely the point. In the context of R package development, there are two possible interpretations. As a commercial developer, I have no idea if the original developer intended to allow either the OSI or FSF interpretation of dynamic linking / derived work. I need to ask every original copyright holder! And maybe it even depends on what my software does : solve global warming or calculate nuclear missile paths? The interpretation of "derived work" is a grey area. One that merits clarity from copyright holder if you want to enable commercial use.

The R core developer team has clearly stated they allow the OSI interpretation and will not prosecute anyone building an aggregate work using R this way. This statement also binds all other developers contributing, as copyright is signed over to R foundation when providing bug fixes, new features ea to R or any base packages (base, stats, utils,...)

An unequivocal statement from RStudio as copyright holder of tidyverse would help provide legal certainty for companies building commercial software with R as a calculation backend (= an aggregate work according to FSF interpretation of GPL, but not an aggregate work in the OSI interpretation).

Going back to this original bug: the guide should clearly state there is some discussion and legal uncertainty about the interpretation of the GPL wrt "derived work". Provide the necessary references (fsf definition of aggregate work, OSI defenition, https://www.gnu.org/licenses/gpl-faq.html#MereAggregation). And state that at least R core packages and tidyverse packages specifically allow the osi interpretation. And make sure this is actually the case.

hadley commented 2 years ago

@rfaelens it's all grey, and this chapter just provides general advice; we are not lawyers. There is only so much we can do to allay your worries; to be really certain you will need hire a lawyer and spend (hundreds of) thousands of dollars. But I genuinely believe that the OSI vs FSF difference is unlikely to apply here because pure R packages do not perform dynamic linking in the generally understood technical sense of the phrase.

I can't make any unequivocal statements on behalf of RStudio, but I can't imagine a scenario where we'd sue our open source users. It would burn vast amounts of community goodwill in return for a small and very uncertain payoff.

matdoering commented 2 years ago

@rfaelens: thanks for the nice summary, I totally agree that due to the GPL's ambiguity the copyright holder should ideally specify how they want the license to be interpreted, although that's not very practical. I didn't know that the R Core Team already had made some statements regarding which use under the GPL they would allow, maybe you can add a reference?

@hadley The dynamic linking issue hasn't be resolved at court yet, indeed, it's still a grey area. Whether R's library system counts as dynamic linking, I can't say but it sounds like it because library instructions have to be made available in memory?

While dynamic linking is a grey area, there have been a couple of lawsuits already that all have ended up in out-of-court agreements, e.g. check out iText, which is an AGPL-licensed library for PDF rendering, which interprets the AGPL very narrowly. That doesn't mean it's the "correct" interpretation but at least it indicates that company's are under a very real danger of becoming sued and potentially losing the lawsuit, especially if the software was released under a dual-license, which probably indicates that the copyright holder would like you to pay for it if you use the software in a commercial product.

To sum up: while open-source projects are unlikely to be sued (because there isn't any money to be had), it's "easy" for them to follow a lax GPL interpretation. However, for companies that use open-source software, the lax interpretation of GPL dynamic linking is a pitfall because this means that it's necessary to check not only dependencies but all the dependencies of the dependencies. To exemplify the considerable differences, let's consider the licenses of two popular packages for Python and R, respectively:

To make it clear, I'm not a GPL fanboy and I think it's a very unfortunate license in that it lacks clarity, so I can appreciate that you are trying to increase the clarity be moving away from GPL and releasing under the MIT license. At the same time, I believe that this creates further confusion about the actual license of the software and will therefore not accelerate adoption of R-based tools in commercial applications: as long as there is a dependence on GPL-based software the legal situation remains unclear.

Please consider this hypothetical scenario which indicates how a liberal interpretation can kill the commercial use case of a company:

hadley commented 2 years ago

@matdoering It sounds like you need/want real legal advice, and (a) I'm not a lawyer and (b) it's well out of scope for this chapter.

But your MASS example is implausible since (a) you'd also have to distribute R which is and always will be GPL and (b) as far as I can tell Oxford university has no copyright claim on MASS (https://github.com/cran/MASS/blob/master/LICENCE.note).

hadley commented 2 years ago

Should mention shiny as another example of inlining.