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

2015-08-04 Thread Phillip Lord


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




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

2015-07-30 Thread Oleh Krehel

Hi Aaron,

Aaron Ecay aarone...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-29 Thread 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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Andreas Hilboll
 Look here:
 https://en.wikipedia.org/w/index.php?title=GNU_General_Public_Licensesection=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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Oleh Krehel
Marcin Borkowski mb...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Oleh Krehel
Eric S Fraga e.fr...@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_Licensesection=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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Oleh Krehel
Andreas Hilboll li...@hilboll.de writes:

 Look here:
 https://en.wikipedia.org/w/index.php?title=GNU_General_Public_Licensesection=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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Andreas Hilboll
On 28.07.2015 11:30, Oleh Krehel wrote:
 Andreas Hilboll li...@hilboll.de writes:
 
 Look here:
 https://en.wikipedia.org/w/index.php?title=GNU_General_Public_Licensesection=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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Oleh Krehel
Andreas Hilboll li...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Eric S Fraga
On Tuesday, 28 Jul 2015 at 11:00, Oleh Krehel wrote:
 Eric S Fraga e.fr...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread 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_Licensesection=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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Oleh Krehel
Eric S Fraga e.fr...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-28 Thread Paul Rudin
Oleh Krehel ohwoeo...@gmail.com writes:

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

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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Rainer M Krug
Oleh Krehel ohwoeo...@gmail.com writes:

 Marcin Borkowski mb...@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:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature


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

2015-07-27 Thread Greg Troxel

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


pgpl0pXcsFXeK.pgp
Description: PGP signature


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

2015-07-27 Thread 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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Rainer M Krug
Andreas Hilboll li...@hilboll.de writes:

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

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature


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

2015-07-27 Thread Greg Troxel

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

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

2015-07-27 Thread Marcin Borkowski

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

 Rainer M Krug rai...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Oleh Krehel
Marcin Borkowski mb...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Marcin Borkowski

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

 Marcin Borkowski mb...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread 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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Andreas Hilboll
On 27.07.2015 15:09, Greg Troxel wrote:
 
 Rainer M Krug rai...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread 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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Marcin Borkowski

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

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

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

2015-07-27 Thread Marcin Borkowski

On 2015-07-27, at 17:13, Eric S Fraga e.fr...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread 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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread 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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Marcin Borkowski

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

 Marcin Borkowski mb...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Oleh Krehel
Marcin Borkowski mb...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Marcin Borkowski

On 2015-07-27, at 15:58, Scott Randby sran...@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 

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

2015-07-27 Thread Marcin Borkowski

On 2015-07-27, at 18:54, Eric S Fraga e.fr...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Marcin Borkowski

On 2015-07-27, at 14:39, Daniele Nicolodi dani...@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 

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

2015-07-27 Thread Nick Dokos
Marcin Borkowski mb...@mbork.pl writes:

 On 2015-07-27, at 14:39, Daniele Nicolodi dani...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Marcin Borkowski

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

 Marcin Borkowski mb...@mbork.pl writes:

 On 2015-07-27, at 14:39, Daniele Nicolodi dani...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Thomas S . Dye

Oleh Krehel ohwoeo...@gmail.com writes:

 Marcin Borkowski mb...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Daniele Nicolodi
On 27/07/15 18:59, Marcin Borkowski wrote:
 On 2015-07-27, at 14:39, Daniele Nicolodi dani...@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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread 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: [O] How to make a non-GPL Org-mode exporter?

2015-07-27 Thread Richard Lawrence

Hi Marcin and all,

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