Re: Release plans

Re: Release plans

[A Soare]

> A Soare wrote:
> >>> Quite so! Investing energy to develop it under Windows is (almost) loss of energy!
> >> Yes, I understood that this is what you meant. But in what way did you 
> >> reach this conclusion?
> > 
> > By induction. I do not use Windows, and in linux I use emacs for lots of purposes.
> 
> So you mean that for you personal benefits there is no use in developing 
> Emacs under Windows? ;-)

I do not say that for _my_benefit_. I say that in general almost nobody use emacs in windows. There are exceptions, quite so. But I have never seen exceptions.


> 
> >>> I know a few cases of _good_ programmers at google, microsoft, etc that never thought to use emacs.
> >>>
> >>> The reason: Windows has nicer environments to write C++, Delphi, C# etc. (that is what they told me).
> >> Then how can it be good to develop Emacs under any operating system?
> > 
> > In Emacs under Linux for Linux!
> 
> Did you mention any reason that I did not notice?

Personally I always use emacs, and I need nothing else. I tell _exactly_ what I heard that the others say. For me it is not useful under windows, and I have never heard a windows user to use it.

> >>> Emacs and Linux is used just by peuple that wants to understand how things work.
> >> Do you say that there is no use for Emacs?
> > 
> > In windows, yes, that is what I say. In Windows it is completely unuseful.
> 
> Then why is there a use for it under Linux? It seems like you are saying 
> that software under Linux is inferior to the corresponding software 
> under Windows and because of this Emacs can be useful on Linux.

No, there is no contradiction in what I say.

I heard many programmers that they prefer use under GNU Linux others editors. The same reason: they want to gain money easy in my opinion.

What choose everybody depends only of his _education_. Of his values. If you tell soebody "Emacs is written profesionnaly and you can learn looking at its sources" does not have the same effect on every person. The majority of peuple will say (I quote a programmer from gooooogle ) : "Yes, emacs is nice, but I do not like emacs, because I want to gain money, and others programmers will copy-paste the open source projects, and they will steal me the projects" . And he never used emacs.

In linux there are others C/C++ development environments than emacs that can be used without effort.

This discution is enless: the best is to put a button on emacs' page and to ask peuple to vote if they need emacs under windows, and the reason why they do.

> If that is the case why is it Emacs we develop and not something better?

I heard many saying that there are better development. If you say "emacs is written in lisp, so it is very customisable" they will say "oui, mais je peux me passer d'emacs et me debrouiller facilement avec d'autres."

> 
> >>> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.
> >> Do you say that using Emacs makes it take long time to do things?
> > 
> > It takes little time when you have already learned how to use it.
>  > The first time when you did a thing, you will never choose something 
> different.
>  > Here is the point: the psychology. Peuple prefers never to make the 
> first effort,
>  > and they prefer to use something to arrive quickly at the point.
> 
> Can we use that point to do something actively? Can we make Emacs better 
> in a way that it satisfies those people's need? (Still not sacrifiying 
> other things.)

This is like demanding to a cannibal "do you want to become a chretien"? Not taking into account a famous tribe of cannibals that died because they lost their native croyance in cannibalisme, the question whether the user want to use emacs does not depend on emacs. But on his values in which he is educated.

So my answer is: this is not a question for programmers, but for educators and family.

> 
> >>> >From all my experience (all what I saw), windows interface for 
>  >>> > emacs is as important as the file ./etc/sex.6 in emacs' sources.
> >> Are you saying that this is the only part of Emacs that we should keep ;-)
> > 
> > Yes, Emacs in Linux is nice.
> 
> Why is the file etc/sex.6 so nice so that we should keep only that on 
> Linux? ;-)

From my viewpoint, all the modules for windows are _not_ useful, i.e. they have the same usefulness as this file.




____________________________________________________

Avant de prendre le volant, repérez votre itinéraire et visualisez le trafic ! http://itineraire.voila.fr/itineraire.html

Re: Release plans

[Lennart Borgman (gmail)]

A Soare wrote:
>> A Soare wrote:
>>>>> Quite so! Investing energy to develop it under Windows is (almost) loss of energy!
>>>> Yes, I understood that this is what you meant. But in what way did you 
>>>> reach this conclusion?
>>> By induction. I do not use Windows, and in linux I use emacs for lots of purposes.
>> So you mean that for you personal benefits there is no use in developing 
>> Emacs under Windows? ;-)
> 
> I do not say that for _my_benefit_. I say that in general almost nobody use emacs in windows. There are exceptions, quite so. But I have never seen exceptions.

Thanks. So maybe I can say what I wanted to point out: You are 
exaggerating and extrapolating from personal experiences. That is of 
course fine sometimes, but not when you want to make conclusions.

I trust you when you say that you have not meat anyone using Emacs on 
Windows. However I am sure you have read about people doing that. And 
they all have their own reasons. Would it not be fair to include their 
reasons before making a conclusion?

>>>>> Emacs and Linux is used just by peuple that wants to understand how things work.
>>>> Do you say that there is no use for Emacs?
>>> In windows, yes, that is what I say. In Windows it is completely unuseful.
>> Then why is there a use for it under Linux? It seems like you are saying 
>> that software under Linux is inferior to the corresponding software 
>> under Windows and because of this Emacs can be useful on Linux.
> 
> No, there is no contradiction in what I say.

Are you sure? Didn't you say that the developers you know do not use 
Emacs on Windows because there are better software for their purpose on 
Windows? And didn't you mean that you trust them?

Why shouldn't we then develop software similar to that they use on 
Windows? It seems like you are hiding some parts of your answer from me ...

Of course I agree with you about making a better world, but I believe 
that sound reasoning is part of going forward in that direction.

>>>>> Windows is used by peuple that want to gain money and to arrive quiqkly at their purpose.
>>>> Do you say that using Emacs makes it take long time to do things?
>>> It takes little time when you have already learned how to use it.
>>  > The first time when you did a thing, you will never choose something 
>> different.
>>  > Here is the point: the psychology. Peuple prefers never to make the 
>> first effort,
>>  > and they prefer to use something to arrive quickly at the point.
>>
>> Can we use that point to do something actively? Can we make Emacs better 
>> in a way that it satisfies those people's need? (Still not sacrifiying 
>> other things.)
> 
> This is like demanding to a cannibal "do you want to become a chretien"?
 > Not taking into account a famous tribe of cannibals that died because 
they
> lost their native croyance in cannibalisme, the question whether the user
 > want to use emacs does not depend on emacs.
 > But on his values in which he is educated.

Don't you just throw away information here?

> So my answer is: this is not a question for programmers, but for educators and family.

Note: It looks like your mail program does something that Thunderbird 
does not expect at all. Thunderbird does not wrap the lines when 
commenting on your text. Do you know the reason? (It takes a lot of time 
that this does not work.)

Re: Release plans

[Alan Mackenzie]

Hi!

On Tue, Aug 12, 2008 at 04:34:49PM +0200, A Soare wrote:

> I say that in general almost nobody use emacs in windows. There are
> exceptions, quite so. But I have never seen exceptions.

In the field I work in (embedded systems), our targets are very often
Unix-like OSs (e.g. QNX), our host systems are (nearly) always Windows,
and development itself is done either on Windows or on a Unix server.  In
this type of environment, cygwin is always installed, and Emacs on
Windows is popular, as is perl, bash, vi, .....; 

It has been known for programmers enamoured of the Windows OS to complain
quite loudly at the lack of a "decent editor" in Unix.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M. Stallman]

    In the field I work in (embedded systems), our targets are very often
    Unix-like OSs (e.g. QNX), our host systems are (nearly) always Windows,

It is a shame to use Windows for that.  Why not switch to GNU/Linux?

Re: Release plans

[Alan Mackenzie]

Hi, Richard,

On Wed, Aug 13, 2008 at 02:26:36AM -0400, Richard M. Stallman wrote:
>     In the field I work in (embedded systems), our targets are very
>     often Unix-like OSs (e.g. QNX), our host systems are (nearly)
>     always Windows,

> It is a shame to use Windows for that.  Why not switch to GNU/Linux?

It's a great shame.  Why not switch?  Because the host system is a
massive company Windows network, much more like a mainframe than a stand
alone PC.  Things like Email and Word processing (with yucky formats) are
done on it.  And backing up files.  For such a company, software
development is merely one department, and not even the most important.
Switching to GNU is possible in principle, but it's difficult,
time-consuming and expensive.  The city administration in Munich is doing
this, for example.  Probably, some medium to large size compaies are,
too.

But yes, it's a great shame.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Richard M. Stallman]

    Switching to GNU is possible in principle, but it's difficult,
    time-consuming and expensive.

Doing things that are difficult and/or time-consuming and/or expensive
in order to escape from proprietary software is precisely the way
to show people that freedom matters.  That is how you lead.  Developing
GNU was also difficult and time-consuming, and some aspects have been
expensive.

Re: Release plans

[Alan Mackenzie]

Hi, Richard!

On Thu, Aug 14, 2008 at 01:19:22AM -0400, Richard M. Stallman wrote:
>     Switching to GNU is possible in principle, but it's difficult,
>     time-consuming and expensive.

> Doing things that are difficult and/or time-consuming and/or expensive
> in order to escape from proprietary software is precisely the way to
> show people that freedom matters.  That is how you lead.  Developing
> GNU was also difficult and time-consuming, and some aspects have been
> expensive.
 
Hey, you snipped too much of the context, you rascal!  The effort I was
talking about was that of a large company, with all the bureaucracy and
inertia that goes with it.  These large companies aren't much concerned
about freedom, unless it is their own.  They might not even be legally
permitted in some jurisdictions to bother much about freedom.

Other people and groups are advancing free software by emphasising free
software's high quality.  Yet you don't recognise their efforts as
legitimate, even though they increase the use of free software, and hence
freedom itself.  I find this puzzling, and I know I'm not alone.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi,

Alan Mackenzie <acm@muc.de> writes:

> Hi, Richard!
>
> On Thu, Aug 14, 2008 at 01:19:22AM -0400, Richard M. Stallman wrote:
>>     Switching to GNU is possible in principle, but it's difficult,
>>     time-consuming and expensive.
>
>> Doing things that are difficult and/or time-consuming and/or expensive
>> in order to escape from proprietary software is precisely the way to
>> show people that freedom matters.  That is how you lead.  Developing
>> GNU was also difficult and time-consuming, and some aspects have been
>> expensive.
>  
> Hey, you snipped too much of the context, you rascal!  The effort I was
> talking about was that of a large company, with all the bureaucracy and
> inertia that goes with it.  These large companies aren't much concerned
> about freedom, unless it is their own.  They might not even be legally
> permitted in some jurisdictions to bother much about freedom.
>
> Other people and groups are advancing free software by emphasising free
> software's high quality.  Yet you don't recognise their efforts as
> legitimate, even though they increase the use of free software, and hence
> freedom itself.  I find this puzzling, and I know I'm not alone.

Freedom should never stand over software quality and usability.  The
same way as security should never do that.  If your security model is to
take the power off your machines you will have a worse solution that one
with higher risk.

Richard, if your argument is really that it is _good_ to have
time-consuming software in order to demonstrate by using it that you
care so much about freedom that you stop solving your problems
efficiently, then I am really sorry for you.

Primarily, software is problem-solving.  If your software comes in a
flavor that doesn't restrict user's freedom, this is really nice.

If you cripple software for freedom's sake, you have driven the purpose
of software ad absurdum.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   Freedom should never stand over software quality and usability.

Freedom must always stand over software quality and usability, without
it we cannot improve the software in question.

   Primarily, software is problem-solving.  If your software comes in
   a flavor that doesn't restrict user's freedom, this is really nice.

It is a prerequisite that software is free to be able to solve
problems; if the software is not free, then you cannot solve anything.

   If you cripple software for freedom's sake, you have driven the
   purpose of software ad absurdum.

Nobody implied that one should cripple software for freedoms sake.
Nor did rms argue that it is good to have badly written free software.
But it is better to have badly written free software than having well
written non-free software.  We can fix the former, but not the later.

Re: Release plans

[Johannes Weiner]

Hi,

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    Freedom should never stand over software quality and usability.
>
> Freedom must always stand over software quality and usability, without
> it we cannot improve the software in question.

Not when your definition of freedom forbids certain improvements.

>    Primarily, software is problem-solving.  If your software comes in
>    a flavor that doesn't restrict user's freedom, this is really nice.
>
> It is a prerequisite that software is free to be able to solve
> problems; if the software is not free, then you cannot solve anything.

This is flat out wrong.  Software is written for a purpose.  Windows
does its job, whether it does it good or bad and whether you like the
philosophy or not.  It is not free and it solves the problem it was
written for.

>    If you cripple software for freedom's sake, you have driven the
>    purpose of software ad absurdum.
>
> Nobody implied that one should cripple software for freedoms sake.
> Nor did rms argue that it is good to have badly written free software.
> But it is better to have badly written free software than having well
> written non-free software.  We can fix the former, but not the later.

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.

	Hannes

Re: Release plans

[Alan Mackenzie]

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.

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.

If there were a way of licensing Emacs so that only free libraries could
be attached to it, this would be done.

What sort of libraries do you want to use from Emacs anyway?

> 	Hannes

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi Alan,

Alan Mackenzie <acm@muc.de> 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
manager.

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

	Hannes

Re: Release plans

[Tassilo Horn]

On Thursday 14 August 2008 13:07:35 Johannes Weiner wrote:

Hi Hannes,

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

That needs not to be true.  Take the nvidia drivers as an example.  If
the kernel wouldn't allow this driver to be loaded, we might have a
better free driver today.  Who knows?

The same applies to the intel wireless drivers, which require some
proprietary firmware.  If something works, the attraction of
implementing a free alternative fades away.

Of course you can argue the other way round, too.  Would GNU/Linux be
where it is today if no proprietary drivers allowed most features of the
computer to be used?

Bye,
Tassilo

Re: Release plans

[Johannes Weiner]

Hi Tassilo,

Tassilo Horn <tassilo@member.fsf.org> writes:

> On Thursday 14 August 2008 13:07:35 Johannes Weiner wrote:
>
> Hi Hannes,
>
>> 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.
>
> That needs not to be true.  Take the nvidia drivers as an example.  If
> the kernel wouldn't allow this driver to be loaded, we might have a
> better free driver today.  Who knows?

It seems to solve itself evolutionary.  nvidia sucks so bad at keeping
up with the kernel api, left aside frequent, undebuggable oopsen, that I
know quite some people who's subsequent video card has been an ATI card
just because there are now free drivers available.

I myself have an nvidia card due to historic reasons which I can not
fully utilize because I decided to not use the nvidia driver.  But as
soon I have enough money for an upgrade, I will sure as hell get a video
card that is supported by free drivers.  And in my case, this is not
only a technical decision.

When someone asks me for help with their kernel becoming unstable after
loading proprietary modules, I explain them that it's neither the
kernels fault, nor the module-vendors fault.  It's the person's fault
who made the decision.

Noone `subjugated' a user of the proprietary nvidia module.  Only their
own stupidity.

> The same applies to the intel wireless drivers, which require some
> proprietary firmware.  If something works, the attraction of
> implementing a free alternative fades away.

I consider ath5k and the ati drivers proving the opposite.  I think
Richard has yet another wireless card that works with free drivers.

I actually see a trend in free drivers evolving.

> Of course you can argue the other way round, too.  Would GNU/Linux be
> where it is today if no proprietary drivers allowed most features of the
> computer to be used?

I don't know.  But are there so many proprietary modules at all?  I
believe there are by far more free modules than non-free ones for the
kernel.

And even if I would myself not do so, I would prefer a user running a
complete GNU/Linux system with one proprietary module loaded to get his
work done over him running a completely non-free environment.

You can still fight the remaining evil.  And I consider myself as a
proof that the figthing spirit is not lost just because there is a
working non-free module available.

	Hannes

Re: Release plans

[Richard M. Stallman]

    Of course you can argue the other way round, too.  Would GNU/Linux be
    where it is today if no proprietary drivers allowed most features of the
    computer to be used?

Where is GNU/Linux today?  Tens of millions of people use it, but most
of them use non-free software with it.  It's a lot of "success", but
we have a long way to go to reach a world of freedom.

Re: Release plans

[Alan Mackenzie]

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.

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

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.

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

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

> 	Hannes

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

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

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

Re: Release plans

[Alan Mackenzie]

Hi, again, again, again!

On Thu, Aug 14, 2008 at 03:15:00PM +0200, Johannes Weiner wrote:

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

.elc files are compiled from .el files.  .el files, because they call
functions like `car', because they embed themselves in the standard Emacs
obarray, ..., are extensions to Emacs.  Therefore, they're subject
to the GPL.  Or something like that.

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

Ah.  A bit like Johann Sebastian Bach.  Got you!  ;-)

> 	Hannes

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi, again, again, again, again!

Alan Mackenzie <acm@muc.de> writes:

> Hi, again, again, again!
>
> On Thu, Aug 14, 2008 at 03:15:00PM +0200, Johannes Weiner wrote:
>
>> By the way, what prevents you from loading proprietary .elc files?
>
> .elc files are compiled from .el files.  .el files, because they call
> functions like `car', because they embed themselves in the standard Emacs
> obarray, ..., are extensions to Emacs.  Therefore, they're subject
> to the GPL.  Or something like that.

Hm, I wonder if this cooperative loader could use the same trick.
I.e. make the module register itself and by using the registration
mechanism which is GPL software, the module becomes derivative work.  Or
something.

>> > 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...'
>
> Ah.  A bit like Johann Sebastian Bach.  Got you!  ;-)

Huh, why JSB?  Bach was a good hacker.  The author of the piece in
question is, well, ... :)

	Hannes

Re: Release plans

[Stephen J. Turnbull]

Johannes Weiner writes:

 > I.e. make the module register itself and by using the registration
 > mechanism which is GPL software, the module becomes derivative
 > work.

According to the prevailing definition of "work", anything loaded into
the same process becomes part of a derivative work.  The FSF's legal
staff says that if a module cannot be used without the rest of the
program, the source as well is part of the same work.  So what you
want is already true.

The difference with the kernel is that (a) the kernel is not a
process, and (b) Linus has made the exception explicit.

What the kernel does is to require the module to call an API to assert
that it is GPLv2.  What that means is that it's an *intentional*
copyright violation if that is a lie.  Statutory damages on a
per-copy-distributed basis, possibly a criminal violation.  "I see
your 0.02 Euro, and raise one CAP budget." ;-)

Re: Release plans

[Gilaras Drakeson]

Hi,

When emacs refuses to load a GPL library I cannot help but to call the
situation an ugly bureaucracy. The bare minimum for GNU to be a
consistent operating system is to be able to dynamically load any GNU
library.

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

Good point.

-- 
Gilaras

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > The loadability of modules into the kernel has effects on the whole free
 > software community.

Yeah, it forces free people to make free choices.  This is a good
thing.

 > The facility you want would allow people, in effect, to make proprietary
 > extensions to Emacs.

That's FUD.  According to the FSF legal staff, it is illegal to
distribute non-GPLv3 modules intended for linking to Emacs.  This
restriction on dynamic loading doesn't change the legal status; it
just makes it cheaper for the FSF to fight would-be violators and wake
up those people who just don't bother to think about whether their
distributions are violations.

As Richard says, it's appropriate that the defenders of freedom pay an
extra cost to show they value freedom.  Emacs should get dynamically
loadable modules.  The kernel's strategy for require'ing GPL would
work here, too.

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

It might cost the FSF to fight that, but they'd win.  Don't defend
freedom with FUD.  If they can't win, then you could distribute Emacs
as a .o with appropriate modules and have the user do the linking to
the same effect.  If the proprietary module is that attractive, you
can bet people would do it.

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

I resemble that remark, although I wasn't there at the time.  Is it
really worth offending those of us who choose to work on XEmacs when
the cases are not parallel at all?

The module-loading facility has long been available for both Emacs (as
3rd party patches, sorry, no URL offhand; maybe from the same source
as XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4).

Re: Release plans

[Richard M. Stallman]

    As Richard says, it's appropriate that the defenders of freedom pay an
    extra cost to show they value freedom.

What I said is that making a sacrifice for the sake of freedom
can have the useful effect of making other people start to think about
freedom.

Re: Release plans

[Alan Mackenzie]

Hello, Stephen!

On Fri, Aug 15, 2008 at 03:00:56AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > The loadability of modules into the kernel has effects on the whole
>  > free software community.

> Yeah, it forces free people to make free choices.  This is a good
> thing.

A bit like the availability of guns in a community does.

>  > The facility you want would allow people, in effect, to make
>  > proprietary extensions to Emacs.

> That's FUD.  According to the FSF legal staff, it is illegal to
> distribute non-GPLv3 modules intended for linking to Emacs.

Are you sure?  OK, yes you are.  Any chance of a reference?  Are you also
sure this applies to external libraries interacting over a clean thin
narrow openly specified interface, as contrasted to Elisp libraries which
burrow into the heart of Emacs?

> This restriction on dynamic loading doesn't change the legal status; it
> just makes it cheaper for the FSF to fight would-be violators and wake
> up those people who just don't bother to think about whether their
> distributions are violations.

> As Richard says, it's appropriate that the defenders of freedom pay an
> extra cost to show they value freedom.  Emacs should get dynamically
> loadable modules.  The kernel's strategy for require'ing GPL would work
> here, too.

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

> It might cost the FSF to fight that, but they'd win.  Don't defend
> freedom with FUD.

Hey, just because I'm mistaken (if I am) doesn't make me a fudder.

> If they can't win, then you could distribute Emacs as a .o with
> appropriate modules and have the user do the linking to the same
> effect.  If the proprietary module is that attractive, you can bet
> people would do it.

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

> I resemble that remark, although I wasn't there at the time.  Is it
> really worth offending those of us who choose to work on XEmacs when
> the cases are not parallel at all?

Sincere topologies.  Offense wasn't intended, it was just an ill
considered throw away comparison.

> The module-loading facility has long been available for both Emacs (as
> 3rd party patches, sorry, no URL offhand; maybe from the same source as
> XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4).

I didn't know that either.  I looked in the two canonical places on my
XEmacs 21.4.17, but didn't find it.  Any chance of a hint to type at C-h
f?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Hello, Stephen!
 > 
 > On Fri, Aug 15, 2008 at 03:00:56AM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > The loadability of modules into the kernel has effects on the whole
 > >  > free software community.
 > 
 > > Yeah, it forces free people to make free choices.  This is a good
 > > thing.
 > 
 > A bit like the availability of guns in a community does.

A bit, yes, but the prevalance of that kind of exaggeration in this
community is precisely why I no longer think of myself as a "free
software advocate", though I do advocate software freedom.

 > >  > The facility you want would allow people, in effect, to make
 > >  > proprietary extensions to Emacs.
 > 
 > > That's FUD.  According to the FSF legal staff, it is illegal to
 > > distribute non-GPLv3 modules intended for linking to Emacs.
 > 
 > Are you sure?  OK, yes you are.

Actually, no.  I misspoke.  It is a violation of the GPL to distribute
something, like a Makefile, that is intended to cause a non-GPLvX-
compatible module to be to be linked to a GPLvX module.  I strongly
believe that would include a module being loaded by an Emacs-specific
dynamic loader, such as one that won't load if you don't call
hey_emacs_i_am_gpl_v(X).

I do believe that the FSF would maintain the original position above
(where "intended" is the key word and "-compatible needs to be
inserted appropriately), but I am not terribly sure of that.  In any
case, the restatement is what I need here.

 > Any chance of a reference?

For the restatement:

FSF vs. XEmacs.  We sought and received guidance from Richard on the
question of whether a Qt XEmacs could be distributed.  His answer was
yes on X11 platforms, no on Windows platforms, and provided that we
made it impossible to link Qt in the Cygwin and native NT builds.
(Unless the user patched our code, of course.)  It's in the XEmacs
archives, but you'd have to ask me as they're currently offline due to
a severe space crunch on our host.

FSF vs. Aladdin (Ghostscript).  It's in the ghostscript mailing list
archives, from several years back.  Searching for readline and
ghostscript probably will bring it up.  The FSF intimidated Aladdin
into removing two lines from its Makefile, on the grounds that they
showed the intention to link Aladdin Ghostscript to GNU readline, thus
making Aladdin Ghostscript a derivative of GNU readline.  Aladdin did
remove the code, under protest that there was no license violation
since they did not distribute GNU readline.

 > Are you also sure this applies to external libraries interacting
 > over a clean thin narrow openly specified interface, as contrasted
 > to Elisp libraries which burrow into the heart of Emacs?

First, that's not an "extension" in the usual sense of the word; to
really extend Emacs you need DEFUN.  But that's wordplay.

Show me the interface, and I'll tell you whether I think it applies.
If you mean something like the interface of libpng, sure, you could do
that and it wouldn't apply.  But any platform that provides a
proprietary version of libpng (for example) can already link it
statically.  This is not a distinction between dynamic and static
linking; if one prohibition can be enforced, so can the other.  Cost
will differ, that's all.

I don't think Emacs itself has any such "specified interfaces", and
all the modules I know of either call Emacs buffer functions or use
the DEFUN macro.

 > Hey, just because I'm mistaken (if I am) doesn't make me a fudder.

No offense intended; I say if it is a mistake it is FUD, but I'm
talking about the statement, not the speaker.  Just because a mistake
is FUD doesn't make one a fudder.  But fudders can pick it up and cite
it as the authority, so one should avoid it.

 > Sincere topologies.  Offense wasn't intended, it was just an ill
 > considered throw away comparison.

Your open sets are accepted, and in private mail David Kastrup
contributed somthing like "It's all parallel anyway; that's the point
of hyperbole."  (Which I failed to get until he explained it.<sigh>)
And I would not believe without strong evidence that you ever intended
offense.

 > > The module-loading facility has long been available for both Emacs (as
 > > 3rd party patches, sorry, no URL offhand; maybe from the same source as
 > > XEmacs/CHISE at Kyoto U?) and XEmacs (standard since 21.4).
 > 
 > I didn't know that either.  I looked in the two canonical places on my
 > XEmacs 21.4.17, but didn't find it.  Any chance of a hint to type at C-h
 > f?

It's probably not quite that standard; I believe you need to configure
--with-modules.  Look in M-x describe-installation for module
capability, and if it's there, C-h f load-module.  If not, you can see
the few that we've got in the modules/ directory of the source.

Re: Release plans

[Richard M. Stallman]

What is libotr?  What precisely is it license status?
There may be something here that I ought to do, once I understand
the facts.

Re: Release plans

[Johannes Weiner]

Hi,

"Richard M. Stallman" <rms@gnu.org> writes:

> What is libotr?

An encryption library that is mostly used by instant messengers.

> What precisely is it license status?

The Off-the-Record Messaging library (in the src directory) is
covered by the following (LGPL) license:

    Off-the-Record Messaging library
    Copyright (C) 2004-2008  Ian Goldberg, Chris Alexander, Nikita
    Borisov
                     <otr@cypherpunks.ca>

    This library is free software; you can redistribute it and/or
    modify it under the terms of version 2.1 of the GNU Lesser General
    Public License as published by the Free Software Foundation.

    This library is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    Lesser General Public License for more details.

    There is a copy of the GNU Lesser General Public License in the
    COPYING.LIB file packaged with this library; if you cannot find it,
    write to the Free Software Foundation, Inc., 59 Temple Place, Suite
    330, Boston, MA 02111-1307  USA

The Off-the-Record Messaging Toolkit (in the toolkit directory) is
covered
by the following (GPL) license:

    Off-the-Record Messaging Toolkit
    Copyright (C) 2004-2008  Ian Goldberg, Chris Alexander, Nikita
    Borisov
                     <otr@cypherpunks.ca>

    This program is free software; you can redistribute it and/or modify
    it under the terms of version 2 of the GNU General Public License as
    published by the Free Software Foundation.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    There is a copy of the GNU General Public License in the COPYING
    file
    packaged with this toolkit; if you cannot find it, write to the Free
    Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
    02111-1307  USA

> There may be something here that I ought to do, once I understand
> the facts.

	Hannes

Re: Release plans

[Richard M. Stallman]

Thanks.  It seems that there is nothing I need to do in regard to OTR,
even though it is unfortunate that the toolkit is available only under
GPL version 2.

Re: Release plans

[Alfred M. Szmidt]

   >    Freedom should never stand over software quality and usability.
   >
   > Freedom must always stand over software quality and usability, without
   > it we cannot improve the software in question.

   Not when your definition of freedom forbids certain improvements.

Free software does not forbid any kinds of improvment.  It explicitly
protects that right.

   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.

If a feature allows someone to subjugate the rights of a computer
user, then it is better not to implement it.  The Emacs maintainers
decided that this feature would do a greater disservice to users than
having it included, so they decided not to.  It is no different to
rejecting a feature because it does something annoying, you may call
it crippling, but it is just good managment of a project.

Re: Release plans

[Johannes Weiner]

Hi,

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    >    Freedom should never stand over software quality and usability.
>    >
>    > Freedom must always stand over software quality and usability, without
>    > it we cannot improve the software in question.
>
>    Not when your definition of freedom forbids certain improvements.
>
> Free software does not forbid any kinds of improvment.  It explicitly
> protects that right.
>
>    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.
>
> If a feature allows someone to subjugate the rights of a computer
> user, then it is better not to implement it.

You always assume people are stupid.  Please don't do that, it really
offends me.

The only way a user can become enslaved is by not having a choice.  If
there are free alternatives and someone choses to use the non-free
version, this is not the fault of the non-free software but the users
own free decision.

> The Emacs maintainers decided that this feature would do a greater
> disservice to users than having it included, so they decided not to.
> It is no different to rejecting a feature because it does something
> annoying, you may call it crippling, but it is just good managment of
> a project.

First of all, I don't consider dictatorship a good management style.

Second, if that feature annoys someone BUT she has the possibility to
disable it, there is no problem with it.

Some people are annoyed by the transient mark, some are not.  Even if
all maintainers would find that feature annoying, it would be a good
thing to have it anyway for some people might find it useful.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   You always assume people are stupid.  Please don't do that, it
   really offends me.

I have no idea where you got that from.  I never made such an
assumption, I am quite naive when it comes to people, and think the
best of them.

   Some people are annoyed by the transient mark, some are not.  Even
   if all maintainers would find that feature annoying, it would be a
   good thing to have it anyway for some people might find it useful.

TTM doesn't have the side effect of alllowing someone to subjugate the
rights of a user, loadable modules do.  

Re: Release plans

[Johannes Weiner]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    You always assume people are stupid.  Please don't do that, it
>    really offends me.
>
> I have no idea where you got that from.  I never made such an
> assumption, I am quite naive when it comes to people, and think the
> best of them.

By saying the user is subjugated you place him under disability.  It's
not that someone would coerce you with death threats into using a
proprietary module for Emacs if it did support loading these things.

>    Some people are annoyed by the transient mark, some are not.  Even
>    if all maintainers would find that feature annoying, it would be a
>    good thing to have it anyway for some people might find it useful.
>
> TTM doesn't have the side effect of alllowing someone to subjugate the
> rights of a user, loadable modules do.  

Again, the user has the right to choose.  As I said, you might forbid
cars with the same argument, i.e. it could be harmful to the user.

Your basic assumption is that if someone writes non-free software, the
user would be totally helpless and enslaved by the author.  This is not
true!  The person would be in a position she chose to be in BY FREE
WILL.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   >    Some people are annoyed by the transient mark, some are not.
   >    Even if all maintainers would find that feature annoying, it
   >    would be a good thing to have it anyway for some people might
   >    find it useful.
   >
   > TTM doesn't have the side effect of alllowing someone to
   > subjugate the rights of a user, loadable modules do.

   Again, the user has the right to choose.  As I said, you might
   forbid cars with the same argument, i.e. it could be harmful to the
   user.

Nobody has forbidden anything.  The Emacs maintainers have simply
decided that the specific feature you want won't be included in Emacs,
nothing more.

   Your basic assumption is that if someone writes non-free software,
   the user would be totally helpless and enslaved by the author.
   This is not true!  The person would be in a position she chose to
   be in BY FREE WILL.

Non-free software users are indeed under the exclusive control of the
author, the author decides what they can do with the program.  The
only right thing from the user is to refuse to use the non-free
program.

Re: Release plans

[Stephen J. Turnbull]

Alfred M. Szmidt writes:

 > Non-free software users are indeed under the exclusive control of the
 > author, the author decides what they can do with the program.

Nonsense.  The user is not under the exclusive control of the author,
nor any control whatsoever.  The software is, of course, under
substantial control of the rightsholder.  The user, however, can
always stop using the program at any time, with their freedom fully
intact.

If their wallet is a bit slimmer, please call it "tuition".  But I
digress: this thread is about freedom, not economics.

Re: Release plans

[Richard M. Stallman]

    Your basic assumption is that if someone writes non-free software, the
    user would be totally helpless and enslaved by the author.  This is not
    true!  The person would be in a position she chose to be in BY FREE
    WILL.

Whether free will exists is a difficult philosophical question which
we have no need to tackle.  We can agree that making choices does
exist.  I think you are saying that these users would run the non-free
software by choice.

That may or may not be true.  Since the example is imaginary and only
vaguely specified, there is no basis to be sure what it would or would
not imply.  It is clearer to look at a real example about which we
really can know something.

Millions of people use Windows.  Why?  Partly because that's what came
on the machine, partly because they don't care, and partly by choice.
And when they do it by choice, why did they make that choice?  Partly
due to network effect, partly because that's what possible or real
employers use, partly because that's what the school taught them.
Perhaps some people actually like it.  Maybe they don't mind the
malicious features, or maybe they don't know about them, or maybe they
choose not to think about them.

But all those things are beside the point.  Windows subjugates the
user, and that's wrong even if people choose to be subjugated.

Re: Release plans

[Lennart Borgman (gmail)]

Richard M. Stallman wrote:
> Millions of people use Windows.  Why?  Partly because that's what came
> on the machine, partly because they don't care, and partly by choice.

It is a bit temptating to see this list as grasping all possibilties. I 
think that is a mistake.

I happened to watch the rise of ms windows. I was astonished and had a 
hard time to understand what was happening. No one of course can really 
tell the reason behind the success, but some things I noticed where:

- The advertising campaign from MS said to the user "you should decide 
what programs you have on your pc". Very smart. If you tried to tell 
users that there are better programs (there were!) then you just had to 
face that the user "wanted to decide".

- The free software world in my opinion did exactly the opposite. It 
said to the users "we know what is best for you" (because we are 
smarter). This is a psychological mistake. And it is not an easy one to 
cure.

- The unix vendor at that time had the best software. I tried to 
encourage them to make something that we could actually use in a company 
environment. The response I got was "we are best", "when the user 
understands they will chose us". Ok, they were best, but today the user 
can rather understand that windows is no longer technically inferior (at 
least not overall). So as I see it there were clearly something that the 
unix vendors did not understand: meeting the needs of the users and the 
companies. (The unix vendors did of course not make free software, but 
the grounds for free software is standards and that is why the unix 
vendors where important.)

- First ms focused on GUI aspects and usability. When I read messages 
from experts at ms on this subject I often found the messages 
surprisingly good. It looked to my like they did take it seriously - and 
that really requires much thought.

- The free software world seem sometimes to think that creativity 
regarding GUI is  making a new GUI. (MS rather integrated different 
aspects and made the interface uniform. And that was not made out of 
laziness, it was as I saw it after careful thought.)

- One of the strength that ms today has it that it has control (at least 
to some degree) over cooperation between different parts of its 
software). They can achieve that because they have everything under one 
umbrella and also have the man power to try to achieve it. Cooperation 
is a very, very difficult thing in my opinion. Complexity and scaling 
jumps in.

Re: Release plans

[Richard M. Stallman]

We were talking about why people keep using Windows.  Why Windows
became successful is a tangent, which I don't want to take up.  So I
will only comment on a couple of things you said about the free
software community.

    - The advertising campaign from MS said to the user "you should decide 
    what programs you have on your pc". Very smart. If you tried to tell 
    users that there are better programs (there were!) then you just had to 
    face that the user "wanted to decide".

    - The free software world in my opinion did exactly the opposite. It 
    said to the users "we know what is best for you" (because we are 
    smarter).

The whole free software world did not say one single thing.  That is
not what the GNU Project says.  Which part are you talking about?  It
could be that some people said that.  But I don't know that it is
true.

Without specifics, we cannot draw any conclusions.

    - First ms focused on GUI aspects and usability. When I read messages 
    from experts at ms on this subject I often found the messages 
    surprisingly good. It looked to my like they did take it seriously - and 
    that really requires much thought.

We have had to play catch-up in GUIs just as we did in the lower
levels of the system.  When Windows appeared, we did not even have
a complete working command line system.

Re: Release plans

[Richard M. Stallman]

    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.

"Crippling" would imply making Emacs unusable, which it clearly isn't.

The reason for my decision is to make sure that extension to Emacs are
free.  The aim is to maximize what users can do while remaining free.

Re: Release plans

[Sean O'Rourke]

"Richard M. Stallman" <rms@gnu.org> writes:

>     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.
>
> "Crippling" would imply making Emacs unusable, which it clearly isn't.

This is disingenuous.  A cripple can still get around town,
albeit awkwardly.  I think "crippling" as in "severely
problematic" is too extreme; this political problem is more like
a persistent, unscratchable itch: you can live with it, but it's
continuously irritating without encouraging you to improve your
physical condition.

What if we included shared library loading in GNU Emacs to see if
anyone tried to use it to abuse the GPL?  If so, we could remove
it, and let the abusers develop a fork.  Since the shared library
patch is already out there and there are no such forks, I doubt
there would be a problem.

Sean

Re: Release plans

[Michael Ekstrand]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

Sean O'Rourke <sorourke@cs.ucsd.edu> writes:
> What if we included shared library loading in GNU Emacs to see if
> anyone tried to use it to abuse the GPL?  If so, we could remove
> it, and let the abusers develop a fork.  Since the shared library
> patch is already out there and there are no such forks, I doubt
> there would be a problem.

I also doubt it would be a problem.  Given the present development
climate, if someone is going to create a non-free "value-add" for a
development environment, I think that they are much more likely to do so
as an Eclipse plugin than as a non-free extension module for Emacs.  It
may not be a pleasant picture for widespread Emacs adoption, but it is
the state of things these days.

Thus, adding dynamic loading support would make Emacs more flexible for
its users, and I would be rather surprised if people actually abused
that feature to make non-free value-adds (other than the X/Refactory
folks possibly wanting to turn their product into an in-process dynamic
load).  The added possibilities are significant.  The libotr possibility
has been mentioned, and I could see cases for others.  Most immediately
coming to mind is an SQLite extension and accompanying nnsqlite Gnus
mail backend.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files?  I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: Release plans

[Johannes Weiner]

Hi,

"Richard M. Stallman" <rms@gnu.org> writes:

>     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.
>
> "Crippling" would imply making Emacs unusable, which it clearly isn't.

A cripple is not naturally dead.  A cripple is limited compared to
others of the same kind or to it's theoretical potential.

> The reason for my decision is to make sure that extension to Emacs are
> free.  The aim is to maximize what users can do while remaining free.

So Stephen was wrong and it is incorrect that the law would forbid
loading GPL-incompatible modules this way?

I won't doubt your intentions here, I *know* that your primary goal is
the software's freedom.  But I question your way of achieving what you
are up to.  This is not meant impolite, I just like to think on my own.

We have the same goal: we both don't want Emacs to become non-free and
have it have the maximum functionality that is within the limits.

So I am interested in your views of the limits and why you think
runtime-loading of shared libraries is beyond these limits and
runtime-loading of byte-compiled .el files is not.

	Hannes

Re: Release plans

[Richard M. Stallman]

    So I am interested in your views of the limits and why you think
    runtime-loading of shared libraries is beyond these limits and
    runtime-loading of byte-compiled .el files is not.

Please stop putting words in my mouth.

Re: Release plans

[Johannes Weiner]

Hi,

"Richard M. Stallman" <rms@gnu.org> writes:

>     So I am interested in your views of the limits and why you think
>     runtime-loading of shared libraries is beyond these limits and
>     runtime-loading of byte-compiled .el files is not.
>
> Please stop putting words in my mouth.

I never did.

As you maintained Emacs and the state is `.elc - yes, .so - no', I
assumed this was your view.

