[Rd] Closed-source non-free ParallelR ?

Fri Apr 24 02:54:14 CEST 2009

On 23-Apr-09 22:21:45, Ian Fellows wrote:
> Assuming that the foundation does not want to deviate from the
> FSF interpretation, there would still be value in clarifying its
> position vis-à-vis how the license applies to R specifically. 

I think (see below) that I agree with this!

> For example the FSF foundation claims that linking to a library
> (even in an interpreted environment) makes your software derivative,
> and therefore must be distributed Freely. They also claim that
> simply executing a program in an interpreted (GPL'ed) environment
> is okay even though the program could not be run without it. So one
> question might be, where does the language end and the libraries
> begin?

As far as I Understand these things (and I think I use language
differently from lawyers), it seems to me that this view about
executing a program in an interpreted environment is reasonable.

For example, suppose I bought a commercial FORTRAN interpreter.
I write a program (plain text, of course) in standard FORTRAN.
Running this on the interpreter surely would not tie me into
any licensing issues arising from the rights of the seller of
the interpreter, and I feel sure I could re-distribute my raw
(test) FORTRAN code as I pleased without any infringement arising
from the fact that I had, myself, executed it on the interpreter.
Others (and I myself) could surely compile the program on some
other compiler, etc.

However, if that commercial interpreter also had a 'compile' option,
and I compiled my progrtam using that, then equally I feel sure
that the compiled version would be subject to whatever restrictions
had been placed on distirbution fo binaries so compiled. I think
those things are clear enough.

The interesting question arises if the commercial interpreter
also included some extension of standard FORTRAN which was unique
to that interpreter. I dare say I could pass a program which
included use of the extension to others without problems, on
thr grounds that they would have to obtain te same interpreter
in order to run it.

But now suppose that my having done this inspires someone to
incorporate the same language extension into a GPL'd FORTRAN
interpreter/compiler. I think I could then be vulnerable, or
they could, on the grounds that I/they had pinched the idea
from the commercial product.

And now (relevent to Ian's next point), maybe a similar principle
might be held to apply to R code which depends on R's use of GPL?
-- since people who write R code often use features of the code
which are peculiar to R. Or maybe the GPL doesn't inhibit you
from using *ideas* and *features* of GPL software, provided you
implement them yourself and in your own way? I dunno ...

Ted.

> Are any/all of the default packages considered part of
> the language? It seems hard to imagine doing anything at all without at
> least 'base.' If I install R in the usual way with no other
> packages/libraries can I release whatever I write under any license, or
> does
> it have to be GPL compatible?
> 
> While I wouldn't expect R core to formulate formal legal opinions
> regarding
> questions like these, it would be nice if there were some kind of
> "community
> standards."
> 
> Ian
> 
> -----Original Message-----
> From: r-devel-bounces at r-project.org
> [mailto:r-devel-bounces at r-project.org]
> On Behalf Of Marc Schwartz
> Sent: Thursday, April 23, 2009 2:34 PM
> To: Stavros Macrakis
> Cc: Matthew Dowle; r-devel at r-project.org
> Subject: Re: [Rd] Closed-source non-free ParallelR ?
> 
> 
> On Apr 23, 2009, at 3:22 PM, Stavros Macrakis wrote:
> 
>> On Thu, Apr 23, 2009 at 1:25 PM, Marc Schwartz  
>> <marc_schwartz at me.com> wrote:
>>> On Apr 23, 2009, at 11:47 AM, Stavros Macrakis wrote:
>>>>
>>>> All that being said, the entity that must enforce these conditions  
>>>> is
>>>> not the FSF, but the copyright owner, in this case the R  
>>>> Foundation...
>>>> bundler. So it would be useful to know what the R Foundation's
>>>> position is....
>>
>>> Actually, the R Foundation has done what it is obligated to do,  
>>> which is to
>>> describe the license under which R is made available.
>>
>> I did not say that the R Foundation was obligated to give advice.  I
>> said that it is up to the R Foundation to decide what cases it cares
>> about, and it would be "useful to know" what that position is.
>>
>>> To ask the R Foundation for anything further is to ask them to  
>>> render a legal
>>> opinion, which is not in their expertise to offer.
>>
>> No, it is asking them what their *policy* is.  Their policy may or may
>> not be enforceable....
>>
>>> It is up to the prospective third party developer of an application  
>>> that is
>>> to use R to consult with lawyers to determine what *THEIR*  
>>> obligations are
>>> if they should elect to proceed.
>>
>> Yes, this is true.  But it is also true that if (for example) the R
>> Foundation says officially that it interprets GPL to allow
>> distributing proprietary packages along with R, then that is the
>> interpretation that matters, since the R Foundation (not the FSF) is
>> the copyright holder.
>>
>>> At this level, it is really pretty simple and a lot of these things  
>>> are
>>> covered in the GPL FAQs, including the reporting of violations.
>>
>> The GPL FAQs are the FSF's interpretation.  The R Foundation is not
>> obliged to have the same interpretation, and of course the FSF cannot
>> enforce licenses given by the R Foundation.
> 
> Underlying all of your comments seems to be a presumption that the R  
> Foundation can disentangle themselves from the FSF vis-a-vis the GPL.
> 
> Keep in mind that it is the FSF that is the copyright holder of the
> GPL.
> 
> The R Foundation may be the copyright holder to R, but they are  
> distributing it under a license which they did not write.
> 
> Thus, I cannot envision any reasonable circumstances under which the R 
> Foundation would place themselves in a position of legal risk in  
> deviating from the interpretations of the GPL by the FSF. It would be  
> insane legally to do so.
> 
> The key issue is the lack of case law relative to the GPL and that  
> leaves room for interpretation. One MUST therefore give significant  
> weight to the interpretations of the FSF as it will likely be the FSF  
> that will be involved in any legal disputes over the GPL and its  
> application. You would want them on your side, not be fighting them.
> 
> A parallel here is why most large U.S. public corporations legally  
> incorporate in the state of Delaware, even though they may not have  
> any material physical presence in that state. It is because the  
> overwhelming majority of corporate case law in the U.S. has been  
> decided under the laws of Delaware and the interpretations of said  
> laws. If I were to start a company (which I have done in the past) and 
> feared that I should find myself facing litigation at some future  
> date, I would want that huge database of case law behind me. A small  
> company (such as I had) may be less concerned about this and be  
> comfortable with the laws of their own state, which I was. But if I  
> were to be looking to build a big company with investors, etc. and  
> perhaps look to go public at a future date, you bet I would look to  
> incorporate in Delaware. It would be the right fiduciary decision to  
> make in the interest of all parties.
> 
> Unfortunately, we have no such archive of case law yet of the GPL.  
> Thus at least from a legally enforceable perspective, all is grey and  
> the FSF has to be the presumptive leader here.
> 
> HTH,
> 
> Marc Schwartz
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding at manchester.ac.uk>
Fax-to-email: +44 (0)870 094 0861
Date: 24-Apr-09                                       Time: 01:54:11
------------------------------ XFMail ------------------------------