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

Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps

On Wed, 2003-05-07 at 19:11, Edmund GRIMLEY EVANS wrote:

> P is not a derived work of GPLLib, but P+GPLLib is likely to be a
> derived work of GPLLib, in which case it is not allowed to distribute
> them together.

In <1050883365.32589.80.camel@bohr>, I posted the legal definition of a
derivative work in the United States at least, taken from Title 17 USC,
Section 101. To repeat:

    A ''derivative work'' is a work based upon one or more
    preexisting works, such as a translation, musical
    arrangement, dramatization, fictionalization, motion
    picture version, sound recording, art reproduction,
    abridgment, condensation, or any other form in which
    a work may be recast, transformed, or adapted. A work
    consisting of editorial revisions, annotations,
    elaborations, or other modifications which, as a whole,
    represent an original work of authorship, is a
    ''derivative work''. (Title 17 USC, Sec. 101)

>From the definition, I don't see how it could be argued that P is not a
derivative work of GPLLib, unless P happens to be on the same CD-ROM
(ftp site, etc.) as GPLLib.

I can see (though not agree with) that the binary image created in
memory may be a derivative work. But the GPL allows arbitrary use, so
there is no license violation. If it dumps core, though, you may not be
able to redistribute the core. :-)

BTW: Beware DFSG 1 when arguing that P alone is distributable, GPLLib
alone is distributable, but together, they are not. This isn't always
true, such as with the system components exception to the GPL, but its
something to certainly be wary of. I think an interpretation of either
that DFSG and GPL that renders the GPL non-free is strange.

> However, you could certainly distribute P on its own if
> you could reasonably claim that P is useful without GPLLib.

I'll further argue that P is not based upon GPLLib in any meaningful
manner; it includes absolutely no part of GPLLib. 

> There are other implementations of grep, ls, etc, so it would
> certainly be all right to distribute the GPL-incompatible shell script
> on its own.

Sure. Assuming, of course, that the shell script doesn't use any GNU
extensions, which is quite a big assumption. Many scripts use GNU
extensions. Especially on Debian, which is a GNU system after all.

How many other tars accept a j option, for example? It ain't in SUSv2.
Neither is z, for that matter.

> which is probably doable if the
> script makes relatively minor use of grep, etc

I think you'd have a very hard time finding scripts which make minor use
of GPL utilities. Even our cat program (like everything else in
coreutils) is GPL. So is our echo program.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: