How to make a non-GPL Org-mode exporter?

How to make a non-GPL Org-mode exporter?

[Marcin Borkowski]

Hi all,

after a short discussion in a recent thread, I have a serious technical
question.

Assume that (for some reason) I want to write an Org-mode exporter which
won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
writing a tutorial on them, and I consider publishing a *tutorial* with
GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
other people can or even should reuse the code in the tutorial, right?
And I see no reason to impose GPL on them.))

How do I do that?  Is that even possible?  Also, is it possible to get
an actual answer to this question without spending money on lawyers?

The manual says:

,----
| Your two entry points are respectively ‘org-export-define-backend’ and
| ‘org-export-define-derived-backend’.  To grok these functions, you
| should first have a look at ‘ox-latex.el’ (for how to define a new
| back-end from scratch) and ‘ox-beamer.el’ (for how to derive a new
| back-end from an existing one.
`----

So basically you are expected to use existing GPL'd code to learn to
write new exporters.

Also, the overall structure of the exporters is extremally similar.  For
instance, the :menu-entry argument of org-export-define-backend is
almost the same for all exporters (and it should be, in order not to
break usability!).  Should I follow such conventions, in order to
satisfy users, or should I deliberately break it, in order to satisfy
lawyers?

Also, the names of functions (like `org-latex-export-as-latex' vs
`org-latex-export-to-latex') are similar across exporters.  Should I use
this convention, too, in order to satisfy fellow programmers, or should
I deliberately break it, in order to satisfy lawyers?

Also, the docstrings of many transcoders are similar.  How am I supposed
to write a docstring which is at the same time more or less
comprehensive and different enough from the existing ones, so that
I don't end up in jail?  (<--- this is actually a joke.  I hope so at
least...)

And so on.

Please refrain from comments about my stupidity or stupidity of the
so-called IP law.  And please understand that if I'm sounding a bit
angry in this email, it's because I'm *very* angry about this whole
lawyer mafia restricting my freedom (again).  (Note: I'm all for
restricting people's freedom when there are important reasons for that.
I just consider this situation not to be one of these.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Oleh Krehel]

Marcin Borkowski <mbork@mbork.pl> writes:

> Hi all,
>
> after a short discussion in a recent thread, I have a serious technical
> question.
>
> Assume that (for some reason) I want to write an Org-mode exporter which
> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
> writing a tutorial on them, and I consider publishing a *tutorial* with
> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
> other people can or even should reuse the code in the tutorial, right?
> And I see no reason to impose GPL on them.))
>
> How do I do that?  Is that even possible?  Also, is it possible to get
> an actual answer to this question without spending money on lawyers?

Like I said in an earlier message just a few minutes ago, you can do it,
but you can't use org.el or Elisp at all, unless you implement your own
Elisp engine that you call.

The GPL isn't as evil as you make it out to be: in fact, it's not evil
at all: it only ensures that you pass on the freedom that you receive to
others, i.e. **you are not free to remove freedom from others**.

As for documentation, here I cite a bit of Elisp manual:

    (a) The FSF’s Back-Cover Text is: “You have the freedom to copy and
     modify this GNU manual.  Buying copies from the FSF supports it in
     developing GNU and promoting software freedom.”

Just think about it: on 99% of published books it says:

    No part of this publication may be reproduced, stored in a retrieval
    system, or transmitted, in any form or by means electronic,
    mechanical, photocopying, or otherwise, without prior written
    permission of the publisher.

Now who is the evil guy here?

regards,
Oleh

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

[Daniele Nicolodi]

Hello Marcin,

On 27/07/15 14:10, Marcin Borkowski wrote:
> Assume that (for some reason) I want to write an Org-mode exporter which
> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
> writing a tutorial on them, and I consider publishing a *tutorial* with
> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
> other people can or even should reuse the code in the tutorial, right?
> And I see no reason to impose GPL on them.))

As Oleh Krehel pointed out in a reply to another mail of yours, if your
code links to org-mode code (or other GPL code) you cannot release it
under a different license. I'm not sure about how linking is intended in
Elisp sense of ('require)ing a library, but I believe it is analog to
executable linking in machine code programs.

Therefore, the only extensions to org-mode that can exist (and be
distributed, if you write code and keep it for yourself you are not
affected by the licensing terms) must be GPL.

Thus, it makes little sense to continue the discussion: even if you
would release the code in your tutorial under a different license, it
would be or no use for who will read it.

> How do I do that?  Is that even possible?  Also, is it possible to get
> an actual answer to this question without spending money on lawyers?

There is no need to have lawyers involved, if you are in doubt about the
interpretation of the GPL you can consult the FSF (or other
organizations) on the matter. They will be happy to answer your question
with a very high degree of authority on the matter.

> The manual says:
> 
> ,----
> | Your two entry points are respectively ‘org-export-define-backend’ and
> | ‘org-export-define-derived-backend’.  To grok these functions, you
> | should first have a look at ‘ox-latex.el’ (for how to define a new
> | back-end from scratch) and ‘ox-beamer.el’ (for how to derive a new
> | back-end from an existing one.
> `----
> 
> So basically you are expected to use existing GPL'd code to learn to
> write new exporters.

The manual makes the thing easy for the ones that want to respect the
authors choice of license.

> Also, the overall structure of the exporters is extremally similar.  For
> instance, the :menu-entry argument of org-export-define-backend is
> almost the same for all exporters (and it should be, in order not to
> break usability!).  Should I follow such conventions, in order to
> satisfy users, or should I deliberately break it, in order to satisfy
> lawyers?

First, your goal is not to satisfy lawyers, but to comply with the
license terms. The license terms are chosen by the authors of the code,
thus you are satisfying the wishes of whom granted you access to their
code. It is the minimum you should do to thank them.

Second, if that is the only structure that makes sense, you can
re-invent it without looking at the GPL code. Thus you can use a similar
structure in your differently licensed code. However, you should really
have re-created it without looking at the original. This email already
suggests otherwise.

> Also, the names of functions (like `org-latex-export-as-latex' vs
> `org-latex-export-to-latex') are similar across exporters.  Should I use
> this convention, too, in order to satisfy fellow programmers, or should
> I deliberately break it, in order to satisfy lawyers?

Function names are not copyrightable (as far as I know).

> Also, the docstrings of many transcoders are similar.  How am I supposed
> to write a docstring which is at the same time more or less
> comprehensive and different enough from the existing ones, so that
> I don't end up in jail?  (<--- this is actually a joke.  I hope so at
> least...)

There is a minimum unit of "code" that is copyrightable (the word "the"
appears in many copyrighted works, but you can still use it in your
own). If the doc-strings are trivial you can freely write something similar.

Cheers,
Daniele

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

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3916 bytes --]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Hi all,
>>
>> after a short discussion in a recent thread, I have a serious technical
>> question.
>>
>> Assume that (for some reason) I want to write an Org-mode exporter which
>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>> writing a tutorial on them, and I consider publishing a *tutorial* with
>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>> other people can or even should reuse the code in the tutorial, right?
>> And I see no reason to impose GPL on them.))
>>
>> How do I do that?  Is that even possible?  Also, is it possible to get
>> an actual answer to this question without spending money on lawyers?
>

> Like I said in an earlier message just a few minutes ago, you can do it,
> but you can't use org.el or Elisp at all, unless you implement your own
> Elisp engine that you call.

Big disclaimer: I am not a lawyer and also no expert in this field.

I am not sure about this. Look for example in the statistical languange
R:

R is licensed under GPL  (https://www.r-project.org/COPYING i I think
this is 2).

You have numerous packages which =are under many different licenses:
To quote from https://www.r-project.org/Licenses/ :

