Re: Release plans

[Thomas Lord <lord@emf.net>]

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



>
>
>
>