GPL with the Classpath exception - clarification needed
Philippe Verdy
verdy_p at wanadoo.fr
Wed Mar 25 07:00:19 UTC 2009
Blake White a envoyé :
> John Cowan wrote:
> > Blake White scripsit:
> > > Let's say I use the GPL with the Classpath exception to distribute
> > > a library I wrote. Suppose someone modifies the library, never
releases
> > > the library directly, but links it into an executable and releases
> > > that executable under a closed license.
> >
> > They can't do that. The Classpath exception allows the distribution of
> > "this library" as part of a proprietary program. It does *not* allow
> > "a modified form of this library" to be so distributed. Any
modifications
> > can only be on the terms of the GPL.
>
> (forgot to reply all)
> But the Classpath library says that "If you modify this library, you may
extend this exception to your version of the library, but you are not
obligated to do so."
> So by that line, if I'm a third party and I modify the library, can't I
extend the exception to my modified library, effectively making "this
library" now mean the modified version?
I also have to disagree with John Cowan. The classpath exception does not
limit the rights on the GPL-ed part of the software, that can still be
modified. The exception just means that the classpath extension does not
need to apply the GPL, and it can be replaced by any other. This linked
extension must even be replacable using a public interface subject to the
GPL with the classpath exception, or just to the GPL if the replacement does
not need this exception.
The Classpath exception also allows replacing a proprietary extension (part
of the exception to the GPL) to bez replaced by another (including modified
versions of the initial proprietary extension). Both parts are separately
modifiable or replacable. However the SPL'ed part must continue to be usable
with another othe substitution of the initial proprietary extenion.
That's why this exception is optional: if possible the proprietary extension
an be safely replaced by a GPL implementation, and then there will be no
reason to keep this exception in the resulting application. Everything will
remain modifiable under the appropriate licence applicable to each linked
part (as long as there's a public interface between these two parts that
will respect the GPL with the SAME allowed exception or with no exception at
all (not even the "Lesser" GPL exception, unless it was also part of the
exceptions granted in the initial licence).
Let's not forget that proprietary programs may be released in some future
with a more permissive licence such as the GPL or compatible with the GPL.
But there are also "open-source" programs (provided with a OSI-approved
licence) that are non-"free", i.e. incompatible with the GPL (they may
contain for example restrictions on the medium of distribution, or
requirements for warranties, or required disclaimers, or forbidden use in
commercial apps or as essential part of paid products or services, or
advertizing requirements, or required use of specific unmodifiable logos or
unmodifiable parts, or nominative registratrion requirements, or exclusion
of providing a written offer for getting the sources, including for modified
programs covered by the licence...) However, the GPL with Classpath
Exception allows some of these non-free programs to be linked with the
GPL'ed application or library.
For a library (including those written in Java), I think however that it's
simpler to use the LGPL (which allows more freedom) than the GPL with
ClassPath Exception (which is more restrictive in the kind of linking
permitted).
Note that the LGPL ("Lesser" GPL) is also a GPL with an exception for
linking, and probably more solid than the GPL with ClassPath Exception, as
it is simpler to interpret (notably since the GPL v3 that the LGPL v3 now
references and uses with a simpler exception.
More information about the License-discuss
mailing list