,----
| R Licenses
| 
| The following licenses are in use for R or associated software such as packages.
| 
|     The “GNU Affero General Public License” version 3
|     The “Artistic License” version 2.0
|     The “BSD 2-clause License”
|     The “BSD 3-clause License”
|     The “GNU General Public License” version 2
|     The “GNU General Public License” version 3
|     The “GNU Library General Public License” version 2
|     The “GNU Lesser General Public License” version 2.1
|     The “GNU Lesser General Public License” version 3
|     The “MIT License”
| 
| R as a package is licensed under GPL-2 | GPL-3. File doc/COPYING is the same as GPL-2.
| 
| Some files are licensed under ‘GPL (version 2 or later)’, which includes GPL-3. See the comments in the files to see if this applies.
| 
| Some header files are distributed under LGPL-2.1: see file COPYRIGHTS (on the SVN server).
`----

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)?

Rainer



>
> The GPL isn't as evil as you make it out to be: in fact, it's not evil
> at all: it only ensures that you pass on the freedom that you receive to
> others, i.e. **you are not free to remove freedom from others**.
>
> As for documentation, here I cite a bit of Elisp manual:
>
>     (a) The FSF’s Back-Cover Text is: “You have the freedom to copy and
>      modify this GNU manual.  Buying copies from the FSF supports it in
>      developing GNU and promoting software freedom.”
>
> Just think about it: on 99% of published books it says:
>
>     No part of this publication may be reproduced, stored in a retrieval
>     system, or transmitted, in any form or by means electronic,
>     mechanical, photocopying, or otherwise, without prior written
>     permission of the publisher.
>
> Now who is the evil guy here?
>
> regards,
> Oleh
>
>
>

-- 
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:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 480 bytes --]

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

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 5396 bytes --]


Marcin Borkowski <mbork@mbork.pl> writes:

> after a short discussion in a recent thread, I have a serious technical
> question.
>
> Assume that (for some reason) I want to write an Org-mode exporter which
> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm

I will assume that you mean "write and distribute".  (The GPL grants
permission to create derived works that are not distributed.)

> writing a tutorial on them, and I consider publishing a *tutorial* with
> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
> other people can or even should reuse the code in the tutorial, right?
> And I see no reason to impose GPL on them.))
>
> How do I do that?  Is that even possible?  Also, is it possible to get
> an actual answer to this question without spending money on lawyers?

Generally, no, it is not really possible, and a lawyer will not give you
an answer, just an opinion about what the answer is likely to be, and
the risks of various choices on your part.  The exact boundaries of
derived works in software is not settled case law.  (Yes, I have
actually consulted with lawyers on Free Software licensing issues.)

Note that I'm a not a lawyer, and I'm certainly not yours -- and I have
no idea what jurisdiction you're in, but I'm assuming a legal system
somewhat similar to the US and Europe, with the Berne convention.

> ,----
> | Your two entry points are respectively ‘org-export-define-backend’ and
> | ‘org-export-define-derived-backend’.  To grok these functions, you
> | should first have a look at ‘ox-latex.el’ (for how to define a new
> | back-end from scratch) and ‘ox-beamer.el’ (for how to derive a new
> | back-end from an existing one.
> `----
>
> So basically you are expected to use existing GPL'd code to learn to
> write new exporters.

Learning is not a right reserved to the copyright owner.  In all
seriousness, copyright protects expression, not ideas, so learning
things from copyrighted code is fine.

> Also, the overall structure of the exporters is extremally similar.
> For instance, the :menu-entry argument of org-export-define-backend is
> almost the same for all exporters (and it should be, in order not to
> break usability!).  Should I follow such conventions, in order to
> satisfy users, or should I deliberately break it, in order to satisfy
> lawyers?

The basic problem you have is that an existing body of code and culture
of users is built around a particular license, and trying to deviate
From that is in general rude (in general; a PD example is not a bad
goal).  I suggest that you stop trying to be inflammatory, especially
incorrectly so.  It's not about satisfying lawyers -- it's about
following both the law and the norms of the Free Software commnity.

The key question is what is and what isn't a derived work.  That's more
or less a work that extends the original work, a concept born in
literature and applied to software.
 
> Also, the names of functions (like `org-latex-export-as-latex' vs
> `org-latex-export-to-latex') are similar across exporters.

Generally, there is a notion of the size of copying that is big enough
to matter.  I have not heard much support for the notion that using
similar variable names constitutes a derived work.

> Also, the docstrings of many transcoders are similar.  How am I supposed
> to write a docstring which is at the same time more or less
> comprehensive and different enough from the existing ones?

You certainly could rewrite it in your own words.

But, you ask "how am I supposed to" as if there is some guarantee that
you can essentially duplicate what's done but not be a derivative work.
That isn't necessarily true, and you have no right to expect it.  The
law and licenses have consequences and it's entirely possible that you
can't (legally and politely) do what you want.

The tricky part about derived works is that a program which makes many
calls into org to do something is arguably a derived work, even if you
wrote all the lines yourself, because it extends the underlying program
and is not sensible without that underyling code.

I believe that the example of using "defun" is different, because lisp
is something that's been implemented many times, differently.  I see a
lisp program as not being a derived work of the lisp implementation.
This is much like a C program not being a derivative work of the
operating system it runs on, because it is (or should be) coded to
POSIX.

All in all, I suspect that in practice, legally distributing a non-GPL
exporter is iffy, and so I don't see any real downside to an example
being GPL.   (Do you know of an actual situation where someone who is
going to write an exporter genuinely wants to distribute under other
terms, and has a rational basis for that desire?)

Your anger about copyright, when directed at other list members, is
highly misplaced.  This all originates from laws in various countries
and the Berne Convention.  It is those laws which prohibit you from
copying other people's creative works without their permission.  And in
the FSF culture, permission is granted via a license that intentionally
withholds from you the permission to distribute works under other terms.
If you don't like that you should choose not to use emacs.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

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

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]


Rainer M Krug <Rainer@krugs.de> 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.

The social question is totally separate.  It's obvious OK in the R world
to have packages under other licenses.  In the emacs world, it's far
From obvious.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

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

[Andreas Hilboll]

On 27.07.2015 15:09, Greg Troxel wrote:
> 
> Rainer M Krug <Rainer@krugs.de> 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.

Cheers,
  Andreas.

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

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3033 bytes --]

Andreas Hilboll <lists@hilboll.de> writes:

> On 27.07.2015 15:09, Greg Troxel wrote:
>> 
>> Rainer M Krug <Rainer@krugs.de> 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:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 480 bytes --]

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

[Scott Randby]

On 07/27/2015 08:10 AM, Marcin Borkowski wrote:
>
> Please refrain from comments about my stupidity or stupidity of the
> so-called IP law.  And please understand that if I'm sounding a bit
> angry in this email, it's because I'm *very* angry about this whole
> lawyer mafia restricting my freedom (again).  (Note: I'm all for
> restricting people's freedom when there are important reasons for that.
> I just consider this situation not to be one of these.)
>

If I understand correctly, you wish to use code that other people have 
written and published under the GPL. These people made the free choice 
put the conditions of the GPL on the code. I don't see how it is 
anything other than improper to reuse the code in a public domain 
setting. I prefer to respect the choices of the code's writers.

Scott Randby

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

[Marcin Borkowski]

On 2015-07-27, at 14:16, Oleh Krehel <ohwoeowho@gmail.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Hi all,
>>
>> after a short discussion in a recent thread, I have a serious technical
>> question.
>>
>> Assume that (for some reason) I want to write an Org-mode exporter which
>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>> writing a tutorial on them, and I consider publishing a *tutorial* with
>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>> other people can or even should reuse the code in the tutorial, right?
>> And I see no reason to impose GPL on them.))
>>
>> How do I do that?  Is that even possible?  Also, is it possible to get
>> an actual answer to this question without spending money on lawyers?
>
> Like I said in an earlier message just a few minutes ago, you can do it,
> but you can't use org.el or Elisp at all, unless you implement your own
> Elisp engine that you call.

Well, I hardly believe what I read here...

> The GPL isn't as evil as you make it out to be: in fact, it's not evil
> at all: it only ensures that you pass on the freedom that you receive to
> others, i.e. **you are not free to remove freedom from others**.
>
> As for documentation, here I cite a bit of Elisp manual:
>
>     (a) The FSF’s Back-Cover Text is: “You have the freedom to copy and
>      modify this GNU manual.  Buying copies from the FSF supports it in
>      developing GNU and promoting software freedom.”
>
> Just think about it: on 99% of published books it says:
>
>     No part of this publication may be reproduced, stored in a retrieval
>     system, or transmitted, in any form or by means electronic,
>     mechanical, photocopying, or otherwise, without prior written
>     permission of the publisher.
>
> Now who is the evil guy here?

Let's not beat that dead horse again.  (BTW, hardly anyone cares about
that notice on published books, and rightly so.)

> regards,
> Oleh

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Marcin Borkowski]

On 2015-07-27, at 15:09, Greg Troxel <gdt@ir.bbn.com> wrote:

> Rainer M Krug <Rainer@krugs.de> 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.
>
> The social question is totally separate.  It's obvious OK in the R world
> to have packages under other licenses.  In the emacs world, it's far
> From obvious.

OK, so let me pose another question: what if I *don't* distribute
a package?  (Whatever "distribution" means, it's probably unclear, but
let us rely on common sense.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Marcin Borkowski]

On 2015-07-27, at 15:05, Greg Troxel <gdt@ir.bbn.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> after a short discussion in a recent thread, I have a serious technical
>> question.
>>
>> Assume that (for some reason) I want to write an Org-mode exporter which
>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>
> I will assume that you mean "write and distribute".  (The GPL grants
> permission to create derived works that are not distributed.)

As I said a minute ago: I hope (at least) that I can write something
non-GPL'd in Elisp and not distribute it.

>> writing a tutorial on them, and I consider publishing a *tutorial* with
>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>> other people can or even should reuse the code in the tutorial, right?
>> And I see no reason to impose GPL on them.))
>>
>> How do I do that?  Is that even possible?  Also, is it possible to get
>> an actual answer to this question without spending money on lawyers?
>
> Generally, no, it is not really possible, and a lawyer will not give you
> an answer, just an opinion about what the answer is likely to be, and
> the risks of various choices on your part.  The exact boundaries of
> derived works in software is not settled case law.  (Yes, I have
> actually consulted with lawyers on Free Software licensing issues.)

