[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release plans

From: Johannes Weiner
Subject: Re: Release plans
Date: Thu, 14 Aug 2008 13:07:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Hi Alan,

Alan Mackenzie <address@hidden> writes:

> Hi, Johannes,
> On Thu, Aug 14, 2008 at 12:04:36PM +0200, Johannes Weiner wrote:
>> Hi,
>> We can fix the former if our definition of freedom allows us to.  This
>> was the whole point of my previous email, in fact.
>> Emacs has still no support to load shared libraries during runtime and
>> IIRC it was rejected back then due to political reasons.  I call this
>> crippling.
> Well, for a piece of software that is crippled, Emacs works remarkably
> well.  If only non-crippled software could run as fast.

Uh, crap, that came over wrong.  I was never to claim that Emacs works
bad.  I just know there are features that would further improve it.

> 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.

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.

I argue with people loading these modules and tell them why I consider
it stupid but the decision should be their own.

Neither the Linux kernel, nor I as a free user who chooses not to load
proprietary bullcrap into it, have been harmed by the kernel's mechanism
to load said bullcrap.

If it restricts people, than because of their own free decision to
restrict themselves.  That is not a reason to leave the mechanism out
alltogether.  You can also not blame car manufacturers for building
devices that might help a person to kill itself by driving against a
tree as a way of suicide.

People will do that on occasion, this is not a reason to forbid cars for
all others that get a good job done by utilizing it.

And having a mechanims that would be very helpful but also makes it
potentially a bit easier to do stupid things is better than not having
this mechanism.  I also refer to the recently discussed emacs package

> 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 explicitely identify themselves as GPL-licensed to be
able to use GPL-only symbols.

IANAL but perhaps a mechanism for Emacs that requires modules to
announce themselves as GPL'd software would be enough?

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]