> 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.
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