Well, I do understand that a lawyer won't give me an answer.  It's not
something I would expect from a lawyer, after all. ;-/ But thanks for
your answer!

It seems that the most interesting (and most important) question, "what
is derived work", is answered nowhere.  Cool.  I find it a bit difficult
not to be harsh in this situation - not against all you people who
actually bear my rants, but against the system in general.

*Hypothetically*, if someone asked me (in private, mind you) what he or
she should do about the IP law system, I *might* consider the advice
"the best idea is to deliberately break it so that it falls apart
faster" to be among the better ones.

> Note that I'm a not a lawyer, and I'm certainly not yours -- and I have
> no idea what jurisdiction you're in, but I'm assuming a legal system
> somewhat similar to the US and Europe, with the Berne convention.

Europe.

>> ,----
>> | Your two entry points are respectively ‘org-export-define-backend’ and
>> | ‘org-export-define-derived-backend’.  To grok these functions, you
>> | should first have a look at ‘ox-latex.el’ (for how to define a new
>> | back-end from scratch) and ‘ox-beamer.el’ (for how to derive a new
>> | back-end from an existing one.
>> `----
>>
>> So basically you are expected to use existing GPL'd code to learn to
>> write new exporters.
>
> Learning is not a right reserved to the copyright owner.  In all
> seriousness, copyright protects expression, not ideas, so learning
> things from copyrighted code is fine.

I was not precise.  What I meant was: if I learn from GPL'd code, I will
(most probably) naturally tend to mimic it myself when writing my own.
AFAIK, this is (more or less) how *culture* works.  Am I the only one
who sees "IP law" and "culture" be at some kind of opposition here?

>> Also, the overall structure of the exporters is extremally similar.
>> For instance, the :menu-entry argument of org-export-define-backend is
>> almost the same for all exporters (and it should be, in order not to
>> break usability!).  Should I follow such conventions, in order to
>> satisfy users, or should I deliberately break it, in order to satisfy
>> lawyers?
>
> The basic problem you have is that an existing body of code and culture
> of users is built around a particular license, and trying to deviate
> From that is in general rude (in general; a PD example is not a bad
> goal).  I suggest that you stop trying to be inflammatory, especially
> incorrectly so.  It's not about satisfying lawyers -- it's about
> following both the law and the norms of the Free Software commnity.

I am really, really sorry if someone considers me rude.  But - forgive
me - as I'm getting older (and wiser, I hope) I care less and less about
following the law *blindly* (e.g., I consider my moral duty to follow
the law, unless the law itself is immoral, when I may consider my moral
duty to break the law.  And that apart from the question of what to do
if the law is at a contradiction with itself...).

> The key question is what is and what isn't a derived work.  That's more
> or less a work that extends the original work, a concept born in
> literature and applied to software.

Agreed.

>> Also, the names of functions (like `org-latex-export-as-latex' vs
>> `org-latex-export-to-latex') are similar across exporters.
>
> Generally, there is a notion of the size of copying that is big enough
> to matter.  I have not heard much support for the notion that using
> similar variable names constitutes a derived work.
>
>> Also, the docstrings of many transcoders are similar.  How am I supposed
>> to write a docstring which is at the same time more or less
>> comprehensive and different enough from the existing ones?
>
> You certainly could rewrite it in your own words.

That is of course true, though perhaps in some cases falling in-between
the "funny" and "absurd" situations I mention below.

> But, you ask "how am I supposed to" as if there is some guarantee that
> you can essentially duplicate what's done but not be a derivative work.
> That isn't necessarily true, and you have no right to expect it.  The
> law and licenses have consequences and it's entirely possible that you
> can't (legally and politely) do what you want.

The more I read the more I think you are right: it may not be possible
to do this legally.  Politely probably yes, though I'm afraid it might
be outside my reach at the moment.  But I'll try hard to correct myself.

> The tricky part about derived works is that a program which makes many
> calls into org to do something is arguably a derived work, even if you
> wrote all the lines yourself, because it extends the underlying program
> and is not sensible without that underyling code.

And (depending on the particular case, and judging by common sense) this
seems to oscillate between "reasonable", "expected", "the right thing",
"just", "funny", "ridiculous", "absurd" and "stupid".

> I believe that the example of using "defun" is different, because lisp
> is something that's been implemented many times, differently.  I see a
> lisp program as not being a derived work of the lisp implementation.

Isn't this a bit vague?  What about Python, which has a few
implementations?

> This is much like a C program not being a derivative work of the
> operating system it runs on, because it is (or should be) coded to
> POSIX.
>
> All in all, I suspect that in practice, legally distributing a non-GPL
> exporter is iffy, and so I don't see any real downside to an example
> being GPL.   (Do you know of an actual situation where someone who is
> going to write an exporter genuinely wants to distribute under other
> terms, and has a rational basis for that desire?)

Thanks for teaching me a new English word ("iffy").  An example (maybe
a bit contrived - but only a bit!) of such situation: someone working at
a university wants the students to use a particular LaTeX template when
writing their thesis (my case), writes an Org exporter for those of them
who want to use Org (not my case), and having the president of the
university who is strongly opposed to GPL'ing anything written by his
employees (possibly my case).

> Your anger about copyright, when directed at other list members, is
> highly misplaced.  This all originates from laws in various countries
> and the Berne Convention.  It is those laws which prohibit you from
> copying other people's creative works without their permission.  And in
> the FSF culture, permission is granted via a license that intentionally
> withholds from you the permission to distribute works under other terms.
> If you don't like that you should choose not to use emacs.

Again: I'm really sorry.  Please understand that it's not you (=the list
members) who I'm angry at.  I'm angry at the stupid legal system I have
to live in.  I do not believe that those laws "prohibit me from copying
other people's creative works without their permission".  This purpose
is better fulfilled by ethics (at least for the currently predominant
values of "law").  Those laws serve (a) the lawyers and (b) the
corporations much more than the authors.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Eric S Fraga]

On Monday, 27 Jul 2015 at 14:10, Marcin Borkowski wrote:

[...]

> And I see no reason to impose GPL on them.))

[...]

> And please understand that if I'm sounding a bit angry in this email,
> it's because I'm *very* angry about this whole lawyer mafia
> restricting my freedom (again).  (Note: I'm all for restricting
> people's freedom when there are important reasons for that.  I just
> consider this situation not to be one of these.)

Interestingly enough, the whole premise of FSF and GPL is that
restrictions imposed by hiding code and/or not allowing redistribution
are restricting our freedom!

You'll find some (many?) of us on this list will disagree fundamentally
with you: for me, GPL is about freedom and ensuring that freedom is
not restricted.  Imposing GPL, as you put it, is about ensuring that
those that want to make use of our code or text pass on the same rights
they made use of in using this code or text.

Note that all of the above is for people writing code that they
subsequently wish to distribute.  If they keep it to themselves, the
licence used is a non-issue...  

Of course, nobody is forced to use any code I write so I am not stopping
anybody from doing whatever they want with *their* code.  Although my
contributions to org are infinitesimally small, I expect the GPL to be
observed in any derivation of org.

YMMV, of course :-)
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

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

[Marcin Borkowski]

On 2015-07-27, at 17:13, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> On Monday, 27 Jul 2015 at 14:10, Marcin Borkowski wrote:
>
> [...]
>
>> And I see no reason to impose GPL on them.))
>
> [...]
>
>> And please understand that if I'm sounding a bit angry in this email,
>> it's because I'm *very* angry about this whole lawyer mafia
>> restricting my freedom (again).  (Note: I'm all for restricting
>> people's freedom when there are important reasons for that.  I just
>> consider this situation not to be one of these.)
>
> Interestingly enough, the whole premise of FSF and GPL is that
> restrictions imposed by hiding code and/or not allowing redistribution
> are restricting our freedom!

As I wrote in other posts (today and also some time ago, on other
FSF-hosted list), I used to consider FSF your typical 3-letter
organization.  Though I revised my standpoint on that a bit, I still am
not a huge fan of FSF and GPL.  Also, I don't consider distributing
non-(free-as-in-FSF) software as morally evil, so I see no reason to
force anyone to use GPL.

> You'll find some (many?) of us on this list will disagree fundamentally
> with you: for me, GPL is about freedom and ensuring that freedom is
> not restricted.  Imposing GPL, as you put it, is about ensuring that
> those that want to make use of our code or text pass on the same rights
> they made use of in using this code or text.

Grown from the TeX community, and knowing how TeX's license works,
I find GPL to be rather restrictive.

And what if I explicitly want people to be able to use my code in
a proprietary software?  Or if I just want to use the "Unlicense"?  Or
if I don't want to use GPL on principle?  (And if I still consider Emacs
to be technically superior to most other software, and do not want to
stop using it and writing Elisp?)  In all these cases, GPL actually
restricts me.

> Note that all of the above is for people writing code that they
> subsequently wish to distribute.  If they keep it to themselves, the
> licence used is a non-issue...  

That I already learned from this discussion.  It's good that FSF does
not try to deny me at least this minimal amount of freedom...  ;-P

> Of course, nobody is forced to use any code I write so I am not stopping
> anybody from doing whatever they want with *their* code.  Although my
> contributions to org are infinitesimally small, I expect the GPL to be
> observed in any derivation of org.

With that I do agree (and it has nothing to do with the question whether
I like GPL or not, it's just basic ethics).  Now the main (and
recurring) question: is an exporter a "derivation" of Org?  My common
sense says it's probably not.  Is an exporter built by copying an
existing one and replacing all the code relevant to one particular
format with the code generating other format, leaving the skeleton
(which is more or less identical in most if not all official exporters,
and it's difficult to even conceive one radically different!) intact,
a "derivation" of the existing exporter?  My common sense is unsure, and
hence my question and this discussion.  Is any Elisp package
a "derivation" of Emacs?  My common sense says definitely not.

> YMMV, of course :-)

Well, it seems it does.  :-)

BTW, while I do not consider myself a "hacker" (in a sense used by RMS)
- I'm probably too inexperienced to deserve to be called that - I find
it ironic in the context of this exchange to recall this excerpt from
RMS's "On hacking":

,----
| Hackers typically had little respect for the silly rules that
| administrators like to impose, so they looked for ways around.
`----

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Oleh Krehel]

