From: Oleh Krehel <ohwoeowho@gmail.com>
To: Andreas Hilboll <lists@hilboll.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: How to make a non-GPL Org-mode exporter?
Date: Tue, 28 Jul 2015 12:29:00 +0200 [thread overview]
Message-ID: <87zj2gy3rn.fsf@gmail.com> (raw)
In-Reply-To: <55B75605.1090204@hilboll.de> (Andreas Hilboll's message of "Tue, 28 Jul 2015 12:14:29 +0200")
Andreas Hilboll <lists@hilboll.de> writes:
>>> However, when the interpreter is extended to provide “bindings” to
>>> other facilities (often, but not necessarily, libraries), the
>>> interpreted program is effectively linked to the facilities it uses
>>> through these bindings. So if these facilities are released under the
>>> GPL, the interpreted program that uses them must be released in a
>>> GPL-compatible way. The JNI or Java Native Interface is an example of
>>> such a binding mechanism; libraries that are accessed in this way are
>>> linked dynamically with the Java programs that call them. These
>>> libraries are also linked with the interpreter. If the interpreter is
>>> linked statically with these libraries, or if it is designed to link
>>> dynamically with these specific libraries, then it too needs to be
>>> released in a GPL-compatible way.
>>
>> Indeed, the Emacs interpreter gives "bindings" to all Emacs facilities,
>> which are GPL, and the interpreted program that uses them must be
>> released in a GPL-compatible way.
>
> I would interpret this as
>
> "As long as I write pure elisp and don't require' and GPL'ed part of
> Emacs, I can release my code under any license I want. If I do
> require' any part of Emacs, I have to go the GPL path."
>
> If I'm wrong with this interpretation, please explain why.
Your interpretation is entirely correct. However, to write almost any
useful code, you're going to need to require some parts of
Emacs. Anything that interacts with text in a buffer will need to call
`buffer-string' eventually - GPL-ed code.
Here are the famous 9 lines from the Oracle-Google Java lawsuit:
private static void rangeCheck(int arrayLen, int fromIndex, int toIndex {
if (fromIndex > toIndex)
throw new IllegalArgumentException("fromIndex(" + fromIndex +
") > toIndex(" + toIndex+")");
if (fromIndex < 0)
throw new ArrayIndexOutOfBoundsException(fromIndex);
if (toIndex > arrayLen)
throw new ArrayIndexOutOfBoundsException(toIndex);
}
This lawsuit is currently on some sort of appeal now. The code above is
essentially the most simple, efficient and obvious way to implement the
rangeCheck function based on the API signature. And still they sued.
On the other hand, the implementation of `buffer-string' isn't at all
trivial:
DEFUN ("buffer-string", Fbuffer_string, Sbuffer_string, 0, 0, 0,
doc: /* Return the contents of the current buffer as a string.
If narrowing is in effect, this function returns only the visible part
of the buffer. */)
(void)
{
return make_buffer_string_both (BEGV, BEGV_BYTE, ZV, ZV_BYTE, 1);
}
Lisp_Object
make_buffer_string_both (ptrdiff_t start, ptrdiff_t start_byte,
ptrdiff_t end, ptrdiff_t end_byte, bool props)
{
Lisp_Object result, tem, tem1;
if (start < GPT && GPT < end)
move_gap_both (start, start_byte);
if (! NILP (BVAR (current_buffer, enable_multibyte_characters)))
result = make_uninit_multibyte_string (end - start, end_byte - start_byte);
else
result = make_uninit_string (end - start);
memcpy (SDATA (result), BYTE_POS_ADDR (start_byte), end_byte - start_byte);
/* If desired, update and copy the text properties. */
if (props)
{
update_buffer_properties (start, end);
tem = Fnext_property_change (make_number (start), Qnil, make_number (end));
tem1 = Ftext_properties_at (make_number (start), Qnil);
if (XINT (tem) != end || !NILP (tem1))
copy_intervals_to_string (result, current_buffer, start,
end - start);
}
return result;
}
It's possible to write some complex number-crunching functions without
relying on the Elisp library. That's the only use-case that I see of
using Emacs like an interpreter and not relying on the "bindings" to the
code that it provides.
--Oleh
next prev parent reply other threads:[~2015-07-28 10:36 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 12:10 How to make a non-GPL Org-mode exporter? Marcin Borkowski
2015-07-27 12:16 ` Oleh Krehel
2015-07-27 13:02 ` Rainer M Krug
2015-07-27 13:09 ` Greg Troxel
2015-07-27 13:13 ` Andreas Hilboll
2015-07-27 13:30 ` Rainer M Krug
2015-07-27 14:05 ` Marcin Borkowski
2015-07-27 14:03 ` Marcin Borkowski
2015-07-28 12:33 ` Paul Rudin
2015-07-27 12:39 ` Daniele Nicolodi
2015-07-27 16:59 ` Marcin Borkowski
2015-07-27 18:02 ` Nick Dokos
2015-07-27 18:12 ` Marcin Borkowski
2015-07-27 18:45 ` Daniele Nicolodi
2015-07-28 7:55 ` Oleh Krehel
2015-07-29 14:54 ` Aaron Ecay
2015-07-30 10:08 ` Oleh Krehel
2015-07-27 13:05 ` Greg Troxel
2015-07-27 14:32 ` Marcin Borkowski
2015-07-27 13:58 ` Scott Randby
2015-07-27 16:32 ` Marcin Borkowski
2015-07-27 15:13 ` Eric S Fraga
2015-07-27 16:01 ` Marcin Borkowski
2015-07-27 16:12 ` Oleh Krehel
2015-07-27 17:12 ` Marcin Borkowski
2015-07-27 17:13 ` Thomas S. Dye
2015-07-27 16:54 ` Eric S Fraga
2015-07-27 17:04 ` Marcin Borkowski
2015-07-27 18:38 ` Eric S Fraga
2015-07-28 8:07 ` Oleh Krehel
2015-07-28 9:00 ` Eric S Fraga
2015-07-28 9:00 ` Oleh Krehel
2015-07-28 10:38 ` Eric S Fraga
2015-07-28 9:20 ` Andreas Hilboll
2015-07-28 9:30 ` Oleh Krehel
2015-07-28 10:14 ` Andreas Hilboll
2015-07-28 10:29 ` Oleh Krehel [this message]
2015-07-27 18:32 ` Richard Lawrence
2015-08-04 15:04 ` Phillip Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zj2gy3rn.fsf@gmail.com \
--to=ohwoeowho@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=lists@hilboll.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).