And thanks for ignoring the rest of the email.  It's a good indicator
for me that it is better to just stop right here before wasting any more
time.

	Hannes

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     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.
>
> "Crippling" would imply making Emacs unusable, which it clearly isn't.
>
> The reason for my decision is to make sure that extension to Emacs are
> free.  The aim is to maximize what users can do while remaining free.
>   


How does not providing dynamic loading maximize what users can
do while remaining free?

If they could dynamically load free libraries, surely their capabilities
would be increased.

I think you mean that your goal is to help GNU Emacs loyalists
remain free even if it means you taking a blunt instrument to
what users can do with their freedom.

-t







>
>
>   

Re: Release plans

[Richard M. Stallman]

    How does not providing dynamic loading maximize what users can
    do while remaining free?

It protects against the danger of non-free C-level add-ons to Emacs.
It's the same principle as the GPL itself.

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

>     How does not providing dynamic loading maximize what users can
>     do while remaining free?
>
> It protects against the danger of non-free C-level add-ons to Emacs.
> It's the same principle as the GPL itself.
>

What about implementing an interface in dynamically loadable modules
that that Emacs can use to determine if the module is GPL compliant?

Free libraries could easily add the interface, proprietary vendors would
highly unlikely add it. I think Linux kernel modules has something
similar.

I'm personally more interested in out-of-process interfaces for Emacs,
like Xembed, Corba etc, but I recognize that dynamic linking of modules
in Emacs would be useful for many tasks.

-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    Free libraries could easily add the interface, proprietary vendors would
    highly unlikely add it. I think Linux kernel modules has something
    similar.

The fact that non-free Linux modules continue to be distributed shows
that this method is not adequate to prevent them.  It also shows that
the danger is not imaginary.

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Free libraries could easily add the interface, proprietary vendors would
>     highly unlikely add it. I think Linux kernel modules has something
>     similar.
>
> The fact that non-free Linux modules continue to be distributed shows
> that this method is not adequate to prevent them.

The Linux kernel doesn't refuse to boot when it recognizes a non GPL
module being loaded. It justs informs you its "tainted".

Emacs should of course just refuse to use functions in modules that are
not GPL compliant, not just inform the user that the moral integrity of
Emacs has been corrupted.

> It also shows that the danger is not imaginary.

I agree completely. 

If this mechanism is implemented, though, I cant see this resulting in any
additional risk of running non-free software. It could, in fact, be a
model of how to eliminate risks of running non-free software.

-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    The Linux kernel doesn't refuse to boot when it recognizes a non GPL
    module being loaded. It justs informs you its "tainted".

    Emacs should of course just refuse to use functions in modules that are
    not GPL compliant, not just inform the user that the moral integrity of
    Emacs has been corrupted.

I don't think this is a solution, because it would be easy to patch out
the code that enforces that restriction.

Re: Release plans

[Tassilo Horn]

On Monday 18 August 2008 08:14:45 Richard M. Stallman wrote:

Hi Richard,

>     The Linux kernel doesn't refuse to boot when it recognizes a non
>     GPL module being loaded. It justs informs you its "tainted".
>
>     Emacs should of course just refuse to use functions in modules
>     that are not GPL compliant, not just inform the user that the
>     moral integrity of Emacs has been corrupted.
>
> I don't think this is a solution, because it would be easy to patch
> out the code that enforces that restriction.

But that register_me_i_am_gpl() function would be in emacs core.  As far
as I understand, if someone patches that function out, the resulting
emacs derivate would have to be GPLv3 as well.

Do you think that someone who would like to distribute non-free emacs
modules would really fork emacs, throw that mechanism out, release it as
GPLv3 and then provide his non-free modules for that fork?

I don't see how that would be much more convenient than forking the
current emacs without module loading support, apply the existing patch
for module loading, release this fork as GPLv3, and then provide the
non-free modules.

In any way, if someone wants to provide non-free modules, he has to fork
emacs.  But if we had support for loading modules, writing free modules
would be as simple as writing elisp extensions.  In my opinion that's a
win for emacs and the free software movement.

Please correct me if I'm wrong.

Bye,
Tassilo

Re: Release plans

[Stefan Monnier]

>     Emacs should of course just refuse to use functions in modules that are
>     not GPL compliant, not just inform the user that the moral integrity of
>     Emacs has been corrupted.

> I don't think this is a solution, because it would be easy to patch out
> the code that enforces that restriction.

Ironically, in the US you might argue that doing that in order to link
a non-GPL module is illegal because of the DMCA: it's trying to work
around a technical device that enforces the copyright.


        Stefan

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

>     The Linux kernel doesn't refuse to boot when it recognizes a non GPL
>     module being loaded. It justs informs you its "tainted".
>
>     Emacs should of course just refuse to use functions in modules that are
>     not GPL compliant, not just inform the user that the moral integrity of
>     Emacs has been corrupted.
>
> I don't think this is a solution, because it would be easy to patch out
> the code that enforces that restriction.

Yes, indeed, but its also trivial to patch Emacs to run non-free
extensions today.

Is the real issue that the GPL doesnt inhibit soft linking of non-free
modules? I always assumed the GPL didnt allow for this. 

-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    Yes, indeed, but its also trivial to patch Emacs to run non-free
    extensions today.

It is not trivial for most people.

    Is the real issue that the GPL doesnt inhibit soft linking of non-free
    modules? I always assumed the GPL didnt allow for this. 

There is no clear simple answer to the question,
and that is why I don't want to run the risk.

Re: Release plans

[Johannes Weiner]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Yes, indeed, but its also trivial to patch Emacs to run non-free
>     extensions today.
>
> It is not trivial for most people.

Most people don't need to study or modify the software they run either.
They will benefit from those who actually can and do so, though.

That doing that change is not trivial for most people is obvious.  But
most people also don't write their own compiler!

It's enough if there is one person writing a compiler.

It's enough if there is one person providing a patch to run non-free
extensions.

	Hannes

Re: Release plans

[Richard M. Stallman]

    It's enough if there is one person providing a patch to run non-free
    extensions.

Such all-or-nothing thinking isn't valid.  It is clear that if some
sort of add-on depends on people to patch Emacs, that obstacle will
discourage its adoption.  This will in turn discourage the development
of such add-ons.  That doesn't absolutely assure no one will develop
them, but does help.

Re: Release plans

[Johannes Weiner]

Hi Richard,

"Richard M. Stallman" <rms@gnu.org> writes:

>     It's enough if there is one person providing a patch to run non-free
>     extensions.
>
> Such all-or-nothing thinking isn't valid.  It is clear that if some
> sort of add-on depends on people to patch Emacs, that obstacle will
> discourage its adoption.  This will in turn discourage the development
> of such add-ons.  That doesn't absolutely assure no one will develop
> them, but does help.

Sure.  Then make that something more convenient.  Consider a
distribution of GNU Emacs that is prepatched with a module loader and
comes with an installation script that fetches the non-free library from
an URL.  Or something similar if this has legal issues.

Or don't distribute a fork but go for the library and executable wrapper
approach you can stack on top of a vanilla GNU Emacs, utilizing the
process interface.

My point is that even today you can implement something that extends
Emacs in non-free ways with rather low efforts and provide a product
that is easy to use.

I highly doubt that people who have the idea of distributing non-free
extensions to Emacs would wait until it grows a module loader.  It's not
needed.

But a module loader probably encourages hackers and not so much immoral
individuals/companies whos primary goal is to sell their software rather
than hacking the good hack.

Like I said, as a person keen on technical stuff I refuse to work around
limited interfaces but would prefer improving them.

If my goal is not a cool mechanism but getting my nonfree software
distributed, I don't need the module loader and can already do that.

	Hannes

Re: Release plans

[Tassilo Horn]

On Tuesday 19 August 2008 14:21:01 Richard M. Stallman wrote:

Hi!

>     Yes, indeed, but its also trivial to patch Emacs to run non-free
>     extensions today.
>
> It is not trivial for most people.

But it's trivial for everybody who is capable of writing such a non-free
module.  So let's say I want to distribute a non-free module (just an
example, I'm on the good side!).  In order to do that right now, I'd do
the following steps.

1. I fork emacs and put some dynamic module loading facility in it, and
   release the whole thing under GPLv3.  Because the patch already
   exists, that's not much work.

2. I provide my non-free module for my fork.

Now let's say emacs had a module loading facility, and each module would
have to register itself as being free in order to allow its loading.  If
I wanted to create a non-free module then, I had two possibilities.

- Falsely register my module as free and FSF and me will meet at court.
  (Is there a danger that a court will decide it's legal to register a
  module as free if it's not?)

- Fork emacs like above and put the registration code out.

So basically I can always provide non-free modules if I fork emacs.  The
costs for that are very low, no matter if emacs has or has no module
loading facility.

So let's now assume I want to provide a free module.  Currently (without
the module loader) I'd have to fork emacs, too.  But I'm a member of the
free software community, so I don't want to do that.  As a result I'll
try to work around the limitations with some ugly hacks like a command
line interface for the library I want to use.

So to summarize: For someone who wants to create a non-free module, the
costs are the same, no matter if emacs has or has no dynamic module
loading support.  For someone who wants to create a free module, the
availability of this feature in GNU Emacs is crucial.

The only danger I can see is that a module loader plus some nice, free
modules would push emacs reputation that high and create such an hype
that industry rediscoveres it as platform for their products.  Honestly,
before that happens the moon becomes a square! ;-)

And at last I want to point out some features SXEmacs has (which has a
full blown foreign function interface) which could be very useful.

  * Use emacs as X11 window manager (talk directly to XLib or xcb).

  * It supports all image formats the free ImageMagick library supports.

  * It has enhanced numbed types by binding to some free math library.

  * It has some direct bindings to various databases.

  * It downloads files by directly using libcurl.

Bye,
Tassilo

Re: Release plans

[Richard M. Stallman]

    - Falsely register my module as free and FSF and me will meet at court.
      (Is there a danger that a court will decide it's legal to register a
      module as free if it's not?)

I have not discussed this with lawyers, but I don't know of any law
that would prohibit it.  That's why I am reluctant to rely on such a
scheme.  If that sort of thing were clearly forbidden by copyright
law, I would find the method would be much more appealing.

Re: Release plans

[Gilaras Drakeson]

        The Linux kernel doesn't refuse to boot when it recognizes a non
        GPL module being loaded. It justs informs you its "tainted".

        Emacs should of course just refuse to use functions in modules
        that are not GPL compliant, not just inform the user that the
        moral integrity of Emacs has been corrupted.

    I don't think this is a solution, because it would be easy to patch
    out the code that enforces that restriction.

True, but we are not in a *much* better situation now, because if
releasing a patched Emacs is acceptable in the game, a large software
corporation can easily release a patch that enables loading of external
modules for Emacs.

I don't think this restriction could be enforced just by software.  Some
addendum to the license (maybe only specific to Emacs, GCC, and other
meta-applications if adding that to GPLv3+ is not easy) might prevent
loading of non GPLv3+ modules. Keeping the loader out of Emacs does not
count as a long term solution.

Gilaras

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:

 >     The Linux kernel doesn't refuse to boot when it recognizes a non GPL
 >     module being loaded. It justs informs you its "tainted".
 > 
 >     Emacs should of course just refuse to use functions in modules that are
 >     not GPL compliant, not just inform the user that the moral integrity of
 >     Emacs has been corrupted.
 > 
 > I don't think this is a solution, because it would be easy to patch out
 > the code that enforces that restriction.

I will remind you that that was good enough for XEmacs and Qt in your
opinion.  Circumstances may be different, but you should explain how.

If it's distributed only as a patch, who cares?  The patch that allows
dynamic loading is already available and quite self-contained IIRC,
we're in the same place already.

If it's a separate distribution with the patch preapplied and maybe
Emacs prebuilt, that is a fork.  The whole world knows what you think
of forks of Emacs, and how you treat the forkers.  I think that's
sufficient deterrent, and if it isn't enough, we can assume there's a
lot of value in the dynamic loader that people want pretty badly --
specifically, enough to overcome the inconvenience of patching in the
loader feature.

I really don't get this.  You are basically taking the open source
route here.  "People don't like to be free, so let's not tell them
about freedom -- let's make it relatively inconvenient to use
proprietary code."  Why not wait for the non-free modules, and then
publish a boycott list of such modules, give them a public dressing-
down, and in that way draw attention to the issue of freedom?

Re: Release plans

[Paul R]

Hi !

On Tue, 19 Aug 2008 02:13:47 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> said:

SJT> I really don't get this. You are basically taking the open source
SJT> route here. "People don't like to be free, so let's not tell them
SJT> about freedom -- let's make it relatively inconvenient to use
SJT> proprietary code." Why not wait for the non-free modules, and
SJT> then publish a boycott list of such modules, give them a public
SJT> dressing- down, and in that way draw attention to the issue of
SJT> freedom?

Stephen is right. We should never respond to a "*possible* lack of
freedom for some hypotetical consenting users" with a solution that
implies an *evident* lack of (technical) freedom for all Emacs fellow
users.

Really, here the cure harms more than the disease.

-- 
  Paul

Re: Release plans

[Richard M. Stallman]

    I will remind you that that was good enough for XEmacs and Qt in your
    opinion.

What opinion are you talking about?  I do not in general approve of
the decisions of the XEmacs developers, and they don't wait on my
approval any more than I wait on yours.

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:
 >     I will remind you that that was good enough for XEmacs and Qt in your
 >     opinion.
 > 
 > What opinion are you talking about?

About 4 years ago I asked you about whether it was compatible with the
GPL to distribute an XEmacs with a Qt interface, given that (a) the
X11 version of Qt had been relicensed to GPL, but (b) the Windows
version was still under a non-free license.

You replied that it was compatible if the build system provided no
support for linking Qt on the Windows system, and configure (for
Cygwin) warned that Qt is a nonfree library and therefore not
supported on Windows.

 > I do not in general approve of the decisions of the XEmacs
 > developers, and they don't wait on my approval any more than I wait
 > on yours.

We are unwilling to be dominated by your authority.  We do consider
your opinions and expertise, however, and of course the FSF is the
largest rightsholder in XEmacs (my estimate, by lines of code).

Re: Release plans

[Richard M. Stallman]

    About 4 years ago I asked you about whether it was compatible with the
    GPL to distribute an XEmacs with a Qt interface, given that (a) the
    X11 version of Qt had been relicensed to GPL, but (b) the Windows
    version was still under a non-free license.

    You replied that it was compatible if the build system provided no
    support for linking Qt on the Windows system, and configure (for
    Cygwin) warned that Qt is a nonfree library and therefore not
    supported on Windows.

That sounds right, but it is a different issue.

whither GNU

[Thomas Lord]

It's interesting how this discussion has laid something bare:

The take away message from RMS' intransigence seems to be
that if you want to make a priority of exercising software freedom
so as to maximize the utility of available free software, you should
not subject yourself to GNU project leadership.  That seems
ironic but it shouldn't be a surprise:

The GNU projects, especially central ones like Emacs, do
double duty as "messages" and their role as messages takes
priority over technical quality.

I'm pretty sure that isn't what I signed up for when I
decided that software freedom is the Right Thing but
I guess other people's mileage may vary.

-t






Richard M. Stallman wrote:
>     About 4 years ago I asked you about whether it was compatible with the
>     GPL to distribute an XEmacs with a Qt interface, given that (a) the
>     X11 version of Qt had been relicensed to GPL, but (b) the Windows
>     version was still under a non-free license.
>
>     You replied that it was compatible if the build system provided no
>     support for linking Qt on the Windows system, and configure (for
>     Cygwin) warned that Qt is a nonfree library and therefore not
>     supported on Windows.
>
> That sounds right, but it is a different issue.
>
>
>
>   

Re: whither GNU

[Juanma Barranquero]

On Fri, Aug 22, 2008 at 02:34, Thomas Lord <lord@emf.net> wrote:

> The GNU projects, especially central ones like Emacs, do
> double duty as "messages" and their role as messages takes
> priority over technical quality.

That was pretty evident in the way bzr did get "chosen" as future dVCS
for Emacs.

   Juanma

Re: whither GNU

[David Robinow]

On Thu, Aug 21, 2008 at 8:17 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Aug 22, 2008 at 02:34, Thomas Lord <lord@emf.net> wrote:
>> The GNU projects, especially central ones like Emacs, do
>> double duty as "messages" and their role as messages takes
>> priority over technical quality.
>
> That was pretty evident in the way bzr did get "chosen" as future dVCS
> for Emacs.
No, that's a separate issue. Thomas is referring to the (unnecessary)
war against non-free software having preference over the improvement
of free software.
 The choice of bzr was perfectly reasonable. Emacs and bzr are part of
the GNU community. The choice has increased the "market share" of bzr
and has already led to improvements.
 Are there still problems? I don't know. I haven't used it yet. If you
find any you should file a bug report.

Re: whither GNU

[Johannes Weiner]

Hi,

"David Robinow" <drobinow@gmail.com> writes:

> On Thu, Aug 21, 2008 at 8:17 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
>> On Fri, Aug 22, 2008 at 02:34, Thomas Lord <lord@emf.net> wrote:
>>> The GNU projects, especially central ones like Emacs, do
>>> double duty as "messages" and their role as messages takes
>>> priority over technical quality.
>>
>> That was pretty evident in the way bzr did get "chosen" as future dVCS
>> for Emacs.
> No, that's a separate issue. Thomas is referring to the (unnecessary)
> war against non-free software having preference over the improvement
> of free software.
>  The choice of bzr was perfectly reasonable. Emacs and bzr are part of
> the GNU community. The choice has increased the "market share" of bzr
> and has already led to improvements.
>  Are there still problems? I don't know. I haven't used it yet. If you
> find any you should file a bug report.

Perhaps the devs might not be quite sure about calling it a bug, but
does it count when I say I have never ever checked out the bzr
repository because I just aborted the operation when it still said `I am
working' after almost 15 minutes?

Btw, there is no point for me in filing a bug report.  There is a free
program that works way better for me and I am not interested in using
something inferior.  I would ponder if the other one was non-free but
this way it's just ridiculous.

	Hannes

Re: whither GNU

[Richard M. Stallman]

We need and appreciate bug reports for Emacs -- so please do report
the bugs you find in other free programs.

Re: whither GNU

[Juanma Barranquero]

On Fri, Aug 22, 2008 at 05:40, David Robinow <drobinow@gmail.com> wrote:

> No, that's a separate issue.

I don't think so. I was answering to that specific point: that some
GNU projects do double duty. bzr was chosen as a political statement,
so its role as message took priority over technical quality (its
technical quality, and those of the alternatives).

> Thomas is referring to the (unnecessary)
> war against non-free software having preference over the improvement
> of free software.

I've been reading the thread.

>  The choice of bzr was perfectly reasonable. Emacs and bzr are part of
> the GNU community. The choice has increased the "market share" of bzr
> and has already led to improvements.

You're agreeing with Tom: the choice of bzr was "perfectly reasonable"
for political, not technical, reasons.

>  Are there still problems? I don't know. I haven't used it yet. If you
> find any you should file a bug report.

I have used it. Perhaps that's why it's a bit more difficult for me to
consider it a perfectly reasonable choice.

(I'm not trying to restart that debate, though; I'm just agreeing with
Tom on a very specific point of his very interesting thoughts).

  Juanma

Re: whither GNU

[Thomas Lord]

Juanma Barranquero wrote:
> (I'm not trying to restart that debate, though; I'm just agreeing with
> Tom on a very specific point of his very interesting thoughts).
>   

It's "off topic" no matter where you bring it up (which is itself
an interesting fact) but ... yeah ... I have trouble cottoning to
any purported free software movement leadership that comes up
with some theory to explain why and demand that we do our
jobs as software engineers less well, on purpose.

Something is wrong with your political calculus if you manage
to come to that conclusion, in my opinion.

I can imagine doing deliberately less well is the Right Thing
if someone is holding a gun to your head, in some imaginable
circumstances, but as an overall GNU policy?  Think harder, RMS.


-t






>   Juanma
>
>
>
>   

Re: whither GNU

[Thomas Lord]

David Kastrup wrote:
> If technical superiority would have been RMS' priority, he would not
> have started the GNU project: 
It all started when he wanted to fix a bug in a printer driver
(the story goes)....





> a starting project will always be worse
> than existing solutions.

That's nothing to do with what we're talking about.

It's fine: we're building a new system and it starts off
"behind the pack".  Of course.

The question is what happens when we get to a fork
in the road.  Say, you are hacking some GNU code
and a choice arises:  you can make a change that makes
it better or you can avoid that change.  So, there's the
choice.    RMS is offering some pretty abstract
"theory" about why you should choose to *not* make
the improvement in these cases. 

Now, I'm not really reaching for some overarching
theory of my own about what makes a program
better or worse but I will go so far as to say that there
are some straightforward cases.  GCC is better (all
else being equal) with tree print/read.  Emacs is better
with a dynamic loader.   I don't think those are controversial
assertions *other than* RMS' theory that those features
put the free software movement at risk.

Now, wait and let's see if I understand this:  I should
fight for software freedom in order (among other things)
to have the rights to inspect and improve a program I
use but, in the course of my fight for software freedom,
I should inspect but not improve in these certain cases.
Sorry, that seems like a reductio ad absurdum conclusion --
there must be some bogus premise.    The bogus premise,
I see from about 20 years of history, is that it is important
to fret over what proprietary hacks a feature might enable.
It's a bogus premise because foresight is not 20-20:  we
sure kept people from making proprietary Emacs or
GCC add-ons but, meanwhile, built a heck of a platform
for proprietary web software.  Fretting over tactics to
avoid creating such platforms is pointless.  20 years of
experience shows this.  

So, I say, back to common sense and simple minded
"make the programs better."    Reject a dynamic loader
in Emacs if there is no good use for it or if the maintenance
cost is too high but don't reject it because someone might
possibly use it to launch proprietary code -- they'll do that
anyway, one way or another, using whatever features we
do include.




>   The free software movement which he started
> has always and consistently considered non-free software unacceptable.
> The "Open Source Movement", in contrast, tries selling free development
> models via claims of technical superiority.  RMS has never ascribed to
> that somewhat seductive idea.
>   

This has nothing to do, either, with the Open Source Industrial
Complex, or ESR's eyeball fetish, or any of that.   Quite independently
of any of those things there is a fork in the road: dynamic loader or
no.




> I don't see your use of insulting language like "think harder"

It's not insulting.   It's colloquial and comparatively mild.  

So: guess again.



>  as a
> desirable contribution either.  You imply that people coming to
> different conclusions than you or having other priorities must be
> stupid.
>   

Well, that's kind of true.   Yes, I think it is a dumb idea to ban
features like a dynamic loader in GNU Emacs.    That's not insulting.
I'm using "dumb" in the technical sense.  It means "please rethink that,"
or something close.   It also means "um, I'm not sure people should
trust the leadership if this is what they're coming up with."

If you can't say words like that in an engineering discussion
then you can't have an engineering discussion.   It isn't personal.
It isn't an attack.   Those words summarize the conclusion of the
critical analysis. 

My own mistakes in software engineering I usually describe
as "bone-headed" or "idiotic" or something like that.   Those
words are attributes of mistaken ideas -- they aren't personal
attacks.   Those are useful words in part because it is always important
to remember that anyone, especially one's self, can be "bone headed"
in an engineering project.    That's why we have peers -- to point
that kind of bogosity out, when it happens, if you are lucky.



> I can assure you that Richard is not an idiot 


He's been my supervisor.  I've worked in an office down the
hall from him.  I've interacted with him on and off for about 20 years.
I personally happen to like him although we aren't close.   I'm pretty
familiar with his strengths and weaknesses as a software engineer.


> (which is not to say that
> you can't find some relative idiots among free software supporters as
> well as anywhere else).  I can also tell you that this sort of public
> insulting and derision is not going to win any points for your case.
>   

Nobody is slinging insults and derision UNTIL YOU JUST THERE.

Stop impugning my character.   I can be understood perfectly well without
interpreting my comments as "insult" and "derision".   You have absolutely
no excuse for attacking my reputation that way.  Knock it off.



> Richard is not a person who takes kindly to this sort of behavior.  And
> I don't see that I can blame him much for that.
>   

Are you his spokesperson?



> If you want to show off your purported superiority, 

Um.... as one who is posturing as a defender of civility,
you make a *fine* hypocrite.


> go ahead and make a
> spectacle of yourself. 

WTF?!?



> But if you want to have your arguments
> considered at all, you'd better choose a different conversation style

Ok.  Try this one:  shut up with that noise.

I've been critical of some ideas that have governed GNU.  You've
"spun" that as if I'm on some kind of personal rampage trying
to attack RMS and prove my superiority or something.
YOU are the problem here, sycophant, and I'm tired of
being attacked in the way you are attacking me.

-t

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:

 >     How does not providing dynamic loading maximize what users can
 >     do while remaining free?
 > 
 > It protects against the danger of non-free C-level add-ons to
 > Emacs.

All a freedom-lover has to do to avoid those non-free add-ons is ...
avoid them.  How does a non-free add-on sneak in under my radar?  As
far as I can see, the possibility of remaining free is unaffected by
the presence or absence of a dynamic loader.

 > It's the same principle as the GPL itself.

As you like to say about copyright and patent, GPL and "no DSOs" are
two completely different things, so the same principles can't be
applied without careful justification.

The GPL prohibits certain freedom-inhibiting activities absolutely,
while leaving all value-in-use available to users.  But as I
understand it anything that can be done by dynamic linking (legally or
physically) can also be done by static linking, so it's not a
prohibition, merely an inconvenience, to potential violators.  On the
other hand, this restriction *does* detract from value-in-use.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     How does not providing dynamic loading maximize what users can
>     do while remaining free?
>
> It protects against the danger of non-free C-level add-ons to Emacs.
> It's the same principle as the GPL itself.
>   


That doesn't answer the question.   You said something odd:
that not having a dynamic loading feature helps to maximize
what users can do in freedom.   That's false, though.   Having
a dynamic loading feature would let users do more, in freedom.

Suppose it were *certain* that non-free (but perfectly legal)
C-level add-ons to GNU Emacs would result from adding a
dynamic loading feature.   That isn't a good argument to not
add the feature and here is why:

It is equally certain that GNU Make is used
to build non-free programs.  It is equally certain that GCC is
used to compile non-free programs.  It is equally certain that
GNU Emacs is used to edit non-free programs.   It is historic
fact that one of the biggest areas in which free software projects
have succeeded in creating free software jobs is in maintaining
and extending a GNU/Linux platform for running non-free
programs.  It is a historic fact that those free (both senses) tools
have led to the creation of non-free programs that were otherwise
unlikely to be written.   The GNU project can not help but
abet the creation of non-free programs, as long as their are people
who want to create non-free programs.

If we accept that the consequence of non-free programs is
reason enough to reject a feature, we ought not write any software
at all!

On the other hand, it is *plausible* that a well designed dynamic
loading feature would lead to tiny "boom" in new free software
programs.   Third parties could release C-level, free software
extensions to GNU Emacs without any need for additional
coordination with the GNU Emacs maintainers.   There would be
opportunity for people to experiment more freely with C-level
extensions -- more chances to find new uses.   There would be a
new marketplace of technical ideas in which people are enriched
by exercising their software freedoms.

When people have cause to *exercise* their software freedoms
they come to understand those freedoms better.   They are more
likely to come to regard those freedoms as simply "natural" --
as a basic right.   If more people are busy exercising their software
freedoms, more people will be prepared to defend those freedoms.

Since it is plausible that a dynamic loading feature can lead to more
people exercising their software freedoms, and since a dynamic loader
makes decent sense technically and at an architectural level, there
are strong arguments *for* adding a dynamic loader.

An analogous analysis applies to tree print and read in GCC. 
Certainty that non-free uses will result hardly changes much of
anything and is not a strong argument against the feature.
Plausibility that the feature will lead to more free software
uses of GCC is a strong argument for the feature.

If you want to think about what software to NOT write in order
to save work, think about software architecture and maintainability
and stuff like that.   Maybe it is wise to NOT write program X because
writing Y instead is simpler.

But thinking about what NOT to write as some kind of tactic for
discouraging new non-free programs is ineffective unless we write
no programs at all!

It is better to think about what programs TO WRITE and to think
in terms of "combinatorics".   A good GNU system will contain
a maximal number of opportunities to write new programs, new
modules, new add-ons, etc.   The more that people *actually do*
with their software freedom, the more they will come to understand
and value their software freedom.

-t

Re: Release plans

[Alan Mackenzie]

'Evening, Thomas!

On Sat, Aug 16, 2008 at 02:04:11PM -0700, Thomas Lord wrote:
> Richard M. Stallman wrote:
> >    How does not providing dynamic loading maximize what users can
> >    do while remaining free?

> >It protects against the danger of non-free C-level add-ons to Emacs.
> >It's the same principle as the GPL itself.

> That doesn't answer the question.   You said something odd:
> that not having a dynamic loading feature helps to maximize
> what users can do in freedom.   That's false, though.   Having
> a dynamic loading feature would let users do more, in freedom.

[ .... ]

> When people have cause to *exercise* their software freedoms
> they come to understand those freedoms better.   They are more
> likely to come to regard those freedoms as simply "natural" --
> as a basic right.   If more people are busy exercising their software
> freedoms, more people will be prepared to defend those freedoms.

Yes, but.  I think you understand Richard's argument but are glossing
over it.  We're not just individuals - we live in a community, and our
exercise of our freedoms affects everybody else.  (If you're a political
libertarian, you probably need read no further. ;-)  You aren't
considering the effect on everybody else.

The ability to link binary libraries into Emacs means the ability to link
non-free binaries in (think Linux modules here), possibly with _very_
useful functionality, whose inclusion could screw up Emacs's freedom in a
significant way.  Five years from now, lots of people could be "freely"
chosing this "non-free" version.  This would be damaging to the aims of
the FSF.

Now I'm not saying this is an overwhelming argument.  I'm saying that
it must be weighed and balanced against the (substantial) benefits of
binary libraries.  Just as individual people's freedom to own guns must
be weighed against the right of the community not to have its members
shot.

My opinion on allowing binary libraries into Emacs is that its dangers
would be greater than the benefits it would allow.  I'm willing to be
persuaded I'm mistaken.

You should address this, instead of evading it as you have done up to
now.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > My opinion on allowing binary libraries into Emacs is that its dangers
 > would be greater than the benefits it would allow.  I'm willing to be
 > persuaded I'm mistaken.
 > 
 > You should address this, instead of evading it as you have done up to
 > now.

No, those of you who *assert without a shred of evidence* that there
are significant dangers should address that lack.  XEmacs, as well as
many GNU applications, allow loadable modules.  SXEmacs takes it a
step further: it provides a generic foreign function interface.  So if
there's a danger, you should be able to quote us the products we can
buy at Circuit City or download from www.DownWithFreedom.com.  The
amount of damage done by NVIDIA's drivers for the Linux kernel is
substantial -- but the damage to users is matched one-for-one by
damage to NVIDIA's reputation, and the damage to freedom is nil, as we
see people easily switching from NVIDIA products to ATI for the sake
of good/free drivers.

$250 for a new state-of-the-art video card?  That's not damage,
friends, that's *tuition*.

Where's the beef, for heaven's sake?

Re: Release plans

[Alan Mackenzie]

Hi, Stephen!

On Sun, Aug 17, 2008 at 07:43:03AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:
>  > My opinion on allowing binary libraries into Emacs is that its
>  > dangers would be greater than the benefits it would allow.  I'm
>  > willing to be persuaded I'm mistaken.

>  > You should address this, instead of evading it as you have done up
>  > to now.
 
> No, those of you who *assert without a shred of evidence* that there
> are significant dangers should address that lack.

That's a category error.  I wasn't talking about a scientific process
for which evidence can be weighed up.  I am rather asserting the
credible existence of a mechanism by which Emacs could become
essentially un-free.  The exercise of freedom of choice by the gormless
masses is an essential component of that mechanism.  Nasty deviousness.

Richard is a master of nasty deviousness, so the fact that he sees a
problem is reason in itself to take it seriously.  ;-)

The essential point is that if an un-free Emacs became established
through the mechanism of loading binary libraries, we could not easily
reverse it.

> XEmacs, as well as many GNU applications, allow loadable modules.
> SXEmacs takes it a step further: it provides a generic foreign
> function interface.  So if there's a danger, you should be able to
> quote us the products we can buy at Circuit City or download from
> www.DownWithFreedom.com.

No.  The fact that nothing has yet happened is not by itself evidence of
lack of danger.

I think you said recently that there's an obscure patch around which
allows binaries to be loaded into XEmacs (and maybe Emacs), rather than
the facility being built in to the official XEmacs.  (Forgive me if I've
misremembered here.)  That's very different from something being a core
feature, encouraged by the prime maintainers.

> Where's the beef, for heaven's sake?

I don't accept that that, by itself, is a valid way to proceed.  We need
to forsee and analyse things which haven't happened but could happen.

To emphasise, I'm not convinced that allowing binaries to be loaded into
Emacs would cause danger.  I'm not convinced it's safe, either.  But I
am convinced the move would be irreversible.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > That's a category error.

I see no morphisms.  How can there be a category?

 > I wasn't talking about a scientific process for which evidence can
 > be weighed up.

Shouldn't you be?  Surely you know it is possible to quantify risk,
and analyze it scientifically?  Why do you ask that we on your
nightmares, or Richard's, to guide policy?

 > I am rather asserting the credible existence of a mechanism by
 > which Emacs could become essentially un-free.

Well, let me propose that it's irrelevant, because I assert the
credible existence of a mechanism involving loadable binaries by which
XEmacs will become so superior to Emacs that only people still using
Emacs are those willing to work two or more hours with Emacs when they
could get the job done with XEmacs.  No users, no unfreeness problem. ;-)

Are you beginning to see how untenable your position is?  In fact the
only thing it has going for it is

 > Richard is a master of nasty deviousness, so the fact that he sees a
 > problem is reason in itself to take it seriously.  ;-)

but that's genuinely ad hominem.

 > The essential point is that if an un-free Emacs became established
 > through the mechanism of loading binary libraries, we could not easily
 > reverse it.

Huh?  All you have to do is write the patch and announce a release.
Richard has done that before (the security patch a couple years ago).

A couple of corrections:

 > I think you said recently that there's an obscure patch around
 > which

The patch is to Emacs, and it's obscure only because it has been
refused inclusion in Emacs with extreme firmness, so that its
proponents gave up about five years ago.  In XEmacs 21.4 and later,
it's as simple as ./configure --with-modules.  In recent SXEmacs, I'm
not sure that --with-modules is still supported, but that's OK because
matters are even worse: .configure --with-ffi gives you a foreign
function interface which allows you to access data and functions in
any .so without any C-level hacking.

 > That's very different from something being a core feature,
 > encouraged by the prime maintainers.

Well, in XEmacs, the module loader *is* a core feature encouraged by
the maintainers.  It's not configured by default because demand is so
far low.  In SXEmacs, FFI is configured by many users because packages
are downloaded not by EFS as in XEmacs, but via a FFI interface to
libcurl implemented entire in Lisp.

Re: Release plans

[Alan Mackenzie]

Morning, Stephen!

On Mon, Aug 18, 2008 at 09:01:54AM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > I wasn't talking about a scientific process for which evidence can
>  > be weighed up.

> Shouldn't you be?  Surely you know it is possible to quantify risk,
> and analyze it scientifically?

OK, but it is like the blowing up of a nuclear reactor, not a plane
crash.  You don't say "hey, no reactors of type XYZ have blown up,
therefore it's safe"; instead, you analyse the way it's made and run, and
probe for potential chains of failures.  With a plane crash, on the other
hand, you can say "a plane of type UVW only crashes every 100,000,000
flight hours, so you'll be OK.".

> Why do you ask that we on your nightmares, or Richard's, to guide
> policy?

I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
word out.

[ .... ]

> Are you beginning to see how untenable your position is?

No.  It may well be that, after more rigorous analysis, loadable binaries
in Emacs might not be a problem.  But being wrong is a long way from
being untenable.

> In fact the only thing it has going for it is

>  > Richard is a master of nasty deviousness, so the fact that he sees a
>  > problem is reason in itself to take it seriously.  ;-)

> but that's genuinely ad hominem.

Yes, but it's not an a.h. attack.  It's an a.h. compliment.

>  > The essential point is that if an un-free Emacs became established
>  > through the mechanism of loading binary libraries, we could not
>  > easily reverse it.

> Huh?  All you have to do is write the patch and announce a release.
> Richard has done that before (the security patch a couple years ago).

"Huh?"?  Such a patch would do nothing to disestablish an established
un-free version.

> A couple of corrections:

>  > I think you said recently that there's an obscure patch around
>  > which

> The patch is to Emacs, and it's obscure only because it has been
> refused inclusion in Emacs with extreme firmness, so that its
> proponents gave up about five years ago.  In XEmacs 21.4 and later,
> it's as simple as ./configure --with-modules. ....

>  > That's very different from something being a core feature,
>  > encouraged by the prime maintainers.

> Well, in XEmacs, the module loader *is* a core feature encouraged by
> the maintainers.  It's not configured by default because demand is so
> far low.

Those two sentences seem to contradict eachother.  I can't find any
documentation for it in either of the manuals (XEmacs 21.4.17) or NEWS.
I even know it exists, and I've even got a solid search term ("loader"),
but I still can't find it.  That's hardly encouragement.

How much use has been made of this module loader in XEmacs?  What's it
been used for?

> In SXEmacs, FFI is configured by many users because packages
> are downloaded not by EFS as in XEmacs, but via a FFI interface to
> libcurl implemented entire in Lisp.

I've just had a look at the SXEmacs home page, having not previously been
aware of it.  I can't really see any reason for SXEmacs's existence.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Morning, Stephen!
 > 
 > On Mon, Aug 18, 2008 at 09:01:54AM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > I wasn't talking about a scientific process for which evidence can
 > >  > be weighed up.
 > 
 > > Shouldn't you be?  Surely you know it is possible to quantify risk,
 > > and analyze it scientifically?
 > 
 > OK, but it is like the blowing up of a nuclear reactor, not a plane
 > crash.

Faulty analogy, until you provide a neutrino's weight of evidence that
any user's freedom to stop using the module is impaired.  The
difference between the nuke and the plane is that we know a nuke
accident endangers millions of people.  A plane crash can be avoided
by not getting on.  Similarly, any damage to my freedom that is
threatened by a proprietary module can be avoided by not using it.
Sneaking it in a distribution of Emacs is clearly a GPL violation.

 > > Why do you ask that we on your nightmares, or Richard's, to guide
 > > policy?
 > 
 > I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
 > word out.

"Why do you ask that we *depend* on your nightmares, or Richard's, to
guide policy?"

 > > Are you beginning to see how untenable your position is?
 > 
 > No.  It may well be that, after more rigorous analysis, loadable binaries
 > in Emacs might not be a problem.  But being wrong is a long way from
 > being untenable.

Sigh.  All the analysis so far has been provided by me and Tom,
principally, with similar comments from others on the pro-DSO side.
You just repeat your assertions, and Stallman compliments your for
your clear statement of the issues.  Humbug!

 > > In fact the only thing it has going for it is
 > 
 > >  > Richard is a master of nasty deviousness, so the fact that he sees a
 > >  > problem is reason in itself to take it seriously.  ;-)
 > 
 > > but that's genuinely ad hominem.
 > 
 > Yes, but it's not an a.h. attack.  It's an a.h. compliment.

Attacks are often valid logically.  Ad hominem is a logical *fallacy*,
inadmissible in reasoned discouse.

 > >  > The essential point is that if an un-free Emacs became established
 > >  > through the mechanism of loading binary libraries, we could not
 > >  > easily reverse it.
 > 
 > > Huh?  All you have to do is write the patch and announce a release.
 > > Richard has done that before (the security patch a couple years ago).
 > 
 > "Huh?"?  Such a patch would do nothing to disestablish an established
 > un-free version.

Of course it does.  The old version was an unfree *GNU* Emacs.  The
new state of affairs is a free GNU Emacs, and an unfree *fork*.  If
you don't think that causes disestablishment, consider that no major
GNU/Linux distributor would be likely to continue to distribute the
fork as GNU Emacs; they'd make a separate package.  Users would get
their butts kicked as this addictive non-free app stops working with a
bizarre error message about `function load-module not found' as soon
as they upgraded Emacs.  And Richard would do what he did to the
Lucid people (what *they* did then is not relevant; I'll bet you none
of them would be willing to go through that again, is the point).

If that doesn't disestablish the fork pretty quick, Emacs is at least
as far behind the fork as Emacs 18.59 was behind Lucid 19.1.  Pretty
unlikely.

The above is what *analysis* looks like.  Are you beginning to see how
untenable your position is yet?

 > Those two sentences seem to contradict eachother.  I can't find any
 > documentation for it in either of the manuals (XEmacs 21.4.17) or NEWS.
 > I even know it exists, and I've even got a solid search term ("loader"),
 > but I still can't find it.  That's hardly encouragement.

OK, so we don't *encourage* it, and we have some documentation bugs.
"Would you like to work on the bugs?"  It's still a standard feature,
supported and easily configured for those interested in it.

Alan, why don't you apply these picky-picky standards to your *own*
non-arguments?  You complain about how we try to avoid the issues,
although I don't see that we do.  I've explained, Tom has explained,
why we don't believe a "non-free Emacs" can become established.  But
you have a monster in the closet that simply disappears every time we
open the door.  Not one dirty footprint, no fur settling to the floor,
nothing.

You haven't even described what a "non-free Emacs" would look like.  I
mean for starters, the GPL guarantees that Emacs remains free.  So
people can just say no and keep their personal freedom.

And what is the difference between an Emacs that calls non-free code
via a binary module, and an Emacs that accesses files via TRAMP and
non-free SSH?  Should we remove process support from Emacs?

 > I've just had a look at the SXEmacs home page, having not previously been
 > aware of it.  I can't really see any reason for SXEmacs's existence.

Freedom.  Steve on the one side and me and Ben on the other had
different ideas about how to run a project, and what quality of code
and design should be allowed in.  ("Quality" here includes style etc,
it's not necessarily better or worse.)

Dynamic loading (was: Release plans)

[Stefan Monnier]

[ Please people, use descriptive subjects. ]

One thing that's not clear to me is:
assuming we add some XEmacs-style dynamic loader to Emacs (probably
with some kind of dynamic GPL-check for good measure), would it be legal
for someone to distribute a non-GPL module?

IIUC, this is a question related to the distribution of non-GPL Elisp
packages (which I thought was illegal but recently Richard mentioned he
wasn't sure and he was waiting for legal advice about it), and maybe
also to the precedent of the GMP-2.0 library.

Can anyone enlighten me?


        Stefan

Dynamic loading (was: Release plans)

[Stephen J. Turnbull]

Stefan Monnier writes:
 > [ Please people, use descriptive subjects. ]
 > 
 > One thing that's not clear to me is:
 > assuming we add some XEmacs-style dynamic loader to Emacs (probably
 > with some kind of dynamic GPL-check for good measure), would it be legal
 > for someone to distribute a non-GPL module?

Larry Rosen (in his book) says that he believes that it would be
permitted under copyright to distribute the non-GPL module only, ie,
not as part of a distribution including Emacs.  (Not for this specific
case, and his language is somewhat abstract.  But that's my reading of
his position, based on a case where no Emacs code is copied into the
module.  APIs apparently don't count because they're not "expressive",
there's only one way to do it.)

The FSF in its complaint to Aladdin (Ghostscript) claimed that it was
infringement of copyright to do so.  Aladdin distributed a non-GPL
Ghostscript with a Makefile that allowed linking to GNU readline if
you had it.  The threat of court action caused Aladdin to back down
and remove the Makefile stanza that implemented the link.)

As far as I know it has not been tested in court.

 > IIUC, this is a question related to the distribution of non-GPL Elisp
 > packages (which I thought was illegal but recently Richard mentioned he
 > wasn't sure and he was waiting for legal advice about it),

Yes.  AFAICS it's the same thing, legally.  Both a module and an Elisp
library would be part of the same process space, so the "standard
sufficient test" for a single work would be satisfied.  The question
then becomes is the user of the non-GPL code, or the distributor of
the non-GPL code, responsible for the derivative work?  If it's the
user, the GPL provides no hindrance, since it doesn't regulate the
running of the program.

 > and maybe also to the precedent of the GMP-2.0 library.

I'm not familier with that.

Re: Dynamic loading

[Stefan Monnier]

> module.  APIs apparently don't count because they're not "expressive",
> there's only one way to do it.)

IIUC the case for GMP was based on the fact that a user of the GMP API
wasn't just using the API but was necessarily using GMP (even if loaded
dynamically) because there was no other implementation (which forced
the offending company to write a substitute for GMP which implemented
the same API but with a more liberal license).

So similarly, an Elisp package can currently only be run by linking it
with GPL'd code (given the lack of non-GPL'd Emacs), which (I thought)
is the reason why it has to be GPL'd as well.


        Stefan

Re: Dynamic loading

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> module.  APIs apparently don't count because they're not "expressive",
>> there's only one way to do it.)
>
> IIUC the case for GMP was based on the fact that a user of the GMP API
> wasn't just using the API but was necessarily using GMP (even if loaded
> dynamically) because there was no other implementation (which forced
> the offending company to write a substitute for GMP which implemented
> the same API but with a more liberal license).
>
> So similarly, an Elisp package can currently only be run by linking it
> with GPL'd code (given the lack of non-GPL'd Emacs), which (I thought)
> is the reason why it has to be GPL'd as well.