Marcin Borkowski <mbork@mbork.pl> writes:

> And what if I explicitly want people to be able to use my code in
> a proprietary software?

Then you're out of luck. Just like thousands (millions) of programmers
are out of luck when they want to examine the code of a closed source
proprietary software.

If I asked someone for Microsoft Word source code, because I want to
understand why my macro doesn't work, they would laugh in my face.  And
then bring up that situation as a joke for years. A credit to FSF
people: no one is laughing at you. Myself included, I tried to explain
the benefits of GPL, but if you don't want to listen that's fine.

--Oleh

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

[Marcin Borkowski]

On 2015-07-27, at 15:58, Scott Randby <srandby@gmail.com> wrote:

> On 07/27/2015 08:10 AM, Marcin Borkowski wrote:
>>
>> Please refrain from comments about my stupidity or stupidity of the
>> so-called IP law.  And please understand that if I'm sounding a bit
>> angry in this email, it's because I'm *very* angry about this whole
>> lawyer mafia restricting my freedom (again).  (Note: I'm all for
>> restricting people's freedom when there are important reasons for that.
>> I just consider this situation not to be one of these.)
>>
>
> If I understand correctly, you wish to use code that other people have 
> written and published under the GPL. These people made the free choice 
> put the conditions of the GPL on the code. I don't see how it is 
> anything other than improper to reuse the code in a public domain 
> setting. I prefer to respect the choices of the code's writers.

I'm afraid that you didn't understand correctly, and I'm sorry for being
too vague.  Let me include an example.

--8<---------------cut here---------------start------------->8---
(defcustom ox-my-cool-menu-key ?o
  "The dispatch key for the My-Cool exporter in the exporter
menu.")

(org-export-define-backend 'my-cool
  '((italic . org-my-cool-italic)
    (bold . org-my-cool-bold)
    (plain-list . org-my-cool-plain-list)
    (item . org-my-cool-item)
    (link . org-my-cool-link)
    (headline . org-my-cool-headline)
    (line-break . org-my-cool-line-break)
    (horizontal-rule . org-my-cool-horizontal-rule)
    (table . org-my-cool-table)
    (table-row . org-my-cool-table-row)
    (table-cell . org-my-cool-table-cell)
    (example-block . org-my-cool-example-block)
    (paragraph . org-my-cool-paragraph)
    (plain-text . org-my-cool-plain-text)
    (section . org-my-cool-section)
    (template . org-my-cool-template))
  :export-block "MY-COOL"
  :menu-entry `(,ox-my-cool-menu-key "Export to My-Cool"
				    ((?O "As buffer" org-my-cool-export-as-my-cool)
				     (?o "As file" org-my-cool-export-to-my-cool))))

(defun org-my-cool-paragraph (paragraph contents info)
  "Transcode PARAGRAPH element into My-Cool format.
CONTENTS is the paragraph contents.  INFO is a plist used as
a communication channel."
  contents)

(defun org-my-cool-plain-text (text info)
  "Transcode a TEXT string from Org to My-Cool.
TEXT is the string to transcode.  INFO is a plist holding
contextual information."
  text)

(defun org-my-cool-section (section contents info)
  "Transcode a SECTION element from Org to My-Cool.
CONTENTS holds the contents of the section.  INFO is a plist
holding contextual information."
  contents)

(defun org-my-cool-template (contents info)
  "Return complete document string after LaTeX conversion.
CONTENTS is the transcoded contents string.  INFO is a plist
holding export options."
  contents)

(defun org-my-cool-italic (italic contents info)
  "Transcode ITALIC from Org-mode to My-Cool."
  (concat "'" contents "'"))

(defun org-my-cool-bold (bold contents info)
  "Transcode BOLD from Org-mode to My-Cool."
  (concat "''" contents "''"))

(defun org-my-cool-plain-list (plain-list contents info)
  "Transcode PLAIN-LIST to My-Cool."
  contents)

(defun org-my-cool-export-as-my-cool
  (&optional async subtreep visible-only body-only ext-plist)
  "Export current buffer as an My-Cool buffer."
  (interactive)
  (org-export-to-buffer 'my-cool "*Org My-Cool Export*"
    async subtreep visible-only body-only ext-plist (lambda ()
						      (when (fboundp #'my-cool-mode) (my-cool-mode)))))
--8<---------------cut here---------------end--------------->8---

The above fragment was written by means of taking (a fragment of)
ox-latex, removing all LaTeX-related parts and filling in my ones (of
course, this one is rather silly).  Assume now that these functions will
be expanded when needed by code generating suitable output.

If I were an author of a (more sophisticated than the above) exporter,
and someone would want to take it, put the "meat" aside, leave the
"skeleton" (as above), fill it with his/her code and publish it under
whatever license s/he wanted, I wouldn't see anything improper about it.
(I *might* expect to be asked first, though, but this would be matter of
politeness, but probably not ethics, and definitely not law.  OTOH,
I probably *would* expect the author to include a short note, like
saying "This code is modelled after ox-whatever.")  I cannot see how
using my code in such a way would be irrespectful.

Actually, such a situation took place a few months ago, though not with
any Elisp code, but with a LaTeX document I published on my website
(someone wanted to take my document, leave the preamble and markup
commands defined by me, and put his contents inside).  He asked me if
I'm fine with it, and my answer was "Of course".  He then proceeded to
ask me how exactly the code is licensed, which I considered a nuisance;
I told him to treat it as CC-licensed (under one of the CC licenses,
I don't recall which one now), just to make him stop asking silly
questions.  (He then proceeded to complain that code should not be
licensed using CC licenses; I wrote back very shortly and ignored him
from that point, since I didn't feel like wasting time on nitpicking).

I am astonished that someone could react differently, especially that
the code is supposed to be "free".  The only regret I have is that
I shouldn't have ignored the guy, but explain (as politely as I can,
which probably means moderately politely at best...) that he's making
fool of himself, since I can license *my* code in whichever way I want,
and besides nobody really cares anyway.

> Scott Randby

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Eric S Fraga]

On Monday, 27 Jul 2015 at 18:01, Marcin Borkowski wrote:

[...]

> And what if I explicitly want people to be able to use my code in
> a proprietary software?  Or if I just want to use the "Unlicense"?  Or
> if I don't want to use GPL on principle?  (And if I still consider Emacs

You are perfectly able to do all of the above with *your* code.  What
you cannot do is "unlicense" my code which I may have released under
GPL.  This is the crux.  I, and others, have not released our codes to
be used however *you* see fit.  We have released them under GPL which
was our decision.

If your code is not based on mine (or any other code released under
GPL), then by all means do what you want with it and give whatever
rights away you wish.  If, however, it is based on GPL, you cannot do
so.

If you write a new exporter based purely on the documented API for use
with org, you can distribute that perfectly fine with whatever licence
you wish, AFAIK.  If you take an existing exporter and modify it for
your target, then you cannot do other than release with GPL.  Likewise
for your tutorial: if it refers to org documentation (e.g. link to Worg
or (info)), that is fine; if it includes org documentation, you are back
to having to release using GPL.

(I'm not a lawyer -- the above is based on my understanding of the
intent of those of us using GPL as part of org.)

I'm off to make dinner now... :-)

cheers,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

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

[Marcin Borkowski]

On 2015-07-27, at 14:39, Daniele Nicolodi <daniele@grinta.net> wrote:

> Hello Marcin,
>
> On 27/07/15 14:10, Marcin Borkowski wrote:
>> Assume that (for some reason) I want to write an Org-mode exporter which
>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>> writing a tutorial on them, and I consider publishing a *tutorial* with
>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>> other people can or even should reuse the code in the tutorial, right?
>> And I see no reason to impose GPL on them.))
>
> As Oleh Krehel pointed out in a reply to another mail of yours, if your
> code links to org-mode code (or other GPL code) you cannot release it
> under a different license. I'm not sure about how linking is intended in
> Elisp sense of ('require)ing a library, but I believe it is analog to
> executable linking in machine code programs.

I understand, and I thank you for your clarification.  (Though I still
consider it plain ridiculous.  And the fact that Oleh's own blog is
CC-BY-NC-SA licensed, and contains many fragments of Elisp code, both
small snippets and whole functions, thus rendering it illegal, is
sweet;-).)

> Therefore, the only extensions to org-mode that can exist (and be
> distributed, if you write code and keep it for yourself you are not
> affected by the licensing terms) must be GPL.
>
> Thus, it makes little sense to continue the discussion: even if you
> would release the code in your tutorial under a different license, it
> would be or no use for who will read it.

I see.  Funnily, I found a few Emacs blogs (also by renowned Emacs
hackers, like Oleh mentioned above) which clearly violate the rule that
any Elisp code should be GPL'd.  So my intuition that nobody cares (at
least until explicitly asked) seems to be confirmed;-).

>> How do I do that?  Is that even possible?  Also, is it possible to get
>> an actual answer to this question without spending money on lawyers?
>
> There is no need to have lawyers involved, if you are in doubt about the
> interpretation of the GPL you can consult the FSF (or other
> organizations) on the matter. They will be happy to answer your question
> with a very high degree of authority on the matter.

As someone mentioned, lawyers will not answer any question with a "high
degree of authority".  Although I admit that this is not entirely their
fault.

>> The manual says:
>> 
>> ,----
>> | Your two entry points are respectively ‘org-export-define-backend’ and
>> | ‘org-export-define-derived-backend’.  To grok these functions, you
>> | should first have a look at ‘ox-latex.el’ (for how to define a new
>> | back-end from scratch) and ‘ox-beamer.el’ (for how to derive a new
>> | back-end from an existing one.
>> `----
>> 
>> So basically you are expected to use existing GPL'd code to learn to
>> write new exporters.
>
> The manual makes the thing easy for the ones that want to respect the
> authors choice of license.

I *do* want to respect the authors, and their choice of license.  For
instance, after all this discussion, I will GPL my tutorial (and
probably include an explanation why it's not PD, CC0 or anything like
that).  Although I doubt that all authors bear in mind (or even know)
these consequences of their choosing GPL.

>> Also, the overall structure of the exporters is extremally similar.  For
>> instance, the :menu-entry argument of org-export-define-backend is
>> almost the same for all exporters (and it should be, in order not to
>> break usability!).  Should I follow such conventions, in order to
>> satisfy users, or should I deliberately break it, in order to satisfy
>> lawyers?
>
> First, your goal is not to satisfy lawyers, but to comply with the
> license terms. The license terms are chosen by the authors of the code,
> thus you are satisfying the wishes of whom granted you access to their
> code. It is the minimum you should do to thank them.

I thank the authors in many ways.  I also hold them in very high
respect.  As I mentioned in an earlier post, I (as an author) consider
being nitpicky about licensing and such as wasting the author's time and
annoying him, and I see little or no value (besides "satisfying
lawyers") in analyzing licenses like we are doing now.

> Second, if that is the only structure that makes sense, you can
> re-invent it without looking at the GPL code. Thus you can use a similar
> structure in your differently licensed code. However, you should really
> have re-created it without looking at the original. This email already
> suggests otherwise.

And who cares whether I did look at the code or not?  I mean, besides
lawyers?

>> Also, the names of functions (like `org-latex-export-as-latex' vs
>> `org-latex-export-to-latex') are similar across exporters.  Should I use
>> this convention, too, in order to satisfy fellow programmers, or should
>> I deliberately break it, in order to satisfy lawyers?
>
> Function names are not copyrightable (as far as I know).

Whoa!  Now things are getting really funny.  I'm not a logician, but
from what I recall from my logic lectures, anonymous functions' names
are their bodies.  Does that mean that if I rewrite everything using
lambdas (which is theoretically possible), I'm fine?  ;-) ;-) ;-)

>> Also, the docstrings of many transcoders are similar.  How am I supposed
>> to write a docstring which is at the same time more or less
>> comprehensive and different enough from the existing ones, so that
>> I don't end up in jail?  (<--- this is actually a joke.  I hope so at
>> least...)
>
> There is a minimum unit of "code" that is copyrightable (the word "the"
> appears in many copyrighted works, but you can still use it in your
> own). If the doc-strings are trivial you can freely write something similar.

As has been settled, docstrings are only a nuisance, not a real problem here.

> Cheers,
> Daniele

Best, and thanks again for your insights!  Angry or not, and whether
I like the legal system or not, I learned a lot from you today.

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Marcin Borkowski]

On 2015-07-27, at 18:54, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> On Monday, 27 Jul 2015 at 18:01, Marcin Borkowski wrote:
>
> [...]
>
>> And what if I explicitly want people to be able to use my code in
>> a proprietary software?  Or if I just want to use the "Unlicense"?  Or
>> if I don't want to use GPL on principle?  (And if I still consider Emacs
>
> You are perfectly able to do all of the above with *your* code.  What
> you cannot do is "unlicense" my code which I may have released under
> GPL.  This is the crux.  I, and others, have not released our codes to
> be used however *you* see fit.  We have released them under GPL which
> was our decision.

Nope.  As stated by someone here (Oleh, I guess), if I (require 'org),
or possibly even just write Elisp, and want to distribute it, it has to
be GPL.

> If your code is not based on mine (or any other code released under
> GPL), then by all means do what you want with it and give whatever
> rights away you wish.  If, however, it is based on GPL, you cannot do
> so.

Also, see my other post to see what I mean by "being based" in this
context.  It boils down to the question "how much of other code (even
rather generic parts) can I take and still consider this *my* code)".
And this is still not clear.

