On 11/29/2013 06:53 PM, Alan G Isaac wrote: > On 11/29/2013 5:41 PM, Nathaniel Smith wrote: >> you seem to be flailing around, hoping that maybe >> there will be some loophole that means the law will work out to be the >> way you want? > Absolutely not. For one thing, I do not "want" one outcome > or another. I just want the project to flourish. Also, I moved > this into a separate thread with the idea that it should not be > seen as an attempt to influence the license outcome, but rather > to learn what is or is not *required*. (As opposed to what should > or should not be chosen by the project.) > > >> In my fairly well informed layman's opinion, rpy2 is unambiguously a >> derivative work of R, and thus subject to the GPL's restrictions > Since you suggested using the AFC criteria as the test, if you are willing, > I would appreciate knowing what is being expressed in RPy that should be > considered to be copied from R? On the one hand, I'm getting the feeling that > you might > say its the API, but of course the EFF has forcefully argued that APIs > should not be copyrightable. And I would be truly surprised to find you > siding with Oracle against Google on something like this. On the other hand, > I suspect that you will say I have completely missed the point, and that this > analogy is entirely irrelevant. > > Again, this is largely academic, since it seems that there is sentiment > to keep RPy GPL'd. If you are willing to help me understand, however, > I'll appreciate it.
My understanding is that in our specific situation the GPL might be the best option for a single license as it: - appears to have been appropriate in other similar situations (note: rpy2 is exposing R to Python through R and Python's respective C APIs) - addresses the current use-cases for rpy2. If a commercial application is using a modified (presumably improved) rpy2 it will have to distribute the source for it along with the application. Note that the recipient of the said source does not have to pass it along. The second point in particular seems like an acceptable outcome for everyone. Without a clear list of what a BSD-like license would bring the amount of uncertainty it would bring appears unjustified (R's own licensing is reportedly unclear - http://lists.gpl-violations.org/pipermail/legal/2011-November/003116.html - but the advice seem to be to go with GPL). Also, a notable difference with the examples given so far is that rpy2 is a bridge from Python to R. For example, where an Adobe plugin for Mozilla's Firefox has arguably a standalone component (such as the Flash runtime engine) rpy2 won't be doing much without R. rpy2's unique input is a layer that exposes a C-level API designed to embed R into applications, and does it as if it was a regular library (a stateful library that is). The closest well-known example I can think of in the Python world is the the readline module. On OS X (or commercial distributions of Python), the options are: - default system's Python (limited functionalities by linking to a library with a compatible license) - install the out-of-standard distribution readline module (https://pypi.python.org/pypi/readline - released under the GPL) - recompile Python after having installed the GNU readline library. The second option suggests strongly that rpy2 should be released under a license compatible with R's own license. The Python people would have probably worked it out otherwise. It also suggests that rpy2 can be used by a variety of projects: ipython, cited as an example of software that moved to a more permissive license, does rely on a fully functioning readline library. If this was not enough, I want to keep the option to patch R for rpy2 open An alternative could be to license the rpy2.rinterface layer as GPL, and allow a more permissive license for rpy2.robjects (while also providing a way interface with R in different processes). This appears to me like an unnecessary burden, but I may revisit this I am shown concrete manifestations of interest (that is contributed code). Regarding contributions from industries, the BSD vs GPL argument is an interesting one, yet possibly a controversial one. I think that it can only be defended when an industry's product is software, although not even in all cases. There is a number of industries, particularly in the data analysis space, that do not have software as an end product. Software is then a mean to an end, which some companies might even provide as OSS. References given as examples early in this thread as demonstration that BSD-licensing would be preferable might reflect an older view of the world. Things have moved since FUD campaigns about the "viral GPL", or the SCO vs Novell episode. I found the following reference to be rather interesting, and correspond to my sentiment that OSS has entered a new phase: http://timreview.ca/article/650 . Freeriders will always be around, no matter the license, but the position of the developer might have changed: using GPL-like licenses, and contributing to it, is no longer an ideological stand but a natural "best thing to do" in a number of situations. While I am perfectly fine with permissive licenses, I also think that GPL-like licenses contribute to a good global situation regarding choice and availability of software. Without it, and with only permissive BSD-like licenses, I doubt that we would have reached the situation we are in today. I followed closely the thread and appreciated all input. It made me read again about licensing, and I feel that I end up slightly more educated about the whole. Yet, I am not convinced that a BSD-type license is appropriate here. The liberal licensing types can easily use the project in isolation, either with a module calling rpy2 (and that does not qualify as a derivative of rpy2 or R, so they can check whether the point is valid or not with their own software ;-) ), or as running in a separate process (the documentation for rpy2 will likely showcase more of this in the future). To wrap it up, I am understanding that the following GPL licenses are possible and people would generally be happy with them: - GPLv2 (that is s R's license) - GPLv2+ (as it was suggested that it would ensure compatibility with GPLv3 - I also read the GPLv2-v3 compatibility landscape seems rather... complicated) Best, Laurent > Alan > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > rpy-list mailing list > rpy-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rpy-list ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
