GPL, "derivative works" and C++ templates

[Alex Rousskov]

I can only give you a partial non-legal answer/opinion: C++ template
definitions are equivalent to libraries as far as derivative work is
concerned. Using such template definitions is the same as using a
software library. In other words, there is nothing special about C++
template definitions compared to any software library.

Please note that C++ template declarations alone (not definitions) can
be considered outside of copyright law because they constitute an
interface. For example, STL interface cannot be copyrighted, but its
implementation (STL library guts) can be. In most cases, C++ template
declarations are located in the same compilation unit as template
definitions, but that does not affect their copyright-ability.

As for the second part of your question, I do not know whether
Lawrence Rosen, Eben, or any given Your Honor is correct at any given
time. Nor my opinion would matter much in this world (see John Cowan's
excellent response).

Fortunately, GCC STL library license is not
viral/reciprocal/force-the-world-into-happiness/whatever. Same for
most (all?) Boost libraries.

HTH,

Alex.



On Tue, 8 Jun 2004 nospam+pixelglow.com at pixelglow.com wrote:

> Dear All,
>
> The OSI and FSF seem to have different ideas about what constitutes a
> "derivative work" under GPL and would thus have to be licensed under GPL as
> well. For example, Lawrence Rosen for OSI says that simply combining something
> with the work isn't a derivative work
> (http://www.sitepoint.com/print/public-license-explained), whereas merely
> statically linking to a GPL library makes your work GPL in the GPL FAQ
> (http://www.gnu.org/licenses/gpl-faq.html#TOCIfLibraryIsGPL).
>
> Putting the issue of static linking aside, what would be the status of a
> header-only C++ template library, such as macstl
> (http://www.pixelglow.com/macstl/), boost (http://www.boost.org/) or even
> portions of GNU libstdc++?
>
> Some pertinent issues:
>
> 1. The library certainly exists as source code.
> 2. The library has no independent existence as executable or object code, unlike
> either the static or the dynamic linked case. It must be combined with client
> code to function.
> 3. The resulting combined object code often cannot be easily segregated into
> client code vs. library code, certainly not on a file or module level.
> 4. On the other hand, the user does not actually change any line of code in the
> library, nor does he have to peruse the entire library to do what he wants; it
> is sufficient to follow the published API.
> 5. Some have seen C++ templates as "metaprograms" i.e. that including the
> template header is tantamount to "running" a program whose "output" is the
> regular source code for the client program. (This smacks of sophistry,
> though...)
>
> Thus there's an argument from 2 - 3 that any use of such a library is
> necessarily a derivative work, akin to if you cut out pieces from a larger
> cloth and patched into your own work. Yet from 4 - 5, it could be argued that
> no change was made to the original, thus the total work is not a derivative of
> the original, and thus you don't need to GPL the lot.
>
> Which view is supportable?
>
> Cheers,
> Glen Low, Pixelglow Software
> www.pixelglow.com
> --
> license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
>
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3