> If you write a new exporter based purely on the documented API for use
> with org, you can distribute that perfectly fine with whatever licence
> you wish, AFAIK.  If you take an existing exporter and modify it for
> your target, then you cannot do other than release with GPL.  Likewise
> for your tutorial: if it refers to org documentation (e.g. link to Worg
> or (info)), that is fine; if it includes org documentation, you are back
> to having to release using GPL.
>
> (I'm not a lawyer -- the above is based on my understanding of the
> intent of those of us using GPL as part of org.)

I'm glad to hear that we (more or less) agree.  I'm less glad that quite
probably we are mistaken.

> I'm off to make dinner now... :-)
>
> cheers,
> eric

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Marcin Borkowski]

On 2015-07-27, at 18:12, Oleh Krehel <ohwoeowho@gmail.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> And what if I explicitly want people to be able to use my code in
>> a proprietary software?
>
> Then you're out of luck. Just like thousands (millions) of programmers
> are out of luck when they want to examine the code of a closed source
> proprietary software.

Good point.  I like the conciseness of your one-sentence summary of the
situation:-).

> If I asked someone for Microsoft Word source code, because I want to
> understand why my macro doesn't work, they would laugh in my face.  And
> then bring up that situation as a joke for years. A credit to FSF
> people: no one is laughing at you. Myself included, I tried to explain
> the benefits of GPL, but if you don't want to listen that's fine.

I'm glad that nobody is laughing at me, though I don't like being
accused of being impolite/rude/inflammatory - even if justly - and
I even more dislike being accused of being irrespectful (and I consider
this accusation to be unjust - after all, I came here to ask, and I plan
to follow the rules, no matter how ridiculous they are).  Also, I do
listen to you - I just want to point out that, while GPL clearly has
benefits (and I do not deny that!), it also has drawbacks, and that
people are entitled not to like it.

On a tangentially related note, as I pointed out in another post, you
might want to make the license note on your blog compliant;-).

> --Oleh

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Thomas S. Dye]

Oleh Krehel <ohwoeowho@gmail.com> writes:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> And what if I explicitly want people to be able to use my code in
>> a proprietary software?
>
> Then you're out of luck. Just like thousands (millions) of programmers
> are out of luck when they want to examine the code of a closed source
> proprietary software.
>
> If I asked someone for Microsoft Word source code, because I want to
> understand why my macro doesn't work, they would laugh in my face.  And
> then bring up that situation as a joke for years. A credit to FSF
> people: no one is laughing at you. Myself included, I tried to explain
> the benefits of GPL, but if you don't want to listen that's fine.
>
> --Oleh

Amen. History over the last 500 years is littered with defunct social
organizations based on rights of person (claims that members can't be
excluded from the use or enjoyment of some social product, like the
GPL).  Over and over, the introduction into them of property rights
(claims that individuals can exclude members from the use or enjoyment
of some social product), often against violent protest, eventually
destroyed both the social organizations and the rights of person they
tried to perpetuate.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

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

