From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleh Krehel Subject: Re: How to make a non-GPL Org-mode exporter? Date: Tue, 28 Jul 2015 12:29:00 +0200 Message-ID: <87zj2gy3rn.fsf@gmail.com> References: <87pp3dvm18.fsf@mbork.pl> <87wpxlocpz.fsf@ucl.ac.uk> <87k2tlvbbk.fsf@mbork.pl> <874mkptuc6.fsf@ucl.ac.uk> <87fv49v8f2.fsf@mbork.pl> <87egjtxx7o.fsf@ucl.ac.uk> <87fv481z8r.fsf@gmail.com> <87zj2gwtas.fsf@ucl.ac.uk> <55B74951.8050609@hilboll.de> <87k2tkzl28.fsf@gmail.com> <55B75605.1090204@hilboll.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZK2FB-0005IJ-KN for emacs-orgmode@gnu.org; Tue, 28 Jul 2015 06:36:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZK2F7-0002Gx-Do for emacs-orgmode@gnu.org; Tue, 28 Jul 2015 06:36:21 -0400 Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:36205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZK2F7-0002GX-4B for emacs-orgmode@gnu.org; Tue, 28 Jul 2015 06:36:17 -0400 Received: by wicgb10 with SMTP id gb10so150116680wic.1 for ; Tue, 28 Jul 2015 03:36:16 -0700 (PDT) In-Reply-To: <55B75605.1090204@hilboll.de> (Andreas Hilboll's message of "Tue, 28 Jul 2015 12:14:29 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Andreas Hilboll Cc: emacs-orgmode@gnu.org Andreas Hilboll writes: >>> However, when the interpreter is extended to provide =E2=80=9Cbindings= =E2=80=9D 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. >>=20 >> 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)=20 throw new ArrayIndexOutOfBoundsException(fromIndex); if (toIndex > arrayLen)=20 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; =20=20=20=20 if (start < GPT && GPT < end) move_gap_both (start, start_byte); =20=20=20=20 if (! NILP (BVAR (current_buffer, enable_multibyte_characters))) result =3D make_uninit_multibyte_string (end - start, end_byte - st= art_byte); else result =3D make_uninit_string (end - start); memcpy (SDATA (result), BYTE_POS_ADDR (start_byte), end_byte - start_= byte); =20=20=20=20 /* If desired, update and copy the text properties. */ if (props) { update_buffer_properties (start, end); =20=20=20=20 tem =3D Fnext_property_change (make_number (start), Qnil, make_nu= mber (end)); tem1 =3D Ftext_properties_at (make_number (start), Qnil); =20=20=20=20 if (XINT (tem) !=3D 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