[Top][All Lists]

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

Re: Emacs contributions, C and Lisp

From: Stephen J. Turnbull
Subject: Re: Emacs contributions, C and Lisp
Date: Mon, 03 Mar 2014 12:43:54 +0900

David Kastrup writes:
 > "Stephen J. Turnbull" <address@hidden> writes:
 > > David Kastrup writes:

 > >  > It only weakens the GPL if you start creating situations where
 > >  > it cannot be taken seriously and/or enforced.
 > >
 > > I see.  So the widespread use of GPL in projects that don't collect
 > > assignments is another excuse to declare a piece of software an enemy
 > > of the movement.
 > >
 > > Seriously, I disagree.
 > Since I cannot even figure out what your strawman is supposed to
 > refer to, I am not sure what you disagree with.

The argument for the FSF assignment policy is that it makes the
license much easier to enforce.  Ie, it is the position of the FSF
that failing to collect assignments creates "situations where [the
GPL] cannot be taken seriously and/or enforced."  If the GPL can't be
enforced, the software can be proprietized -- and so such projects,
like LLVM, are "failing to defend software freedom".  So Emacs
shouldn't provide modes to support their unique features according to
RMS's logic AIUI.

But I don't see how it can weaken the GPL.  Some users will ignore the
permission notice, but they do so at their peril -- the whole app
can't be defended, but any parts original to the copyleft project can,
and the licensor is under no obligation to make disentangling the two
simple (for most upstream licenses -- like the GPL at most you must
indicate that the program is modified, not what you did).

The GPL *itself* isn't weakened, at least not in the U.S.: it's well-
established that failure to pursue a copyright infringement does not
constitute a license -- the copyright holder can change her mind and
put infringers in the dock at any time.  If users copy other than as
provided by the GPL, they likely have no license at all (AFAIK
permissive licenses don't have clauses like GPL sec. 10).

And there is a potential benefit.  Most users will open the file, see
"GPL", and automatically obey the terms of the GPL for code they copy
into their own projects.  OK, some may feel cheated if they discover
the file is substantially identical to permissively licensed upstream
code, but those folks already resent the GPL -- what's lost?

 > > If Apache didn't want to enable one-way code flow, they wouldn't
 > > use a permissive license.
 > They are fine with one-way flow into proprietary products.  They
 > tend to be less than enthused about GPLed or LGPLed reuse.

Sure.  But they aren't stopping it by adding an EAY clause to the
license.  At worst, they jawboning for their philosophy of freedom in
the style practiced by RMS as well.  Eg, he has not added the Affero
clause to the GPL itself, but instead made a separate license.  Still,
he recommends the AGPL, and denounces closed cloud-based applications
using GPLed software every chance he gets.

I just don't see a strong argument that a GPLed fork is legally
impractical, just RMS's argument that it wouldn't be effective because
it would permit the same kind of proprietary combination that his
policy toward refactoring GCC is intended to prevent.

reply via email to

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