[Nick Dokos]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2015-07-27, at 14:39, Daniele Nicolodi <daniele@grinta.net> wrote:
>
>> Hello Marcin,
>>
>> On 27/07/15 14:10, Marcin Borkowski wrote:
>>> Assume that (for some reason) I want to write an Org-mode exporter which
>>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>>> writing a tutorial on them, and I consider publishing a *tutorial* with
>>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>>> other people can or even should reuse the code in the tutorial, right?
>>> And I see no reason to impose GPL on them.))
>>
>> As Oleh Krehel pointed out in a reply to another mail of yours, if your
>> code links to org-mode code (or other GPL code) you cannot release it
>> under a different license. I'm not sure about how linking is intended in
>> Elisp sense of ('require)ing a library, but I believe it is analog to
>> executable linking in machine code programs.
>
> I understand, and I thank you for your clarification.  (Though I still
> consider it plain ridiculous.  And the fact that Oleh's own blog is
> CC-BY-NC-SA licensed, and contains many fragments of Elisp code, both
> small snippets and whole functions, thus rendering it illegal, is
> sweet;-).)
>

Illegal? You are building strawmen.

>> Therefore, the only extensions to org-mode that can exist (and be
>> distributed, if you write code and keep it for yourself you are not
>> affected by the licensing terms) must be GPL.
>>
>> Thus, it makes little sense to continue the discussion: even if you
>> would release the code in your tutorial under a different license, it
>> would be or no use for who will read it.
>
> I see.  Funnily, I found a few Emacs blogs (also by renowned Emacs
> hackers, like Oleh mentioned above) which clearly violate the rule that
> any Elisp code should be GPL'd.  So my intuition that nobody cares (at
> least until explicitly asked) seems to be confirmed;-).
>

There is no such rule anywhere so this is another strawman. You can
write an emacs module and use whatever license you want, put it up on
the web (or not) and do anything you want with it. Just don't expect
it to become part of emacs: it will have a separate life (and most
probably a short one when you get bored with it). Ditto for your
tutorial.

Nick

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

[Marcin Borkowski]

On 2015-07-27, at 20:02, Nick Dokos <ndokos@gmail.com> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> On 2015-07-27, at 14:39, Daniele Nicolodi <daniele@grinta.net> wrote:
>>
>>> Hello Marcin,
>>>
>>> On 27/07/15 14:10, Marcin Borkowski wrote:
>>>> Assume that (for some reason) I want to write an Org-mode exporter which
>>>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>>>> writing a tutorial on them, and I consider publishing a *tutorial* with
>>>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>>>> other people can or even should reuse the code in the tutorial, right?
>>>> And I see no reason to impose GPL on them.))
>>>
>>> As Oleh Krehel pointed out in a reply to another mail of yours, if your
>>> code links to org-mode code (or other GPL code) you cannot release it
>>> under a different license. I'm not sure about how linking is intended in
>>> Elisp sense of ('require)ing a library, but I believe it is analog to
>>> executable linking in machine code programs.
>>
>> I understand, and I thank you for your clarification.  (Though I still
>> consider it plain ridiculous.  And the fact that Oleh's own blog is
>> CC-BY-NC-SA licensed, and contains many fragments of Elisp code, both
>> small snippets and whole functions, thus rendering it illegal, is
>> sweet;-).)
>>
>
> Illegal? You are building strawmen.
>
>>> Therefore, the only extensions to org-mode that can exist (and be
>>> distributed, if you write code and keep it for yourself you are not
>>> affected by the licensing terms) must be GPL.
>>>
>>> Thus, it makes little sense to continue the discussion: even if you
>>> would release the code in your tutorial under a different license, it
>>> would be or no use for who will read it.
>>
>> I see.  Funnily, I found a few Emacs blogs (also by renowned Emacs
>> hackers, like Oleh mentioned above) which clearly violate the rule that
>> any Elisp code should be GPL'd.  So my intuition that nobody cares (at
>> least until explicitly asked) seems to be confirmed;-).
>>
>
> There is no such rule anywhere so this is another strawman. You can
> write an emacs module and use whatever license you want, put it up on
> the web (or not) and do anything you want with it. Just don't expect

Really?  As Oleh wrote:

