* Dynamic loading (was: Release plans)
@ 2008-08-24 1:57 Eric M. Ludlam
0 siblings, 0 replies; 3+ messages in thread
From: Eric M. Ludlam @ 2008-08-24 1:57 UTC (permalink / raw)
To: emacs-devel
Hi,
Note: I'm not on the mailing list, but have been reading some threads
via the archive, so I don't have thread info in my mail headers. Sorry.
> > > 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!
While I personally think that dynamically loadable libraries would be
very helpful to me, I'd like to provide an example which would support
what I think Alan is worried about.
I've been working on CEDET for a long time. It supports smart
completion for various langauges plus a bunch of other stuff. It's
something I've been working on since 1995 or so. The not-free
XRefactory tool uses Emacs as the editor for its UI. It uses Emacs
Lisp, and subprocesses to do it's work.
I've seen at least two explicit instances of folks who try CEDET, have
some percieved issue, and end up using XRefactory instead because it
works for them. By this, I mean they sent email saying this was their
intent. Based on the number of folks who just stopped using CEDET
because it wasn't "ready yet", I'd guess there are more.
When it comes down to it, XRefactory has a lot of great stuff I just
haven't gotten to yet in CEDET. Would more folks use CEDET, and help
identify or fix bugs in CEDET if there was no XRefactory? I would
guess so. I don't use it, so it doesn't affect me or my computer, but
it's existence makes it less important for others to help w/ CEDET,
and make it better because their problems are already solved.
Now, all that said, would supporting dynamic libraries in Emacs
earlier have changed any of that? The difference would be that
XRefactory would be using dll's for some of it's stuff, but I doubt
much else would change. I would posit that the issue already exists,
and dlls are just another flavor. Anything you do w/ a DLL, you can
do by writing main.c with a text IO interface, compiling it, and
writing some lisp to do process IO. It just takes longer when I'm the
one doing it.
Eric
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
@ 2008-08-14 9:49 Alfred M. Szmidt
2008-08-14 10:04 ` Johannes Weiner
0 siblings, 1 reply; 3+ messages in thread
From: Alfred M. Szmidt @ 2008-08-14 9:49 UTC (permalink / raw)
To: Johannes Weiner; +Cc: acm, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-14 9:49 Release plans Alfred M. Szmidt
@ 2008-08-14 10:04 ` Johannes Weiner
2008-08-15 3:41 ` Richard M. Stallman
0 siblings, 1 reply; 3+ messages in thread
From: Johannes Weiner @ 2008-08-14 10:04 UTC (permalink / raw)
To: ams; +Cc: acm, rms, emacs-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-14 10:04 ` Johannes Weiner
@ 2008-08-15 3:41 ` Richard M. Stallman
2008-08-15 17:20 ` Thomas Lord
0 siblings, 1 reply; 3+ messages in thread
From: Richard M. Stallman @ 2008-08-15 3:41 UTC (permalink / raw)
To: Johannes Weiner; +Cc: acm, ams, emacs-devel
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-15 3:41 ` Richard M. Stallman
@ 2008-08-15 17:20 ` Thomas Lord
2008-08-16 10:39 ` Richard M. Stallman
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Lord @ 2008-08-15 17:20 UTC (permalink / raw)
To: rms; +Cc: acm, ams, Johannes Weiner, emacs-devel
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
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-15 17:20 ` Thomas Lord
@ 2008-08-16 10:39 ` Richard M. Stallman
2008-08-16 21:04 ` Thomas Lord
0 siblings, 1 reply; 3+ messages in thread
From: Richard M. Stallman @ 2008-08-16 10:39 UTC (permalink / raw)
To: Thomas Lord; +Cc: acm, ams, hannes, emacs-devel
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-16 10:39 ` Richard M. Stallman
@ 2008-08-16 21:04 ` Thomas Lord
2008-08-16 21:35 ` Alan Mackenzie
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Lord @ 2008-08-16 21:04 UTC (permalink / raw)
To: rms; +Cc: acm, ams, hannes, emacs-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-16 21:04 ` Thomas Lord
@ 2008-08-16 21:35 ` Alan Mackenzie
2008-08-16 22:43 ` Stephen J. Turnbull
0 siblings, 1 reply; 3+ messages in thread
From: Alan Mackenzie @ 2008-08-16 21:35 UTC (permalink / raw)
To: Thomas Lord; +Cc: ams, emacs-devel, rms, hannes
'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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-16 21:35 ` Alan Mackenzie
@ 2008-08-16 22:43 ` Stephen J. Turnbull
2008-08-17 7:31 ` Alan Mackenzie
0 siblings, 1 reply; 3+ messages in thread
From: Stephen J. Turnbull @ 2008-08-16 22:43 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Thomas Lord, hannes, ams, rms, emacs-devel
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?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-16 22:43 ` Stephen J. Turnbull
@ 2008-08-17 7:31 ` Alan Mackenzie
2008-08-18 0:01 ` Stephen J. Turnbull
0 siblings, 1 reply; 3+ messages in thread
From: Alan Mackenzie @ 2008-08-17 7:31 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: Thomas Lord, hannes, ams, rms, emacs-devel
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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-17 7:31 ` Alan Mackenzie
@ 2008-08-18 0:01 ` Stephen J. Turnbull
2008-08-18 10:18 ` Alan Mackenzie
0 siblings, 1 reply; 3+ messages in thread
From: Stephen J. Turnbull @ 2008-08-18 0:01 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Thomas Lord, emacs-devel, hannes, rms, ams
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-18 0:01 ` Stephen J. Turnbull
@ 2008-08-18 10:18 ` Alan Mackenzie
2008-08-18 17:58 ` Stephen J. Turnbull
0 siblings, 1 reply; 3+ messages in thread
From: Alan Mackenzie @ 2008-08-18 10:18 UTC (permalink / raw)
To: Stephen J. Turnbull; +Cc: emacs-devel, hannes, rms
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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Release plans
2008-08-18 10:18 ` Alan Mackenzie
@ 2008-08-18 17:58 ` Stephen J. Turnbull
2008-08-18 20:20 ` Dynamic loading (was: Release plans) Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: Stephen J. Turnbull @ 2008-08-18 17:58 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: hannes, rms, emacs-devel
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.)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Dynamic loading (was: Release plans)
2008-08-18 17:58 ` Stephen J. Turnbull
@ 2008-08-18 20:20 ` Stefan Monnier
2008-08-18 22:18 ` Stephen J. Turnbull
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2008-08-18 20:20 UTC (permalink / raw)
To: emacs-devel
[ 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Dynamic loading (was: Release plans)
2008-08-18 20:20 ` Dynamic loading (was: Release plans) Stefan Monnier
@ 2008-08-18 22:18 ` Stephen J. Turnbull
0 siblings, 0 replies; 3+ messages in thread
From: Stephen J. Turnbull @ 2008-08-18 22:18 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-08-24 1:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-24 1:57 Dynamic loading (was: Release plans) Eric M. Ludlam
-- strict thread matches above, loose matches on Subject: below --
2008-08-14 9:49 Release plans Alfred M. Szmidt
2008-08-14 10:04 ` Johannes Weiner
2008-08-15 3:41 ` Richard M. Stallman
2008-08-15 17:20 ` Thomas Lord
2008-08-16 10:39 ` Richard M. Stallman
2008-08-16 21:04 ` Thomas Lord
2008-08-16 21:35 ` Alan Mackenzie
2008-08-16 22:43 ` Stephen J. Turnbull
2008-08-17 7:31 ` Alan Mackenzie
2008-08-18 0:01 ` Stephen J. Turnbull
2008-08-18 10:18 ` Alan Mackenzie
2008-08-18 17:58 ` Stephen J. Turnbull
2008-08-18 20:20 ` Dynamic loading (was: Release plans) Stefan Monnier
2008-08-18 22:18 ` Stephen J. Turnbull
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.