This is how I thought an Emacs dynamic load facility would be done as
well. That is, Emacs would not load any old .so/.dll file, it would only load
libraries confirming to a specific Emacs api. 

>
>
>         Stefan
>
-- 
Joakim Verona

Re: Dynamic loading

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > module.  APIs apparently don't count because they're not "expressive",
 > > there's only one way to do it.)
 > 
 > IIUC the case for GMP was based on the fact that a user of the GMP API
 > wasn't just using the API but was necessarily using GMP (even if loaded
 > dynamically) because there was no other implementation (which forced
 > the offending company to write a substitute for GMP which implemented
 > the same API but with a more liberal license).

Sure, but if no GMP code is actually copied *by the distributor* then
it's very hard to argue that the distributor has violated the GPL (this
is something Richard referred to earlier).  That was the contention of
Aladdin in the Ghostscript + GNU readline case, but it didn't go to
court because it didn't matter to Aladdin's business plan, it only
hurt non-paying users.  So they weren't willing to spend USD 0.01, and
the FSF won by having more lawyers, not on the strength of the case.

Did a case for GMP actually go to court, or was it simply that it
seemed cheaper (in community reputation as well as legal fees) to cave
in and write a workalike?

That also happened with readline, of course.  The BSD community has
a similar library under BSD license (called libedit, I believe).

 > So similarly, an Elisp package can currently only be run by linking it
 > with GPL'd code (given the lack of non-GPL'd Emacs), which (I thought)
 > is the reason why it has to be GPL'd as well.

Well, there's also stuff like macros to worry about.

However, I think the distributor of the Lisp package could probably
argue that an Elisp package is data being processed, not part of
Emacs.  Since running Emacs is 100% unrestricted, IMO IANAL a claim
that an Elisp package must be distributed under GPL would be hard to
prove under copyright law.  For example, note that the special
exemption to the GPL for bison only applied to programs using the
"hairy" skeleton, because that was the code being copied.  Even though
yacc was available, copying the skeleton meant it was a derivative
work.  (Not directly relevant, since with elisp we have no copying --
assuming that no compiled code based on GPLed macros is distributed,
but it illustrates the way to think about these problems.)

Re: Dynamic loading

[Richard M. Stallman]

    Sure, but if no GMP code is actually copied *by the distributor* then
    it's very hard to argue that the distributor has violated the GPL (this
    is something Richard referred to earlier).

Sometimes we can still argue that it is a violation, but it would be a
different kind of issue and the case is not so clear.

    That also happened with readline, of course.  The BSD community has
    a similar library under BSD license (called libedit, I believe).

("Under BSD license" is ambiguous; it is best always to say which one.
See http://www.gnu.org/philosophy/bsd.html.)

That is true now, but there was a long time when readline had no
compatible replacement.  At that time, anything designed to call
readline was certainly meant to be linked with GNU readline.

    However, I think the distributor of the Lisp package could probably
    argue that an Elisp package is data being processed, not part of
    Emacs.

That is true as regards the interpreter itself, and programming
constructs, but not as regards calling the editing-specific
application facilities of Emacs.

Re: Release plans

[Alan Mackenzie]

Evening, Stephen!

On Tue, Aug 19, 2008 at 02:58:16AM +0900, Stephen J. Turnbull wrote:

> Faulty analogy, until you provide a neutrino's weight of evidence that
> any user's freedom to stop using the module is impaired.

I do not accept, as a criterion for freedom, that it is permissible to
consider a person's actions divorced from the effect on his neighbours.
We are not just individuals, we are each part of a community, in fact of
several communities.  If Joe gets saddled with a non-free Emacs, that
affects James who has a free one, and quite markedly.  That's just my
philosophy and my politics.  If you're going to challenge my arguments,
you're going to have to accept, even if only for the sake of argument,
these principles.  I think I made that clear last night, with my image of
lots of hypothetical Microsoft users who'd get saddled with an entirely
non-free Emacs.

> The difference between the nuke and the plane is that we know a nuke
> accident endangers millions of people.  A plane crash can be avoided by
> not getting on.

This is where we differ.  A plane crash hurts not just the people on
board, but the people the wreckage falls on.  Think of Lockerbie in 1988.

> Similarly, any damage to my freedom that is threatened by a proprietary
> module can be avoided by not using it.

The fallout will hit you.  That proprietary module will gunge up Emacs
development, damage Emacs's reputation, cause sysadmins to hate it
(they must field the rage from hackers) just as that aeroplane devastated
a street in Lockerbie.

Again, I'm thinking about the Community's freedom, not just yours as an
isolated individual.

>  > > Why do you ask that we on your nightmares, or Richard's, to guide
>  > > policy?

>  > I don't ask anyone to we on my nightmares.  ;-)  I think you missed a
>  > word out.

> "Why do you ask that we *depend* on your nightmares, or Richard's, to
> guide policy?"

I think I've made it clear that my "nightmares", as you call them, are
not positions I'm defending.  I put them forward only as a counter
(mainly) to Tom and to you, to show that bad things are possible, even if
not probable.

>  > No.  It may well be that, after more rigorous analysis, loadable
>  > binaries in Emacs might not be a problem.  But being wrong is a long
>  > way from being untenable.

> Sigh.  All the analysis so far has been provided by me and Tom,
> principally, with similar comments from others on the pro-DSO side.
> You just repeat your assertions, and Stallman compliments your for
> your clear statement of the issues.  Humbug!

Well, I don't think I'm calling people nasty names, and I'm not using
derogatory hyperbole/ambiguous terms like "nightmare", "defeatist", and
"untenable" to imply or half imply other people are idiots or incapable,
or to detract from calm factual discussion.

The analysis from you and Tom falls short of mathematical perfection.
Unless I'm mistaken, it focusses purely on the effects it would have on
knowledgeable automous hackers.  To me, it is thus incomplete, and thus
invalid.  In any case, I think the burden of proof lies on you, as a
proponent of change, not on me.

I think we differ because our axioms differ.  You and T regard only the
freedom of the informed automous hacker as important.  I (and possibly
RMS) see freedom for the entire community as important.  I think my
hypothetical bad case ("microsoft8.dll") from last night made that clear.
That such could be imposed on others is a bad thing for me.  Apparently
it bothers you not at all.

>  > >  > Richard is a master of nasty deviousness, so the fact that he
>  > >  > sees a problem is reason in itself to take it seriously.  ;-)

>  > > but that's genuinely ad hominem.

>  > Yes, but it's not an a.h. attack.  It's an a.h. compliment.

> Attacks are often valid logically.  Ad hominem is a logical *fallacy*,
> inadmissible in reasoned discouse.

<sigh>.  What I meant, and I think this was perfectly obvious, is that
Richard's copious experience of nasty deviousness in the real world, his
contacts with legal experts, his experience of and intuition in such
things, and so on, should incline the rest of us to respect his judgement
and caution.  Is that OK for you now? 

>  > >  > The essential point is that if an un-free Emacs became
>  > >  > established through the mechanism of loading binary libraries,
>  > >  > we could not easily reverse it.

>  > > Huh?  All you have to do is write the patch and announce a
>  > > release.  Richard has done that before (the security patch a
>  > > couple years ago).

>  > "Huh?"?  Such a patch would do nothing to disestablish an established
>  > un-free version.

> Of course it does.  The old version was an unfree *GNU* Emacs.  The
> new state of affairs is a free GNU Emacs, and an unfree *fork*.  If
> you don't think that causes disestablishment, .....

Sorry, this is just a pedantic squabble about the exact meaning of words.
"Establish" has more than one syllable, and that should have been a
warning sign for me not to use it.  Here's a clarification:

Should a non-free Emacs become widely installed ("established"), say GNU
Emacs hobbled by the "microsoft8.dll" I pictured last night, a newer
version of Emacs is unlikely to cause the number of installations of that
un-free version to fall rapidly to near zero (i.e., become
"disestablished").

> The above is what *analysis* looks like.  Are you beginning to see how
> untenable your position is yet?

I've nothing more to add in this particular bit of the conversation.

>  > Those two sentences seem to contradict eachother.  I can't find any
>  > documentation for it in either of the manuals (XEmacs 21.4.17) or
>  > NEWS.  I even know it exists, and I've even got a solid search term
>  > ("loader"), but I still can't find it.  That's hardly encouragement.

> OK, so we don't *encourage* it, and we have some documentation bugs.
> "Would you like to work on the bugs?"  It's still a standard feature,
> supported and easily configured for those interested in it.

Assuming that, somehow, they get to find out the feature exists.  If I
didn't know you better, I'd wonder if you weren't being economical with
the truth here.  It's your project, Stephen, so please give me a pointer
to something in XEmacs 21.4.17 which tells me how to link in an external
binary.  I'm interested in what this feature looks like.  And please tell
me how I should have become aware of it.  Or did the feature first appear
in 21.4.x, where x > 17?

> Alan, why don't you apply these picky-picky standards to your *own*
> non-arguments?  You complain about how we try to avoid the issues,
> although I don't see that we do.  I've explained, Tom has explained,
> why we don't believe a "non-free Emacs" can become established.  But
> you have a monster in the closet that simply disappears every time we
> open the door.  Not one dirty footprint, no fur settling to the floor,
> nothing.

For the third time, our basic axioms seem to differ.  I don't think you
see the point I'm making, and your analysis is oblivious to that point,
so I disregard it.  Maybe.

> You haven't even described what a "non-free Emacs" would look like.

That's unwarranted and manifestly false.  In my post last night, I drew a
picture of Emacs running on a future MS OS, where in order to get access
to its file system, you had to install the proprietary library
"microsoft8.dll".  This would have the side-effect, on the pretext of
"security", of disabling `defun' and only allowing signed (by MS) Lisp
libraries to be loaded.  This scenario would be essentially impossible
without Emacs linking into external binaries.  Tom, in his reply, simply
failed to address this central issue of my post.  An apology, please.

> I mean for starters, the GPL guarantees that Emacs remains free.  So
> people can just say no and keep their personal freedom.

Oh, so GPL's "guarantees" mean that everything's fine, and so we don't
need to worry about anything.  They are guarantees, after all.  Hmmm.

For the fourth time, I reject your axiom that the measure of freedom is
solely that of individual informed autonomous hackers.

> And what is the difference between an Emacs that calls non-free code
> via a binary module, and an Emacs that accesses files via TRAMP and
> non-free SSH?

The ability of a binary module to disable `defun' and prevent all but
digitally signed code from being loaded.

> Should we remove process support from Emacs?

No.  My question to you: what can an intimately linked binary module
achieve that calling something as a separate process couldn't?  Linking
to external binaries has been in XEmacs for some while.  What have people
done with it?  Could they have done the same by calling an external
program via an OS call?

Up to now, you and Tom have been asserting that calling external binaries
is critically important and very useful.  I don't recall seeing much
justification.  If I've missed it, a pointer would be appreciated.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi,

Alan Mackenzie <acm@muc.de> writes:

>> And what is the difference between an Emacs that calls non-free code
>> via a binary module, and an Emacs that accesses files via TRAMP and
>> non-free SSH?
>
> The ability of a binary module to disable `defun' and prevent all but
> digitally signed code from being loaded.

How about fset'ing defun to something new?

You still have not answered to what I said yesterday: This
microsoft8.dll `functionality' does not in any way rely on the feature
proposed here.

And if you would want to do Bad Things, what prevents you from calling a
non-free binary with Emacs' process interface?

See, I really believe in your points that this feature has the potential
to be abused.  But to me it is not obvious how it would open a _extra_
possibilities besides doing it more technically advanced.

The libotr bindings I have in mind would also work with the process
model.  Just hack up an executable that can be controlled by
command-line arguments to wire up your elisp stuff with libotr.

But frankly, I only have seen such irksome solutions by people with low
motives and little technical interest.  Look at how bad programs like
matlab are distributed: they dump themselves into /opt including all the
shared libaries they need while totally ignoring the rest of the system,
not giving a damn about standards.

So if I had other motives than technical cleverness and elegance, it
seems I would already be able to interact really close with non-free
software (not the ssh case but with an executable abstraction of a
non-free library!).

But I have no way right now to implement pluggable bindings in a sane
way that I would consider better than an ugly hack.

	Hannes

Re: Release plans

[Alan Mackenzie]

Hi, Johannes!

On Tue, Aug 19, 2008 at 01:27:19AM +0200, Johannes Weiner wrote:
> Hi,

> Alan Mackenzie <acm@muc.de> writes:

> >> And what is the difference between an Emacs that calls non-free code
> >> via a binary module, and an Emacs that accesses files via TRAMP and
> >> non-free SSH?

> > The ability of a binary module to disable `defun' and prevent all but
> > digitally signed code from being loaded.

> How about fset'ing defun to something new?

> You still have not answered to what I said yesterday: This
> microsoft8.dll `functionality' does not in any way rely on the feature
> proposed here.

I suppose not, strictly speaking.  From a publicity point of view, using
a Lisp library to disable Lisp is much more blatantly wrong than using a
binary "to enhance the security of an otherwise complete working system".
It would be easier (technically, and probably legally, too) to remove the
nastiness from a .elc file than a .dll one, whilst still leaving positive
features working.

> And if you would want to do Bad Things, what prevents you from calling a
> non-free binary with Emacs' process interface?

You mean getting other people to call your non-free binary, I think.  The
fact that it's a process-level interface prevents the binary from doing
much damage to the guts of Emacs.  Doesn't it?

> See, I really believe in your points that this feature has the
> potential to be abused.  But to me it is not obvious how it would open
> a _extra_ possibilities besides doing it more technically advanced.

> The libotr bindings I have in mind would also work with the process
> model.  Just hack up an executable that can be controlled by
> command-line arguments to wire up your elisp stuff with libotr.

How much more does the libotr library need than writing to its stdin and
reading from its stdout?

[ .... ]

> But I have no way right now to implement pluggable bindings in a sane
> way that I would consider better than an ugly hack.

OK.

> 	Hannes

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi, Alan!

Alan Mackenzie <acm@muc.de> writes:

> Hi, Johannes!
>
> On Tue, Aug 19, 2008 at 01:27:19AM +0200, Johannes Weiner wrote:
>> Hi,
>
>> Alan Mackenzie <acm@muc.de> writes:
>
>> >> And what is the difference between an Emacs that calls non-free code
>> >> via a binary module, and an Emacs that accesses files via TRAMP and
>> >> non-free SSH?
>
>> > The ability of a binary module to disable `defun' and prevent all but
>> > digitally signed code from being loaded.
>
>> How about fset'ing defun to something new?
>
>> You still have not answered to what I said yesterday: This
>> microsoft8.dll `functionality' does not in any way rely on the feature
>> proposed here.
>
> I suppose not, strictly speaking.  From a publicity point of view, using
> a Lisp library to disable Lisp is much more blatantly wrong than using a
> binary "to enhance the security of an otherwise complete working system".
> It would be easier (technically, and probably legally, too) to remove the
> nastiness from a .elc file than a .dll one, whilst still leaving positive
> features working.

It is certainly easier to reverse-engineer, I guess.

>> And if you would want to do Bad Things, what prevents you from calling a
>> non-free binary with Emacs' process interface?
>
> You mean getting other people to call your non-free binary, I think.  The
> fact that it's a process-level interface prevents the binary from doing
> much damage to the guts of Emacs.  Doesn't it?

It still damages your freedom.

I thought twice about appending `*SCNR*' to the previous sentence as it
was first meant as a satirical response in the RMS style.  You write up
arguments and all you get back is a totally generic, ignoring everything
you said, `this is bad[tm] for freedom[tm]'.

But after thinking more about it, yes, this should really be _your_
argument, too.

I really don't think it makes more harm compared to a nasty .elc because
Emacs has so much of its core accessible through Lisp.

And then, practically, it does not matter which way you damage freedom,
right?

As a user, you won't even realize the difference:

  apt-get install some-nonfree-emacs-extension

Whether this is a shared library that loads into Emacs, a precompiled
.elc that loads into Emacs or an .el wrapper and a non-free executable.

And all the user sees is this, in either case:

  (require 'nonfree-extension)
  (non-free-extension-mode 1)

And what I also consider important: you can modify every variable or
function binding from the Lisp side.  That means that you don't need to
go to the C level to be really harmful.  You can also just rebind every
core symbol and already modify Emacs' behaviour quite severely.

Save the old binding, rebind it and you have total control over
everything the user does.  You can decide whether you want to allow
garbage collection at the moment by rebinding GARBAGE-COLLECT and decide
according to the phase of the moon whether you pass on to #<subr
garbage-collect> or ignore the request.  I really wonder what you could
NOT do.

Emacs is already so powerful that I don't understand all the fuzz about
the shared library loader.  It would be nothing more than convenience.
But don't see it introducing any extra danger at all.

I probably repeat myself, sorry.

>> The libotr bindings I have in mind would also work with the process
>> model.  Just hack up an executable that can be controlled by
>> command-line arguments to wire up your elisp stuff with libotr.
>
> How much more does the libotr library need than writing to its stdin and
> reading from its stdout?

That's probably it.

	Hannes

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Evening, Stephen!
 > 
 > On Tue, Aug 19, 2008 at 02:58:16AM +0900, Stephen J. Turnbull wrote:
 > 
 > > Faulty analogy, until you provide a neutrino's weight of evidence that
 > > any user's freedom to stop using the module is impaired.
 > 
 > I do not accept, as a criterion for freedom, that it is permissible to
 > consider a person's actions divorced from the effect on his neighbours.

That's a very strange philosophy of freedom.  Freedom *means* that you
may do something without concern for interference from your government
or your neighbors.  That doesn't mean it's ethically right to do, of
course.  But you have to argue from a different ethical principle than
freedom.

 > That's just my philosophy and my politics.  If you're going to
 > challenge my arguments, you're going to have to accept, even if
 > only for the sake of argument, these principles.

But Alan, I have accepted your principles, except the one that says
anything you can imagine is probable enough to worry about.

And unfortunately, I can't challenge your arguments because you
haven't posted one (except that fallacious argument from the authority
of Richard Stallman).  You have only posted assertions.  I grant the
conceptual possibility that you assert, but I deny its importance.  I
claim it is both extremely unlikely to come to pass, and that we can
deal with the process of it arising in other ways.  And I've supported
both claims with concrete technical details and policy proposals.

 > This is where we differ.  A plane crash hurts not just the people on
 > board, but the people the wreckage falls on.  Think of Lockerbie in 1988.

I guess I should deduce that you are in favor of closing airports so
that planes will stop falling out of the sky on innocent people?  The
analogy is quite exact, you see.

 > The fallout will hit you.  That proprietary module will gunge up
 > Emacs development, damage Emacs's reputation, cause sysadmins to
 > hate it (they must field the rage from hackers) just as that
 > aeroplane devastated a street in Lockerbie.

I really don't see it.  Emacs developers won't touch the module,
requests for support will be directed to the vendor, and surely
vandalism/netrage by hackers is not to be attributed to Emacs but
rather to the hackers themselves.

What damage to Emacs's reputation do you envision?

 > Again, I'm thinking about the Community's freedom, not just yours as an
 > isolated individual.

I object to your implication that I care only about myself.

 > I think I've made it clear that my "nightmares", as you call them, are
 > not positions I'm defending.  I put them forward only as a counter
 > (mainly) to Tom and to you, to show that bad things are possible, even if
 > not probable.

Bad things are possible.  Stipulated.  As with closing airports to
prevent mid-flight crashes, some policies to ameliorate the possible
bad things are stupid; there are better ways to deal with them.  I
think GNU's refusal to allow dynamic loading in Emacs is such a stupid
policy, because there are better ways to address potential problems.

 > The analysis from you and Tom falls short of mathematical perfection.
 > Unless I'm mistaken, it focusses purely on the effects it would have on
 > knowledgeable automous hackers.