,----
| Like I said in an earlier message just a few minutes ago, you can do it,
| but you can't use org.el or Elisp at all, unless you implement your own
| Elisp engine that you call.
`----

AFAIU, he wrote about writing *any* Elisp.

> it to become part of emacs: it will have a separate life (and most
> probably a short one when you get bored with it). Ditto for your
> tutorial.

And thank you so much for your encouragement.

> Nick

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

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

[Richard Lawrence]

Hi Marcin and all,

Marcin Borkowski <mbork@mbork.pl> writes:

> after a short discussion in a recent thread, I have a serious technical
> question.
>
> Assume that (for some reason) I want to write an Org-mode exporter which
> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
> writing a tutorial on them, and I consider publishing a *tutorial* with
> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
> other people can or even should reuse the code in the tutorial, right?
> And I see no reason to impose GPL on them.))

I am not a lawyer, this is not legal advice, etc., but for what it's
worth, here's my opinion:

It sounds to me like you are not creating a program derived from GPL'ed
code, but rather *quoting* GPL'ed code (and introducing some
modifications to those quotes) in a document whose purpose is to educate
its readers.

I don't know about your jurisdiction, but in the U.S., that sounds to me
like it would fall well within the bounds of fair use:

https://en.wikipedia.org/wiki/Fair_use

(There is also a brief section there about fair use in Poland; maybe
that will help you?)

Only a court can say, but if you are only publishing this source code as
part of a tutorial, so that it
  - has an educational purpose
  - serves to discuss ideas that can be gleaned from reading the original
  - does not substantially copy the original
  - does not devalue the original 
then I would guess the GPL does not apply to the code, as it is quoted/derived
in your tutorial, due to a fair use limitation.

So my advice would be: (1) treat the code in your tutorial along
whatever lines are appropriate for quotation of copyrighted works in
your jurisdiction; and (2) maybe include a notice in your tutorial to
your readers, that if they create *and distribute* a working exporter
based on the code in your tutorial and/or code in the Org distribution,
the GPL may apply.

If you are actually distributing the complete exporter as a working
program, that seems a little murkier to me; the issue there, as you are
aware, is whether that working program counts as a derived work.  I have
no idea how to answer that question.

Hope that helps!

Best,
Richard

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

[Eric S Fraga]

On Monday, 27 Jul 2015 at 19:04, Marcin Borkowski wrote:

[...]

> Nope.  As stated by someone here (Oleh, I guess), if I (require 'org),
> or possibly even just write Elisp, and want to distribute it, it has to
> be GPL.

I do not think this is true.  I would like to see a proper reference
where it is shown to be the case.  Oleh?

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

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

[Daniele Nicolodi]

On 27/07/15 18:59, Marcin Borkowski wrote:
> On 2015-07-27, at 14:39, Daniele Nicolodi <daniele@grinta.net> wrote:
>> Therefore, the only extensions to org-mode that can exist (and be
>> distributed, if you write code and keep it for yourself you are not
>> affected by the licensing terms) must be GPL.
>>
>> Thus, it makes little sense to continue the discussion: even if you
>> would release the code in your tutorial under a different license, it
>> would be or no use for who will read it.
> 
> I see.  Funnily, I found a few Emacs blogs (also by renowned Emacs
> hackers, like Oleh mentioned above) which clearly violate the rule that
> any Elisp code should be GPL'd.  So my intuition that nobody cares (at
> least until explicitly asked) seems to be confirmed;-).

Only who detains the copyright in something can enforce his licensing
terms. The copyright holder can decide that a specific use of its
copyrights material is fine and allow it, despite it not following
strictly the license agreement. In this case (I believe) the FSF
recognizes that there is no point in nitpicking on the license of a few
snippets of code. However, the FSF could ask in any moment to have the
license of those snippets clarified.

>>> How do I do that?  Is that even possible?  Also, is it possible to get
>>> an actual answer to this question without spending money on lawyers?
>>
>> There is no need to have lawyers involved, if you are in doubt about the
>> interpretation of the GPL you can consult the FSF (or other
>> organizations) on the matter. They will be happy to answer your question
>> with a very high degree of authority on the matter.
> 
> As someone mentioned, lawyers will not answer any question with a "high
> degree of authority".  Although I admit that this is not entirely their
> fault.

Who spoke about lawyers? I suggested to contact the FSF (or other
organizations involved in GPL enforcement). The FSF is the organizations
that wrote the GPL and that detains the copyright of a fairly large
codebase released under the GPL. Therefore they know what they meant
when they wrote it.

Furthermore, they detain the copyright on Emacs (and its Elisp
implementation) and org-mode, the project from which you are basing (or
not) your work. Therefore, they are authoritative when they deal with
copyright issues on that code.

I will not comment on the rest of your nonsensical arguments.

Cheers,
Daniele

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

[Oleh Krehel]

Marcin Borkowski <mbork@mbork.pl> writes:

>> As Oleh Krehel pointed out in a reply to another mail of yours, if your
>> code links to org-mode code (or other GPL code) you cannot release it
>> under a different license. I'm not sure about how linking is intended in
>> Elisp sense of ('require)ing a library, but I believe it is analog to
>> executable linking in machine code programs.
>
> I understand, and I thank you for your clarification.  (Though I still
> consider it plain ridiculous.  And the fact that Oleh's own blog is
> CC-BY-NC-SA licensed, and contains many fragments of Elisp code, both
> small snippets and whole functions, thus rendering it illegal, is
> sweet;-).)

I think posting snippets on a blog falls into "Fair Use". As long as I'm
not posting something which is a full program, this is fine.  Besides,
CC-BY-NC-SA is compatible with GPL! Compatible. With GPL.

Quoting the SA (ShareAlike) part from the website:

> ShareAlike — If you remix, transform, or build upon the material, you
> must distribute your contributions under the same license as the
> original.

So if anyone dislikes GPL, add CC-...-SA to your list as well.

--Oleh

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

[Oleh Krehel]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Monday, 27 Jul 2015 at 19:04, Marcin Borkowski wrote:
>
> [...]
>
>> Nope.  As stated by someone here (Oleh, I guess), if I (require 'org),
>> or possibly even just write Elisp, and want to distribute it, it has to
>> be GPL.
>
> I do not think this is true.  I would like to see a proper reference
> where it is shown to be the case.  Oleh?

Look here:
https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License&section=11#Libraries

Most useful quote:

> The Free Software Foundation (which holds the copyright of several
> notable GPL-licensed software products and of the license text itself)
> asserts that an executable which uses a dynamically linked library is
> indeed a derivative work. This does not however apply to separate
> programs communicating with one another.

So calling GNU find in your program via the shell call API (or whatever
else, pipes ...) of your language is totally fine.

But adding #include "find.h" to your code is not fine, according to FSF.
Same thing with Org: adding a shell call "emacs --eval org-export ..."
is fine. Adding (require 'org) to your program is not fine.

Org the text format is fully open and not copyright-able. Anyone can
choose to support it (Orgzzly, Trello etc.). Org-mode's Elisp
implementation is GPL, just like the whole of the Elisp interpreter.

You could argue about Elisp being close to Common Lisp, and indeed: if
you write in a subset of Elisp that is compatible with Common Lisp,
you're not using "the Elisp standard library", and your code can run on
whatever CL implementation and you don't have to GPL your code.

One could try make a BSD licensed Emacs, just like the Wine (https://www.winehq.org/) project was
made to emulate Windows: just try to adhere to the API without reusing
any of the original code.

See also GNU LGPL: https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License.
That license explicitly allows closed code to link to a free software
library. Since this license exists, it's natural to assume that GPL does
not allow this.

--Oleh

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

[Eric S Fraga]

On Tuesday, 28 Jul 2015 at 10:07, Oleh Krehel wrote:

[...]

> Look here:
> https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License&section=11#Libraries
>
> Most useful quote:
>
>> The Free Software Foundation (which holds the copyright of several
>> notable GPL-licensed software products and of the license text itself)
>> asserts that an executable which uses a dynamically linked library is
>> indeed a derivative work. This does not however apply to separate
>> programs communicating with one another.

Oleh,

thanks for this link and excerpt.  I could argue that the key word in
the excerpt is "executable".  I cannot see how code written in elisp
itself would need to be GPL.  Distributing it *with* emacs would
probably require it being GPLed but the source code itself, if not based
on already GPLed code, should be fine, e.g. in the context of a
tutorial.

Anyway, I think we've beaten this to death already.  Time to get real
work done! :-)

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

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

[Oleh Krehel]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Anyway, I think we've beaten this to death already.  Time to get real
> work done! :-)

That is my usual approach: label everything I write with GPL and not
think about it:)

It's just that most posts about GPL cast it in a bad light: I think it's
the best license, and I don't want people who casually read this list to
think that GPL has no supporters or that we are somehow "stuck" with it,
or it is imposed on us.

Even if I was not *required* to use this license, I would *choose* to
use it, because I like the idea.

--Oleh

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

[Andreas Hilboll]

>> Look here:
>> https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License&section=11#Libraries
>>
>> Most useful quote:
>>
>>> The Free Software Foundation (which holds the copyright of several
>>> notable GPL-licensed software products and of the license text itself)
>>> asserts that an executable which uses a dynamically linked library is
>>> indeed a derivative work. This does not however apply to separate
>>> programs communicating with one another.
> 
> Oleh,
> 
> thanks for this link and excerpt.  I could argue that the key word in
> the excerpt is "executable".  I cannot see how code written in elisp
> itself would need to be GPL.

Exactly.  To quote again
https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL:

   When the interpreter just interprets a language, the answer is no.
   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.

--
Andreas Hilboll

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

[Oleh Krehel]

Andreas Hilboll <lists@hilboll.de> writes:

>>> Look here:
>>> https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License&section=11#Libraries
>>>
>>> Most useful quote:
>>>
>>>> The Free Software Foundation (which holds the copyright of several
>>>> notable GPL-licensed software products and of the license text itself)
>>>> asserts that an executable which uses a dynamically linked library is
>>>> indeed a derivative work. This does not however apply to separate
>>>> programs communicating with one another.

>> thanks for this link and excerpt.  I could argue that the key word in
>> the excerpt is "executable".  I cannot see how code written in elisp
>> itself would need to be GPL.
>
> Exactly.  To quote again
> https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL:
>
>    When the interpreter just interprets a language, the answer is no.
>    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.

Just to link the paragraph exactly below the one you quoted

> However, when the interpreter is extended to provide “bindings” to
> other facilities (often, but not necessarily, libraries), the
> interpreted program is effectively linked to the facilities it uses
> through these bindings. So if these facilities are released under the
> GPL, the interpreted program that uses them must be released in a
> GPL-compatible way. The JNI or Java Native Interface is an example of
> such a binding mechanism; libraries that are accessed in this way are
> linked dynamically with the Java programs that call them. These
> libraries are also linked with the interpreter. If the interpreter is
> linked statically with these libraries, or if it is designed to link
> dynamically with these specific libraries, then it too needs to be
> released in a GPL-compatible way.

Indeed, the Emacs interpreter gives "bindings" to all Emacs facilities,
which are GPL, and the interpreted program that uses them must be
released in a GPL-compatible way.

Plus Emacs supports byte compilation: someone could publish only the
exporter.elc, without providing exporter.el. That would be illegal, but
if the third party is given exporter.el released under BSD by a second
party, theoretically they could do it. Therefore, the second party
should not be allowed to change to BSD if they're linking to GPL code.

--Oleh

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

[Andreas Hilboll]

On 28.07.2015 11:30, Oleh Krehel wrote:
> Andreas Hilboll <lists@hilboll.de> writes:
> 
>>>> Look here:
>>>> https://en.wikipedia.org/w/index.php?title=GNU_General_Public_License&section=11#Libraries
>>>>
>>>> Most useful quote:
>>>>
>>>>> The Free Software Foundation (which holds the copyright of several
>>>>> notable GPL-licensed software products and of the license text itself)
>>>>> asserts that an executable which uses a dynamically linked library is
>>>>> indeed a derivative work. This does not however apply to separate
>>>>> programs communicating with one another.
> 
>>> thanks for this link and excerpt.  I could argue that the key word in
>>> the excerpt is "executable".  I cannot see how code written in elisp
>>> itself would need to be GPL.
>>
>> Exactly.  To quote again
>> https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL:
>>
>>    When the interpreter just interprets a language, the answer is no.
>>    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.
> 
> Just to link the paragraph exactly below the one you quoted
> 
>> However, when the interpreter is extended to provide “bindings” to
>> other facilities (often, but not necessarily, libraries), the
>> interpreted program is effectively linked to the facilities it uses
>> through these bindings. So if these facilities are released under the
>> GPL, the interpreted program that uses them must be released in a
>> GPL-compatible way. The JNI or Java Native Interface is an example of
>> such a binding mechanism; libraries that are accessed in this way are
>> linked dynamically with the Java programs that call them. These
>> libraries are also linked with the interpreter. If the interpreter is
>> linked statically with these libraries, or if it is designed to link
>> dynamically with these specific libraries, then it too needs to be
>> released in a GPL-compatible way.
> 
> Indeed, the Emacs interpreter gives "bindings" to all Emacs facilities,
> which are GPL, and the interpreted program that uses them must be
> released in a GPL-compatible way.

I would interpret this as

   "As long as I write pure elisp and don't require' and GPL'ed part of
   Emacs, I can release my code under any license I want.  If I do
   require' any part of Emacs, I have to go the GPL path."

If I'm wrong with this interpretation, please explain why.

-- Andreas.

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

[Oleh Krehel]

Andreas Hilboll <lists@hilboll.de> writes:

>>> However, when the interpreter is extended to provide “bindings” to
>>> other facilities (often, but not necessarily, libraries), the
>>> interpreted program is effectively linked to the facilities it uses
>>> through these bindings. So if these facilities are released under the
>>> GPL, the interpreted program that uses them must be released in a
>>> GPL-compatible way. The JNI or Java Native Interface is an example of
>>> such a binding mechanism; libraries that are accessed in this way are
>>> linked dynamically with the Java programs that call them. These
>>> libraries are also linked with the interpreter. If the interpreter is
>>> linked statically with these libraries, or if it is designed to link
>>> dynamically with these specific libraries, then it too needs to be
>>> released in a GPL-compatible way.
>> 
>> Indeed, the Emacs interpreter gives "bindings" to all Emacs facilities,
>> which are GPL, and the interpreted program that uses them must be
>> released in a GPL-compatible way.
>
> I would interpret this as
>
>    "As long as I write pure elisp and don't require' and GPL'ed part of
>    Emacs, I can release my code under any license I want.  If I do
>    require' any part of Emacs, I have to go the GPL path."
>
> If I'm wrong with this interpretation, please explain why.

Your interpretation is entirely correct. However, to write almost any
useful code, you're going to need to require some parts of
Emacs. Anything that interacts with text in a buffer will need to call
`buffer-string' eventually - GPL-ed code.

