Re: New maintainer

[joakim]

David Kastrup <address@hidden> writes:

> John Wiegley <address@hidden> writes:
>
>> I can't help but think that unless the FSF has more to offer than its
>> ideals, its technical decisions are going to render it obsolete.
>
> The FSF never had substantially more to offer than its ideals.  All the
> rest has been provided by volunteers and donations.  While Richard has
> thrown a substantial amount of his own work and money and time into it
> at the start, in the overall scheme that's not much more than a
> catalyst.
>
>> Progress waits for no man, and the world is changing more and more
>> rapidly. There is a reason Clang is eating GCC's lunch: because the
>> needs of a larger community demand a better free compiler.
>
> The FSF has no control over the direction of Clang, technical or with
> regard to licensing.  A whole lot of software is "eating GNU's lunch" in
> a number of technical categories.  GNU started out with everybody
> "eating its lunch".  The mission of the GNU project is to provide a
> coherent whole with freedoms that cannot be subverted.
>
> Apple's XCode environment is based on a free compiler, Clang, but is
> licensed in a way where you may not run it on anything but Apple
> computers.  _That's_ how you really eat the lunch of free software.
> Having Emacs integrate with XCode for developing code in a manner that
> cannot be done with the GNU system would be self-defeating.

As I sometimes get bitten by this in my day job, I would just like to
add that a lot of people I meet that are not even interested in free
software, find this aspect of the Apple development stack appalling.

While this is not my personal position, you can use the GNU tools and
not really care about the freedom, but you still benefit from it. You
can use free software library and all you need to do is provide the
source for your users. You can deploy code like this with no worries, as
long as you comply with the GPL, which isn't really hard.

Then when you are writing, say, an ios client, the situation is
different. The developers I work with quite often don't think that Apple
software is especially fascinating. Still, they can't choose not to use Apple
tools in the build chain. You have to have Apple hardware, which isn't
suitable in a datacenter. You can't choose to not use Xcode and
whatever.

With this I just wanted to add another datapoint.  


>
> It's the point of the GPL to be hard to subvert against the cause of
> free software.  But the GPL is not a philosophical authority but a legal
> tool.  Software licensed under it can be used according to our goals or
> against them.  Where the only uses are weakening our cause, there is no
> point in being the front-runner.  Everybody may fork Emacs (or just
> provide his own packages) who wants to work on goals not helping the GNU
> project, but there is no point in the core of Emacs relying on resources
> and the blessing of the FSF to do so.
>
>> Emacs is still a fantastic editor, but it's old and its age is
>> showing. If we remain competitive, it could stay awesome for another
>> 30 years; but if we avoid progress to further non-technical agendas, I
>> think it will drive people AWAY from the GNU project, not bind them
>> more tightly to it.
>
> That argument is more than 30 years old, and many parts of the GNU
> project have taken second place to other software a whole lot of the
> time.  But the front leaders wither and die and get replaced by others.
> GNU sticks around.  Emacs sticks around.  Its largest traditional
> competitor is "vi" and it is factually gone, replaced by the most
> popular free vi clone of the decade (currently vim).
>
> Yes, we'll not end up in first place on technical merit lots of the time
> because ending up in first place is not the first priority.  The first
> priority is to provide a free cohesive system with essential parts
> nominally and effectively under the GPL so that its use as a building
> block will lead to more systems honoring and providing software freedom.
>
> Taking custody of that may be a nuisance if you don't care or even
> disagree.  But even though it's an essential part of the job, it should
> not turn out a permanent distraction.  And if it does, one should try
> finding a solution or compromise that manages to serve the conflicting
> priorities better.

-- 
Joakim Verona