I don't speak for Tom, but my analysis falls short of perfection.  As
I say, you should apply such standard to yourself, as well.

And you are mistaken.  My analysis focusses purely on the *lack* of
freedom-destroying effects for *anybody*.  Once we have some effects
to talk about, I'll worry about whose ox is getting gored.

 > I think we differ because our axioms differ.

I think we differ because I've gone beyond axioms to offer concrete
analysis, and you haven't.

 > You and T regard only the freedom of the informed automous hacker
 > as important.

I am very offended.  I could not have imagined that you would stoop so
low.

 > I (and possibly RMS) see freedom for the entire community as
 > important.  I think my hypothetical bad case ("microsoft8.dll")
 > from last night made that clear.  That such could be imposed on
 > others is a bad thing for me.

I claim it cannot be imposed.  Please rebut.

 > Should a non-free Emacs become widely installed ("established"), say GNU
 > Emacs hobbled by the "microsoft8.dll" I pictured last night, a newer
 > version of Emacs is unlikely to cause the number of installations of that
 > un-free version to fall rapidly to near zero (i.e., become
 > "disestablished").

Depends on what you mean by "rapidly".  Overnight?  No.  In two or
three years?  Yes, I think that can be done, and that's fast enough.

 > For the third time, our basic axioms seem to differ.

They do.  However, for the sake of this discussion, I've adopted
yours.  Except for the axiom that "dynamic loading leads to unfree
Emacs", which I consider a proposition to be proved or disproved.

 > I don't think you see the point I'm making, and your analysis is
 > oblivious to that point, so I disregard it.  Maybe.

No.  I understand your point.  "Introducing a module loader could
cause Emacs to become non-free."  That's scary.

In the light of day, though, I don't believe it's going to happen.
Just like I don't believe there's a mass murderer waiting in the rear
seat of my car.  Possible, yes, and people have been killed by such.
But very very rare, and much better dealt with by locking the car than
by selling it.

OTOH, I do know that benefits (so far of modest size) will certainly
happen.  For example, you're the same Alan Mackenzie who's been
annoyed by the Emacs build process recently, right?  Wouldn't it be
nice if you could just disable the broken feature you don't like, or
even just not build that module and use yesterday's build of the
module with today's core?  How about if you are developing new C code,
and can change and reinitialize it in your running Emacs with a
turnaround of about 5 seconds on a reasonable machine?

Of course those conveniences don't stand up against the nightmarish
scenario of microsoft.dll.  Except that they are *certain*, based on
my personal experience with the feature, whereas IMO the scenario of
microsoft.dll becoming popular has *vanishing* probability, and even
if it does occur, I believe that it is nearly certain that we can
disestablish microsoft.dll.

 > > You haven't even described what a "non-free Emacs" would look like.
 > 
 > That's unwarranted and manifestly false.

I'm sorry, but what is "warranted" for me to say is *my* call, and
"manifestly false" would imply that you provided a description that a
reasonably intelligent person would see as plausible and something
that can be responded to in a reasonable way.  You haven't provided
any such thing, yet.  I discuss below why "microsoft8.dll" is
technically implausible, and I've provided a number of reasons to
believe it's managerially implausible, too.

 > In my post last night, I drew a picture of Emacs running on a
 > future MS OS, where in order to get access to its file system, you
 > had to install the proprietary library "microsoft8.dll".  This
 > would have the side-effect, on the pretext of "security", of
 > disabling `defun'

I can't find anything about disabling `defun', and that's not
plausible anyway.  All defun really does is establish a value for the
function cell (the primitive is defalias), and add some properties
like the documentation string.  You'd have to also disable funcall,
apply, and eval.  Really you'd probably have to replace both the Lisp
interpreter and the byte-code engine, and since there is no documented
API and semantics for those, the FSF would have no problem getting a
subpoena for Microsoft's source code if it was at all compatible.

 > and only allowing signed (by MS) Lisp libraries to be loaded.

Again, the technical difficulties of accomplishing this in GNU Emacs
are enormous.  Remember, GNU Emacs's security features were designed
by the guy who posted his password for somebody else's system in a
public place.

And who do you think would use such a thing?  Word users are used to
such restriction, but they'd piss their pants at the threat of being
saddled with Emacs.  I'd bet a majority of Emacs users, including all
gurus would refuse to use it, so there goes internal suppport.  Making
such a thing popular would require enormous resources put into support.

How could that be imposed?

 > This scenario would be essentially impossible without Emacs linking
 > into external binaries.

False.  It would be possible, and possibly cheaper, simply to build
such an Emacs-alike from scratch, as Richard himself did. This would
have the benefit that *all* of such an Emacs could be proprietary, too.

 > Tom, in his reply, simply failed to address this central issue of
 > my post.  An apology, please.

I'm not in a position to apologize on behalf of Tom.  I offer you my
apology, but it's not clear to me for what. I still don't see a
description of a (feasible) non-free Emacs nor one that can't be
achieved without a dynamic loader.  All you have is your assertion
that this is a real danger, and all I've done is point out
(repeatedly) that you are simply making bare assertions.

 > > I mean for starters, the GPL guarantees that Emacs remains free.  So
 > > people can just say no and keep their personal freedom.
 > 
 > Oh, so GPL's "guarantees" mean that everything's fine, and so we don't
 > need to worry about anything.

What do you think "for starters" means?  It's not a complete argument,
but you really do have to answer it since you have claimed that Emacs
itself would become non-free.  In the case of microsoft8.dll, the user
still has the source, they still have the right to redistribute Emacs,
etc.  So how has Emacs become non-free?

Even if the DLL is loaded in site-start, you can disable that.  (Well,
I can, in XEmacs.)

 > For the fourth time, I reject your axiom that the measure of freedom is
 > solely that of individual informed autonomous hackers.

It's not my axiom.  Please provide a quote of me asserting that axiom.

 > > And what is the difference between an Emacs that calls non-free code
 > > via a binary module, and an Emacs that accesses files via TRAMP and
 > > non-free SSH?
 > 
 > The ability of a binary module to disable `defun'

No need for a binary module: (fmakunbound 'defun).

 > and prevent all but digitally signed code from being loaded.

I don't know how to do this without taking over eval and the bytecode
engine.  That's going to be very difficult, even without worrying
about the fact that the only documentation of the semantics at that
level is the source, and thus the author of microsoft8.dll is very
vulnerable to a copyright infringement suit.

 > > Should we remove process support from Emacs?
 > 
 > No.  My question to you: what can an intimately linked binary module
 > achieve that calling something as a separate process couldn't?

Reload a patched C object into a running Emacs.

Manipulate Emacs data structures, and provide new ones.

Very little that a separate process can't, but it can do everything a
lot faster.

 > Linking to external binaries has been in XEmacs for some while.
 > What have people done with it?  Could they have done the same by
 > calling an external program via an OS call?

Look in the modules directory of XEmacs.  In the case of the Canna
module, no such command exists, so you need to link to Canna.
Although there's also a network protocol so you could use just Lisp.

 > Up to now, you and Tom have been asserting that calling external binaries
 > is critically important and very useful.

No, I haven't.  I've simply said I don't see enough risk, even given
the nightmarish consequences you envision, to outweigh the benefits I
see.

Re: Release plans

[Robert J. Chassell]

     > I do not accept, as a criterion for freedom, that it is
     > permissible to consider a person's actions divorced from the
     > effect on his neighbours.

    That's a very strange philosophy of freedom.

No, it depends on your culture.  The US, Great Britain, and to a large
extent, western Europe, think that.  But others (in the early 1990s,
Japan and Singapore, according to Charles Hampden-Turner and Alfons
Trompenaars, "The Seven Cultures of Capitalism") are more communitarian.
(You need both.  For example, one person will invent and many people
will innovate.)

Weirdly enough, over the past century or so, most independence movements
have favored communitarian culture, possibly because you cannot have
warriors or soldiers without such a culture.

    Freedom *means* that you may do something without concern for
    interference from your government or your neighbors.

That is individualist freedom.  I think it is good, but then I am
American and don't trust my government or any authority that is not
harmonizing.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 >     Freedom *means* that you may do something without concern for
 >     interference from your government or your neighbors.
 > 
 > That is individualist freedom.

Sure, but communitarian freedom has typically been espoused by leaders
who create a personality cult around them and brook little actual
dissent, etc.  Software freedom is *not* about a personality that
overshadows the rest of the community, is it?  Rather, it is a very
individualist freedom.

Re: Release plans

[Robert J. Chassell]

    Robert J. Chassell writes:

     >     Freedom *means* that you may do something without concern for
     >     interference from your government or your neighbors.
     > 
     > That is individualist freedom.

    Sure, but communitarian freedom has typically been espoused by
    leaders
    who create a personality cult around them and brook little actual
    dissent, etc. 

That is often true.  Same in software.

    Software freedom is *not* about a personality that overshadows the
    rest of the community, is it?  Rather, it is a very individualist
    freedom.

Copyright law has to do with copying between people.  It is not very
individualist except that it is supposed somewhat to protect smaller
people and corporations who can afford lawyers from bigger people and
corporations who can also afford lawyers.  The current copyright law and
its implementation may not be the best mechanism for dealing with easily
transferred goods, like computer programs, but it is all we have for
dealing with those who might steal from us.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc
References: <E1KTqBj-0005Or-Mu@fencepost.gnu.org>
    <48A5BAD7.8030302@emf.net>
    <E1KUJCN-000309-FC@fencepost.gnu.org> <48A740CB.4050404@emf.net>
    <20080816213508.GA8530@muc.de>
    <87hc9ka8eg.fsf@uwakimon.sk.tsukuba.ac.jp>
    <20080817073124.GA1294@muc.de>
    <87ljyv5gy5.fsf@uwakimon.sk.tsukuba.ac.jp>
    <20080818101802.GA2615@muc.de>
    <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp>
    <20080818210927.GD2615@muc.de>
    <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp>
    <87ljytkwpk.fsf@rattlesnake.com>
    <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp>
In-reply-to: <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp>
    (stephen@xemacs.org)
To: emacs-devel@gnu.org
Subject: Re: Release plans
From: bob@rattlesnake.com (Robert J. Chassell)
--text follows this line--
    Robert J. Chassell writes:

     >     Freedom *means* that you may do something without concern for
     >     interference from your government or your neighbors.
     > 
     > That is individualist freedom.

    Sure, but communitarian freedom has typically been espoused by
    leaders who create a personality cult around them and brook little
    actual dissent, etc.

That is often true.  Same in software.

    Software freedom is *not* about a personality that overshadows the
    rest of the community, is it?  Rather, it is a very individualist
    freedom.

Copyright law has to do with copying between people.  It is not very
individualist except that it is supposed somewhat to protect smaller
people and corporations who can afford lawyers from bigger people and
corporations who can also afford lawyers.  The current copyright law and
its implementation may not be the best mechanism for dealing with easily
transferred goods, like computer programs, but it is all we have for
dealing with those who might steal from us.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

I wish you (and RMS) would get a real MUA.  VM is a good one for those
used to Rmail.  Fixing attributions:

I wrote:

 >     Sure, but communitarian freedom has typically been espoused by
 >     leaders who create a personality cult around them and brook
 >     little actual dissent, etc.

Robert J. Chassell writes:
 
 > That is often true.  Same in software.

You said it, not me.  Thank you.

 >     Software freedom is *not* about a personality that overshadows the
 >     rest of the community, is it?  Rather, it is a very individualist
 >     freedom.

 > Copyright law has to do with copying between people.

And software freedom is about removing hindrances to an individual's
copying, of which copyright and patent laws are (according to the free
software movement) the most important (ie, the ones we need to "do
something" about).

I don't understand what you're trying to say.  I don't mean to oppose
it, but rather indicate where I'm getting stuck.  Help?

Re: Release plans

[Robert J. Chassell]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

    > I wish you (and RMS) would get a real MUA. ... Fixing attributions
    > ...

According to my records, you wrote

    >  >     Sure, but communitarian freedom has typically been espoused
    >  >     by leaders who create a personality cult around them and
    >  >     brook little actual dissent, etc.

and I wrote

    > That is often true.  Same in software.

I know the latter is correct both in attribution and in content.  My
electronic mail says the former is correct, too.  The attributions look
correct both in my originals and in your copies as they were sent to me.
No need for a different mail user agent.

    >  >     Software freedom is *not* about a personality that
    >  >     overshadows the rest of the community, is it?  Rather, it
    >  >     is a very individualist freedom.

    > Copyright law has to do with copying between people.

I said the last about copyright law, too.  Again, its attribution looks
correct to me.

You wrote

    >     And software freedom is about removing hindrances to an
    >     individual's copying, ...

I agree.  Software copying is made possible in a free mannner by using
*current* laws, international treaties, and experience.

You also wrote

    >     I don't understand what you're trying to say. ...

I am saying that the current laws, international treaties, and
experience send us to the GNU Public License, version 3.  You may not
like the current laws and international treaties; I don't; technology
makes it easier to copy than before.  Unfortunately, the current laws
and international treaties exist and their backers are powerful.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 > I am saying that the current laws, international treaties, and
 > experience send us to the GNU Public License, version 3.  You may not
 > like the current laws and international treaties; I don't; technology
 > makes it easier to copy than before.  Unfortunately, the current laws
 > and international treaties exist and their backers are powerful.

And this is related to communitarian freedom ... how?

Re: Release plans

[Robert J. Chassell]

Robert J. Chassell writes:

     > I am saying that the current laws, international treaties, and
     > experience send us to the GNU Public License, version 3.  You may not
     > like the current laws and international treaties; I don't; technology
     > makes it easier to copy than before.  Unfortunately, the current laws
     > and international treaties exist and their backers are powerful.

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

    And this is related to communitarian freedom ... how?

Laws and international treaties have to do with other people.  They are
not individualistic in that sense.  When you make a decision involving
others, the consequences don't involve you alone.  A community has other
people in it.

You may prefer your community to be more individualistic -- I do with my
own -- but regardless, a community as other people in it.  It is a
matter of degree.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Thomas Lord]

It's kind of amazing to watch how the defense
of the dynamic loader ban has evolved.

First a philosophically dubious distinction between
individual and community freedom is posited.

Then that questionable distinction is projected onto
people's moral standing:  we are asked to believe that
there are those who care only about individual
freedom, not community, and asked to accept that
those people are just morally wrong.

Then members of the community at hand are
singled out and tarred and feathered as examples
of the miscreants who care not about community
freedom.   In particular, anyone who argues against
the FUD that leads to a dynamic loader ban is now
naive or bad or in some way or is otherwise morally
defective for failing to display proper concern for
"community freedom".

What Bob and others seem to have constructed
here is an argument for the dynamic loader ban
that can be summed up:

  Only bad people argue against the dynamic loader ban.
  Therefore, the ban is a good idea.

-t

Re: Release plans

[Stephen J. Turnbull]

Thomas Lord writes:

 > First a philosophically dubious distinction between
 > individual and community freedom is posited.

This was Bob Chassell.  That was *all* he really had to say.

 > Then that questionable distinction is projected onto
 > people's moral standing:  we are asked to believe that
 > there are those who care only about individual
 > freedom, not community, and asked to accept that
 > those people are just morally wrong.

This was Alan Mackenzie, but I don't think he would accept the idea of
community freedom as opposed to freedom for all members of the
community.

So not only have you changed the slant of their comments dramatically,
but you have also conflated two subthreads whose relation is not at
all clear, and which certainly do not stem from a coherent single
worldview, but rather accidentally juxtaposed opinions of different
individuals.

We (all) can and should do better than this.

 > What Bob and others seem to have constructed
 > here is an argument for the dynamic loader ban
 > that can be summed up:

[as an ad hominem attack.]  I don't see it, either.  I was certainly
offended by Alan's comments about ignoring the needs of some people in
the community, but I don't see it as a deliberate attack.

Re: Release plans

[Robert J. Chassell]

"Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
copyright law does not have to do with copying between people?

My part of this started after Johannes Weiner <hannes@saeurebad.de>
wrote

    > Whether one loads proprietary modules into the kernel is a
    > personal decision and I don't like deciding for other people.

and I wrote

    No; it is not a personal decision.  When you load proprietary
    modules, you are telling those who pay attention that you do not
    mind restricting yourself.

He did not understand what I meant, so I wrote

    You are not being personal when you make a decision involving others ...

"Stephen J. Turnbull" <stephen@xemacs.org> wrote, which I disagreed with 
with respect to the actual practice of law

     >     Freedom *means* that you may do something without concern for
     >     interference from your government or your neighbors. ...

The question is whether software copying studying, modifying, and
redistributing over the next generation will remain as legal or illegal
as it has in the past generation.  (Copyright law and treaties count in
lawful areas; I am presuming, perhaps erronously, that areas that ignore
that law when people are bribed millions of US dollars do not grow
much bigger in the next generation.  Generally speaking, free software
support companies lack the resources to bribe a huge amount.)

I agree it is important to emphasize the importance of software freedom,
to emphasize the costs, and to provide good software.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 > "Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
 > copyright law does not have to do with copying between people?

Since I have no clue what you might mean by "copying between people",
no, I'm not saying any such thing.

In the U.S., and I believe similarly for other jurisdictions,
copyright law regulates not only copying but distribution,
performance, and other such social activity.  Nevertheless, a specific
agent (the copyer or distributor) is identified as being restricted,
and IANAL but AFAIK receiving an illegal copy in good faith is not a
crime nor are you liable for civil damages (of course, you must give
up the copy on request of the rights holder).

 > "Stephen J. Turnbull" <stephen@xemacs.org> wrote, which I disagreed
 > with with respect to the actual practice of law

 >> Freedom *means* that you may do something without concern for
 >> interference from your government or your neighbors. ...

Er, when did you mention the "actual practice of law"?  I seem to have
missed it.

 > The question is whether software copying studying, modifying, and
 > redistributing over the next generation will remain as legal or illegal
 > as it has in the past generation.

Um, no, my question was "what does 'communitarian freedom' mean?" and
you still have made no visible attempt to answer it.

As for this new question you've introduced, none of those *acts* are
legal or illegal as such, so you seem a bit confused as to the actual
practice of law.  Rather, the right to perform those acts is reserved
to "owners", and they are by that token prohibited by law for others
until permission is granted.[1]

So what you are now asking is "will we expropriate existing exclusive
rights, and stop issuing them in the future", I guess?  I certainly
hope we don't expropriate them entirely, although I would like to see
the retroactive term extensions reversed as unconstitutional[2], and
future grants dramatically reduced or even eliminated.

By the way, although studying software is specified among the four
freedoms, it was never made illegal by copyright law, until the DMCA,
and there only a very restricted subset of software is illegal to
study.  It's just impossible to study it if you don't get a copy, and
acceptance of a EULA binding you not to study it is often a condition
required to acquire a copy.  But that is governed by contract law, not
copyright law.


Footnotes: 
[1]  However, for nearly all software applications I wish to use,
versions are available for which copying, modifying, and
redistributing are perpetually legal under copyright law because they
are covered by free software licenses.  My belief, and I suspect Tom's
is similar, is that the best way to extend that region of freedom is
to write more excellent software and distribute it under free
licenses.  Removing features from software is neither helpful to that
cause, nor is it likely to slow the growth of the non-free region.

[2]  My theory is that the Constitution explicitly says that these
franchises are intended "to encourage the useful arts", but any
putative encouragement must have happened before the original grant of
franchise---retroactive extensions are expropriating the public, pure
and simple, to no conceivable good (except the profit of owners).

Re: Release plans

[Robert J. Chassell]

    > Robert J. Chassell writes:
    >
    >  > "Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
    >  > copyright law does not have to do with copying between people?

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

    > Since I have no clue what you might mean by "copying between people",
    > no, I'm not saying any such thing.

Currently, law is made by humans.  In the future, it may be made by
artificial intelligences, extraterrestrials, or others, but currently,
it is made by people to handle some of their affairs both with each
other and with non-human nature.

    > In the U.S., and I believe similarly for other jurisdictions,
    > copyright law regulates not only copying but distribution,
    > performance, and other such social activity.

My question concerned copying.

    > Er, when did you mention the "actual practice of law"?  I seem to
    > have missed it.

I presumed we were talking about what might be copied and distributed.
That would be "actual practice".  Your question about 'communitarian
freedom' does not seem to have much to do with the "actual practice of
law" world wide.

    > As for this new question you've introduced, none of those *acts* are
    > legal or illegal as such, so you seem a bit confused as to the actual
    > practice of law.

As far as I know, in the United States and other countries that have
agreed to the modern replacements for the Berne Convention, every
expression is currently owned at origination by someone, an owner (in
other words, putting a copyright notice on the expression adds legal
power), and, except for good faith copying, you may not copy it without
permission.  The GNU General Public License takes this law and says that
the owner permits you to copy, study, modify, and distribute this code
in perpetuity.

    > By the way, although studying software is specified among the four
    > freedoms, it was never made illegal by copyright law, until the
    > DMCA, and there only a very restricted subset of software is
    > illegal to study.

People in general cannot readily study binary.  That is a practical
issue.

    > [2]  My theory is that the Constitution explicitly says that these
    > franchises are intended "to encourage the useful arts", ...

The Chinese constitution is not written in English; in any case,
copyright enforcement concerns both the treaties that the Chinese
government has signed and how much they are pushed.  Like the study of
binaries, this is a practical issue.

World wide, I think we should "encourage the useful arts".  I am
concerned about the degree to which and how to "encourage the useful
arts" currently.  Compliance is a practical matter.

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Stephen J. Turnbull]

Robert J. Chassell writes:

 >     > Robert J. Chassell writes:
 >     >
 >     >  > "Stephen J. Turnbull" <stephen@xemacs.org>, are you saying that
 >     >  > copyright law does not have to do with copying between people?
 > 
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 >     > Since I have no clue what you might mean by "copying between people",
 >     > no, I'm not saying any such thing.
 > 
 > Currently, law is made by humans.  In the future, it may be made by
 > artificial intelligences, extraterrestrials, or others, but currently,
 > it is made by people to handle some of their affairs both with each
 > other and with non-human nature.

I gather I've been trolled.  'bye!

Re: Release plans

[Robert J. Chassell]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
 
     > Since I have no clue what you might mean by "copying between people",
     > no, I'm not saying any such thing.
 
   > I gather I've been trolled.  'bye!

You should never write that you have no clue, unless, of course, you
really don't!

What about the practical issues, whether binary study is easy, and the
degree to which and how to gain compliance world wide for copyright law?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: Release plans

[Richard M. Stallman]

The decision on whether to include a dynamic linker in Emacs
does not directly affect users' freedom.  (It doesn't change the license.)
What is affects is which changes we facilitate and which changes we don't.

The case of XRefactory and its harmful effects on CEDET illustrate the
kind of harm I'm trying to avoid.  It also shows that we cannot
totally avoid such problems.  But opening a convenient door for making
them is likely to mean more of them.  I want to have less of them.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
> The decision on whether to include a dynamic linker in Emacs
> does not directly affect users' freedom.  (It doesn't change the license.)
> What is affects is which changes we facilitate and which changes we don't.
>
> The case of XRefactory and its harmful effects on CEDET illustrate the
> kind of harm I'm trying to avoid.  It also shows that we cannot
> totally avoid such problems.  But opening a convenient door for making
> them is likely to mean more of them.  I want to have less of them.
>   


You picked a great example.

The absence of a dynamic loader makes it harder
to implement the more performance-intensive
parts of a modern IDE.

Therefore, the dynamic loader ban makes a free
software project like CEDET harder than it
needs to be.

That a modern IDE project for Emacs is so hard makes
the problem an attractive target for a proprietary software
company.   To the proprietary vendor, the difficulty of
writing the program in the first place is a barrier to entry
and will help protect future profits

In other words: the incentive to create the non-free
XRefractory comes, in part, from the ban on a dynamic
loader.

The ban has the exact opposite of the intended effect.

-t




>
>
>
>
>   

Re: Release plans

[Richard M. Stallman]

    In other words: the incentive to create the non-free
    XRefractory comes, in part, from the ban on a dynamic
    loader.

Your reasoning is confused, and the conclusion makes no sense.
My decision remains unchanged.

Re: Release plans

[Paul R]

On Wed, 27 Aug 2008 14:54:18 -0400, "Richard M. Stallman" <rms@gnu.org> said:

Thomas> In other words: the incentive to create the non-free
Thomas> XRefractory comes, in part, from the ban on a dynamic loader.

RMS> Your reasoning is confused, and the conclusion makes no sense. My
RMS> decision remains unchanged.

Thomas reasoning is :

1- There is NO ROOM for proprietary software when free software exists
   and meet all the users technical requirements. IOW, nowaday
   proprietary software only survives when it proves clear technical
   superiority over free software (or when it locks users with file
   formats, but that's not the point here)

2- Banning technical facilities like DLL from free software is likely
   to leave a clear advantage to proprietary software that use those
   facilities to provide the best technical solution.

Conclusion : banning DLL from emacs is likely to make it technicaly
inferior than alternatives, thus preventing users from using it, thus
reducing the global freedom of the community.

-- 
  Paul

Re: Release plans

[Richard M. Stallman]

    2- Banning technical facilities like DLL from free software is likely
       to leave a clear advantage to proprietary software that use those
       facilities to provide the best technical solution.

Refusing to support DLL does not give an advantage to non-free
software.  In particular, it does not give XRefractory an advantage
over CEDET.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     2- Banning technical facilities like DLL from free software is likely
>        to leave a clear advantage to proprietary software that use those
>        facilities to provide the best technical solution.
>
> Refusing to support DLL does not give an advantage to non-free
> software.  In particular, it does not give XRefractory an advantage
> over CEDET.
>   


It gives an equal technical disadvantage to both but an
economic favor to XRefractory.   That economic favor to
XRefractory is an example of why people invest in proprietary
software entrepreneurship.

The declaration of intent to refuse (aka "ban") helps give
XRefractory a business plan (because the same ban makes life harder
for less speculatively funded competitors like CEDET).

-t

Re: Release plans

[Bruce Stephens]

Thomas Lord <lord@emf.net> writes:

> Richard M. Stallman wrote:
>>     2- Banning technical facilities like DLL from free software is likely
>>        to leave a clear advantage to proprietary software that use those
>>        facilities to provide the best technical solution.
>>
>> Refusing to support DLL does not give an advantage to non-free
>> software.  In particular, it does not give XRefractory an advantage
>> over CEDET.
>
> It gives an equal technical disadvantage to both but an
> economic favor to XRefractory.   That economic favor to
> XRefractory is an example of why people invest in proprietary
> software entrepreneurship.
>
> The declaration of intent to refuse (aka "ban") helps give
> XRefractory a business plan (because the same ban makes life harder
> for less speculatively funded competitors like CEDET).

Is this an abstract discussion or is it concretely about Emacs and
CEDET?  (I'm struggling to imagine what realistic benefit CEDET might
get from a dynamic extension to Emacs.  Maybe linking with SQLite?)

Surely XRefactory's big advantage over CEDET is use of an EDG-based
parser (which costs money)?  So in that sense the restrictions on how
the core gcc project develops (whether it can provide suitable dumps
of parse trees and the like) are more significant than restrictions on
Emacs?

Re: Release plans

[Lennart Borgman (gmail)]

Bruce Stephens wrote:
> Is this an abstract discussion or is it concretely about Emacs and
> CEDET?  (I'm struggling to imagine what realistic benefit CEDET might
> get from a dynamic extension to Emacs.  Maybe linking with SQLite?)

Linking to parsing libraries (but I am not sure which one there are).
That way greater control could be get, parsing could be stopped and
restarted with very little cost. It could be easier to save the data and
go deeper into the parsing (but that is just a guess).

I believe that for web development there often are free or at least
freely available for parsing.

Re: Release plans

[Thomas Lord]

Lennart Borgman (gmail) wrote:
> I believe that for web development there often are free or at least
> freely available for parsing.
>   

Speaking of parsing, that doesn't, quite, but what you
meant either "is" or "immediately suggests" a good idea:
an Emacs-based, schema-aware, validating XML
parser and XML database browser.   Very much like
an IDE with built-in parser, such tools want built-in
XML parsers (and validators) and it would be very
nice, performance-wise and semantics-wise, to be
able to address the database from lisp directly rather
than going through the serialization bottleneck to a
sub-process.

-t





>
>
>   

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Fri, 29 Aug 2008 12:23:20 -0700

   it would be very nice, performance-wise and semantics-wise, to
   be able to address the database from lisp directly rather than
   going through the serialization bottleneck to a sub-process.

I think you've got it backwards; in any system involving Emacs (of
the current design), the serialization bottleneck is Emacs `eval'.
In this light, a subprocess is actually the most clean and (more
importantly) upwardly compatible way to scale performance.

If we wish to augment this extremely clean model:

  (1a) emacs
  (1b) emacs------------emacs           ; fork
  (1c) emacs--[serial]--subproc         ; exec

for performance purposes, then i suggest we concentrate on the
data structure for sharing info between emacs and the subproc,
rather than the control structure (i.e., dynamic loader).  More
precisely, i would like to see something like:

  (2a) emacs
  (2b) emacs--[sharable-buffer]         ; "sweep-porch"
  (2c) emacs---[shared-buffer]---emacs  ; "invite-kibitz" :-D

The second emacs (from 2c) can mux traditional children (1b, 1c)
as it sees fit, of course.

In Unix, the data structure for sharing info is a shared buffer,
but the protocol for manipulating that buffer is very limited.
Lots of fun ensued, anyway.  Emacs deserves no less.

thi

Re: Release plans

[Stefan Monnier]

>    it would be very nice, performance-wise and semantics-wise, to
>    be able to address the database from lisp directly rather than
>    going through the serialization bottleneck to a sub-process.

> I think you've got it backwards; in any system involving Emacs (of
> the current design), the serialization bottleneck is Emacs `eval'.

I'm not sure I understand what you mean.  In the case of something like
Semantic, if parsing in Elisp is too expensive or if you want to use
some existing C code to do the parsing, the bottleneck you'll have to
handle is that the external process can't directly access the buffer's
text, and it can be very costly to pass that text to the subprocess and
then process the returned value (which may look like a list of text
properties to add to various parts of the text).

A DLL could be significantly more efficient.  The difference can be as
large as "on-the-fly" vs "batch".


        Stefan

Re: Release plans

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>    it would be very nice, performance-wise and semantics-wise, to
>>    be able to address the database from lisp directly rather than
>>    going through the serialization bottleneck to a sub-process.
> 
>> I think you've got it backwards; in any system involving Emacs (of
>> the current design), the serialization bottleneck is Emacs `eval'.
> 
> I'm not sure I understand what you mean.  In the case of something like
> Semantic, if parsing in Elisp is too expensive or if you want to use
> some existing C code to do the parsing, the bottleneck you'll have to
> handle is that the external process can't directly access the buffer's
> text, and it can be very costly to pass that text to the subprocess and
> then process the returned value (which may look like a list of text
> properties to add to various parts of the text).
> 
> A DLL could be significantly more efficient.  The difference can be as
> large as "on-the-fly" vs "batch".


It looks to me like the buffer string routines Thomas is working on
could perhaps make that easier to implement (in the DLL case of course).
But I guess you have thought much more about that, Thomas?

Re: Release plans

[Thomas Lord]

Lennart Borgman (gmail) wrote:
>
> It looks to me like the buffer string routines Thomas is working on
> could perhaps make that easier to implement (in the DLL case of course).
> But I guess you have thought much more about that, Thomas?
>   


Not deeply (because I'm confident on general principles).

Using functional strings that, behind the scenes, share state
and use mutation rather than copy/alter when they can -- that
pattern -- generally simplifies higher-level coroutine coding.
Beyond that I haven't worried about it and am instead fretting
over getting just the basics working, first.

A fun problem that I found a solution for and am currently
coding is the fragmentation problem.   The splay-tree-of-gap-buffers
allows strings to be arbitrarily fragmented.    However, low-level
I/O systems (e.g., DMA, L2 and L1 caches) like the fragments
to be various minimum sizes (cache lines, pages, etc.).   A fun
set of tricks to think about is how to manage the splay-tree-of-gap-buffers
such that the majority of string/buffer data winds up being in
roughly page-sized chunks, to minimize the amount of data-copying
needed and to maximize the effectiveness of caches.

It's a fun puzzle.

-t

Re: Release plans

[Thomas Lord]

Stefan Monnier wrote:
> A DLL could be significantly more efficient.  The difference can be as
> large as "on-the-fly" vs "batch".
>   

Exactly.  That's the gambit.

Thien-thi Nguyen's suggestion of shared buffers is a very
plausible dynamic loading API for such aims, if you ask me.
So you're both right (if you ask me).

-t




>
>         Stefan
>
>   

Re: Release plans

[Thien-Thi Nguyen]

() Stefan Monnier <monnier@IRO.UMontreal.CA>
() Fri, 29 Aug 2008 16:20:09 -0400

   I'm not sure I understand what you mean.  In the case of something like
   Semantic, if parsing in Elisp is too expensive or if you want to use
   some existing C code to do the parsing, the bottleneck you'll have to
   handle is that the external process can't directly access the buffer's
   text,

In the common case, that text is a file on the filesystem (which the
subprocess can access independently).  I would design things so that the
subprocess persists for the Emacs session and maintains its own state,
such as various project-specific symbol tables and a copy of the buffer.
Commands from Emacs would be along the lines of "sync-with-file",
"query-symbol", "query-parse-state", and so forth.  Results from the
query-FOO commands should typically be very low bandwidth.

So no, i don't think the bottleneck would be the buffer access (for this
design), because the subprocess does not really need to access the buffer.
Changes to the buffer that have not yet hit the filesystem can be
communicated by publishing some portion of `buffer-undo-list' (which is
also relatively lightweight).

   and it can be very costly to pass that text to the subprocess and
   then process the returned value (which may look like a list of text
   properties to add to various parts of the text).

Well...

   A DLL could be significantly more efficient.  The difference can be as
   large as "on-the-fly" vs "batch".

...i suppose i'll have to agree that all these "could be" scenarios are
possible.  My view is that given the requirement of external symbol tables
(and other state), the biggest win for both performance and maintainability
is to go asynchronous.  If you want async from a subprocess, no worries,
but if you want async in-process, you need to either design (and debug and
maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads
or phase-of-the-moon-threads or whathaveyou.  Then, you need to make sure
every visitor treats your program counter w/ the respect it deserves.
That's a lot of thankless and brutish police work.

thi

Re: Release plans

[Thomas Lord]

Thien-Thi Nguyen wrote:
> So no, i don't think the bottleneck would be the buffer access (for this
> design), because the subprocess does not really need to access the buffer.
> Changes to the buffer that have not yet hit the filesystem can be
> communicated by publishing some portion of `buffer-undo-list' (which is
> also relatively lightweight).
>   

So, the sub-process basically contains a text editor
in this design, albeit one without redisplay code and
with an unusual, limited command set.   That need for
redundant code to make this thing work helps to prove
that, indeed, the absence of dynamic loading (including
just shared memory regions for buffers) creates make-work
to work around it.

