[Top][All Lists]

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

Re: Unibyte characters, strings, and buffers

From: David Kastrup
Subject: Re: Unibyte characters, strings, and buffers
Date: Thu, 03 Apr 2014 18:26:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> <URL:http://arstechnica.com/tech-policy/2013/12/googles-copyright-win-against-oracle-is-in-danger-on-appeal/>
> Even if you take this article at face value (as opposed to someone
> whose interests are unknown reiterating rumors), the conclusion is
> that jury is still out in this issue.  Which is exactly what I wrote:
> this issue is not decided yet, and precedents are contradictory.
>> and that the FSF would not have been in a position to pay the kind of
>> legal expenses incurred here.
> If there is a precedent, you don't need to pay any expenses.

Nonsense.  For most court cases there are precedents that are getting
referenced.  In the U.S., both sides have to pay their own legal
expenses.  Judges _may_ award legal costs to a defendant if the case was
brought forward clearly frivolously and/or vexatiously.  That is very
rarely done.  A successful defense will be expensive even in the rare
case that the case is decided in summary judgment.

> Anyway, this all is only relevant if someone of those who wrote the
> code that was discussed and reimplemented actually sue the FSF.  Since
> such code almost always comes from Free Software, I don't think
> there's a danger of this.

If an employer of a non-assigned contributor is sued by the FSF over
infringement of some FSF-copyrighted software, the whole case can get
thrown out of court if the FSF is shown to have "dirty hands", namely to
have incorporated code themselves that is legally under copyright by the

In the case of XEmacs, we are not necessarily talking about core
developers highly sympathetic to the FSF.  There is no playful element
to the history of the Emacs/XEmacs schism like with the Emacs/vi "editor

The details of the complex Emacs/XEmacs relation aside, nobody should be
blamed for choosing to err on the safe side.  In particular since the
copyright maximalists are pretty successful in eroding the safe side and
moving the borderlines.

David Kastrup

reply via email to

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