licensing

[dpastoor]

Rather than pollute the other PR I think this discussion can be moved here.

The point is we can call the license a LGPL license, however the hard dependencies on ggplot2/ggforce and many of the other packages across the ecosystem are going to end up causing this to reasonably fall under GPL license rather than LGPL.

This is somewhat of a silly discussion in the R ecosystem, as the source code is all available anyway, rather than than problems like deploying as a static binary.

I just wanted to bring up awareness, with regards to future decisions about the ability to include/exclude code and the impact on the project license.

https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works

https://softwareengineering.stackexchange.com/questions/342156/can-i-use-some-gpl-code-in-lgpl-project

https://opensource.stackexchange.com/questions/1640/if-im-using-a-gpl-3-library-in-my-project-can-i-license-my-project-under-mit-l

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

Overall, the easiest way I've seen GPL licensing described is that if your program cannot function without the GPL'd software, it is pretty clear to be a derivative work, and therefore falls under the license. ggplot2 clearly falls under this purview. That said, realistically, I am unaware of any litigation surrounding R package licensing, so this is likely all a moot point anyway.

[bguiastr]

@ronkeizer you used the MIT license in your vpc package and you also have a dependency on ggplot2 do you have any experience on the way this works?

[bguiastr]

Check out the following: https://www.r-project.org/Licenses/

Looking at this, the base R package is licensed under GPL-2 | GPL-3. However, less restrictive MIT and LGPL license are on their website as possible licenses for packages. I seems that there is a big grey area around this...

[dpastoor]

Its a SUPER grey area - thats why I say realistically the chance of someone coming after you is very small - but here are other findings I've accumulated over time trying to deal with this:

1. From the FSF foundation:

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

You can see under "I want to license my code as LGPL and use a GPL library" the resulting license is GPL.

From the GPL FAQ regarding dynamic inclusion

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. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL.

From the community the consensus is also pretty consistent across languages:

https://opensource.stackexchange.com/questions/2139/can-i-license-python-project-under-3-clause-bsd-while-it-has-gpl-based-dependenc?rq=1

https://opensource.stackexchange.com/questions/35/if-i-include-some-gpl-code-in-my-project-can-i-release-it-as-bsd?noredirect=1&lq=1

In the JS community they try to avoid GPL like the plague (removing nested dependency that is GPL out of concern) - browserify/browserify#488

That said, as you can see yourself, the R community seems to have no 'clue' about how to license things. For example, dplyr links to Rcpp https://github.com/tidyverse/dplyr/blob/master/DESCRIPTION#L52 but calls itself MIT. This is about as clearcut as you can get regarding the linking infection.

The conclusion overall seems to be, from a purely legal perspective, if you want to avoid GPL you gotta abandon R and look to languages like Julia/python/JS that have ecosystems that started out and maintained a preference for more permissive licenses (MIT/BSD/Apache). This obviously isn't practical.

[ronkeizer]

What Devin said. It's a bit backward within R community, many packages are still using GPL (probably because default) while the rest of the world has moved on. I prefer to ignore the potential issue and use MIT, like dplyr and jsonlite do as well, since I don't see the point of being so restrictive.