I'm also skeptical about the performance claims here.
A full update involves changing the buffer, print + system
calls to inform the sub-process, system calls + read to
get back the results of the parse updates, and then the
actual text property updates.     For interactive typing
that can probably keep up on a modern machine but
for other stuff it can easily be a performance bottleneck.
(Still, even if it is not, it's doing it "the hard way".)


>    and it can be very costly to pass that text to the subprocess and
>    then process the returned value (which may look like a list of text
>    properties to add to various parts of the text).
>
> Well...
>
>    A DLL could be significantly more efficient.  The difference can be as
>    large as "on-the-fly" vs "batch".
>
> ...i suppose i'll have to agree that all these "could be" scenarios are
> possible.  My view is that given the requirement of external symbol tables
> (and other state), the biggest win for both performance and maintainability
> is to go asynchronous.  If you want async from a subprocess, no worries,
> but if you want async in-process, you need to either design (and debug and
> maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads
> or phase-of-the-moon-threads or whathaveyou.  Then, you need to make sure
> every visitor treats your program counter w/ the respect it deserves.
> That's a lot of thankless and brutish police work.
>   

That seems exaggerated.   A hook in the interact loop that locked
a shared mem buffer briefly while asking for updates from an
incremental parser / ide-helper doesn't seem like it would be all that
hard to get right.

-t

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Sat, 30 Aug 2008 16:07:51 -0700

   So, the sub-process basically contains a text editor
   in this design, albeit one without redisplay code and
   with an unusual, limited command set.

I suppose that's a fitting description.

   That need for redundant code to make this thing work helps to
   prove that, indeed, the absence of dynamic loading (including
   just shared memory regions for buffers) creates make-work to
   work around it.

I don't follow your logic, perhaps because you include
shared-memory buffers in dynamic loading (which is not what i
described), to make your point.  But that's ok; maybe we are
talking about different designs.

   For interactive typing
   that can probably keep up on a modern machine but
   for other stuff it can easily be a performance bottleneck.
   (Still, even if it is not, it's doing it "the hard way".)

Perhaps difficulty lies also in the eye of the beholder.

   That seems exaggerated.  A hook in the interact loop that
   locked a shared mem buffer briefly while asking for updates
   from an incremental parser / ide-helper doesn't seem like it
   would be all that hard to get right.

OK.

thi

Re: Release plans

[Thomas Lord]

Thien-Thi Nguyen wrote:
> () Thomas Lord <lord@emf.net>
> () Fri, 29 Aug 2008 12:23:20 -0700
>
>    it would be very nice, performance-wise and semantics-wise, to
>    be able to address the database from lisp directly rather than
>    going through the serialization bottleneck to a sub-process.
>
> I think you've got it backwards; 

Actually I don't but there is a linguistic problem between
you and I (a minor one).

You contrast my advocacy for a dynamic loader with what
you propose as an alternative.   I'll just quote in full here since
it's short:

> in any system involving Emacs (of
> the current design), the serialization bottleneck is Emacs `eval'.
> In this light, a subprocess is actually the most clean and (more
> importantly) upwardly compatible way to scale performance.
>
> If we wish to augment this extremely clean model:
>
>   (1a) emacs
>   (1b) emacs------------emacs           ; fork
>   (1c) emacs--[serial]--subproc         ; exec
>
> for performance purposes, then i suggest we concentrate on the
> data structure for sharing info between emacs and the subproc,
> rather than the control structure (i.e., dynamic loader).  More
> precisely, i would like to see something like:
>
>   (2a) emacs
>   (2b) emacs--[sharable-buffer]         ; "sweep-porch"
>   (2c) emacs---[shared-buffer]---emacs  ; "invite-kibitz" :-D
>
> The second emacs (from 2c) can mux traditional children (1b, 1c)
> as it sees fit, of course.
>   

One little catch, please.   If you are going to have (2c) then
you also implicitly have:

      (2c') emacs -- [shared buffer] -- any[*]

      [*] any program that knows the buffer data structure
      and sharing protocol

In other words, (2c) is one possible API for a dynamic loader in
Emacs.

I think a dynamic loading API based on shared buffers is a very
good idea, by the way.   That is probably a better way to do it than
just a cut-and-paste dlopen job from some other app.  A shared buffer
API is just as much an invitation to non-free add-ons as a dlopen
API, but the shared buffer API is probably (I'd agree with you, if
we're just kibbitzing) better for free software developers, better for
Emacs maintainers, etc.




> In Unix, the data structure for sharing info is a shared buffer,
> but the protocol for manipulating that buffer is very limited.
> Lots of fun ensued, anyway.  Emacs deserves no less.
>
>   

I think that there are leaks in that abstraction -- it's not quite as
minimal and contained as I think you suggest.

For example, buffer have buffer local variables and have lexical
environments that include global scope so, ideally, the entire Emacs
lisp address space is accessible from a shared buffer.   The actual
API has to achieve that API or compromise with some simplifications.
I would expect a compromise, for practical reasons.   It is an
interesting medium-sized research project to search for a sweet-spot
API for shared buffers.  By what metric should we be invited to measure
the compromise?  and then how is the compromise implemented?  and
how does it perform? and what is it good for?

-t





> thi
>
>
>
>   

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Fri, 29 Aug 2008 15:53:50 -0700

   You contrast [...]
   If you are going to have (2c) then
   you also implicitly have:

        (2c') emacs -- [shared buffer] -- any[*]

        [*] any program that knows the buffer data structure
        and sharing protocol

   In other words, (2c) is one possible API for a dynamic loader in
   Emacs.

Instead of "contrast", you can look at shared buffers as the
strength- (and thus complexity- and maintenance-burden-)reduced
well-behaved little brother to the dynamic loader.  This is
because the focus is on sharing data, not the program counter.

   A shared buffer API is just as much an invitation to non-free
   add-ons as a dlopen API, but the shared buffer API is probably
   (I'd agree with you, if we're just kibbitzing) better for free
   software developers, better for Emacs maintainers, etc.

If you keep the protocol focused on data, then you stay out of the
scope of free software (modulo what GPLv3 brings to bear wrt
patents).  This is the primary {at,de}traction of this (and any
network-protocol-based) approach.

   I think that there are leaks in that abstraction -- it's not
   quite as minimal and contained as I think you suggest.
   [design issues]

OK.

   By what metric should we be invited to measure the compromise?
   and then how is the compromise implemented?  and how does it
   perform? and what is it good for?

These are good questions.  I don't know their answers.

thi

Re: Release plans

[Thomas Lord]

Bruce Stephens wrote:
> Is this an abstract discussion or is it concretely about Emacs and
> CEDET?  (I'm struggling to imagine what realistic benefit CEDET might
> get from a dynamic extension to Emacs.  Maybe linking with SQLite?)
>   

That's an interesting idea.   I was thinking about tools for incremental
parsing as an example.   Fast and good support for small databases
makes sense, too.

Other people mentioned other applications of a dynamic loader,
too, not necessarily IDE related (e.g., image manipulation, network
protocols, etc.)

In general, anytime you want the coroutine to use a lot of data
that normally sits in Emacs memory (e.g., buffer contents) -- and
you want that coroutine to randomly access that data or in other
ways have fast access to it -- a dynamic loader would be handy.

I don't claim, by the way, that a dynamic loader makes perfect
technical sense for GNU Emacs as it stands today.   It *might*
and it *might not*.  I do claim that that fears of non-free add-ons
aren't argument enough against a dynamic loader.  So, the discussion
is abstract in that sense, I guess.


> Surely XRefactory's big advantage over CEDET is use of an EDG-based
> parser (which costs money)?  So in that sense the restrictions on how
> the core gcc project develops (whether it can provide suitable dumps
> of parse trees and the like) are more significant than restrictions on
> Emacs?
>   

It could be.


Hmm.  There is an architecture to consider:  Imagine dynamically
loadable parsers for your favorite languages.   Might there be a
reasonable API design such that a single parsing tool can do both
incremental parsing / re-parsing and efficient straight-through parsing,
producing output (in the form of API calls or return values) suitable
for both building GCC trees and updating text properties and database
values in an IDE?

If so, can tools such as Bison be extended to support generation
of the incremental (re-) parsing parts (e.g., with suitable ways of
handling parse errors and recovery in an incremental context)?

The resulting "kit" of Emacs w/DL + GCC w/DL +  extended Bison
could be very fun to play with.

-t

Re: Release plans

[Richard M. Stallman]

    Surely XRefactory's big advantage over CEDET is use of an EDG-based
    parser (which costs money)?  So in that sense the restrictions on how
    the core gcc project develops (whether it can provide suitable dumps
    of parse trees and the like) are more significant than restrictions on

The FSF would be glad to have features in GCC for outputting
cross-reference information, if that is the best way to do this job.

One drawback of that approach for cross-references is that it tends
to fail to show that this code uses both foo and bar:

#ifdef HAVE_XYZ
  foo ();
#else /* not HAVE_XYZ */
  bar ();
#endif /* not HAVE_XYZ */

Re: Release plans

[Richard M. Stallman]

    The declaration of intent to refuse (aka "ban") helps give
    XRefractory a business plan (because the same ban makes life harder
    for less speculatively funded competitors like CEDET).

That's just speculation, and I don't find it convincing.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     The declaration of intent to refuse (aka "ban") helps give
>     XRefractory a business plan (because the same ban makes life harder
>     for less speculatively funded competitors like CEDET).
>
> That's just speculation, and I don't find it convincing.
>   

Is that a pun?   I mean, if my comments are speculation
they are speculation about how people speculate...

The general principle I've expressed rests on pretty
uncontroversial assumptions:   feature bans help
protect a barrier to entry for anyone who manages to
work around them;  barriers to entry are one of the
key things that venture funders and similar investors
look for in software firms.  


-t





>
>
>   

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     In other words: the incentive to create the non-free
>     XRefractory comes, in part, from the ban on a dynamic
>     loader.
>
> Your reasoning is confused, and the conclusion makes no sense.
> My decision remains unchanged.
>   


My reasoning is not confused.  I'll restate it more plainly:

Consider a feature, X, which is desirable for practical purposes.

Consider a feature, Y, which is banned.

If the ban on Y makes X harder to implement, in the sense
of costing more in labor or money, then the economic incentive
to go into business selling a non-free implementation of X goes
up.

The reason that incentive goes up is because the cost of
going into business selling a non-free X goes up while the
demand for the practically useful X remains steady.

Now, someone with some money that they want to spend
writing new, non-free software looks at that and says
"I think I can do X, in spite of the ban on Y.  In fact,
given the work I did on my masters thesis, I think I can do
X cheaper than most people.   If I start selling a non-free X,
it will be a long time before some competitor comes along
either selling a non-free competitor to X or sharing a free
version of X.  It will be a long time because I'm almost the only one
with an effective idea of how to get around the ban on Y.
Therefore, I'll go into business selling proprietary X and count
my blessings for the banning of Y."

There are (and have long been) available to the GNU project
a kind of dichotomy of positive and negative strategies for
designing and implementing software.   On the positive side:
writing code that directly helps users' and developers' of
free software.  On the negative side, writing code or refusing
to write code -- either way -- so as to push back the goals of
non-free software developers.

Obviously the happiest cases are when the strategy can
use both simultaneously:  with one line of code written or
not written both help users and developers on the free side
and directly impede developers on the non-free side. 

The hard cases (apparently) are when the only choices
apparent are either only positive or only negative:  only
help free software users and developers directly, or
only directly interfere with non-free developer ambitions --
but not both.   The dynamic loader and GCC tree print/read
problems are in this category of "either but not both".

What I am pointing out to you is that those "either but not
both" cases are not very clear cut -- you don't actually have the
choice you think you have.   You *think* that the dynamic loader
ban impedes non-free Emacs add-ons but the abstract argument
above about X and Y and the specific real-world example of
XRefractory illustrate that, well, the dynamic loader ban may actually
make especially problematic non-free add-ons *more* likely.

So, what "strategy do you use for picking a strategy" when cases
like that arise -- cases of partial knowledge and easy mistakes like
that?

I say: stay positive and stick to what you know about making life
easier for free software users and developers and ignore any
(probably mistaken) hypotheticals about what non-free developers
might do.   The more capable free software users and developers
become, the faster the free software movement will snowball and
win -- at least that is the view that comes from confidence.

Remember that 30 years ago you were a hacker just out to
"improve the system" and any artificial legal hoo-haw that
got in the way just seemed stupid (at first) and then sinister
(leading to the movement).

Ok, so... don't go from that good position, way back then,
to a modern one where for some twisted reason you conclude
that you should decline to "improve the system" when you have
every right to.   Feature bans are antithetical to the hacker spirit that
gave rise to the free software movement.



-t


>
>
>   

Re: Release plans

[Alfred M. Szmidt]

   Remember that 30 years ago you were a hacker just out to "improve
   the system" and any artificial legal hoo-haw that got in the way
   just seemed stupid (at first) and then sinister (leading to the
   movement).

   Ok, so... don't go from that good position, way back then, to a
   modern one where for some twisted reason you conclude that you
   should decline to "improve the system" when you have every right
   to.  Feature bans are antithetical to the hacker spirit that gave
   rise to the free software movement.

Nobody has banned any feature.  The maintainers are simply stating
that such a patch would be rejected and why; just like they would
reject a patch that does not follow coding standards or introduces a
bug.

It would have been no different than rejecting a patch that would add
a login with passwords on ITS or file permissions...  People hacking
the system would have felt that it would not improve the system, as is
the case here.

Re: Release plans

[Thomas Lord]

Alfred M. Szmidt wrote:
>
> Nobody has banned any feature.  The maintainers are simply stating
> that such a patch would be rejected 


That is what I mean by "ban": a feature not permitted,
by the maintainers, to appear in a release of GNU Emacs.


> It would have been no different than rejecting a patch that would add
> a login with passwords on ITS or file permissions...  People hacking
> the system would have felt that it would not improve the system, as is
> the case here.
>   


That is a poor analogy on many levels.  Do you really wish
to defend it?

-t

Re: Release plans

[Richard M. Stallman]

    That is what I mean by "ban": a feature not permitted,
    by the maintainers, to appear in a release of GNU Emacs.

That word is misleading and hostile.  In effect, you are trying
to change my mind by insulting me.
you don't like.

My natural tendency is to dig in my heels.  However, I will try to
resist that and continue judging the issue as if you were not here.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     That is what I mean by "ban": a feature not permitted,
>     by the maintainers, to appear in a release of GNU Emacs.
>
> That word is misleading and hostile. 

I doubt that -- I think it more likely that you have just attacked
me with defamation and answered my arguments with ad hominem --
but I do wonder which word you mean, how it is supposedly
misleading and hostile, and what a better word would be.


-t

Re: Release plans

[Alan Mackenzie]

On Wed, Aug 27, 2008 at 03:32:15PM -0700, Thomas Lord wrote:
> Richard M. Stallman wrote:

> >Your reasoning is confused, and the conclusion makes no sense.
> >My decision remains unchanged.

> My reasoning is not confused.  I'll restate it more plainly:

[ Snip 70 lines of the usual. ]

> Ok, so... don't go from that good position, way back then, to a modern
> one where for some twisted reason you conclude that you should decline
> to "improve the system" when you have every right to.   Feature bans
> are antithetical to the hacker spirit that gave rise to the free
> software movement.

Thomas, this is the Emacs developers' mailing list.  Basic courtesy is
the expected norm here, even when disagreeing strongly with somebody.

If you were to fix a bug, or start implementing a cool new feature - you
know, make some sort of contribution, no matter how small - it would be
really appreciated.

We don't need a Director of Marketing here.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Thomas Lord]

Alan Mackenzie wrote:
> If you were to fix a bug, or start implementing a cool new feature - you
> know, make some sort of contribution, no matter how small - it would be
> really appreciated.
>   


I'm working on a new implementation of strings and buffers,
including support for undo, markers, properties, and overlays.
That's going well.

If it finishes well, then I might make a new implementation of
interact loops and redisplay primitives, add a dynamic loader,
and call it a day.   (After which I might work on a dynamically
loadable extension language interpreter.)

There is a fork in the road coming up, though.  I started on the
strings and buffers project for a different purpose, originally:  I
want them for an extended XML parser with SAX and DOM
models.   After I get strings and buffers working I'll have to consider
what to work on next out of the set: XML foo, Emacs interact loop,
or Emacs-style redisplay.   I'm not sure which I'll pick.

The new strings and buffers implementation is inspired by
several needs including but not limited to:

1) to have such as a stand-alone C library
2) to be useful for a lisp implementation without requiring all
    the baggage of a lisp implementation
3) to fix some performance problems that gap buffers have
4) to handle unicode very cleanly
5) to make string-handling C code easier to get right

The string representation is based on splay trees: a string
is a splay tree of gap buffers.   There are various invariants
(that I won't get into here) that make these trees more than
ordinary splay trees -- they are a new data structure (afaict).

The string representation is (semantically) functional: strings
are never modified.     Instead, strings share state (i.e., share
sub-trees) and linear styles of programming are rewarded (e.g.,
sometimes new strings are constructed by cheaply modifying
existing strings *if* there are no other references left to the unmodified
string).

Because strings are functional and share state, "undo" is pretty
trivial.   To snapshot the state of a buffer at some instant,
just make a copy of the string it contains.   That copy
will share state (so it is space efficient and cheap to create). 
That copy won't change (since the string representation is
functional).

The splay tree of gap buffers representation means that the
amortized cost of shifting characters from one side of the
conceptual gap to another (moving the point) is O(log n) (compared
to gap buffers which are O(n)).  At the
same time, the space inefficiency of the tree and time inefficiency
of scanning it are no worse than O(n) (in the length of the string) --
the same as gap buffers.   So the new data structure is at least
asymptotically faster.

Another interesting advantage of this string/buffer representation
is that it is very good at representing *sparse* buffers -- buffers that
are mostly just a string of a single character repeated, only in a few
places interrupted with others.    As a consequence, these new 
strings/buffers
can be used for non-traditional purposes, such as huge sparse bitsets, or
large hash tables.   (A buffer as a hash table?    Roughly speaking: compute
an N-bit hash value, then go to that line of the buffer -- that line of 
the buffer
contains the corresponding (possibly empty) hash bucket.   This 
splay-of-gap-buffers
thing can handle that quite efficiently -- O (log N) for the "goto step" 
with amortized
cost much lower if access patterns display locality.  It's not really 
*quite* that
simple for a fast hash table but it's close.)


This kind of project is very much Emacs related and, also, is slower
than just looking up a minor bug with a quick fix.  I like to get some 
orientation
to the terrain along the way, hence the bursts of verbosity (which, really,
aren't *that* much in the overall ebb and flow).

Oh, the meat of the new string data structure looks like it will weigh in
far under 5K lines of code -- the whole buffer support perhaps doubling it.
It's shaping up as pretty tight code that is pretty and simple to follow 
(another
of the goals).   The main logic for editing primitives and splaying look to
come in under 1K lines of code -- maybe 2K.

Thinking of the possible follow-on projects of interact loop, redisplay, and
dynamic loader:

Interact loops are easy enough and I can certainly make a "stackless"
version (so, no more "recursive minibuffers" hair).

Redisplay is the intimidating one, still, because it just looks hopelessly
tedious.   Conceptually easy, sure, but tedious and requiring too much code.
I'm still thinking about that part.

The combination of the buffers, interact loop, redisplay and loader would
be "an Emacs", stripped of lisp, but ready to dynamically load a lisp
(or any other language) interpreter.

Since you asked so nicely,
-t

Re: Release plans

[Richard M. Stallman]

    The string representation is based on splay trees: a string
    is a splay tree of gap buffers.   There are various invariants
    (that I won't get into here) that make these trees more than
    ordinary splay trees -- they are a new data structure (afaict).

It will not be easy to determine whether this is a better data
structure for Emacs, even given a full implementation of it.  Even if
we had Emacs working using this, it might be hard to tell whether that
was an improvement.  For instance, many operations might be faster in
some cases, and slower in other cases.
is an improvement.

I also worry that it will be harder for most developers to understand
and change -- or even to use.  For instance, making redisplay operate
on that data structure could be very hard for that reason.

I don't think we would want to implement undo by making a snapshot,
even if the data makes snapshots possible, because this would take up
a lot more space than the current undo data.  Snapshots might be useful
for something, but not for this.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     The string representation is based on splay trees: a string
>     is a splay tree of gap buffers.   There are various invariants
>     (that I won't get into here) that make these trees more than
>     ordinary splay trees -- they are a new data structure (afaict).
>
> It will not be easy to determine whether this is a better data
> structure for Emacs, even given a full implementation of it.  Even if
> we had Emacs working using this, it might be hard to tell whether that
> was an improvement.  For instance, many operations might be faster in
> some cases, and slower in other cases.
>   

There is no need to make any decisions in advance.

I'm not worried about whether or not the code proves out
for GNU Emacs because I am certain I have plenty of uses
for it other than that.   It might well be good in Emacs.
The design is certainly influenced by Emacs' design and
experience.

It can be hard to compare things like this, I agree.



> I also worry that it will be harder for most developers to understand
> and change -- or even to use.  For instance, making redisplay operate
> on that data structure could be very hard for that reason.
>   

I don't see any reason that code would *need* to change.

It might be *desirable* to change redisplay code if simplifications
became possible, or interesting new capabilities.   I don't
see anything that would *need* to change there.



> I don't think we would want to implement undo by making a snapshot,
> even if the data makes snapshots possible, because this would take up
> a lot more space than the current undo data.  Snapshots might be useful
> for something, but not for this.
>   

You misunderstand how it works.   To illustrate:

    buffer_contents = [some big string];

    saved_undo_point = copy (buffer_contents);

    buffer_contents = insert (buffer_contents, "foobar");


After that code, there are two strings floating around:
buffer_contents and saved_undo_point.

The two strings differ by the insertion of "foobar" into
buffer_contents (or, if you like, the deletion of "foobar"
from saved_undo_point).

Internally, the two strings share most of their state.
The total amount of memory used is (roughly speaking)
the memory for saved_undo_point plus the memory
for just the string "foobar".

So, it is almost exactly the same space consumption
as an undo list.

(In reality, it's a little bit fancier than what is
described above in order to put an upper bound on
the amount of fragmentation of strings in memory.)

-t






>
>   

Re: Release plans

[Richard M. Stallman]

    > I also worry that it will be harder for most developers to understand
    > and change -- or even to use.  For instance, making redisplay operate
    > on that data structure could be very hard for that reason.
    >   

    I don't see any reason that code would *need* to change.

I think lots of the redisplay code operates directly on buffer
contents.  Other primitives too.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     > I also worry that it will be harder for most developers to understand
>     > and change -- or even to use.  For instance, making redisplay operate
>     > on that data structure could be very hard for that reason.
>     >   
>
>     I don't see any reason that code would *need* to change.
>
> I think lots of the redisplay code operates directly on buffer
> contents.  Other primitives too.
>   


If you would, please point me to a specific line of code or two
that illustrates what you mean.  I was poking around in the code
before trying to answer you and I didn't spot anything that
looked problematic but I don't claim to know that code well,
either.


-t

Re: Release plans

[Richard M. Stallman]

current_column is one example of code that looks directly
at buffer contents.

I cannot give an example from xdisp.c because I cannot find the code
that actually looks at the buffer.  I don't remember the function name,
and I can't find the place it is called from either.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
> current_column is one example of code that looks directly
> at buffer contents.
>   

I see.   And like regex.c it has special-case hair to cope with
the gap, etc.

FWIW I think this new data structure will be *easier* to
use and require less hair like that (but, proof is in the pudding
so we'll see when it's done).


> I cannot give an example from xdisp.c because I cannot find the code
> that actually looks at the buffer.  I don't remember the function name,
> and I can't find the place it is called from either.
>   

It looks to me like the display code has gotten gradually
more cleanly abstract over the years.    It still has all of the
considerable hair/tedium that seems to be intrinsic to the redisplay
problem but looks like it keeps a decent arm's length from
buffer internals.  It looks nicer than I remember it being
way back.

-t



>
>
>   

Re: Release plans

[Stefan Monnier]

> I don't think we would want to implement undo by making a snapshot,
> even if the data makes snapshots possible, because this would take up
> a lot more space than the current undo data.

I don't think it would necessarily take up significantly more memory.
In some cases it'll use up less memory.  OTOH it might make it difficult
to implement undo-elt-in-region.


        Stefan

Re: Release plans

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

Stefan Monnier wrote:
>> I don't think we would want to implement undo by making a snapshot,
>> even if the data makes snapshots possible, because this would take up
>> a lot more space than the current undo data.
>>     
>
> I don't think it would necessarily take up significantly more memory.
> In some cases it'll use up less memory.  OTOH it might make it difficult
> to implement undo-elt-in-region.
>   


Neat problem.  No, I hadn't thought about that case.

Is it the case that undo-elt-in-region exists for little or
nothing more than undo-in-region?    Because:

Markers are currently still stored in a list, right?
So inserts and deletes are linear in the number of
markers in a buffer, right?   (I thought I remembered
that changing long ago but looking at 22.1 source
I guess not.)

My plan is to keep markers in a tree in such a way that
inserts and deletes are log N in the number of markers,
and accessing a marker's position is log N in the number
of markers, but because this will be a self-adjusting tree
all those operations will be O(1) in the expected case where
changes display pretty good locality.

In other words: markers get a lot cheaper.

It *should* (in theory) be just fine for each undo-elt
to contain both string snapshot(s) and markers that
track the region effected.   That's easy to code and in
turn it makes undo-elt-in-region very easy to code.

That's an example of why I (so far) like this data
structure better than the current ones.   If markers get
significantly cheaper than they currently are, and
functional string edit operations get faster -- a lot of
code can be simpler.

-t





>
>         Stefan
>
>
>
>
>   


[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

Re: Release plans

[Stefan Monnier]

>>> I don't think we would want to implement undo by making a snapshot,
>>> even if the data makes snapshots possible, because this would take up
>>> a lot more space than the current undo data.
>> I don't think it would necessarily take up significantly more memory.
>> In some cases it'll use up less memory.  OTOH it might make it difficult
>> to implement undo-elt-in-region.
> Neat problem.  No, I hadn't thought about that case.
> Is it the case that undo-elt-in-region exists for little or
> nothing more than undo-in-region?

AFAIK yes.

> Markers are currently still stored in a list, right?

Yes.

> My plan is to keep markers in a tree in such a way that
> inserts and deletes are log N in the number of markers,
> and accessing a marker's position is log N in the number
> of markers, but because this will be a self-adjusting tree
> all those operations will be O(1) in the expected case where
> changes display pretty good locality.

Not sure how you intend to do that (I considered exactly this kind of
change in the past, but could never come up with a solution that was
satisfactorily elegant).  The O(1) is not necessary, actually.
Anything close to O(log N) will be a welcome improvement.
IIUC XEmacs uses a gap-buffer kind of solution (i.e. not a list of
markers but an array of markers with a moving gap in the middle).

(I've tried splay-trees for text-properties, and the performance was not
noticeably different from the current mostly-balanced binary tree.
In particular it seems that either we don't get to see the O(1) behavior
because the locality is not as good as it seems, or the constant factor
makes up for the difference).

> It *should* (in theory) be just fine for each undo-elt
> to contain both string snapshot(s) and markers that
> track the region effected.   That's easy to code and in
> turn it makes undo-elt-in-region very easy to code.

But that would significantly increase the size of the undo log, I expect
(maybe not algorithmically, but by a non-negligible factor).

It's too bad, because of we ignore the undo-in-region, we don't need
undo info for each modification, we could just grab a snapshot in
undo-boundary.  That would be elegant (tho it's not like it matters:
changing the implementation of the undo data is trying to solve
a non-problem, really).


        Stefan

Re: Release plans

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

Stefan Monnier wrote:
> (I've tried splay-trees for text-properties, and the performance was not
> noticeably different from the current mostly-balanced binary tree.
> In particular it seems that either we don't get to see the O(1) behavior
> because the locality is not as good as it seems, or the constant factor
> makes up for the difference).
>   

Thanks for the anecdote.

I was kind of thinking that, worst case, that was exactly
what to expect and so then, yes, is expected log N good
for these purposes?  (And I decided, "probably", so I'm
coding....)

It'll be interesting to see.

I think I have an elegant way to do properties and
markers but since I haven't coded that part yet I
can't swear there isn't a devil in the details. 

Years ago I did something very close to what I
have in mind while working on Guile.   (For a while,
Guile had an (unreleased) buffer type, with text properties
and markers, and a redisplay engine for X11.  It was
doing OK and might have matured to what I'm thinking
of now but that work got interrupted and then bit-rotted
away.




>   
>> It *should* (in theory) be just fine for each undo-elt
>> to contain both string snapshot(s) and markers that
>> track the region effected.   That's easy to code and in
>> turn it makes undo-elt-in-region very easy to code.
>>     
>
> But that would significantly increase the size of the undo log, I expect
> (maybe not algorithmically, but by a non-negligible factor).
>   

I guess the way I would say it is that it will *noticably* increase
the size of the undo log (yes, by a constant factor).    And I would
guess that that's *noticably* not *significantly*.   We'll see.
The library is useful, either way.



> It's too bad, because of we ignore the undo-in-region, we don't need
> undo info for each modification, we could just grab a snapshot in
> undo-boundary.  That would be elegant (tho it's not like it matters:
> changing the implementation of the undo data is trying to solve
> a non-problem, really).
>   

The real problems are a desire for a *nice* unicode-and-text-properties-
capable string library with buffer-like capabilities.   I want that as a
library, first and foremost, not tied to just one program.


Thanks,
-t



>
>         Stefan
>
>   


[-- Attachment #2: Type: text/html, Size: 3198 bytes --]

Re: Release plans

[Stephen J. Turnbull]

Thomas Lord writes:

 > of markers, but because this will be a self-adjusting tree
 > all those operations will be O(1) in the expected case where
 > changes display pretty good locality.

I would advise you not to expect that case.  Experience in XEmacs
shows that some applications (the VM MUA in particular, but also the
old implementation of font-lock, dunno about jit-lock) like to run up
and down the buffer a lot.  AFAICS it's really important to have O(log
N) worst-case behavior.

Sorry I can't be much more precise about why this happens, I just know
that our algorithms that deal with extents (which we use to support
overlay-like behavior and text properties) are tuned for good locality
and lose badly in large buffers; they show up as time hogs in profiling.

It's possible it's something internal to the implementation of
extents, too, but I think a word to the wise is appropriate here.

Re: Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
> Thomas Lord writes:
>
>  > of markers, but because this will be a self-adjusting tree
>  > all those operations will be O(1) in the expected case where
>  > changes display pretty good locality.
>
> I would advise you not to expect that case. 

That's two of you now (saying that).   Ok, then, I'll assume the
worst (which should still be "good enough").


>  Experience in XEmacs
> shows that some applications (the VM MUA in particular, but also the
> old implementation of font-lock, dunno about jit-lock) like to run up
> and down the buffer a lot.  AFAICS it's really important to have O(log
> N) worst-case behavior.
>   
> Sorry I can't be much more precise about why this happens, I just know
> that our algorithms that deal with extents (which we use to support
> overlay-like behavior and text properties) are tuned for good locality
> and lose badly in large buffers; they show up as time hogs in profiling.
>
>   

I looked at (an old version of?) the XEmacs internals manual.

It says extents are implemented as a pair of gap buffers.  It also talks
about the concept of cached stacks of events -- e.g., a cache
of the list of extents at a given point from which the extents over
a nearby point can be quickly computed.

I don't know if that's current.

The gap buffer and extent-stack cache would fit your
description of "optimized for locality" and would exhibit
the (performance) failure mode you describe under
access patterns about like you describe ("[running] up and down
the buffer").   In that access pattern, you're frequently
moving lots of data across the gap and if you're jumping around
at all during this traversal then you're constantly getting
cache misses or unwanted cache hits for the extent stack.

The splay tree of gap buffers should do considerably better
with those access patterns.  That's the theory, anyway:

The new data structure has an operation equivalent
to "move the gap" (so, e.g., insertions just write to
a linear piece of memory) however gap motion
is O(log N) buffer size in terms of operations and
O(1) for the amount of text that has to move.  Marker
updates, getting the position of a marker, and getting
back a list of text properties over a given point are all
O(log N) -- O(1) with good locality.

When I say "locality" I'm using that more loosely than
it is used when talking about ordinary gap buffers.
With ordinary gap buffers, the optimized case is a
lot of action near one point at a buffer, then an
infrequent motion far away, then lots of closely
placed action.    When I say "locality" I mean to
include (a) cases where the action at a given time
forms a dense set, even if that set is scattered;  (b)
linear access patterns.     By "dense set" I mean that
programs can be simultaneously modifying, say,
5 widely separated areas of the buffer in a multiplexed
way -- every modification is probably close to a recent
modification (so the set is dense) but every modification
is also probably far from the *most* recent modification
(so the set is scattered).  By "linear access" I mean cases
where code is scanning forwards or backwards.



> It's possible it's something internal to the implementation of
> extents, too, but I think a word to the wise is appropriate here.
>   

If extents are still the double gap buffer + extent stack
cache then I can see where you'd have problems like those
you describe.   In theory, this new thing does better in
those cases.

Thanks,
-t

Re: Release plans

[Stephen J. Turnbull]

Thomas Lord writes:

 > It says extents are implemented as a pair of gap buffers.

Well, yes and no.  The extent lists used by redisplay are implemented
as a pair of gap buffers; this allows O(log N) -- where N is always
the number of objects (here, extents) -- identification of the
display-order-maximal extent containing a buffer location, and also is
the correct order for redisplay to process extents so that redisplay
of an Emacs window can be O(number of buffer characters visible in
window).

However, extents themselves are full-fledged Lisp objects allocated on
the heap, and that is where position information is kept.  And it
turns out that in many common cases finding a particular extent is
O(N) (consider the case where the desired extent happens to cover the
whole buffer and the location is (point-max), while any extent *could*
have the desired property).

How does your splay tree scheme handle that?

 > It also talks about the concept of cached stacks of events -- e.g.,
 > a cache of the list of extents at a given point from which the
 > extents over a nearby point can be quickly computed.

With the caveat above, this is the current scheme.

 > The splay tree of gap buffers should do considerably better with
 > [the] access patterns [Steve described].  That's the theory,
 > anyway:

OK.

 > The new data structure has an operation equivalent
 > to "move the gap" (so, e.g., insertions just write to
 > a linear piece of memory) however gap motion
 > is O(log N) buffer size in terms of operations and
 > O(1) for the amount of text that has to move.  Marker
 > updates, getting the position of a marker, and

Urk.  Markers are not interesting AFAICS.  What needs to be efficient
is extents (whether text properties or overlays), because they carry
display properties and other things that may be referenced many times
in a pass over the buffer (eg, font-lock or building a parse tree).
What is difficult (for me, anyway) is extents.

 > getting back a list of text properties over a given point are all
 > O(log N) -- O(1) with good locality.

This last I'll want to see.  I suspect it will be expensive in space.

 > If extents are still the double gap buffer + extent stack
 > cache then I can see where you'd have problems like those
 > you describe.   In theory, this new thing does better in
 > those cases.

Well, we'll see.  I've found it quite easy to develop O(log N)
algorithms for markers.  But (except for redisplay, where the
two-sorted-list scheme is great), common operations on extents can
involve O(N) algorithms.

Re: Release plans

[Lennart Borgman (gmail)]

Thomas Lord wrote:
> Consider a feature, X, which is desirable for practical purposes.
> 
> Consider a feature, Y, which is banned.
> 
> If the ban on Y makes X harder to implement, in the sense
> of costing more in labor or money, then the economic incentive
> to go into business selling a non-free implementation of X goes
> up.
> 
> The reason that incentive goes up is because the cost of
> going into business selling a non-free X goes up while the
> demand for the practically useful X remains steady.
> 
> Now, someone with some money that they want to spend
> writing new, non-free software looks at that and says
> "I think I can do X, in spite of the ban on Y.  In fact,
> given the work I did on my masters thesis, I think I can do
> X cheaper than most people.   If I start selling a non-free X,
> it will be a long time before some competitor comes along
> either selling a non-free competitor to X or sharing a free
> version of X.  It will be a long time because I'm almost the only one
> with an effective idea of how to get around the ban on Y.
> Therefore, I'll go into business selling proprietary X and count
> my blessings for the banning of Y."


Are you sure that reasoning is valid as an argument here? There will for
example, as you even hint, be different economic incentives for
different people.

Re: Release plans

[Thomas Lord]

Lennart Borgman (gmail) wrote:
> Thomas Lord wrote:
>   
>> Consider a feature, X, which is desirable for practical purposes.
>>
>> Consider a feature, Y, which is banned. [....]
>>
>>     
>
> Are you sure that reasoning is valid as an argument here? There will for
> example, as you even hint, be different economic incentives for
> different people.
>
>   


Yes, I've seen it happen.

There are different incentives for different people, that's right.
So, the guy that goes into business selling non-free X because
he did a masters thesis that made it uniquely easy for him to
implement X -- THAT GUY --  that guy is the main (type of)
guy around whom start-ups are formed.

That unique advantage for "that guy" is only half of what makes
the business, though.   The other two halves are that other people
will find other things easier to do than implement X and that other
people want X.

The "hat trick" -- the perfect three points for a non-free software
start-up -- are:  (1) a program X that it is easy for me to write;  (2)
where X is hard for YOU to write;  (3) and people want X for
practical purposes.

"That guy" for whom X is easy is rare but, in a sufficiently
large crowd, he is practically guaranteed to exist: so (1) is
almost a free point.  

There are a lot of possible values of X that people might want so
(3) is practically a free point.

The only touch bit is (2):  X has to be hard for (most) *other*
people to write.   And that's where the questions about banning
feature Y come in.    Banning Y can only help "that guy" with (2).

You should see how the industry of deep packet inspection appliance
vendors has unfolded, for example.   It is exactly this pattern of
start-ups and non-free software.

You can also do the thought experiment of imagining an (unachievable)
world in which any program you could possibly want was, somehow,
cheap and easy to write.   Non-free software business models would not
thrive in such a world, not like they do now (mostly).

We can't every perfectly get to that world but we can get a lot closer
than we are -- and feature bans are a retreat from that objective.

-t

Re: Release plans

[Lennart Borgman (gmail)]

Thomas Lord wrote:
> Lennart Borgman (gmail) wrote:
>> Thomas Lord wrote:
>>  
>>> Consider a feature, X, which is desirable for practical purposes.
>>>
>>> Consider a feature, Y, which is banned. [....]
>>>
>>>     
>>
>> Are you sure that reasoning is valid as an argument here? There will for
>> example, as you even hint, be different economic incentives for
>> different people.
>>
>>   
> 
> 
> Yes, I've seen it happen.

Sure.

> The "hat trick" -- the perfect three points for a non-free software
> start-up -- are:  (1) a program X that it is easy for me to write;  (2)
> where X is hard for YOU to write;  (3) and people want X for
> practical purposes.
> 
> "That guy" for whom X is easy is rare but, in a sufficiently
> large crowd, he is practically guaranteed to exist: so (1) is
> almost a free point. 

And of course it is also guaranteed that there are quite a few in the
group (1) ...

> There are a lot of possible values of X that people might want so
> (3) is practically a free point.

Don't you have to have buyers too?

That is a pretty important point in my opinion since actually
implementing and polishing an idea so that it meets the end user is
quite labor intensive. And this point may change the scene quite a lot.

> The only touch bit is (2):  X has to be hard for (most) *other*
> people to write.   And that's where the questions about banning
> feature Y come in.    Banning Y can only help "that guy" with (2).

Perhaps you are right, but I am not sure. More specific examples might help.

However looking at the economic incentives and possibilities is
necessary and good. One way I have often wondered about is trying to
raise money from governements for developing free software. They are
probably large enough to directly benefit from it (in cost benefit
terms) if suitable projects can be found.

But then there must be people who are willing and able to write
attractive software for them.

> You can also do the thought experiment of imagining an (unachievable)
> world in which any program you could possibly want was, somehow,
> cheap and easy to write.   Non-free software business models would not
> thrive in such a world, not like they do now (mostly).

I am not sure. The overall picture have to be taken into account. (That
is part of the nature of power. It happens because it takes things into
account - in perhaps an unconscious way.)

> We can't every perfectly get to that world but we can get a lot closer
> than we are -- and feature bans are a retreat from that objective.
> 
> -t
> 
> 
> 

Re: Release plans

[joakim]

"Richard M. Stallman" <rms@gnu.org> writes:

> The decision on whether to include a dynamic linker in Emacs
> does not directly affect users' freedom.  (It doesn't change the license.)
> What is affects is which changes we facilitate and which changes we don't.
>
> The case of XRefactory and its harmful effects on CEDET illustrate the
> kind of harm I'm trying to avoid.  It also shows that we cannot
> totally avoid such problems.  But opening a convenient door for making
> them is likely to mean more of them.  I want to have less of them.

I would like to add two things I find missing from this discussion.

- Things can change over time
- People can change over time with helpful education

I had trouble understanding the dynamic linker ban ten years ago, but I
now understand the relevance of it at the time. I've learned something
from this.

Today I would claim that limiting Emacs technical abilities hurts Emacs
ability to be used as an educational tool for the value of software
freedom. I claim this because I belive people need somewhere acessible
to start learning.

When I started using Emacs it was because of its technical merits. It
was available on all the proprietary platforms I used. Only later did I
discover the value of freedom, and Emacs helped me with this.

Emacs still has great technical merit of course, but its not imediately
obvious to newcommers. In order to make it more obvious, heres a short
list of things I think would help:

- Merge CEDET, and improve it so great IDE functionality can be had
  fairly easily
- Merge ECB so IDE like code browsing tools becomes available
- Make it possible to write more beautiful elisp. I'm not a lisp expert
  but even I find it painful that writing recursive functions is made
  hard due to the lack of tail-optimization. It should be fun to code
  elisp.
- provide different levels of chrome out of the box. One skin would be
  bling-bling with all facilities enabled, transparent windows etc, and
  another one would be monk mode with nearly nothing.



-- 
Joakim Verona

Re: Release plans

[Richard M. Stallman]

    - Merge CEDET, and improve it so great IDE functionality can be had
      fairly easily
    - Merge ECB so IDE like code browsing tools becomes available

I am in favor of these goals.

    - Make it possible to write more beautiful elisp. I'm not a lisp expert
      but even I find it painful that writing recursive functions is made
      hard due to the lack of tail-optimization. It should be fun to code
      elisp.

Yes and no.  To make tail-recursion work would be nice.
However, USING it in the code of Emacs could be a bad thing,
because it often makes the code harder to understand.
All in all, it is better to write a loop.

    - provide different levels of chrome out of the box. One skin would be
      bling-bling with all facilities enabled, transparent windows etc, and
      another one would be monk mode with nearly nothing.

I am for it if users like it.

Re: Release plans

[Alan Mackenzie]

Hi, Stephen,

On Tue, Aug 19, 2008 at 06:46:22PM +0900, Stephen J. Turnbull wrote:

> But Alan, I have accepted your principles, except the one that says
> anything you can imagine is probable enough to worry about.

> And unfortunately, I can't challenge your arguments because you
> haven't posted one .....

What, exactly, are we getting so worked up about, then?

> .... (except that fallacious argument from the authority of Richard
> Stallman).

That's a mischaracterisation of what I've said.  I respect his opinion
not because of his "authority", but because of his experience of the
murky place where legality, politics, and software meet, and my own near
total lack of it.

> You have only posted assertions.  I grant the conceptual possibility
> that you assert, but I deny its importance.

OK, thanks!

> I claim it is both extremely unlikely to come to pass, and that we can
> deal with the process of it arising in other ways.  And I've supported
> both claims with concrete technical details and policy proposals.

>  > This is where we differ.  A plane crash hurts not just the people on
>  > board, but the people the wreckage falls on.  Think of Lockerbie in 1988.

> I guess I should deduce that you are in favor of closing airports so
> that planes will stop falling out of the sky on innocent people?  The
> analogy is quite exact, you see.

Now who's drawing wild conclusions?

>  > The fallout will hit you.  That proprietary module will gunge up
>  > Emacs development, damage Emacs's reputation, cause sysadmins to
>  > hate it (they must field the rage from hackers) just as that
>  > aeroplane devastated a street in Lockerbie.

> I really don't see it.  Emacs developers won't touch the module,
> requests for support will be directed to the vendor, and surely
> vandalism/netrage by hackers is not to be attributed to Emacs but
> rather to the hackers themselves.

In a nice rational world that might be the case.  In the world we know,
it'd be "Emacs = hassle = problems, let's just ditch it."

> What damage to Emacs's reputation do you envision?

It's reputation for being a highly effective reliable working program
which causes trouble neither for its users nor sysadmins.

>  > Again, I'm thinking about the Community's freedom, not just yours as an
>  > isolated individual.

> I object to your implication that I care only about myself.

OK.  I got this notion from what you have written in your posts, see
below.

>  > I think I've made it clear that my "nightmares", as you call them,
>  > are not positions I'm defending.  I put them forward only as a
>  > counter (mainly) to Tom and to you, to show that bad things are
>  > possible, even if not probable.

> Bad things are possible.  Stipulated.  As with closing airports to
> prevent mid-flight crashes, some policies to ameliorate the possible
> bad things are stupid; there are better ways to deal with them.

Right.  So do you agree the present issue is a matter of analysis and
judgement, weighing up risks and benefits?  For example, it is (or used
to be) sensible to close airports during thick fog.

> I think GNU's refusal to allow dynamic loading in Emacs is such a
> stupid policy, because there are better ways to address potential
> problems.

That is clear.

>  > The analysis from you and Tom falls short of mathematical
>  > perfection.  Unless I'm mistaken, it focusses purely on the effects
>  > it would have on knowledgeable automous hackers.

> I don't speak for Tom, but my analysis falls short of perfection.  As
> I say, you should apply such standard to yourself, as well.

> And you are mistaken.  My analysis focusses purely on the *lack* of
> freedom-destroying effects for *anybody*.  Once we have some effects
> to talk about, I'll worry about whose ox is getting gored.

A little while ago, I opined that it is more important to be free than to
be aware of that freedom.  I don't think your analysis has covered those
Emacs users who are free by virtue of that use, but are unaware of it.
They could lose freedom, possibly without realising it, if any of the Bad
Things we're talking about happen.

>  > I think we differ because our axioms differ.

> I think we differ because I've gone beyond axioms to offer concrete
> analysis, and you haven't.

>  > You and T regard only the freedom of the informed automous hacker
>  > as important.

> I am very offended.  I could not have imagined that you would stoop so
> low.

That wasn't intended to offend, and I'm sorry it did.  I was trying to
get some sort of handle on why two highly intelligent, normally genial,
hackers, are having such a bad tempered exchange.  Please consider this
extract from your email in this thread:
    
    Message-ID: <878wuw7wji.fsf@uwakimon.sk.tsukuba.ac.jp>
    Date: Sun, 17 Aug 2008 01:29:53 +0900

    Richard M. Stallman writes:

     >     How does not providing dynamic loading maximize what users can
     >     do while remaining free?
     >
     > It protects against the danger of non-free C-level add-ons to
     > Emacs.

Stephen: All a freedom-lover has to do to avoid those non-free add-ons is ...
     avoid them.

Further, in your post before your last one, you wrote:

Stephen: I mean for starters, the GPL guarantees that Emacs remains free.
     So people can just say no and keep their personal freedom.


That sentence "All a freedom-lover has to do ...." suggested to me that
you only considered the effect on "freedom-lovers" (what I called
"informed autonomous hackers") important.  The sentence "So people can
just say no and keep their personal freedom." reinforces this impression,
in that it disregards those who can't just say no.  I think Richard was
concerned about protecting users who would be less able to avoid non-free
add-ons, for whatever reason.

These sentences of yours still suggest to me that you don't regard the
freedom of the non-informed, or non-autonomous hacker with very much
importance.  Please comment on this.

>  > I (and possibly RMS) see freedom for the entire community as
>  > important.  I think my hypothetical bad case ("microsoft8.dll") from
>  > last night made that clear.  That such could be imposed on others is
>  > a bad thing for me.

> I claim it cannot be imposed.  Please rebut.

I can't, at least, not at the level I think you want.  It would need more
expertise on and more interest in things like licensing, copyright, ...
than I've got.  Anyhow, I'm not the person that needs to be persuaded.

>  > Should a non-free Emacs become widely installed ("established"), say
>  > GNU Emacs hobbled by the "microsoft8.dll" I pictured last night, a
>  > newer version of Emacs is unlikely to cause the number of
>  > installations of that un-free version to fall rapidly to near zero
>  > (i.e., become "disestablished").

> Depends on what you mean by "rapidly".  Overnight?  No.  In two or
> three years?  Yes, I think that can be done, and that's fast enough.

I don't think it could.

>  > For the third time, our basic axioms seem to differ.

> They do.  However, for the sake of this discussion, I've adopted
> yours.  Except for the axiom that "dynamic loading leads to unfree
> Emacs", which I consider a proposition to be proved or disproved.

The bit I think you're neglecting is the free "for whom?".

>  > I don't think you see the point I'm making, and your analysis is
>  > oblivious to that point, so I disregard it.  Maybe.

> No.  I understand your point.  "Introducing a module loader could
> cause Emacs to become non-free."  That's scary.

Again, non-free "for whom?".  If you'ld've made specific reference to
people who couldn't or wouldn't take action against non-free add ons
themselves, I'd accept you'd understood my point.

> In the light of day, though, I don't believe it's going to happen.

I don't think it would happen either, for what it's worth.  

> OTOH, I do know that benefits (so far of modest size) will certainly
> happen.  For example, you're the same Alan Mackenzie who's been annoyed
> by the Emacs build process recently, right?  Wouldn't it be nice if you
> could just disable the broken feature you don't like, or even just not
> build that module and use yesterday's build of the module with today's
> core?  How about if you are developing new C code, and can change and
> reinitialize it in your running Emacs with a turnaround of about 5
> seconds on a reasonable machine?

Yes, it would indeed be nice.  If Emacs had been structured more
modularly, this would be easy.

>  > In my post last night, I drew a picture of Emacs running on a future
>  > MS OS, where in order to get access to its file system, you had to
>  > install the proprietary library "microsoft8.dll".  This would have
>  > the side-effect, on the pretext of "security", of disabling `defun'

> I can't find anything about disabling `defun', and that's not
> plausible anyway.

The sentence fragment ".... only allowing digitally signed LISP or binary
libraries to be COMPILED or loaded."  But that's not important.  The fact
is, a loaded binary module could disable any part of the Lisp
infrastructure.  It's a mere technical problem, not even that difficult.

> ..... the FSF would have no problem getting a subpoena for Microsoft's
> source code if it was at all compatible.

Maybe, maybe not.  Who wants to go there?  What would happen to Emacs in
the years the court case would drag over?

>  > and only allowing signed (by MS) Lisp libraries to be loaded.

> Again, the technical difficulties of accomplishing this in GNU Emacs
> are enormous.

Really?  A few defadvices in the right (wrong?) place would do the trick.

> Remember, GNU Emacs's security features were designed by the guy who
> posted his password for somebody else's system in a public place.

What was somebody saying about ad hominem attacks not all that long ago?

> How could that be imposed?

I don't think the module I depicted, microsoft8.dll, could be imposed.
It is just too extreme, too blatant.  A more subtle, insidious spoiler
module might be imposable.

>  > > I mean for starters, the GPL guarantees that Emacs remains free.
>  > > So people can just say no and keep their personal freedom.

>  > Oh, so GPL's "guarantees" mean that everything's fine, and so we
>  > don't need to worry about anything.

> What do you think "for starters" means?

It's a colloquial expression which means, anywhere I've lived, something
like "I have a number points I could make, any one of which will refute
your point, so I am going mention just one of them, in the hope you'll
not be so abstruse as to carry on a long fruitless argument which you'd
lose anyway.".

> It's not a complete argument, but you really do have to answer it since
> you have claimed that Emacs itself would become non-free.  In the case
> of microsoft8.dll, the user still has the source, they still have the
> right to redistribute Emacs, etc.  So how has Emacs become non-free?

Without the mischief module they can't access their files, since the OS
puts some sort of lock on the file system.  That module prevents any Lisp
code other than the standard distribution libraries from being compiled
or loaded, and will itself only run in an unmodified Emacs.  Emacs has
now become non-free for those users on that system.

> Even if the DLL is loaded in site-start, you can disable that.  (Well,
> I can, in XEmacs.)

Sure, assuming that the --no-site-start flag isn't removed from Emacs
(which anyone is free to do).

>  > > Should we remove process support from Emacs?

>  > No.  My question to you: what can an intimately linked binary module
>  > achieve that calling something as a separate process couldn't?

> Reload a patched C object into a running Emacs.

> Manipulate Emacs data structures, and provide new ones.

> Very little that a separate process can't, but it can do everything a
> lot faster.

>  > Linking to external binaries has been in XEmacs for some while.
>  > What have people done with it?  Could they have done the same by
>  > calling an external program via an OS call?

> Look in the modules directory of XEmacs.  In the case of the Canna
> module, no such command exists, so you need to link to Canna.
> Although there's also a network protocol so you could use just Lisp.

>  > Up to now, you and Tom have been asserting that calling external
>  > binaries is critically important and very useful.

> No, I haven't.  I've simply said I don't see enough risk, even given
> the nightmarish consequences you envision, to outweigh the benefits I
> see.

OK.  I think the benefits are moderate rather than profound.  David K.
mentioned the Lilypond info pages having images, and how it would be
helpful dynamically to load image libraries for them.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > What, exactly, are we getting so worked up about, then?

Well, I've been perplexed by the "no dynamic loading" policy for about
a decade now.  I know that Richard is not going to give an answer
except that he's fearful, uncertain, and doubtful about dynamic
loading, and so has decided to avoid it.  I was hoping you might
provide some insight, but you're giving me the same line.  I'm very
frustrated by that.

 > Right.  So do you agree the present issue is a matter of analysis and
 > judgement, weighing up risks and benefits?

Of course I do.  I see small benefits (measured in terms of freedom,
as I understand it) and much smaller risks (ditto).  That's precisely
what I've been arguing all along, but you and Richard assert that
*any* risk is too large.

 > > No.  I understand your point.  "Introducing a module loader could
 > > cause Emacs to become non-free."  That's scary.
 > 
 > Again, non-free "for whom?".  If you'ld've made specific reference to
 > people who couldn't or wouldn't take action against non-free add ons
 > themselves, I'd accept you'd understood my point.

I don't think there are *any* people who *couldn't* take action[1],
and I don't understand why "wouldn't" is a problem in the context of
freedom.  There are two kinds of people who wouldn't, those who have
considered the consequences and decided they don't care, and those who
just don't care.  Either way, why isn't it their place to decide, and
our place to provide them with the information they need to make
informed judgments?

And I still don't see how they "lose" freedom or Emacs becomes unfree.
In the first place, they *gain* capabilities that they did not have
before.  True, those capabilities do not come with the four freedoms
attached, but what have they "lost"?  In the second, Emacs itself is
still free, the users have the four freedoms with respect to it.

 > >  > and only allowing signed (by MS) Lisp libraries to be loaded.
 > 
 > > Again, the technical difficulties of accomplishing this in GNU Emacs
 > > are enormous.
 > 
 > Really?  A few defadvices in the right (wrong?) place would do the trick.

(ad-stop-advice)

It really is not that easy.  And yes, since it's supposed to be a
security feature, you do have to deal with savvy users like me who
would be able to handle a defadvice of ad-stop-advice.  The whole
thing would get blown out of the water with a million CERT reports.

 > > Remember, GNU Emacs's security features were designed by the guy who
 > > posted his password for somebody else's system in a public place.
 > 
 > What was somebody saying about ad hominem attacks not all that long ago?

It's not really an ad hominem.  It's an *allusion*, to the fact that
*by design* Emacs has no security features, except to protect itself
from crashing, and a little bit for protecting passwords (but a couple
of defadvices would defeat that, too).


Footnotes: 
[1]  At least, they have other, much more dire problems, as Richard
has been at pains to point out to you.  You *can* be free, you just
don't want to badly enough.

Re: Release plans

[Alan Mackenzie]

Hi, Stephen!

On Mon, Aug 25, 2008 at 11:39:16PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > What, exactly, are we getting so worked up about, then?

> Well, I've been perplexed by the "no dynamic loading" policy for about
> a decade now.  I know that Richard is not going to give an answer
> except that he's fearful, uncertain, and doubtful about dynamic
> loading, and so has decided to avoid it.  I was hoping you might
> provide some insight, but you're giving me the same line.  I'm very
> frustrated by that.

Sorry.  The thing is, we're at the place where free software principles
become ironic, inconsistent and contradictory, even absurd.  Every
half-decent religion or philosopy, even science and maths, has suchlike,
so why should we expect free software to be any different?

Yes, we want software to be free, but no, we don't want people to use
this freedom in certain ways, ways which would inhibit the progress of
free software.  Something's got to give.  In a democracy, sometimes
people get elected who want to dismantle the democracy.  So you have a
constitution to protect it, and this usually works.  In maths, there is
the Axiom of Choice (which is obviously true) and Zorn's Lemma (which is
patently absurd), yet the two are logically equivalent.  Mathematicians
are fairly relaxed about absurdities and joke about them over an
afternoon cup of tea.

The "resolution" in free software is to soft-pedal, to hope that nobody
does anything too unfree, and to avoid giving them too much help and
encouragement.  A bit like politics, really.  So whilst making dynamic
modules part of "official" Emacs might not change what is possible, it
might well encourage what is legitimate, yet we don't want to happen;
it's a kind of touchy-feely thing.  That's my understanding, anyway - I
could be totally wrong.  On the particular issue of dynamic modules, I
don't feel I have the experience to judge the conflicting issues, so I
defer to Richard's.  I'm not sure what would happen if we made dynamic
loading a first-class feature, documented in the Elisp manual and NEWS,
as opposed to being downloadable in some obscure patch, not supported by
the main maintainers, assuming you've even heard of it.

Eric Ludlam mentioned a product called Xrefactory a couple of days ago.
It seems to be a refactoring tool based upon (X)Emacs.  Yes, this is
legitimate within the terms of the GPL, but isn't the sort of thing we
really want to encourage; it's not free, neither in the speech nor beer
sense.

[ .... ]

>  > > No.  I understand your point.  "Introducing a module loader could
>  > > cause Emacs to become non-free."  That's scary.

>  > Again, non-free "for whom?".  If you'ld've made specific reference to
>  > people who couldn't or wouldn't take action against non-free add ons
>  > themselves, I'd accept you'd understood my point.

> I don't think there are *any* people who *couldn't* take action[1],
> and I don't understand why "wouldn't" is a problem in the context of
> freedom.  There are two kinds of people who wouldn't, those who have
> considered the consequences and decided they don't care, and those who
> just don't care.  Either way, why isn't it their place to decide, and
> our place to provide them with the information they need to make
> informed judgments?

I think our basic philosophies just differ here.  I appreciate living in
a "free" society, yet if Nuremberg were once again subject to a military
invasion, would I accept a rifle and be willing to use it?  Probably not.
I gladly accept the freedom guaranteed by professional soldiers.  Just as
those soldiers protect those "who don't give a damn", I feel we should
protect the (software) freedom of those who, for whatever reason,
wouldn't protect their own.

> And I still don't see how they "lose" freedom or Emacs becomes unfree.
> In the first place, they *gain* capabilities that they did not have
> before.  True, those capabilities do not come with the four freedoms
> attached, but what have they "lost"?  In the second, Emacs itself is
> still free, the users have the four freedoms with respect to it.

Again, with Eric's example of Xrefactory, any hackers who buy that
product and incorporate it into their development process thereby lose
some of their freedom - their process has become tied to a product they
can't control - to some extent.  This is another one of these
contradictions about software freedom - by exercising freedom you
diminish it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
> constitution to protect it, and this usually works.  In maths, there is
> the Axiom of Choice (which is obviously true) and Zorn's Lemma (which is
> patently absurd), yet the two are logically equivalent.  Mathematicians
> are fairly relaxed about absurdities and joke about them over an
> afternoon cup of tea.

No math please, that takes too much time ;-)

