Re: [O] 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