Re: Release plans

[Thomas Lord <lord@emf.net>]

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


>
>
>