> Again, with Eric's example of Xrefactory, any hackers who buy that
> product and incorporate it into their development process thereby lose
> some of their freedom - their process has become tied to a product they
> can't control - to some extent.  This is another one of these
> contradictions about software freedom - by exercising freedom you
> diminish it.

I am not sure that conclusion is valid. You can think

"Ah, why should people have to buy that sort of software? Everyone can't
do that! I will write a free version of this! Hope someone else will
join ..."

Is not that what often happens?

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Yes, we want software to be free, but no, we don't want people to
 > use this freedom in certain ways, ways which would inhibit the
 > progress of free software.

I'm not sure I agree with this formulation, but it's not what I'm
talking about in this thread.

I'm talking about a specific decision which is based not on observing
people misusing freedom, not on the likelihood of people misusing
freedom in foreseeable ways, but rather on the conceptual possibility
that in some as-yet unforeseeable way somehow someday somebody might
possibly misuse freedom to a disastrous end.  Granted, Richard points
out that Linux did have problems with binary modules, but, um, the
result is egg on NVIDIA's face and in ATI's beer, and Linus explicitly
was neutral on the practice.  As Richard is wont to say about patents
and copyright, the cases are completely different and shouldn't be
grouped together.

 > Eric Ludlam mentioned a product called Xrefactory a couple of days
 > ago.  It seems to be a refactoring tool based upon (X)Emacs.  Yes,
 > this is legitimate within the terms of the GPL, but isn't the sort
 > of thing we really want to encourage; it's not free, neither in the
 > speech nor beer sense.

The reductio is obvious, isn't it?  Since any free software program
can be abused as part of a non-free software product, we should stop
all distribution of free software to the heathen.  That way we can be
sure of providing the minimum encouragement to abuse freedom.

Personally, I agree with Tom: we should be going all-out to encourage
use of free software, using three main tactics: (1) emphasizing the
importance of software freedom (eg, from a code-is-law basis), (2)
emphasizing the costs both in freedom and economic value of non-free
software, and (3) providing kick-ass software that everybody wants to
use.

Effectively discouraging non-free software is out of our control.
"Mr. Quixote, meet Mr. Windmill...."

 > I gladly accept the freedom guaranteed by professional soldiers.  Just as
 > those soldiers protect those "who don't give a damn", I feel we should
 > protect the (software) freedom of those who, for whatever reason,
 > wouldn't protect their own.

At the cost of the freedom of those who would *like* to use unfree
software: they have done the calculation on the costs of lock-in, and
like the answers they got.  I find your paternalism distasteful.

 > Again, with Eric's example of Xrefactory, any hackers who buy that
 > product and incorporate it into their development process thereby lose
 > some of their freedom - their process has become tied to a product they
 > can't control - to some extent.  This is another one of these
 > contradictions about software freedom - by exercising freedom you
 > diminish it.

This paradox has *nothing whatsoever* to do with software.  Freedom
means choice.  If everybody is free, everybody is making choices, and
this *imposes* uncertainty about those choices on others.  People
*dislike* uncertainty (eg, about when you're next going to have sex)
and so they *accept* constraints (marriage, to continue the metaphor).[1]

Some people are willing to accept the constraints of unfree software
constrained for commercial advantage.  Some people hate unfree
software so much that they impose constraints on the use of their
software by others, and claim that the net result is somehow an
increase in freedom when in fact there is a clear decrease in options
available to users.  I don't really see an ethical difference here.

Footnotes: 
[1]  Before you ask, and I have every reason to believe you will: No,
I do not believe that more regular sex is the only or even the main
reason people get married, nor do I believe that the strategy actually
works all that well.  I will assert that many of the reasons for
getting married do take the same form of a voluntary exchange of one's
own freedom for a commitment to stability from the partner.

Re: ["agree"] Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
> Personally, I agree with Tom: we should be going all-out to encourage
> use of free software, using three main tactics: (1) emphasizing the
> importance of software freedom (eg, from a code-is-law basis), (2)
> emphasizing the costs both in freedom and economic value of non-free
> software, and (3) providing kick-ass software that everybody wants to
> use.
>   

I'm saying an additional thing that is a bit subtle.   So, there should
be a (4) in that list.

The additional thing is a qualifier on "kick-ass software".

We want (4) Kick-ass software that is kick-ass in the specific
sense that a maximized number of users will find it personally
beneficial to themselves to study the code, modify it, and share
modifications.

That is, we want software that is not only a good choice among
software in general but, among the good choices, we want software
architectures and engineering practices that non-linearly reward
the *exercise* of software freedom by as many users as we can.
If a lot of people are fully USING software freedom, then they
and many others will come to EXPECT software freedom and
DEFEND software freedom.   Seems like a no-brainer, to me.

I would claim that API features like a dynamic loader or
tree print/read in GCC are special.   They encourage people to
get work done by studying, modifying, and sharing code -- by their
nature.   GNU should / should have run for such features rather
than ban them.   Those feature-ban decisions were pretty much
the opposite of right.

I also am saying that I can't think of any non-contrived feature
bans that wouldn't be subject to the same criticism.   At least as a
good rule of thumb, I think we could just say that, in general,
no feature is banned.   Then we don't have to spend nearly as much
time thinking about what not to implement (and always, eventually,
coming up with the null set as the best-guess answer).

-t


-t

Re: ["agree"] Release plans

[Stephen J. Turnbull]

Thomas Lord writes:

 > I'm saying an additional thing that is a bit subtle.   So, there should
 > be a (4) in that list.

OK.

 > The additional thing is a qualifier on "kick-ass software".
 > 
 > We want (4) Kick-ass software that is kick-ass in the specific
 > sense that a maximized number of users will find it personally
 > beneficial to themselves to study the code, modify it, and share
 > modifications.

Quibble: I don't think all free software needs to be kick-ass in this
sense.  So it's not a qualifier, it's an additional goal that we want
"a lot" of free software to satisfy.

 > I would claim that API features like a dynamic loader or
 > tree print/read in GCC are special.   They encourage people to
 > get work done by studying, modifying, and sharing code -- by their
 > nature.   GNU should / should have run for such features rather
 > than ban them.   Those feature-ban decisions were pretty much
 > the opposite of right.

Nicely put.  I had a feeling for this but you put words to it.
Thanks!

 > I also am saying that I can't think of any non-contrived feature
 > bans that wouldn't be subject to the same criticism.

I wouldn't go so far.  I think it's arguable that the
anti-tech-measures and must-distribute-keys provisions of GPL v3 fit
this bill.

Re: ["agree"] Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
>  > I also am saying that I can't think of any non-contrived feature
>  > bans that wouldn't be subject to the same criticism.
>
> I wouldn't go so far.  I think it's arguable that the
> anti-tech-measures and must-distribute-keys provisions of GPL v3 fit
> this bill.
>   

Those aren't feature bans, though: they are legal and technical
conditions on conveying a work.

You are free to distribute GPLv3 code, modified
to have DRM features.    The catches are that you (a) assert
that the code is not covered by anti-circumvention laws;
(b) not use secret keys or similar measures to prevent users
from fully exercising their GPLv3 rights.

You can put the code in there, though.   Might even be
useful for something, who knows.

-t

Re: Release plans

[Alan Mackenzie]

Hi, Stephen,

On Tue, Aug 26, 2008 at 01:54:15PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > Yes, we want software to be free, but no, we don't want people to
>  > use this freedom in certain ways, ways which would inhibit the
>  > progress of free software.

> I'm not sure I agree with this formulation, but it's not what I'm
> talking about in this thread.

I think it is.  I think it's the abstract principle behind RMS's decision
not to put a binary module loader in Emacs.

If you don't like my formulation, how about reformulating it your own
way?

> I'm talking about a specific decision which is based not on observing
> people misusing freedom, not on the likelihood of people misusing
> freedom in foreseeable ways, but rather on the conceptual possibility
> that in some as-yet unforeseeable way somehow someday somebody might
> possibly misuse freedom to a disastrous end.

You might be right there.  Such a "conceptual possibility" existed wrt
patents in GPL2.  Microsoft and Novell exploited it to give special
"patent protection" (against unspecified MS patents) to direct Novell
customers only, in gross violation of the ideals of the GPL.  Rather
clumsily, they pulled the stunt as GPL3 was being developed.  I think
it's right to be very wary about exposing possible vulnerabilities to
proprietary competitors.  They will be actively seeking weak points to
exploit.

[ .... ]

>  > Eric Ludlam mentioned a product called Xrefactory a couple of days
>  > ago.  It seems to be a refactoring tool based upon (X)Emacs.  Yes,
>  > this is legitimate within the terms of the GPL, but isn't the sort
>  > of thing we really want to encourage; it's not free, neither in the
>  > speech nor beer sense.

> The reductio is obvious, isn't it?  Since any free software program can
> be abused as part of a non-free software product, we should stop all
> distribution of free software to the heathen.  That way we can be sure
> of providing the minimum encouragement to abuse freedom.

No, not at all.  The absurdum is what I pointed out yesterday, not what
you've just written: we restrict freedom to protect it against being used
to destroy itself.

[ .... ]

> Effectively discouraging non-free software is out of our control.
> "Mr. Quixote, meet Mr. Windmill...."

It is not.  There are few non-free extensions to Emacs, at least that I
have heard of.  With a binary module loader, there might well be more.

>  > I gladly accept the freedom guaranteed by professional soldiers.
>  > Just as those soldiers protect those "who don't give a damn", I feel
>  > we should protect the (software) freedom of those who, for whatever
>  > reason, wouldn't protect their own.

> At the cost of the freedom of those who would *like* to use unfree
> software: they have done the calculation on the costs of lock-in, and
> like the answers they got.

Yes, this is down in the irony and contradictions department of free
software.  But as you've noted, the lock-in is largely psychological:
there's nothing in the GPL to prevent anybody extending Emacs pretty much
however they want, and that includes adding a binary module loader -
providing the loaded modules wouldn't get too intimate with Emacs itself.

> I find your paternalism distasteful.

Yes, I expected that and I've no problem with it.  Likewise, I find
aspects of your personal philosophy distasteful too.  I look on it as a
source of fruitful debate, far better than the near slanging match we
were having just a few days ago.

[ .... ]

> Some people are willing to accept the constraints of unfree software
> constrained for commercial advantage.  Some people hate unfree software
> so much that they impose constraints on the use of their software by
> others, and claim that the net result is somehow an increase in freedom
> when in fact there is a clear decrease in options available to users.
> I don't really see an ethical difference here.

I think you're right.  That is down in the irony/contradiction/absurdity
region again, where the ethics can't help but being murky.

A while ago, I was arguing that Emacs being available on w32 was a good
thing - not from any highly principled position, just for purely
pragmatic reasons.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > Hi, Stephen,
 > 
 > On Tue, Aug 26, 2008 at 01:54:15PM +0900, Stephen J. Turnbull wrote:
 > > Alan Mackenzie writes:
 > 
 > >  > Yes, we want software to be free, but no, we don't want people to
 > >  > use this freedom in certain ways, ways which would inhibit the
 > >  > progress of free software.
 > 
 > > I'm not sure I agree with this formulation, but it's not what I'm
 > > talking about in this thread.
 > 
 > I think it is.  I think it's the abstract principle behind RMS's decision
 > not to put a binary module loader in Emacs.

Please don't tell me what I'm talking about.  Let me clarify: I don't
mean to disagree that it's the abstract principle behind the decision,
so it's not what I'm talking about.

 > If you don't like my formulation, how about reformulating it your own
 > way?

It's a different thread, and not relevant to Emacs at all, since I
don't contest your assertion that it is (part of) the basis for
decision.

 > > Effectively discouraging non-free software is out of our control.
 > > "Mr. Quixote, meet Mr. Windmill...."
 > 
 > It is not.  There are few non-free extensions to Emacs, at least that I
 > have heard of.

There are about a dozen of them that I've heard of (not illegal
because they are extensions to XEmacs used only internally to
corporations, the largest of which has about 500 users of the
corporate XEmacs), and there may be a few more when XEmacs converts to
GPLv3 (because some currently free extensions contain GPLv2-only code,
it will no longer be legal to distribute them).

 > With a binary module loader, there might well be more.

