[Top][All Lists]

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

Re: Emacs contributions, C and Lisp

From: Jacob Bachmeyer
Subject: Re: Emacs contributions, C and Lisp
Date: Wed, 14 Jan 2015 17:17:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

> It has been a while since I last read through the FSF GPL FAQs on this, > so maybe copyright has been weakened, but I thought that dynamic linking > does not avoid the GPL.

Our position is that dynamic linking makes a combination covered by
the GPL -- provided the code _as distributed_ is designed for linking
the parts together.

Combinations that the user decides to make, which are not prearranged
by code that gets distributed, are not limited by the GPL.  This is
true regardless of how the parts get linked.

Where is the line here? Does having GPL code define a new API mean that programs using that new API can be considered designed for linking to that GPL code? If not, how can the GPL be effective on libraries, such as Readline? I thought that this was how that worked.

More specifically, if a future version of GCC, buildable as a Guile extension, offers access to its AST through a Guile API, would nonfree programs be able to use the GCC API, or would the GPL protections cover GCC's API? Assume that GCC invents its own API and does not reimplement some other API for AST access. If nonfree programs could use GCC in this case, what prevents the same abuse of Readline now? (I base my longer-term proposal for Emacs/Guile/GCC on past positions I have seen taken with respect to Readline; perhaps I have misunderstood.)

reply via email to

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