emacs-devel
[Top][All Lists]
Advanced

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

Re: Release plans


From: Thomas Lord
Subject: Re: Release plans
Date: Sun, 17 Aug 2008 10:42:28 -0700
User-agent: Thunderbird 1.5.0.5 (X11/20060808)

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






reply via email to

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