With a binary module loader, we might be able to develop them faster
and head off the proprietary versions---there might well be less.

 > >  > I gladly accept the freedom guaranteed by professional soldiers.
 > >  > Just as those soldiers protect those "who don't give a damn", I feel
 > >  > we should protect the (software) freedom of those who, for whatever
 > >  > reason, wouldn't protect their own.
 > 
 > > At the cost of the freedom of those who would *like* to use unfree
 > > software: they have done the calculation on the costs of lock-in, and
 > > like the answers they got.
 > 
 > Yes, this is down in the irony and contradictions department of free
 > software.  But as you've noted, the lock-in is largely
 > psychological:

Who's ignoring 6 billion people now?  Nothing in the GPL creates
lock-in, no, but 99.9999% of humanity doesn't have the skills!  So
they are locked in unless the market provides for them.

IMO, the free software distribution model offers very little to those
people in the way of hope that their needs will be met.  Jury's still
out, but I don't know any office-type users who prefer a working
Ubuntu to a working Windows.  Windows has more of the apps they want.
Some still choose the reliability etc of a GNU/Linux distro, but
they're painfully aware of being behind the curve in most application
areas.

Re: Release plans

[Alan Mackenzie]

Hi, Stephen,

On Wed, Aug 27, 2008 at 02:38:24PM +0900, Stephen J. Turnbull wrote:
> Alan Mackenzie writes:

>  > >  > Yes, we want software to be free, but no, we don't want people
>  > >  > to use this freedom in certain ways, ways which would inhibit
>  > >  > the progress of free software.

>  > > I'm not sure I agree with this formulation, but it's not what I'm
>  > > talking about in this thread.

>  > I think it is.  I think it's the abstract principle behind RMS's decision
>  > not to put a binary module loader in Emacs.

> Please don't tell me what I'm talking about.

Hey, I'm allowed to think, amn't I?  :-)

> Let me clarify: I don't mean to disagree that it's the abstract
> principle behind the decision, so it's not what I'm talking about.

>  > If you don't like my formulation, how about reformulating it your own
>  > way?

> It's a different thread, and not relevant to Emacs at all, since I
> don't contest your assertion that it is (part of) the basis for
> decision.

OK, thanks.

> There are about a dozen of them [non-free Emacs extensions] that I've
> heard of (not illegal because they are extensions to XEmacs used only
> internally to corporations, the largest of which has about 500 users of
> the corporate XEmacs), and there may be a few more when XEmacs converts
> to GPLv3 (because some currently free extensions contain GPLv2-only
> code, it will no longer be legal to distribute them).

"When" XEmacs -> GPL3?  I take it you've settled this, then.  By the way,
is there any way in the XEmacs website to get the history of individual
source files?  I couldn't find any when I looked today.

>  > With a binary module loader, there might well be more [non-free
>  > extensions to Emacs].

> With a binary module loader, we might be able to develop them faster
> and head off the proprietary versions---there might well be less.

Possibly.  But there's no way to test this safely.  It's got to be judged
by insight and guesswork.

[ .... ]

> Who's ignoring 6 billion people now?  Nothing in the GPL creates
> lock-in, no, but 99.9999% of humanity doesn't have the skills!  So
> they are locked in unless the market provides for them.

Look, Stephen, I've probably given you the impression over my last few
posts that I was merely winding you up, trolling you.  If so, I'm sorry
about that; everything I've written was sincerely meant.

However, I can't myself guarantee to be consistent in these essentially
contradictory things.  In fact, I'm as confused about them as most
people here, and that has probably shown.

Whom I take issue with is the people here who've insisted that the
immediate practical benefits of a dynamic loader are the only issues to
consider.  I don't feel qualified to judge the pros and cons of this
feature, but I do feel I'm ahead of those who don't even see there's
anything to judge.  No, not you!

And I take very grave exception to those who cast snide and unfounded
aspersions of evasiveness and deceit on the people who've put the work
in.  This isn't you either, but they know who they are.

> IMO, the free software distribution model offers very little to those
> people in the way of hope that their needs will be met.  Jury's still
> out, but I don't know any office-type users who prefer a working Ubuntu
> to a working Windows.  Windows has more of the apps they want.  Some
> still choose the reliability etc of a GNU/Linux distro, but they're
> painfully aware of being behind the curve in most application areas.

Yes.  Sadly.  At the moment.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Lennart Borgman (gmail)]

Alan Mackenzie wrote:
>> IMO, the free software distribution model offers very little to those
>> people in the way of hope that their needs will be met.  Jury's still
>> out, but I don't know any office-type users who prefer a working Ubuntu
>> to a working Windows.  Windows has more of the apps they want.  Some
>> still choose the reliability etc of a GNU/Linux distro, but they're
>> painfully aware of being behind the curve in most application areas.
> 
> Yes.  Sadly.  At the moment.

My impression is also that a consistent user interface matters a lot
because it makes it much easier to learn a new application.

Re: Release plans

[Sean Sieger]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

    My impression is also that a consistent user interface matters a lot
    because it makes it much easier to learn a new application.

Forgive me if I have misread your comment as comparative, but if I am on
the right track, the user interfaces of say Ubuntu GNU/Linux and its
office suite are no less consistent than those of Microsoft Windows XP
and its office suite---not in my limited experience.

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Hey, I'm allowed to think, amn't I?  :-)

Of course, but when it comes to what I'm talking about, please think
what I tell you to.[1]  :-)

 > "When" XEmacs -> GPL3?  I take it you've settled this, then.

We really don't have much choice, since most Lisp is maintained by
third parties, and Emacs is just 'nano' on steroids without all the
Lisp.  We've got some legal i's to dot and t's to cross, and we need
to think about how to deal with backward compatibility, which we care
about even though GNU does not.  But it's definitely coming.

 > By the way, is there any way in the XEmacs website to get the
 > history of individual source files?  I couldn't find any when I
 > looked today.

Not at the website per se, but there's ViewCVS at
http://cvs.xemacs.org/ for the packages and 21.4, and there's probably
a Mercurial equivalent at http://hg.debian.org/xemacs/ for 21.5.

 > > With a binary module loader, we might be able to develop them faster
 > > and head off the proprietary versions---there might well be less.
 > 
 > Possibly.  But there's no way to test this safely.  It's got to be judged
 > by insight and guesswork.

I disagree.  Watch XEmacs and SXEmacs.  The flag-carrying battleship
is safe, but there are a few cruisers out there engaged with the
opponent.

 > > Who's ignoring 6 billion people now?  Nothing in the GPL creates
 > > lock-in, no, but 99.9999% of humanity doesn't have the skills!  So
 > > they are locked in unless the market provides for them.
 > 
 > Look, Stephen, I've probably given you the impression over my last few
 > posts that I was merely winding you up, trolling you.

No, not at all.  And in any case it's surely mutual; at least on my
side there were quite incorrect expectations about what you know, and
have thought carefully about.

 > If so, I'm sorry about that; everything I've written was sincerely
 > meant.

No apology is needed.

 > > IMO, the free software distribution model offers very little to those
 > > people in the way of hope that their needs will be met.  Jury's still
 > > out, but I don't know any office-type users who prefer a working Ubuntu
 > > to a working Windows.  Windows has more of the apps they want.  Some
 > > still choose the reliability etc of a GNU/Linux distro, but they're
 > > painfully aware of being behind the curve in most application areas.
 > 
 > Yes.  Sadly.  At the moment.

Sadly, I think we are now at the point where we need to put a period.
We've come to agreement on the questions, but don't have answers that
satisfy all the relevant decision makers.

Yet.  See ya!

Footnotes: 
[1]  This is a reference to an actual response by a Japanese career
bureaucrat to a question at a press conference.  *I*'m not serious but
I couldn't resist, as I just arrived back here Through the Looking
Glass and am not *not* NOT enjoying the bureaucracy, although the food
is wonderful.

Re: Release plans

[Thien-Thi Nguyen]

() "Stephen J. Turnbull" <stephen@xemacs.org>
() Tue, 26 Aug 2008 13:54:15 +0900

   Some people hate unfree software so much that they impose
   constraints on the use of their software by others, and claim
   that the net result is somehow an increase in freedom when in
   fact there is a clear decrease in options available to users.

This characterization doesn't cleanly apply in this case; i'd like
to point out that the ban on the addition of dynamic loading to
Emacs is not an imposition on all Emacs users, only on those users
who hack Emacs and write to its repo.

All other users are not so constrained.

FWIW, i stand w/ the ban mostly due to personal ineptitude: i
can't imagine (though i've tried) any coroutine that could not be
supervised through a repl to a subprocess.  Moreover, i believe
everything useful moves to a network protocol eventually.  This
includes not just functionality, but methodology.  Now that DVCs
are on the rise, it's no big deal to flourish your Emacs without
having to "write to its repo".

thi

Re: Release plans

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Aug 27, 2008 at 05:57:14PM +0200, Thien-Thi Nguyen wrote:

[...]

> FWIW, i stand w/ the ban mostly due to personal ineptitude: i
> can't imagine (though i've tried) any coroutine that could not be
> supervised through a repl to a subprocess [...]

Just to tickle your imagination: envision an Emacs with a proper FFI:
browse (interactively) the entry points of a shared object (say,for
example libsndfile) and call them (interactively) from the repl...

Of course, you always can interpose gdb ;-)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFItZ3oBcgs9XrR2kYRApaBAJ9rSwhwGeXzidrziubE54g0kgoV0QCfY3Jr
AfdPAROvG367fIG3x3EP3dE=
=Jmmi
-----END PGP SIGNATURE-----

Re: Release plans

[Stephen J. Turnbull]

tomas@tuxteam.de writes:

 > Just to tickle your imagination: envision an Emacs with a proper FFI:
 > browse (interactively) the entry points of a shared object (say,for
 > example libsndfile) and call them (interactively) from the repl...

Don't imagine it.  Look at it:  http://www.sxemacs.org/.

Re: Release plans

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 28, 2008 at 03:09:17PM +0900, Stephen J. Turnbull wrote:
> tomas@tuxteam.de writes:
> 
>  > Just to tickle your imagination: envision an Emacs with a proper FFI:
[...]
> Don't imagine it.  Look at it:  http://www.sxemacs.org/.

Thanks for the pointer.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFItl5iBcgs9XrR2kYRAkgYAJ90AHRxXZpIbHDS0G1PwYPhyc1EGgCfbhjC
nN1KTB7mS+P4QN4yCYyZaFw=
=+VOl
-----END PGP SIGNATURE-----

Re: Release plans

[Alan Mackenzie]

Good morning, Tomás!

On Wed, Aug 27, 2008 at 08:33:12PM +0200, tomas@tuxteam.de wrote:
> On Wed, Aug 27, 2008 at 05:57:14PM +0200, Thien-Thi Nguyen wrote:

> [...]

> > FWIW, i stand w/ the ban mostly due to personal ineptitude: i
> > can't imagine (though i've tried) any coroutine that could not be
> > supervised through a repl to a subprocess [...]

> Just to tickle your imagination: envision an Emacs with a proper FFI:
> browse (interactively) the entry points of a shared object (say,for
> example libsndfile) and call them (interactively) from the repl...

What's an FFI?

> Of course, you always can interpose gdb ;-)

Oh, good!

> Regards
> -- tomás

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Aug 28, 2008 at 07:25:04AM +0000, Alan Mackenzie wrote:
> Good morning, Tomás!

Good morning, Alan

> What's an FFI?

That's jargn for "foreign function interface". It's a natively
implemented dynamic loader (in our hypothetical case it would be
implemented in Emacs Lisp). The nice thing about that is that it's more
hackable -- you don't have to write a C library with your app in mind,
sticking to some protocol (think extending Perl or Python), but you
can attach to any existing library (provided you know its interface,
of course).

Another way to express it would be that the host language (Lisp)
"speaks" the platform's native protocol.

I think the term originates from the Lisp community, but I don't know
for sure.

> > Of course, you always can interpose gdb ;-)
> 
> Oh, good!

Now this would be a fun project (tongue-in-cheek ;-P

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFItmBuBcgs9XrR2kYRAt4lAJ92zxi91rFlH9emKQkEeqKgnBHGFwCfYV/Y
hIuUNRNLM0QgBDkNc1O/7q4=
=TNHO
-----END PGP SIGNATURE-----

Re: Release plans

[Stephen J. Turnbull]

Thien-Thi Nguyen writes:

 > This characterization doesn't cleanly apply in this case; i'd like
 > to point out that the ban on the addition of dynamic loading to
 > Emacs is not an imposition on all Emacs users, only on those users
 > who hack Emacs and write to its repo.

This is sufficiently important that Richard has devoted some thought
and an explicit ban to the problem.  If other users were similarly
problematic, I would suppose that he would have considered adding it
to the GPL, or so.

 > FWIW, i stand w/ the ban mostly due to personal ineptitude: i
 > can't imagine (though i've tried) any coroutine that could not be
 > supervised through a repl to a subprocess.  Moreover, i believe
 > everything useful moves to a network protocol eventually.

Thank you for making this point; it is true in my opinion, too.

However, I think of dynamic loading not as adding more features to
Emacs, but rather pushing features out of Emacs.  The modules I
personally work on at the moment are things like libcurl and neon,
which provide fast, robust access to network protocols, *maintained by
somebody else*.  I've also used them in the past (libcanna) to push
junky, hard-to-maintain, but popular, code out of core.

This strategy has been quite successful for Python.

 > This includes not just functionality, but methodology.  Now that
 > DVCs are on the rise, it's no big deal to flourish your Emacs
 > without having to "write to its repo".

True, but in the GNU Project it is considered anti-social to do that.
That is basically what Lucid did, and look at what that led to.

Re: Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
> Alan Mackenzie writes:
>
>  > The analysis from you and Tom falls short of mathematical perfection.
>  > Unless I'm mistaken, it focusses purely on the effects it would have on
>  > knowledgeable automous hackers.
>
> I don't speak for Tom, but my analysis falls short of perfection.  As
> I say, you should apply such standard to yourself, as well.
>   

My analysis falls short of perfection as well, but by the
perfect amount, of course.

Seriously, Alan is being kind of read-only here.   Nothing
I've said limits attention to only the "effects [...] on
knowledgeable [autonomous] hackers."




>  > You and T regard only the freedom of the informed automous hacker
>  > as important.
>
> I am very offended.  I could not have imagined that you would stoop so
> low.
>   

Moreover, neither of us has written anything that suggests
we even consider "informed autonomous hackers" as a special
case.




>  > I don't think you see the point I'm making, and your analysis is
>  > oblivious to that point, so I disregard it.  Maybe.
>
> No.  I understand your point.  "Introducing a module loader could
> cause Emacs to become non-free."  That's scary.
>
> In the light of day, though, I don't believe it's going to happen.
>   

For the record, where Stephen and I take different tacks is
that Stephen argues that scary outcome is improbable.   I don't
bother (since it ultimately is just speculation).   Rather, I'm willing
to assume (without proof, and although I believe it unlikely) that
non-free add-ons will appear and be popular.    That is still no
argument against the feature, which ought to be judged by what
*free software* it can give rise to.


>  > Tom, in his reply, simply failed to address this central issue of
>  > my post.  An apology, please.
>
> I'm not in a position to apologize on behalf of Tom.  
I repeatedly stipulated that, sure, let's assume the "worst case"
outcome is certain (although we don't have any good reason to
believe that, really).


>  > Up to now, you and Tom have been asserting that calling external binaries
>  > is critically important and very useful.
>
> No, I haven't. 

I've said that it can be, if well designed.   I like some of the
use ideas Stephen is putting forward.  

Other use ideas: 

Link in a DOM library and add new lisp types for
that.

Link in database clients (MySQL?,  DB XML, Exist, etc.).

Link in incremental parsers for various programming languages
(for syntax directed editing modes).

Link in various scripting language interpreters.

etc.

It could well be that GNU Emacs is essentially moribund
no matter what is done (dynamic loader or no).  I certainly
can't predict with certainty that a dynamic loader would
be used or for what.   On general principles and by analogy
to the history of other systems (e.g., Apache), dynamic loaders
do get used, in clever ways, and help turn a lot of separate
programs into a recombinant toolkit of components.   Meanwhile,
they don't complicate the internals of a program very much
at all and are easy to maintain.

The biggest drawbacks to them are:

a) It complicates bug report handling to have to always
ask "What versions of which add-ons did you have loaded?"

b) Creating a stable, portable, useful API requires some
thought and doing a poor job of it is probably worse than
not doing the job at all.

-t






>  I've simply said I don't see enough risk, even given
> the nightmarish consequences you envision, to outweigh the benefits I
> see.
>
>
>
>
>   

Re: Release plans

[Richard M. Stallman]

      I grant the
    conceptual possibility that you assert, but I deny its importance.  I
    claim it is both extremely unlikely to come to pass, and that we can
    deal with the process of it arising in other ways.

No one can tell for certain.  The only relevant fact is that the problem
scenario did indeed occur for Linux.  Whether it would happen with
Emacs, none of us can determine.  I have decided not to take the risk.

Re: Release plans

[Stephen J. Turnbull]

Richard M. Stallman writes:

 >     I grant the conceptual possibility that you assert, but I deny
 >     its importance.  I claim it is both extremely unlikely to come
 >     to pass, and that we can deal with the process of it arising in
 >     other ways.

 > No one can tell for certain.  The only relevant fact is that the problem
 > scenario did indeed occur for Linux.

Linus invited binary modules, and eventually found it was a bad
thing.  You would not make that mistake; I don't think the
scenarios are the same.

 > Whether it would happen with Emacs, none of us can determine.

That is true.

 > I have decided not to take the risk.

That's a shame for Emacs, and for the free software community, in my
opinion.

Re: Release plans

[Richard M. Stallman]

      Similarly, any damage to my freedom that is
    threatened by a proprietary module can be avoided by not using it.

Not everyone will make the decision not to use it.
Depending on how convenient it is, lots of people might use it.
That would be a big change for the worse.

I have responded in order to explain my decision, but if you hope to
convince me to change my decision, you are going about it all wrong.
You cannot win me over by attacking or playing to an audience.

Re: Release plans

[Paul R]

Hello Richard,

On Tue, 19 Aug 2008 08:21:43 -0400, "Richard M. Stallman" <rms@gnu.org> said:
RMS> Not everyone will make the decision not to use it. Depending on
RMS> how convenient it is, lots of people might use it. That would be
RMS> a big change for the worse.

And depending on how inconvenient emacs is, lots of people might just
avoid it in favor of a fully-proprietary system.

OTOH, depending on how convenient the solution libre is, lots of
people might start using it.

You can read every figures concerning the recent rise of popularity
and usage of free software to the mass. The fact is that more and more
people are now liberated from the proprietary world by using free
software. Do you think it is because they suddently realized that
proprietary software was unethical ? I don't think so. They just
realized how much more convenient it was for them to use free
software.

I totally agree with you how sad it is, but Firefox, OpenOffice and
Ubuntu bring free software to many people, while GNUEmacs or gNewSense
can't really help to spread the word.

Ultimatly, you can't prevent other vendors to provide proprietary
solutions, so I think such a technical retriction to emacs will
only penalize emacs users (and more generaly free software users).

-- 
  Paul

Re: Release plans

[Richard M. Stallman]

    And depending on how inconvenient emacs is, lots of people might just
    avoid it in favor of a fully-proprietary system.

I think you are exaggerating, but it might happen sometimes.
But that would not alter the issue, unless it happens a lot.
We will not extend toleration to proprietary software
just to gain a little popularity.

     Do you think it is because they suddently realized that
    proprietary software was unethical ? I don't think so. They just
    realized how much more convenient it was for them to use free
    software.

Yes -- and unless we teach them to care about their freedom,
it won't be secure.  That is why we don't just compete with
proprietary software.  We fight against it.  We tell  the
public that proprietary software is evil, and our actions reflect
our principles.

Many users of free software do not share these basic ideas,
and want us to change the policies which follow from these ideas.
We never listen to them.

Re: Release plans

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

Alan Mackenzie wrote:
>  You aren't
> considering the effect on everybody else.
>   

That is the main thing that I *am* considering.


> The ability to link binary libraries into Emacs means the ability to link
> non-free binaries in (think Linux modules here), possibly with _very_
> useful functionality, whose inclusion could screw up Emacs's freedom in a
> significant way.  Five years from now, lots of people could be "freely"
> chosing this "non-free" version.  This would be damaging to the aims of
> the FSF.
>   

It is defeatism if you think that Emacs maintainers can't easily hack their
way out of such a situation or even if you think that that's a likely 
outcome.

 

> Now I'm not saying this is an overwhelming argument. 


I'm saying it's completely underwhelming.


>  I'm saying that
> it must be weighed and balanced against the (substantial) benefits of
> binary libraries.  Just as individual people's freedom to own guns must
> be weighed against the right of the community not to have its members
> shot.
>   

Stephen said it a different way.  I said it already.   There is no
"must be weighed and balanced" here.  Yes, that's what RMS would
have us believe -- that it is a judgment call and one that has to be
made centrally and who better to make it....

I argued that no judgment call is needed.   By generic reasoning --
just general common sense principles -- that feature X enables
non-free hacks is neutral: never an argument against feature X.  
That feature X enables many free software hacks is an argument
for X.

RMS has been exercising an authority for which there is no need
in deciding these "hard" cases.



> My opinion on allowing binary libraries into Emacs is that its dangers
> would be greater than the benefits it would allow.  I'm willing to be
> persuaded I'm mistaken.
>   

How did you become persuaded of the supposed "dangers" in the
first place?



> You should address this, instead of evading it as you have done up to
> now.
>
>   

Stephen's reply answered that bit well.

-t



>> -t
>>     
>
>   


[-- Attachment #2: Type: text/html, Size: 3266 bytes --]

Re: Release plans

[Alan Mackenzie]

Morning, Thomas!

On Sat, Aug 16, 2008 at 07:37:24PM -0700, Thomas Lord wrote:
> Alan Mackenzie wrote:
> > You aren't considering the effect on everybody else.

> That is the main thing that I *am* considering.

Not in its full compass.

> >The ability to link binary libraries into Emacs means the ability to link
> >non-free binaries in (think Linux modules here), possibly with _very_
> >useful functionality, whose inclusion could screw up Emacs's freedom in a
> >significant way.  Five years from now, lots of people could be "freely"
> >chosing this "non-free" version.  This would be damaging to the aims of
> >the FSF.

> It is defeatism if you think that Emacs maintainers can't easily hack
> their way out of such a situation or even if you think that that's a
> likely outcome.

"Defeatism".  That's a sort of ad hominem, which seems intended to
deflect from analysing whether something's true or not.  And no, it's
not defeatism.  We can hack our way out of software problems fairly
easily, that's what we do.  But you're kidding yourself in the extreme
if you think you can just hack your way out of a legal problem, or a
social problem.

> >Now I'm not saying this is an overwhelming argument. 

> I'm saying it's completely underwhelming.

Yes, but you're doing it by shouting loudly, disparaging people by
calling them "defeatists", and evading others' arguments rather than
facing them head on.  My last post was an attempt to get you to analyse
these arguments.

> > I'm saying that it must be weighed and balanced against the
> > (substantial) benefits of binary libraries.  Just as individual
> > people's freedom to own guns must be weighed against the right of
> > the community not to have its members shot.

> Stephen said it a different way.  I said it already.   There is no
> "must be weighed and balanced" here.  Yes, that's what RMS would
> have us believe -- that it is a judgment call and one that has to be
> made centrally and who better to make it....

RMS is battle hardened with bitter experience behind him.  He's possibly
the only one of us with any useful feel for legalities.  There is nobody
better to make the final judgement.

> I argued that no judgment call is needed.   By generic reasoning --
> just general common sense principles -- that feature X enables
> non-free hacks is neutral: never an argument against feature X.  That
> feature X enables many free software hacks is an argument for X.

I've heard your argument and I accept it as far as it goes, but it
doesn't go far enough.  You're oblivious to some of the wider issues -
responding to these with words like "defeatism" isn't useful discussion.

> >My opinion on allowing binary libraries into Emacs is that its
> >dangers would be greater than the benefits it would allow.  I'm
> >willing to be persuaded I'm mistaken.

> How did you become persuaded of the supposed "dangers" in the first
> place?

By carefully paying attention to what people have been saying and
thinking about it.

> >You should address this, instead of evading it as you have done up to
> >now.

> Stephen's reply answered that bit well.

No, _YOU_ should address this.  Show, by careful discussion, that you
have understood what is being said, and give quality argument against
it.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Thomas Lord]

Alan Mackenzie wrote:

 > The ability to link binary libraries into Emacs means the
 > ability to link non-free binaries in (think Linux modules
 > here), possibly with _very_ useful functionality, whose
 > inclusion could screw up Emacs's freedom in a significant way.
 > Five years from now, lots of people could be "freely" chosing
 > this "non-free" version.  This would be damaging to the aims
 > of the FSF.


Lots of things might happen in the future.




 >> It is defeatism if you think that Emacs maintainers can't
 >> easily hack their way out of [popular, non-free Emacs
 >> add-ons] or even if you think that that's a likely outcome.

 > "Defeatism".  That's a sort of ad hominem,

No, it is not.

"Defeatism" means a mode of strategic or tactical reasoning in
which it is assumed that the only choices are between various
losses.  The assumption in the dynamic loading decision is that
either GNU Emacs loses by not having a dynamic loader, or GNU
Emacs loses by having non-free, C-level add-ons catch on.
Defeatism is a kind of "planning to lose" and if defeatism is
the only reasoning applied then it is self-fulfilling: loss of
some kind is assured.



 > which seems intended to deflect from analysing whether
 > something's true or not.

In contrast, THAT is an ad hominem.

You see, you ascribed intent ("intended") to the speaker.  In
particular, you ascribed malicious intent ("deflect").  And you
used this to argue against what the speaker was saying.

THAT is an ad hominem attack.


 >  And no, it's not defeatism.  We can hack our way out of
 > software problems fairly easily, that's what we do.  But
 > you're kidding yourself in the extreme if you think you can
 > just hack your way out of a legal problem, or a social
 > problem.

I'm afraid I get a bit lost in the theoretical abstractions of
possible future legal and social problems.  Here is what I see:

A dynamic loader *might* lead to non-free, C-level add-ons.

A dynamic loader *might* then lead to non-free add-ons that
become very popular.

A dynamic loader (well designed) *will* lead to opportunities to
write valuable free software C-level add-ons.  Therefore it
*might* lead to free software add-ons being written and some of
those *might* become very popular.

Conversely, no dynamic loader means no add-ons, either free or
non-free.  No dynamic loader means *certainty* that GNU will not
enjoy the benefits of having a dynamic loader in Emacs.  No
dynamic loader means *certainty* that no non-free add-ons will
be created.

If the free and non-free software worlds are regarded as
opposing armies, the GNU army's choice is to either inflict a
loss on both sides (no dynamic loader -- the defeatist strategy)
or afford both sides a possible win (possible free and non-free
add-ons).

I happen to believe that there is *power* in freedom.  If both
the free and non-free army is given the chance to create
add-ons, the free army (if it plays intelligently) can obtain
more benefit from the opportunity in the long run.  The same
advantage, offered to both sides, is worth more to the free
side.



 >> I'm saying it's completely underwhelming.

 > Yes, but you're doing it by shouting loudly, disparaging
 > people by calling them "defeatists",


Actually, you made that up.  You falsely accused me of making an
ad hominem attack.  You then made an ad hominem attack against
me.  Now, here, you are making another ad hominem attack against
me.



 > and evading others' arguments rather than facing them head on.
 > My last post was an attempt to get you to analyse these
 > arguments.

I did and concluded that they are defeatist arguments.  See
above.


 >> Stephen said it a different way.  I said it already.  There
 >> is no "must be weighed and balanced" here.  Yes, that's what
 >> RMS would have us believe -- that it is a judgment call and
 >> one that has to be made centrally and who better to make
 >> it....

 > RMS is battle hardened with bitter experience behind him.
 > He's possibly the only one of us with any useful feel for
 > legalities.  There is nobody better to make the final
 > judgement.

Why is any "final judgement" needed over this question?

It's only a judgment call *if* you believe that the consequence
of non-free add-ons can possibly be reason enough to avoid a
feature.  If you reject that defeatism, then no judgment (of
that sort) is needed here: the question of whether or not to
have a dynamic loader in GNU Emacs can hinge entirely and
appropriately on its utility to free software developers and
users.


 > I've heard your argument and I accept it as far as it goes,
 > but it doesn't go far enough.  You're oblivious to some of the
 > wider issues - responding to these with words like "defeatism"
 > isn't useful discussion.

The "wider issues" (the purported social consequences, the
chances that GNU Emacs will get effectively 'taken over' by
non-free add-ons, etc) are beyond analysis.  Nobody knows what
will really happen.  There's a lot of hot air going around on
those wider issues but I don't think it adds up to much.

We know with absolute certainty, though, that adding a dynamic
loading feature to GNU Emacs will let people write and share
free software add-ons to GNU Emacs.  All else being equal, I
think it is safe to call that outcome a "win" for software
freedom.

We can assume, with absolute conservatism, that non-free add-ons
*will* result and *will* become popular.  No reason to believe
it but let's assume it.  Let's assume the worst case imagined.  What then?

Short answer: "We'll have to think of something."

Longer answer: We'll have to think of something but we'll also
be in an enriched circumstance.  We'll be enriched because we
have the option to write free software GNU Emacs add-ons.  We'll
be enriched because we didn't waste time arguing against a
feature with defeatist reasoning.

As a rule of thumb, we shouldn't inflict losses on ourselves
(such as not having a dynamic loader) unless there is very
clearly no other choice.  Otherwise, we should always hack *as
if we are certainly going to win software freedom for everyone*.

Assuming we will win software freedom for everyone, the question
of whether or not to add a dynamic loader is a question of:
"Will the free users of GNU systems, and the free developers of
GNU systems, benefit from the feature?"  (The answer to that one
seems a no-brainer!)



 >> How did you become persuaded of the supposed "dangers" in the
 >> first place?

 > By carefully paying attention to what people have been saying
 > and thinking about it.


 From "Elephant Talk" (King Crimson)

  Talk, its only talk
  Arguments, agreements, advice, answers,
  Articulate announcements
  Its only talk

  Talk, its only talk
  Babble, burble, banter, bicker bicker bicker
  Brouhaha, boulderdash, ballyhoo
  Its only talk
  Back talk

  Talk talk talk, its only talk
  Comments, cliches, commentary, controversy
  Chatter, chit-chat, chit-chat, chit-chat,
  Conversation, contradiction, criticism
  Its only talk
  Cheap talk

  Talk, talk, its only talk
  Debates, discussions
  These are words with a d this time
  [....]


Ok, I'm not really that nihilist about it but there is a lot of
hot air going around imagining the consequences of a feature
like dynamic loading or imagining how Emacs influences Windows
users or imagining how a "typical worker" can influence his
workplace to switch away from windows or......  Enough Already!
Too much "making stuff up" and guesswork.   I'm sure everyone's
contributions are not *random* -- there is some relation to reality there --
but collectively the discussion is just aimless, hopelessly abstract,
way to hypothetical, and so doomed to go in tiny circles.

That hot air is mostly very elaborate fantasizing and it has
been going on for 20 years.  Meanwhile, we have 20 years of
actual history to compare to it.  For all of GNU's efforts to
discourage the development of proprietary software one of our
largest economic achievements has been contributions to the
GNU/Linux platform that was a key catalyst to two dot com
bubbles and an explosion of companies developing non-free
software to run on the GNU/Linux platform.  To be sure, nobody
wrote a non-free front-end to GCC using the (banned) tree
print/read functionality.  Nobody wrote a non-free C-level
add-on to GNU Emacs using the (banned) dynamic loading facility.
Yet, those tools and the shell tools are the glue that binds the
main components of the LAMP stack: one of the largest growth
platforms for proprietary software in years and years.

The way to defeat non-free software in the market is to hone the
corpus of available free software so that, when developing new
software and new software products, it is always "faster,
cheaper, better, and profitable" to develop new programs as free
software programs.  Everytime we "ban" a feature from the GNU
system because of a defeatist perception of risk, we retreat
from the goal of making it economically natural to write new
programs as free software programs.  That is, we retreat from the
goal of software freedom for everyone.


-t

Re: Release plans

[Alan Mackenzie]

On Sun, Aug 17, 2008 at 10:42:28AM -0700, Thomas Lord wrote:
> Alan Mackenzie wrote:

> > The ability to link binary libraries into Emacs means the
> > ability to link non-free binaries in (think Linux modules
> > here), possibly with _very_ useful functionality, whose
> > inclusion could screw up Emacs's freedom in a significant way.
> > Five years from now, lots of people could be "freely" chosing
> > this "non-free" version.  This would be damaging to the aims
> > of the FSF.

> Lots of things might happen in the future.

Now you're playing verbal games with me.  <sigh>

> >> It is defeatism if you think that Emacs maintainers can't
> >> easily hack their way out of [popular, non-free Emacs
> >> add-ons] or even if you think that that's a likely outcome.

