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

[Greg Troxel]

Marcin Borkowski <address@hidden> 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.

pgp3tD6kcHGVg.pgp
Description: PGP signature