Here are the famous 9 lines from the Oracle-Google Java lawsuit:

    private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
         if (fromIndex > toIndex)
              throw new IllegalArgumentException("fromIndex(" + fromIndex +
                   ") > toIndex(" + toIndex+")");
         if (fromIndex < 0) 
              throw new ArrayIndexOutOfBoundsException(fromIndex);
         if (toIndex > arrayLen) 
              throw new ArrayIndexOutOfBoundsException(toIndex);
    }

This lawsuit is currently on some sort of appeal now. The code above is
essentially the most simple, efficient and obvious way to implement the
rangeCheck function based on the API signature. And still they sued.

On the other hand, the implementation of `buffer-string' isn't at all
trivial:

    DEFUN ("buffer-string", Fbuffer_string, Sbuffer_string, 0, 0, 0,
           doc: /* Return the contents of the current buffer as a string.
    If narrowing is in effect, this function returns only the visible part
    of the buffer.  */)
      (void)
    {
      return make_buffer_string_both (BEGV, BEGV_BYTE, ZV, ZV_BYTE, 1);
    }

    Lisp_Object
    make_buffer_string_both (ptrdiff_t start, ptrdiff_t start_byte,
    			 ptrdiff_t end, ptrdiff_t end_byte, bool props)
    {
      Lisp_Object result, tem, tem1;
    
      if (start < GPT && GPT < end)
        move_gap_both (start, start_byte);
    
      if (! NILP (BVAR (current_buffer, enable_multibyte_characters)))
        result = make_uninit_multibyte_string (end - start, end_byte - start_byte);
      else
        result = make_uninit_string (end - start);
      memcpy (SDATA (result), BYTE_POS_ADDR (start_byte), end_byte - start_byte);
    
      /* If desired, update and copy the text properties.  */
      if (props)
        {
          update_buffer_properties (start, end);
    
          tem = Fnext_property_change (make_number (start), Qnil, make_number (end));
          tem1 = Ftext_properties_at (make_number (start), Qnil);
    
          if (XINT (tem) != end || !NILP (tem1))
    	copy_intervals_to_string (result, current_buffer, start,
    				  end - start);
        }

      return result;
    }

It's possible to write some complex number-crunching functions without
relying on the Elisp library. That's the only use-case that I see of
using Emacs like an interpreter and not relying on the "bindings" to the
code that it provides.

--Oleh

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

[Eric S Fraga]

On Tuesday, 28 Jul 2015 at 11:00, Oleh Krehel wrote:
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> Anyway, I think we've beaten this to death already.  Time to get real
>> work done! :-)
>
> That is my usual approach: label everything I write with GPL and not
> think about it:)
>
> It's just that most posts about GPL cast it in a bad light: I think it's
> the best license, and I don't want people who casually read this list to
> think that GPL has no supporters or that we are somehow "stuck" with it,
> or it is imposed on us.
>
> Even if I was not *required* to use this license, I would *choose* to
> use it, because I like the idea.
>
> --Oleh

Well said.  I'm with you on this completely!

Having said this, some of what I write cannot be GPLed due to
restrictions imposed on me by my employer but at least all research
publications we generate now have to be open access so we're moving in
the right direction.

And speaking of research publications, time to get back to the one I'm
working on now, using org of course ;-) including ox-latex, ob-octave,
ob-shell, and ob-gnuplot!

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1293-g985420

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

[Paul Rudin]

Oleh Krehel <ohwoeowho-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> Marcin Borkowski <mbork-yQ6rpnL/fpw@public.gmane.org> writes:
>
>> Hi all,
>>
>> after a short discussion in a recent thread, I have a serious technical
>> question.
>>
>> Assume that (for some reason) I want to write an Org-mode exporter which
>> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
>> writing a tutorial on them, and I consider publishing a *tutorial* with
>> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
>> other people can or even should reuse the code in the tutorial, right?
>> And I see no reason to impose GPL on them.))
>>
>> How do I do that?  Is that even possible?  Also, is it possible to get
>> an actual answer to this question without spending money on lawyers?
>
> Like I said in an earlier message just a few minutes ago, you can do it,
> but you can't use org.el or Elisp at all, unless you implement your own
> Elisp engine that you call.

AIUI, in the UK at least this isn't correct. There is no infringement of
copyright by writing and distributing your own elisp (or any other
language) code.

Whether or not somebody else chooses to use a particular elisp
implementation to run that code is up to them. But you don't have any
liability simply by using the language.

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

[Aaron Ecay]

Hi Oleh,

2015ko uztailak 28an, Oleh Krehel-ek idatzi zuen:
> Besides, CC-BY-NC-SA is compatible with GPL! Compatible. With GPL.

This isn’t correct.  -NC licenses are non-Free (in the FSF sense of the
word): <https://www.gnu.org/licenses/license-list.en.html#CC-BY-NC>
-SA licenses are Free, but not GPL-compatible, as indicated
by the dashed orange line in the left-hand margin at:
<https://www.gnu.org/licenses/license-list.en.html#ccbysa>

-- 
Aaron Ecay

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

[Oleh Krehel]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:
>> Besides, CC-BY-NC-SA is compatible with GPL! Compatible. With GPL.
>
> This isn’t correct.  -NC licenses are non-Free (in the FSF sense of the
> word): <https://www.gnu.org/licenses/license-list.en.html#CC-BY-NC>
> -SA licenses are Free, but not GPL-compatible, as indicated
> by the dashed orange line in the left-hand margin at:
> <https://www.gnu.org/licenses/license-list.en.html#ccbysa>

Thanks for clarifying. Maybe I should switch to CC-BY-SA instead.
Theoretically, I wouldn't want someone to simply mirror my blog and put
ads on it. But I guess it would be fine if a link to my blog is
provided, since then the reader is then aware of the option for ad-free
posts.

On the other hand, I wouldn't want to restrict anyone from significantly
building upon my content and making money from that.

--Oleh

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

[Phillip Lord]

Marcin Borkowski <mbork@mbork.pl> writes:

> Hi all,
>
> after a short discussion in a recent thread, I have a serious technical
> question.
>
> Assume that (for some reason) I want to write an Org-mode exporter which
> won't be GPL'd.  (Use-case: having written a few custom exporters, I'm
> writing a tutorial on them, and I consider publishing a *tutorial* with
> GPL'd code a Bad Thing™.  (The idea of a programming tutorial is that
> other people can or even should reuse the code in the tutorial, right?
> And I see no reason to impose GPL on them.))
>
> How do I do that?  Is that even possible?  Also, is it possible to get
> an actual answer to this question without spending money on lawyers?


I hesitate to answer this, as the thread has already been long and I am
very late, but it seems to me that the thread has been wrong headed.

Yes, you can do this. To do it, well, you just do it.

My evidence for these statements are as follows:

;;; emerge.el --- merge diffs under Emacs control

;;; The author has placed this file in the public domain.

;; This file is part of GNU Emacs.

This is the header of emerge.el which is PART OF emacs, and yet under
public domain, explicitly.

However, you have to consider carefully what rights this gives you. The
combined work can only be released GPL. You can combine GPL and public
domain because public domain section does not add any further
restrictions than the GPL already does. However, because you include GPL
code, you can *only* release the derivative work under GPL.

However, your public domain code can be used without GPL.

My evidence for this statement is from the GPL faq


If a program combines public-domain code with GPL-covered code, can I
take the public-domain part and use it as public domain code?
(#CombinePublicDomainWithGPL)

    You can do that, if you can figure out which part is the public
    domain part and separate it from the rest. If code was put in the
    public domain by its developer, it is in the public domain no matter
    where it has been.


My interpretation is, therefore, that theoretically, if someone re-wrote
Emacs, and org-mode with no shared code but the same function names
public domain, therefore, they could use your exporter. In practice this
is never going to happen.

However, say you wrote an exporter which included a general purpose
piece of code (say a quick sort), someone else *could* take that piece
of code and use it, for example, on another lisp as they chose, even in
a closed source product because your exporter is only under PD, and
there are no restrictions on it use. Possible but unlikely, I think, as
an org-mode exporter is a pretty specific piece of code.

You might, however, want to do this because for a blog post, it avoids
issues of how to interpret the GPL, including "linking" and all that
entails within the context of what is, after all, documentation.

That is my interpretation, with evidence. I think my position largely
disagrees with what others have said. My apologies to everyone who sees
my start this as a zombie thread who says "oh know, no that again".

Phil