> > "Defeatism".  That's a sort of ad hominem,

> No, it is not.

No, of course not.  It's one of those handy little words which can always
be defended as rational and objective, yet at the same time give a very
good impression of an ad hominem attack and have the same effect.  It can
be used to appear to be exceptionally rude, yet without exposing the
writer to general censure.  Except, of course, you're not being rude
here, you're just being objective and rational, which is very reassuring.

> "Defeatism" means a mode of strategic or tactical reasoning in which it
> is assumed that the only choices are between various losses.  The
> assumption in the dynamic loading decision is that either GNU Emacs
> loses by not having a dynamic loader, or GNU Emacs loses by having
> non-free, C-level add-ons catch on.  Defeatism is a kind of "planning
> to lose" and if defeatism is the only reasoning applied then it is
> self-fulfilling: loss of some kind is assured.

"Defeat" is utter loss; it's when your king is in checkmate, when when
the whistle blows after 90 minutes your opponents have scored more goals,
when the enemy troups have routed your army and destroyed your strategy
to the point where the only sensible action is to surrender.

The inability to use dynamically loaded binaries in Emacs is like none of
these things.  It's an inconvenience, possibly minor, possibly major.
But it is _nothing_ like the utter rout implied by the word "defeatism".

> > which seems intended to deflect from analysing whether something's
> > true or not.

> In contrast, THAT is an ad hominem.

Of course it is.  You were just being rational and objective.  Thanks for
clarifying that.  My apologies.

> >  And no, it's not defeatism.  We can hack our way out of software
> >  problems fairly easily, that's what we do.  But you're kidding
> >  yourself in the extreme if you think you can just hack your way out
> >  of a legal problem, or a social problem.

> I'm afraid I get a bit lost in the theoretical abstractions of
> possible future legal and social problems.

I've noticed this.  That's why I'm trying to help you visualise these in
a more concrete, more accessible fashion.

> Here is what I see:

> A dynamic loader *might* lead to non-free, C-level add-ons.

> A dynamic loader *might* then lead to non-free add-ons that
> become very popular.

> A dynamic loader (well designed) *will* lead to opportunities to
> write valuable free software C-level add-ons.  Therefore it
> *might* lead to free software add-ons being written and some of
> those *might* become very popular.

> Conversely, no dynamic loader means no add-ons, either free or
> non-free.  No dynamic loader means *certainty* that GNU will not
> enjoy the benefits of having a dynamic loader in Emacs.  No
> dynamic loader means *certainty* that no non-free add-ons will
> be created.

Here is what you don't see, or at least refuse to consider: a non-free
add-on which becomes popular could be used maliciously to remove freedom
from Emacs.  Seen through your spectacles, every user is free to chose to
use that add-on or not, so there's no problem.  I'm making one last
effort in the post to help you see where you are wrong (see below).  If
this doesn't help, there's no sense in continuing the conversation.

> If the free and non-free software worlds are regarded as opposing
> armies, the GNU army's choice is to either inflict a loss on both sides
> (no dynamic loader -- the defeatist strategy) or afford both sides a
> possible win (possible free and non-free add-ons).

That's a wierd way of looking at things, which I don't agree with either
in detail or in the broad sweep.  The continuing absence of a dynamic
loader does not impose a loss on both "sides", or even any side.  It
merely makes it inconvenient to integrate certain inessential[*]
functionality into Emacs.

[*] inessential = "not composing the essence of", which is not identical
to "unimportant".

> I happen to believe that there is *power* in freedom.  If both the free
> and non-free army is given the chance to create add-ons, the free army
> (if it plays intelligently) can obtain more benefit from the
> opportunity in the long run.  The same advantage, offered to both
> sides, is worth more to the free side.

I don't think you understand power and its mechanisms, such as dominance,
deceit, lies, disinformation, demagoguery, deviousness, blackmail,
ridicule, manipulation, .... at all.  Richard most assuredly does, which
is why I am happy to trust his judgement on this matter.

[ .... ]

> > RMS is battle hardened with bitter experience behind him.  He's
> > possibly the only one of us with any useful feel for legalities.
> > There is nobody better to make the final judgement.

> Why is any "final judgement" needed over this question?

"Final" as in being the last person in the chain of command, the one who
is finally responsible.  Not "final" as in fixed once and for evermore.

> It's only a judgment call *if* you believe that the consequence of
> non-free add-ons can possibly be reason enough to avoid a feature.

I do believe this, so does Richard, and I expect a lot of other people do
too.

[ .... ]

> We can assume, with absolute conservatism, that non-free add-ons *will*
> result and *will* become popular.  No reason to believe it but let's
> assume it.  Let's assume the worst case imagined.  What then?

> Short answer: "We'll have to think of something."

Maybe that's how the Trojan leader fielded the misgivings of his
underlings as they were dragging the magically materialised horse through
their city walls.

> Longer answer: We'll have to think of something but we'll also be in an
> enriched circumstance.  We'll be enriched because we have the option to
> write free software GNU Emacs add-ons.  We'll be enriched because we
> didn't waste time arguing against a feature with defeatist reasoning.

What don't you understand about this:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;;  microsoft8.dll
;;
;;  Copyright (C) Microsoft, 2013.
;;
;;  This binary library extends Emacs, giving it transparent access to all
;;  directories and files in the .NYET environment, together with convenient
;;  access from Emacs to your Email, calendar, etc.
;;
;;  To protect the security of your .NYET system, this library also guards
;;  against malware by only allowing digitally signed LISP or binary libraries
;;  to be compiled or loaded.  All libraries you may need to run Emacs have
;;  been duly signed.
;;
;;  microsoft8.dll MUST be loaded before any other Emacs extensions.  The
;;  system administrator is recommended to load this library at the top of his
;;  site's site-start.el file.
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

?  Nobody is forced to load this library.  But I hope you can see now
that it would be a big problem nonetheless.

> -t

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Release plans

[Johannes Weiner]

Hi,

Alan Mackenzie <acm@muc.de> writes:
> What don't you understand about this:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;
> ;;  microsoft8.dll
> ;;
> ;;  Copyright (C) Microsoft, 2013.
> ;;
> ;;  This binary library extends Emacs, giving it transparent access to all
> ;;  directories and files in the .NYET environment, together with convenient
> ;;  access from Emacs to your Email, calendar, etc.
> ;;
> ;;  To protect the security of your .NYET system, this library also guards
> ;;  against malware by only allowing digitally signed LISP or binary libraries
> ;;  to be compiled or loaded.  All libraries you may need to run Emacs have
> ;;  been duly signed.
> ;;
> ;;  microsoft8.dll MUST be loaded before any other Emacs extensions.  The
> ;;  system administrator is recommended to load this library at the top of his
> ;;  site's site-start.el file.
> ;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> ?  Nobody is forced to load this library.  But I hope you can see now
> that it would be a big problem nonetheless.

register_gpl3_module ();

Now, how long do you think does it take to have the restrictions patched
out?

If this mechanism works out, we can stop argueing about personal views.
It will lead to nothing.

	Hannes

Re: Release plans

[Alfred M. Szmidt]

   > ?  Nobody is forced to load this library.  But I hope you can see now
   > that it would be a big problem nonetheless.

   register_gpl3_module ();

   Now, how long do you think does it take to have the restrictions patched
   out?

The elisp libraries where signed, recompiling will give you a
different signature, and .NYET will refuse to load it.

Re: Release plans

[Johannes Weiner]

Hi Alfred,

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    > ?  Nobody is forced to load this library.  But I hope you can see now
>    > that it would be a big problem nonetheless.
>
>    register_gpl3_module ();
>
>    Now, how long do you think does it take to have the restrictions patched
>    out?
>
> The elisp libraries where signed, recompiling will give you a
> different signature, and .NYET will refuse to load it.

Hehe, you already stripped the context I was going to strip to emphasize
my point.  Because the very sentence you just wrote does not depend on
the feature of loading shared objects into emacs, so I don't think this
is a good argument for keeping it out.

	Hannes

Re: Release plans

[Thomas Lord]

[-- Attachment #1: Type: text/plain, Size: 5875 bytes --]

Alan Mackenzie wrote:
> Now you're playing verbal games with me. 
>   

No, I'm not.


> No, of course not. ["Defeatism" is] one of those handy little words which can always
> be defended as rational and objective, yet at the same time give a very
> good impression of an ad hominem attack and have the same effect.  It can
> be used to appear to be exceptionally rude, yet without exposing the
> writer to general censure.  Except, of course, you're not being rude
> here, you're just being objective and rational, which is very reassuring.
>   

If we just use words in simple ways, communication with
near strangers over the Internet can work out.   If we always
look for hidden meanings or sly insults, communication is harder.


>   
>> "Defeatism" means a mode of strategic or tactical reasoning in which it
>> is assumed that the only choices are between various losses.  The
>> assumption in the dynamic loading decision is that either GNU Emacs
>> loses by not having a dynamic loader, or GNU Emacs loses by having
>> non-free, C-level add-ons catch on.  Defeatism is a kind of "planning
>> to lose" and if defeatism is the only reasoning applied then it is
>> self-fulfilling: loss of some kind is assured.
>>     
>
> "Defeat" is utter loss; 

No, it isn't.   You can see that it is not because of the existence
of two cliche phrases:  "defeat at battle" and "utter defeat".
"Defeat" means an "undoing" or a loss.

"Defeatism" is an assumption that loss of one kind or another
is inevitable, then a choice of action aimed to minimize loss.
"Defeatism" is a kind of "null upside investment strategy"
by which I mean that defeatism is the way of spending
to minimize loss, EVEN AT THE EXPENSE of possible
gain.    When lots of people adopt defeatist tactics in the
stock market, that's called a panic.



> it's when your king is in checkmate, when when
> the whistle blows after 90 minutes your opponents have scored more goals,
> when the enemy troups have routed your army and destroyed your strategy
> to the point where the only sensible action is to surrender.
>   

That's mostly in your head.   In a tragic context,
defeatism could refer to an inevitable and utter defeat
like that but the word "defeat" itself has much broader
meaning.



> The inability to use dynamically loaded binaries in Emacs is like none of
> these things.  It's an inconvenience, possibly minor, possibly major.
> But it is _nothing_ like the utter rout implied by the word "defeatism".
>   

I guess the question you are speculating about is how "important"
dynamic loading is.    I don't think either of us really knows but
I can guess too:

I'm really impressed by the roles dynamic loading has played
in the LAMP stack, particularly loading of modules into scripting
languages and loading of modules into Apache and other
web servers.

It makes sense, in retrospect, that it would be such an influential
feature.  It's a kind of combinatorics phenomenon.  If there are
M programs with dynamic loaders, and N dynamically loadable
libraries, then there are M*(2^N) possible run-time environments!
That's very flexible.   And what's more, because of the way
dynamic loading works, ANYONE can increment N without having
to bother any upstream maintainers or have patches accepted -- it's
always possible to add a new library.   The result of a dynamic loader
in the LAMP stack is a super-exponential explosion of possible
configurations of free software components and the the result of
that circumstance is the enormous success of the stack (and the
ongoing development of lots of components that "plug in" to it).

Would dynamic loading in GNU Emacs matter as much?
I'm sure nobody knows and that the answer depends largely
on the design of the dynamic loading mechanism.   Nevertheless,
the potential upside is huge, if the LAMP environment is any
indication.

The *cost* (in labor and other real expenses) of adding dynamic
loading is, I suspect, pretty low.    A crappy job of it should be
basically free.   A very good job of it should still be pretty
"cheap".   So, we're talking about a penny stock:   cheap to add
dynamic loading and a huge potential upside. 



> Here is what you don't see, or at least refuse to consider: a non-free
> add-on which becomes popular could be used maliciously to remove freedom
> from Emacs.  Seen through your spectacles, every user is free to chose to
> use that add-on or not, so there's no problem.  I'm making one last
> effort in the post to help you see where you are wrong (see below).  If
> this doesn't help, there's no sense in continuing the conversation.
>   


Your ".nyet" license?   So, the nightmare scenario is 10s of millions or 
more
of new Emacs users, but all "addicted" to the ".nyet" add-on?

That sounds to me like a battle won for free software.  Not a war won
but a major battle:   The next step is to whittle away at the advantages
of the ".nyet" add-on and then free GNU Emacs has 10s of millions or
more of new users.


> [*] inessential = "not composing the essence of", which is not identical
> to "unimportant".
>   

The combinatorics experience of the LAMP stack with
add-ons suggests that calling a dynamic loader "unimportant"
is at best premature.


>> I happen to believe that there is *power* in freedom.  If both the free
>> and non-free army is given the chance to create add-ons, the free army
>> (if it plays intelligently) can obtain more benefit from the
>> opportunity in the long run.  The same advantage, offered to both
>> sides, is worth more to the free side.
>>     
>
> I don't think you understand power and its mechanisms, such as dominance,
> deceit, lies, disinformation, demagoguery, deviousness, blackmail,
> ridicule, manipulation, .... at all.  Richard most assuredly does, which
> is why I am happy to trust his judgement on this matter.
>   

Uh, you might be surprised.

-t


[-- Attachment #2: Type: text/html, Size: 7502 bytes --]

Re: Release plans

[Richard M. Stallman]

    Here is what you don't see, or at least refuse to consider: a non-free
    add-on which becomes popular could be used maliciously to remove freedom
    from Emacs.  Seen through your spectacles, every user is free to chose to
    use that add-on or not, so there's no problem.

Even if the non-free add on does not go to the malicious lengths
of the microsoft8.dll scenario, it is still a problem for users'
freedom if it becomes popular.

Re: Release plans

[Thien-Thi Nguyen]

() Thomas Lord <lord@emf.net>
() Sun, 17 Aug 2008 10:42:28 -0700

   Everytime we "ban" a feature from the GNU system because of a
   defeatist perception of risk, we retreat from the goal of
   making it economically natural to write new programs as free
   software programs.  That is, we retreat from the goal of
   software freedom for everyone.

Perhaps you are right.  Perhaps Emacs is not the proper vehicle.

thi

Re: Release plans

[Richard M. Stallman]

    If the free and non-free software worlds are regarded as
    opposing armies, the GNU army's choice is to either inflict a
    loss on both sides (no dynamic loader -- the defeatist strategy)
    or afford both sides a possible win (possible free and non-free
    add-ons).

A win for non-free software is ipso facto a loss for our campaign to
eliminate non-free software.  When the non-free software in question
is an add-on for a free program, it tends to pervert the liberating
nature and message of that free program; that is another kind of loss
for us.  These are the potential kinds of harm that I am concerned to
avert.

Our community develops lots of free software, but which software it
develops is a matter of what many people are inspired to do.
We cannot count on the community to develop a free equivalent
of a nasty Emacs add-on in a short time, not if it is nontrivial.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     If the free and non-free software worlds are regarded as
>     opposing armies, the GNU army's choice is to either inflict a
>     loss on both sides (no dynamic loader -- the defeatist strategy)
>     or afford both sides a possible win (possible free and non-free
>     add-ons).
>
> A win for non-free software is ipso facto a loss for our campaign to
> eliminate non-free software.  When the non-free software in question
> is an add-on for a free program, it tends to pervert the liberating
> nature and message of that free program; that is another kind of loss
> for us.  These are the potential kinds of harm that I am concerned to
> avert.
>
> Our community develops lots of free software, but which software it
> develops is a matter of what many people are inspired to do.
> We cannot count on the community to develop a free equivalent
> of a nasty Emacs add-on in a short time, not if it is nontrivial.
>
>   

I am willing to assume that if a dynamic loader is added
to Emacs that non-free add-ons will follow.  I'll allow that,
yes, that will diminish the "liberating nature and message"
of GNU Emacs regarded as an isolated program.

Nevertheless, there is a bigger fish to fry:

GNU Emacs is not an isolated program.  There are many
free software programs and libraries and GNU Emacs exists
along side those.

If we concentrate on adding features that allow programs to
be flexibly combined, the resulting GNU system will be a
flexible, powerful environment.   Conversely, if we neglect,
ban, or poorly execute such interconnection features, the GNU
system will be be little more than a set of mutually isolated
programs -- either there's a program that does what you need
or there isn't -- there's no way easy way to build the program
you need because even if the parts exist there's no easy way to
fit them together.

A modular GNU system with good interconnects -- a set of
programs and libraries that can be recombined many ways --
would itself have a "liberating nature and message" and one
much more powerful than GNU Emacs taken in isolation.

In trying to protect GNU Emacs in isolation, you are
giving up on the goal of creating a more profound
piece of free software.


-t

Re: Release plans

[René Kyllingstad]

* Richard M. Stallman:
>      If the free and non-free software worlds are regarded as
>      opposing armies, the GNU army's choice is to either inflict a
>      loss on both sides (no dynamic loader -- the defeatist strategy)
>      or afford both sides a possible win (possible free and non-free
>      add-ons).
>  
>  A win for non-free software is ipso facto a loss for our campaign to
>  eliminate non-free software.  When the non-free software in question
>  is an add-on for a free program, it tends to pervert the liberating
>  nature and message of that free program; that is another kind of loss
>  for us.  These are the potential kinds of harm that I am concerned to
>  avert.
>  
>  Our community develops lots of free software, but which software it
>  develops is a matter of what many people are inspired to do.
>  We cannot count on the community to develop a free equivalent
>  of a nasty Emacs add-on in a short time, not if it is nontrivial.

I'd like to get your comment on another side of this:

One problem the free software community is struggling with is
funding. Developing new software is time consuming.  It's made even harder
if a team is not working together in the same building, and only part-time.

If a company would put a lot of effort into creating a non-free Emacs
plug-in, the effort of coming up with the idea and finding out exactly how
it should work would be paid for by them.

Then it's a much easier job for the free software community to organize an
effort to implement the missing parts as free software, since it's clear to
everyone exactly what kind of features are being discussed.

It's hardly a new argument, I just haven't seen anyone acknowledging it in
this thread, and funding of free software is also a topic that interests me
very much.


-- René

Re: Release plans

[Richard M. Stallman]

    If a company would put a lot of effort into creating a non-free Emacs
    plug-in, the effort of coming up with the idea and finding out exactly how
    it should work would be paid for by them.

This is no reason to ogive permission for non-free software.

Re: Release plans

[Richard M. Stallman]

You expressed the issue very clearly.

Re: Release plans

[Richard M. Stallman]

    But it is better to have badly written free software than having well
    written non-free software.  We can fix the former, but not the later.

Exactly.  The idea of the free software movement is that we don't
give up our freedom just to "get a job done".

    Software is written for a purpose.  Windows
    does its job, whether it does it good or bad and whether you like the
    philosophy or not.  It is not free and it solves the problem it was
    written for.

If you define "the job" in purely practical terms, that response
follows logically.  There are users who can get their work done using
Windows.

It does not follow that the existence of Windows is a good thing or that
developing it was ethically acceptable.  Part of valuing freedom is that
you don't consider something a "solution" if it costs you freedom.

Re: Release plans

[Thomas Lord]

Richard M. Stallman wrote:
>     But it is better to have badly written free software than having well
>     written non-free software.  We can fix the former, but not the later.
>
> Exactly.  The idea of the free software movement is that we don't
> give up our freedom just to "get a job done".
>   

Then why was the GNU system bootstrapped on proprietary
systems?   And, aren't you creating a kind of ontological problem
there:  is it truly an increase in freedom to give up capability
in exchange for conditions?

It's a four-by-four decision matrix that people are talking about
in this thread:  poor-v.-good software on one axis, free-v.-proprietary
on the other.   Ranking the four choices is partially easy and
partially always contentious:   good/free trumps all other choices.
Every choice trumps poor/proprietary.   

The problem is that it is hard to compare good/proprietary
to poor/free in some absolute way.  NOT EVEN THE GNU
PROJECT always makes that choice the same way, whether
it was the use of proprietary platforms for bootstrapping or
the invention of LGPL.

The good/proprietary vs. poor/free question is eternal.  It always
invites looking at the larger context and the specifics of particular
situations.   There will never be consensus on it.

The freedom-fighting thing to do, if we place an absolute
value on freedom, is to work to avoid the good/proprietary
vs. poor/free choice: to avoid creating (or resting pat with)
poor/free software.

Let's look at two  cases:  (a) adding dynamic loading
to GNU Emacs;  (b) adding GCC features to dump and
read back the tree format intermediate form.  

Both of those features were historically rejected by the
GNU project on the grounds that they would make it too
easy to create proprietary derivatives of free software
programs.

I think those decisions by GNU were ethically questionable.
Both of them avoided making proprietary derivatives easier
to write but both ALSO pushed the free programs farther
towards "poor" and away from "good".   In other words,
both multiplied the number of times users would be confronted
by a "poor/free vs. good/proprietary" choice.

Those actions by GNU represent defeatism.  They carry an implicit
assumption that free software developers can't compete -- that
"good/free" is a practical impossibility.   A *confident*
GNU project, in contrast, would have noted "Oh, people
will probably use these to make proprietary derivatives.
Shrug.  Doesn't matter: these features will help Emacs and
GCC become very good and, importantly, much more
flexible -- so over time, they will help to deprive proprietary
software authors of any niches left to exploit.  So, do it: put
those features in."

The defeatism we got instead gives rise to an ethically questionable
absolutism:  it is OK, evidently, for the GNU project to
choose to use proprietary software to bootstrap itself but
we are told that if the GNU project no longer has to make
that choice then, therefore, anyone else making that choice
is morally wrong.   Yet, what gives GNU that special
privilege in morality?   If the details of "why compromise"
are circumstantial for GNU then they are circumstantial
for everyone.    Grand pronouncements about absolutely rejecting
proprietary software and just "working harder" smack of
hypocrisy, desperation, condescension,  and messianic
self-righteousness.

Adding to the apparent hypocrisy:  GNU concentrated
for years on the "poor/free is good enough" strategy
and at a certain point the Linux kernel came along and
shortly thereafter the modern GNU/Linux vendors arose.
As a rule, they (a) get the bulk of their money selling
a platform for running proprietary apps;  (b) combine
GNU/Linux with proprietary apps and other materials
to make their products hard to copy.   And, yet, the GNU
project seems to take this as a victory and point to these
vendors and their achievements as evidence of the
success of GNU!

To put it bluntly:   is the real goal here to make the
"good/free" choice widely available and easy to
understand?   or is the real goal to perpetuate the
opportunities to talk about the theoretical desirability
of having a "good/free" choice, someday, maybe?

As I said more succinctly, earlier:  RMS, you spend
a lot of time worrying about what programs to NOT
write.


>     Software is written for a purpose.  Windows
>     does its job, whether it does it good or bad and whether you like the
>     philosophy or not.  It is not free and it solves the problem it was
>     written for.
>
> If you define "the job" in purely practical terms, that response
> follows logically.  There are users who can get their work done using
> Windows.
>
> It does not follow that the existence of Windows is a good thing or that
> developing it was ethically acceptable.  Part of valuing freedom is that
> you don't consider something a "solution" if it costs you freedom.
>   

A fine example.   Please look at the overly abstract, overly
theorized, bordering on hypocrisy claim there:

     "You don't consider something a 'solution'
       if it costs you freedom."

Really?   Ever?

Not even when bootstrapping the GNU project?

How about during recovery operations from a natural
disaster?

How about to be able to afford an apartment and food?

Maybe it depends on the nature of the costs to freedom vs.
the rewards?   Maybe it depends on the circumstances and
the other degrees of freedom they afford?

Let's see... how do those old ethical quiz-game puzzles go?
You see a train speeding down the tracks, heading towards
a fork in the tracks.   On one fork, your loved one has their
foot stuck in the tracks and can't escape in time.  On the
other is a school-bus full of children, stalled -- evacuating
but they won't make it in time.   Your hand is on the
switch and you can send the train one way or the other....
What do you do?

The right answer, of course, is that you go to the administration
office and drop the philosophy course where the question
is posed, signing up for an engineering course instead.
Perhaps you'll figure out how to invent a more efficient
evacuation system for school buses or tracks that people
can't get stuck in so easily.

Persistent, ethically impossible choices are best addressed not
by exhortation towards one or another theory of how to make
them, but by engineering towards avoiding them.   Answers to
the questions about what (free) software to NOT write (in order
to avoid accidentally aiding proprietary software developers)
are not, in my opinion, contributions to the advance of the free
software movement.   The last 15 years or so of GNU history
makes a strong case for me.


-t



>
>
>
>   

Re: Release plans

[Richard M. Stallman]

    Then why was the GNU system bootstrapped on proprietary
    systems?

I thought about this issue and concluded that use of a non-free program
for the specific purpose of developing its free replacement.

You describe defensive measures as "defeatism".  I call it "prudence".
There are other confused and inaccurate assertions as well, but
I'm not going to play your game by responding to each of them.

Re: Release plans

[Alfred M. Szmidt]

Just to note, I wrote the following text:

       But it is better to have badly written free software than
       having well written non-free software.  We can fix the former,
       but not the later.

   Exactly.  The idea of the free software movement is that we don't
   give up our freedom just to "get a job done".

But not this:

       Software is written for a purpose.  Windows
       does its job, whether it does it good or bad and whether you like the
       philosophy or not.  It is not free and it solves the problem it was
       written for.

   If you define "the job" in purely practical terms, that response
   follows logically.  There are users who can get their work done using
   Windows.

   It does not follow that the existence of Windows is a good thing or that
   developing it was ethically acceptable.  Part of valuing freedom is that
   you don't consider something a "solution" if it costs you freedom.

Re: Release plans

[Stefan Monnier]

> Primarily, software is problem-solving.

Maybe that was the case in some distant past.  Nowadays, software runs
the world (quite literally).


        Stefan

Re: Release plans

[Richard M. Stallman]

    Hey, you snipped too much of the context, you rascal!  The effort I was
    talking about was that of a large company, with all the bureaucracy and
    inertia that goes with it.  

I was talking about switching your own computing to GNU/Linux, within
the company, not the bigger task of convincing the whole company to
change.  With that clarified, is my response more understandable?

    Other people and groups are advancing free software by emphasising free
    software's high quality. Yet you don't recognise their efforts as
    legitimate,

You have misunderstood my position.  I do not criticize them for
persuasively citing practical advantages.  If they oppose our efforts
at a deeper level, by endorsing the idea that freedom is not an
important issue, I do criticize that.

Re: Release plans

[Alan Mackenzie]

Hi, Richard!

On Thu, Aug 14, 2008 at 11:41:16PM -0400, Richard M. Stallman wrote:
>     Hey, you snipped too much of the context, you rascal!  The effort I was
>     talking about was that of a large company, with all the bureaucracy and
>     inertia that goes with it.  

> I was talking about switching your own computing to GNU/Linux, within
> the company, not the bigger task of convincing the whole company to
> change.  With that clarified, is my response more understandable?

Yes, indeed it is.  Sorry for the misunderstanding.

OK, to start with, most of my time at work needs access to the company
network, for things like Email (over proprietary protocols), access to
the VCS (often ClearCase (yuck!!)), sometimes "talk" programs,
spreadsheets used for reserving meeting rooms, that kind of thing.

I couldn't put GNU onto my desktop PC in the office, at least not
without being instantly dismissed.  If I were to bring in my own PC and
connect it to the company network, something similar would happen - such
is regarded as a security hazard, quite rightly.  I'm not sure there's
even any clients on GNU which speak the necessary proprietary protocols,
such as for Email.

The nearest I could get would be having my own PC alongside the office
one, exchanging files by USB stick.  How would this be any better, from
a freedom point of view, than running the w32 versions of the software
on the office PC?

>     Other people and groups are advancing free software by emphasising
>     free software's high quality. Yet you don't recognise their
>     efforts as legitimate,

> You have misunderstood my position.  I do not criticize them for
> persuasively citing practical advantages.  If they oppose our efforts
> at a deeper level, by endorsing the idea that freedom is not an
> important issue, I do criticize that.

Your word "endorsing" is one of those flexible, vague, open-ended words
that could mean almost anything.  Do these other people actually
campaign against software freedom?  Do they actually say "freedom is
unimportant", rather than just not mentioning it much?

I think it's more important for people actually to be free than to be
aware of it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [OT] Release plans

[Yavor Doganov]

Alan Mackenzie wrote:
> 
> I couldn't put GNU onto my desktop PC in the office, at least not
> without being instantly dismissed.

This is the price everyone should be prepared to pay, yes.  More than
5 years ago, I told my boss that I refuse to use non-free software at
work, and I was prepared to get fired.  But it didn't happen.
Instead, we migrated to GNU/Linux.

That was a small company (about 10 computers at that time).  I was
doing most of the work, so he faced the dilemma of finding a
replacement (which is pretty hard in our area of business) or honoring
my request.  So we made a deal -- we'll migrate if I guarantee to
support the systems free of charge.  I'm pretty happy with that.
There were many problems (and still are!) with GNU/Linux, but all the
colleagues got accustomed to it, more or less.  A crucial point is
that all of them still don't care for their freedom, so that's not a
success story.

It is a success story for me personally, because I enjoy full software
freedom since then (i.e. not only at home until then).

Of course, if you work in a larger company, or you're not enough
valuable employee, that fortunate scenario is unlikely to happen.  But
if enough people stand up and refuse to use non-free software, there's
a chance.  That is how strikes worked for centuries, basically.

Re: [OT] Release plans

[Miles Bader]

Yavor Doganov <yavor@gnu.org> writes:
> Of course, if you work in a larger company, or you're not enough
> valuable employee, that fortunate scenario is unlikely to happen.  But
> if enough people stand up and refuse to use non-free software, there's
> a chance.  That is how strikes worked for centuries, basically.

Most of my co-workers are very passive about such things, they just use
what everybody else uses, and don't really seem to care.

-Miles

-- 
Cabbage, n. A familiar kitchen-garden vegetable about as large and wise as a
man's head.

Re: [OT] Release plans

[Richard M. Stallman]

    Most of my co-workers are very passive about such things, they just use
    what everybody else uses, and don't really seem to care.

Doing something conspicuous, like bringing in your own PC and
transferring files by USB device, could be just the thing to jar
them out of their somnolence.

Re: Release plans

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > I think it's more important for people actually to be free than to be
 > aware of it.

Freedom is about choice; choice requires awareness of alternatives and
that you are able to choose them.  IMO, you cannot "actually be free"
without being aware of it.

Re: Release plans

[Thomas Lord]

Stephen J. Turnbull wrote:
> Alan Mackenzie writes:
>
>  > I think it's more important for people actually to be free than to be
>  > aware of it.
>
> Freedom is about choice; choice requires awareness of alternatives and
> that you are able to choose them.  IMO, you cannot "actually be free"
> without being aware of it.
>   

That's too simple.

Hopefully one's freedoms are larger in scope than one's awareness  can
fully grasp.   That is, we (hope to be) always more free than we can
ever know -- we always have only partial knowledge of our possible
choices.

Instead, we're free to do anything in the intersection of that those
choices we can *discover* from our current state with those
choices that are physically available to us.

Of course, even the question of "what choices can we *discover*"
doesn't have a static, classical answer.   For example, to discover
choice A might preclude discovering choice B and vice versa --
so, before we see either choice A or B, where are we exactly?
Free to A or free to B but not both in one sense.   In another
sense not free to A or B until we become aware of one or the
other.   Simplistic "rational actor" theories of "freedom" don't
cut it except as approximations.

All this highly abstract ethical theory is a cul de sac:  pretty
to drive around and have a look at but, then to get anywhere
else, you have to leave and find another street.

In a civic context, the question is simpler:  a condition
of liberty is one in which the civil order doesn't impose
an obstacle to a given choice or to discovering that choice.

The conclusion is the same, though, regarding dynamic
loading in GNU Emacs.  The civil order precludes doing
so.  Users are deprived of a freedom that could otherwise
be trivially afforded them by virtue of a deliberate effort
to achieve exactly that effect.



-t





>
>
>   

Re: Release plans

[Richard M. Stallman]

    The nearest I could get would be having my own PC alongside the office
    one, exchanging files by USB stick.  How would this be any better, from
    a freedom point of view, than running the w32 versions of the software
    on the office PC?

It would be MUCH better.  The more you can do on GNU/Linux
and reject Windows, the more of your life will be in freedom.

Also, your doing this would inspire others to think about the issue,
and that could open the door to further steps.  This is exactly the
sort of thing that can influence them to recognize that GNU/Linux is
at least as secure as Windows, move to protocols supported by free
software, and so on.  You should do it!

Re: Release plans

[Richard M. Stallman]

    Your word "endorsing" is one of those flexible, vague, open-ended words
    that could mean almost anything.  Do these other people actually
    campaign against software freedom?  Do they actually say "freedom is
    unimportant", rather than just not mentioning it much?

Many of them do.  Occasionally they directly oppose the ideals of
software freedom; Torvalds has done so.  More often, they do not
explicitly address the issue, but they say things which implicitly
assert that the most important values are powerful, reliable,
convenient software and that non-free software is acceptable.

    I think it's more important for people actually to be free than to be
    aware of it.

What I've learned is that people tend not remain free for long
unless they appreciate freedom and defend it.

re: whither GNU

[Jonathan Yavner]

> Juanma Barranquero wrote:
>   That was pretty evident in the way bzr did get "chosen" as future
>   dVCS for Emacs.

> David Robinow wrote:
>   Are there still problems? I don't know. I haven't used it yet. If
>   you find any you should file a bug report.

I tried using it, but it was too slow, even for my small project (only 
1200 commits of history, bzr takes many seconds just to show "info").
I haven't bothered to file a bug report because previous messages on 
emacs-devel indicate that the bzr people are already quite aware of the 
speed problem.  I hope Emacs doesn't drop CVS until after bzr has been 
improved considerably.

I also tried git and looked at mercurial, but I haven't yet found the 
right dVCS for my application (central repository and working checkout 
on server, copy of repository and checkout on laptop, push from laptop 
to server updates server's checkout but only if no merge-conflicts 
occur).  For now I'm still using CVS even though it doesn't really do 
the job.  A familiar tool with problems (and known workarounds) is 
better than an unfamiliar tool that still has problems but no known 
workarounds!

Re: whither GNU

[Jonathan Lange]

On Fri, Aug 22, 2008 at 2:47 PM, Jonathan Yavner <jyavner@member.fsf.org> wrote:
>> Juanma Barranquero wrote:
>>   That was pretty evident in the way bzr did get "chosen" as future
>>   dVCS for Emacs.
>
>> David Robinow wrote:
>>   Are there still problems? I don't know. I haven't used it yet. If
>>   you find any you should file a bug report.
>
> I tried using it, but it was too slow, even for my small project (only
> 1200 commits of history, bzr takes many seconds just to show "info").
> I haven't bothered to file a bug report because previous messages on
> emacs-devel indicate that the bzr people are already quite aware of the
> speed problem.  I hope Emacs doesn't drop CVS until after bzr has been
> improved considerably.

Well, the Bazaar hackers always appreciate well-filed bugs —
particularly those that include profiling information. And since
pretty much every release includes performance improvements, it's
worth filing a bug so you get notified when we fix *that* speed
problem. (Like most other complex applications, Bazaar's got a few of
them.)

Also, your particular bug interests me. :)

jml