On Fri, Nov 29, 2013 at 2:12 PM, Alan G Isaac <alan.is...@gmail.com> wrote: >> On Wed, Nov 27, 2013 at 2:14 PM, Alan G Isaac wrote: >>> http://www.law.washington.edu/lta/swp/law/derivative.html > > On 11/28/2013 5:58 PM, Nathaniel Smith wrote: >> There's no meaningful legal distinction between static and dynamic >> linking. And pretty much everyone agrees that if you do either, for >> any library with a unique interface (and R's C interface, for better >> or worse, is VERY unique ;-)), then your code can only be >> distributed under GPL-compatible terms. >> ... >> rpy2 can legally be re-licensed under any GPL-compatible >> terms, including BSD. > > > I believe that Nathan's last statement above is true. > > The first statement is trickier, as the link I provided > above discusses. An example from the linked paper > illustrates some of the conceptual problems. (At least, > I believe so.) > > "consider for a moment the Acrobat Reader plugin for > Firefox, and assume that the browser is licensed under > the GPL. The plugin offers its own set of user interface > buttons and is capable of rendering file formats that > are exotic to Firefox. Does this seem like a derivative > work of Firefox? Whatever our intuition may tell us, > the answer depends - according to the GPL's drafters at > least - on the particulars of the Firefox plugin > architecture. If the plugin architecture launches > plugins and runs them in separate address spaces as > separate, running executables, then the GPL does not > consider Acrobat Reader a derived work of Firefox. On > the other hand, if the plugin is dynamically linked to > Firefox, then the GPL urges the opposite > characterization. This seems to fly in the face of > common sense, which tells us that Acrobat Reader is not > a work derived from Firefox." > > The article makes that case that the common sense view also > has the upper hand legally on this issue. So Nathan is right > that dynamic vs. static linking is not really the right demarcation, > but that observation may not cut in the direction he intended. > > Separately, the issue of "intent" has come up in the form of > "what did the writers of the GPL itend?". Doctrines of > original intent are difficult to pursue, but if one were to > attempt such a path, I think it should rather lead to "did > the authors of R intend their adoption of the GPL to > restrict the license choices of related but not derivative > software such as RPy?" It is hard for me to believe they > did intend this, but the question can only be answered by > asking them. I would find it entirely reasonable to allow > the licensing discussion to be influenced by their answer to > such a question, as a matter of courtesy.
Hi Alan, I know you're trying to contribute in good faith here, but I'm not sure it's being very helpful. The link-implies-derivative rule is probably the best rule of thumb for those who don't know the details of copyright law. If one wants to do better than that, then one has to actually, well, learn the law. (One place to start would be by googling the abstraction-filtration-comparison test.) Instead of doing either of these, 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? In my fairly well informed layman's opinion, rpy2 is unambiguously a derivative work of R, and thus subject to the GPL's restrictions -- I have no idea how you could argue that it isn't. The edge cases like firefox plugins or nvidia's linux graphic drivers are based on situations where the interface between the GPL and non-GPL code exists independently of the GPL code. This isn't the case for R, whose API is highly idiosyncratic -- that's why I put in that proviso in my original message. Maybe there exists some plausible argument for how rpy2 could be non-derivative that is actually grounded in legal reasoning, and if you come up with one I'd be curious to hear it, but if not then can we drop this? -n ------------------------------------------------------------------------------ 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
