[Debburn-devel] License of cdrkit - GPLv2 + additional restrictions

[Francesco Poli]

On Sun, 24 Sep 2006 13:43:39 +0200 Josselin Mouette wrote:

> Le vendredi 15 septembre 2006 à 23:51 +0200, Francesco Poli a écrit :
> > > Because the hard problems that you pointed out have been fixed. We
> > > do no longer return "schily" author ID, etc.
> > 
> > You no longer return "schily", but it seems that noone is allowed to
> > create a modified version of cdrkit that returns "schily" again or
> > that returns a SCG_AUTHOR string identical to yours.
> > This is a non-free restriction that is not present in the GNU GPL
> > v2.
> 
> Jörg Schilling interprets this restriction as implied by trademark law
> in his country.

I don't know whether his interpretation is a legally valid one (IANAL),
even though I've heard of cases where courts prevented the attempt to
use an exclusive right (copyright, trademark, ...) to block
interoperability.
Here, the restriction clearly forbids creating a derivative work that is
a drop-in replacement of the original, and thus interferes with
interoperability.

> Replacing the text by a 'this software cannot return
> "schily" because it would infringe on Jörg Schilling's trademark'
> notice - or no notice at all - would seem like a fine solution.

Dropping this restriction from cdrkit would be a solution, if a
qualified lawyer confirms that we have the right to do so...

> 
> After all, it isn't allowed to display "(c) Microsoft corp." in a GPL
> program, but it doesn't cause any issue with the GPL.

It depends on where and how that string is displayed.
If it is a (false) copyright notice for the GPL'd program, then, yes,
it's not allowed.
If it is used, e.g., to refer to a work copyrighted by Microsoft, or,
anyway, in a descriptive way, it could be allowed.
Moreover, if displaying that string is a functional behavior of the
GPL'd program (perhaps because it's a client program designed to
interact with a server program that wants to receive the string in order
to operate correctly), then I think sane courts would consider that to
be allowed.


Anyway, let's not split hairs on the validity of Joerg Schilling's
claims: what we are talking about are clearly non-free restrictions (I
hope we can agree on that...) and must thus be solved somehow.

I think that whether those restrictions can be dropped from cdrkit is
for a lawyer to say.  Otherwise a workaround must be found
(independently rewriting the problematic files, or forking from a
previous unencumbered version of those files, or enhancing
cdrskin/libburn and switching to that as a replacement, ...)


A big thanks to anyone working on these issues!

-- 
But it is also tradition that times *must* and always
do change, my friend.   -- from _Coming to America_
..................................................... Francesco Poli .
 GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debburn-devel/attachments/20060924/423e7387/attachment.pgp