Combining GPL and non-GPL code

Chris Travers chris.travers at
Sat Aug 18 02:23:52 UTC 2007

> GPLv2 section 2b does indeed use the phrase "must cause any work [...]
> to be licensed as a whole [...] under the terms of this License."

I agree with your statement and reasoning.  Work as a whole does not
necessarily mean "every line of code" but rather "the compilation" in the
same sense as "anthology" but IANAL.

I.e. nothing prevents me from licensing *part* of that work under a license
compatible with the GPL as long as the "work as a whole" is licensed with
appropriate permissions.  This becomes a larger question if the BSD depends
on GPL code rather than the other way around (and that might be a more
difficult case because one could argue derivation).

Absent from the concerns of derivation, nothing in the GPL requires that
code not derived from other GPL code that the author does not hold
appropriate copyrights to might be licensed under terms more permissive than
the GPL.  For example, if the code is all my own, nothing says I can't
license every file based on different compatible licneses provided that they
do not prevent the *work as a whole* from carrying the rights and
restrictions of the GPL.

To put it another way, I can compile a large amount of public domain
literature, and reserve all rights to the anthology, but someone can still
take my work and copy out the public domain components, combine them with
other ones, re-arrange them, and copyright that anthology as non-derivative
of my own.

There may be cases where the path of licensing has an effect (I license a
copy of a program to you under a BSD license, change my mind, and release to
the public under the GPL).  Limited distribution might matter.

_However_, for purposes of avoiding copyright infringement, it suffices
> for the extra, third-party code to be available with new-BSD or MIT /
> X11 rights, of which GPLv2 rights are a proper subset, with the effect
> of compliance to the likely satisfaction of any judge.  I agree with
> John Cowan:  If someone hands me a CD with tarballs of the Exim MTA
> source code (which is GPLv2 with a licensing exception for
> old-BSD-licensed libraries) configured to use external library code for
> SSL/TLS-wrapped SMTP, accompanied by OpenSSL source code (which is a
> combination of Eric A. Young's old-BSD code and subsequent new-BSD
> additions), then, if I extract the OpenSSL tarball and redistribute it,
> _that_ code remains BSD-licensed, as specified and required by its
> owners and licensors.

Agreed.  THe license isn't "that" contageous.  Arguing that any user of GPL
tools forfits BSD rights to the dependencies is silly :-).

Many innocent electrons have been needlessly murdered, over the years,
> by some of our BSD brethren up in arms over the bugabear of GPL
> codebases' alleged "relicensing" of their work to GPLv2, against their
> wishes:  This may be a fine point of law, but I personally think it's
> abundantly clear that this is, actually, a phoney issue, because
> copyright owners alone are entitled to decree licence terms for their
> creations.  Period.

It is a moot point.  The BSD code is publically available.  Therefore they
have granted such a license to the public at large.  Restricting code copied
into another application does not mean you can't go back to the original.
And if the file as a whole is still licensed under the BSD license, I would
argue that this would be sufficient even if other files in the application
are now GPL, absent concerns about derivation (i.e. one would probably want
to look over the code to make sure that the GPL code depended on the BSD
code and not the other way around).

The BSD vs GPL argument is furthermore *stupid* and *counterproductive.* All
software lives or dies based on community.  GPL and BSD both have advantages
and not in many areas including collaborative development of systems to
compete with established competition (I think it is a toss-up as for
utility), but in the end community, and not licenses are what are important
for the success of a project.

Best WIshes,
Chris Travers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the License-discuss mailing list