Re: Release plans

[Johannes Weiner <hannes@saeurebad.de>]

Hi, again again!

Alan Mackenzie <acm@muc.de> writes:

> Hi, again!
>
> On Thu, Aug 14, 2008 at 01:07:35PM +0200, Johannes Weiner wrote:
>> Hi Alan,
>
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > I think the lack of provision of binary libraries is more of a legal
>> > thing than a political one.  It would allow people to extend Emacs
>> > with non-free code, and it would be problematic to prevent them
>> > distributing their enslaved versions of Emacs.
>
>> > I agree with Richard that this would be undesirable in the extreme.
>> > Linux has taken the opposite attitude: that extending Linux with
>> > non-free modules is OK.  This has not been free of problems.
>
>> I am very sensitive when it comes to such decisions.  Because when you
>> try to prevent idiots from being idiots, you will also restrict people
>> that could do great work with the potential features.
>
> Just to clarify my previous post, I do see that there are strong points
> on both sides of this argument.  My personal view is that the coming into
> effective existence of "enslaved" versions of Emacs through the loading
> of binary libraries would outweigh the benefits.

Okay.

>> The primary thing about Linux modules is, well, that you can load
>> modules.  This gives you power to do really clever stuff.
>
>> Whether one loads proprietary modules into the kernel is a personal
>> decision and I don't like deciding for other people.
>
> The loadability of modules into the kernel has effects on the whole free
> software community.  Somebody MUST decide this issue for other people,
> possibly by default.  In these two cases, the decisions were taken by
> Linus Torvalds and Richard Stallman.  It is entirely possible that both
> were right.  Now I agree with you about it being a political thing.
> ;-)

I see the main difference is that Torvalds choose to leave that decision
to the user by giving him the needed mechanisms to do crazy stuff.

Richard restricted the user from doing crazy stuff.

>> I argue with people loading these modules and tell them why I consider
>> it stupid but the decision should be their own.
>
> The facility you want would allow people, in effect, to make proprietary
> extensions to Emacs.  We could end up with a firm like Linspire saying
> "our version of Emacs is superior because it can access files over the
> <proprietary X> protocol, so why don't you buy a license for our superior
> version of Linux instead of your lame Ubuntu or RedHat?".

Yeah, this module license restriction comes to mind again.  But really,
this possibility has been there since XEmacs included the module loader
and noone cared to sell proprietary modules.

BUT!  If a proprietary module would be written for Emacs that solves a
problem no free alternative does so far and the functionality could be
of benefit to the users, this could be motivation to create a free
alternative.  At least that is what I think.  But that's just me, I
really love evolving technology :-)

> I think that this possibility outweighs the benefit from being able to
> load in something like the OTR libraries.  At the same time, I respect
> your view to the contrary.
>
>> > If there were a way of licensing Emacs so that only free libraries
>> > could be attached to it, this would be done.
>
>> Linux prevents certain APIs from being used by non-free modules.  And
>> modules have to explicitly identify themselves as GPL-licensed to be
>> able to use GPL-only symbols.
>
> I didn't know that.  Thanks!
>
>> IANAL but perhaps a mechanism for Emacs that requires modules to
>> announce themselves as GPL'd software would be enough?
>
> More specifically, as GPL3 software.

Yeah, of course.  The thing that you implement a cooperative loader,
more or less.  If the module doesn't say `hey, I am free software' on
load time, the loader could refuse to continue.

This works for Linux.  I mean, I don't know of situations where a module
claimed falsely to be under a free license while it was not, in order to
access GPL symbols or prevent the kernel from tainting itself.

But as said, it would be good to have some lawyer sort this out.

>> > What sort of libraries do you want to use from Emacs anyway?
>
>> I would be interested in having OTR support for jabber.el.  So my
>> choice is between implementing the OTR protocol in elisp or linking the
>> emacs binary against libotr.
>
>> I consider both solutions bad by design.  The optimal solution would be
>> for jabber.el to issue (require 'libotr) and have Emacs doing the right
>> thing.
>
> There are other choices.  You could, for example, write a module-loading
> facility yourself, and thus distribute your own Emacs fork.  You'ld not
> make yourself popular though, any more than the Lucid Emacs crowd did a
> long time ago.

Yes, it's the difference between theoretical freedom and reality.

Also, forking would mean leaving GNU Emacs behind, which I would prefer
not to :)

> Or, you could simply adapt the OTR sources and build them into Emacs.
> Well, you could if either the OTR author was prepared to release his
> sources under GPL3, or RMS was prepared to accept GPL2 stuff into Emacs.
> Hell will freeze over before the second of these happens.  ;-)

In my opinion the OTR sources don't have anything to do with the Emacs
core.  The idea of the el packages is that you lazy load code and have
it apart from the core.

The same is not possible for C code but it would be great to have that!

By the way, what prevents you from loading proprietary .elc files?

> By the way, do you really live in an acid bath?  ;-)

Jawohl!  It's actually a reference to a reeeeaaally bad piece of german
electronic dance music... `Join me in my bath of acid.  Witness your own
decay.  Boom Boom Boom Boom...'

	Hannes