emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] How to make a non-GPL Org-mode exporter?


From: Rainer M Krug
Subject: Re: [O] How to make a non-GPL Org-mode exporter?
Date: Mon, 27 Jul 2015 15:30:09 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)

Andreas Hilboll <address@hidden> writes:

> On 27.07.2015 15:09, Greg Troxel wrote:
>> 
>> Rainer M Krug <address@hidden> writes:
>> 
>>> These packages all depend on R itself.
>>>
>>> So isn't this the same as in emacs / elisp? Isn't an exporter / .el file
>>> the same as a package in R, something which enhances the original
>>> product using a provided interface (the functions) but does not change
>>> anything in the original program (R or emacs)?
>> 
>> It's both the same and different.
>> 
>> The legal question of whether R packages are derivative works of R is
>> similar to the question of elisp packages that use editing primitives
>> are derivative works of emacs.
>
> https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL seems to
> give an answer:
>
> The interpreted program, to the interpreter, is just data; a free
> software license like the GPL, based on copyright law, cannot limit what
> data you use the interpreter on. You can run it on any data (interpreted
> program), any way you like, and there are no requirements about
> licensing that data to anyone.
>
> [...]
>
> Another similar and very common case is to provide libraries with the
> interpreter which are themselves interpreted. For instance, Perl comes
> with many Perl modules, and a Java implementation comes with many Java
> classes. These libraries and the programs that call them are always
> dynamically linked together.
>
> A consequence is that if you choose to use GPL'd Perl modules or Java
> classes in your program, you must release the program in a
> GPL-compatible way, regardless of the license used in the Perl or Java
> interpreter that the combined Perl or Java program will run on.
>
>
> So if I understand this correctly, an R module can be non-GPL if and
> only if it does not use any GPL'ed R modules.

Interesting. This actually i line with what I just read at
http://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic :

,----
| Does the GPL have different requirements for statically vs dynamically linked 
modules with a covered work? (#GPLStaticVsDynamic)
| 
|     No. Linking a GPL covered work statically or dynamically with
|     other modules is making a combined work based on the GPL covered
|     work. Thus, the terms and conditions of the GNU General Public
|     License cover the whole combination. See also What legal issues
|     come up if I use GPL-incompatible libraries with GPL software?
`----

According to this it seems clear: GPL compatible license.

Cheers,

Rainer


>
> Cheers,
>   Andreas.
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      address@hidden

Skype:      RMkrug

PGP: 0x0F52F982

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]