emacs-devel
[Top][All Lists]
Advanced

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

Re: The copyright issue


From: David Kastrup
Subject: Re: The copyright issue
Date: Thu, 05 Aug 2010 18:40:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Uday S Reddy <address@hidden> writes:

> Stephen J. Turnbull writes:
>
>> BTW, you forgot David Reitter, who must fork because Aquamacs is
>> dedicated to implementing features that make his proprietary platform
>> (the Mac) more attractive for users than free platforms -- and such
>> features are not allowed as a matter of Emacs policy.
>
> I suppose this is a legal issue, and can't just be settled by
> newsgroup debates.
>
> But it seems that the FSF copyright policy has become a bugbear, which
> might not have been the original intention.

It is a popular misconception that Richard must be oblivious to the
consequences of what he is doing.  If you bother to check, you'll find
that not only has he been very consistent for the last 30 years, but
also the effects have been basically the intended and predicted ones.

There are consequences to the decisions and policies, and some people
don't like the consequences.  If people bothered to check them for
consistency with the stated goals, they'd find them likely not just
intentional but also effective.

> The current situation is highly asymmetric.  Anybody, including a
> private corporation, can use the FSF codebase to develop their
> variants, but Gnu Emacs can't use their enhancements to enrich itself.

That's a consequence of having Emacs be a piece of software
intentionally keeping the copyright limited to few parties.

If you want to keep the GPL on a work of yours strongly enforceable, it
is safest not to reap any of the benefits you grant downstream yourself.
There is not much case law to rely on otherwise.

> So, Gnu ends up lagging behind and, perhaps in cases like Aquamacs,
> not even being able to enter the territory.  It leads to more and more
> forking, making life hard for the package developers and becoming a
> disservice to the users.
>
> Can't we find a way out of this dilemma?

No.  While it has been popular to "debate" this "dilemma" for the past
30 years, nothing has changed regarding the origin and evaluation of the
underlying choices.

-- 
David Kastrup




reply via email to

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