[Fedora-legal-list] Please define "effective license" (for the love of consistency)

Joerg Schilling Joerg.Schilling at fokus.fraunhofer.de
Sun Jul 18 11:10:40 UTC 2010


Orcan Ogetbil <oget.fedora at gmail.com> wrote:

> However, during the review of the package
> https://bugzilla.redhat.com/show_bug.cgi?id=537325
> this issue came up again. Upon Michael Schwendt's warning, I have
> changed the license tag of this package from "GPLv2" to "GPLv2+ and
> LGPLv2+ and GPLv2", since there is no such thing as "the effective
> license".

You started a discussion on a topic that is frequently missunderstood in the 
OSS community.

Unless you are the author and own all the code under GPLv2, do not change 
the license of code that is under GPLv2 only. You will otherwise end up with
illegal and undistributable code such as GNU vcdimager or GNU libcdio.

Background: in vcdimager, there is non-OSS code that is claimed to be under GPL
without getting the permission from the author of the code. In libcdio, there
is code that was relicensed to GPLv3 without permission from the original 
author and the original license for the code in the latter case was GPLv2 only.


Regarding "effective license", the answer is: "it depends".

If someone takes code under GPLv2+ and personally changes the code, creating a
so called derivative work (by putting the changes under GPLv2) this is permitted
and the resultant work is effectively under GPLv2 as a whole.

If someone takes code under GPLv2+ and adds code from a different author under
e.g. the BSD license, the result is very different: 

-	You cannot declare code from other people to be "your changes" in hope
	that this results in a derivative work.

-	The GPL requires you to put the "whole work" under GPL

-	The BSD license does not permit to change the license and the Copyright
	law disallows to change the license in case there is no explicit 
	permission

-	The BSD license does not allow to sub-license the code, so even if
	changing the licence was permitted, this would not cause any effect.
	This is because (for both BSD-l and GPL) you always receive the license
	directly from the original author only and this author selected the BSD 
	license for his code.

-	As a result, the combination of GPL and BSD code happens by creating
	a "collective work". In a collective work, each work stays separate
	even if both works are linked together. The BSD work part remains 
	under BSDl and the GPL work part remains under GPL.

Note that you need to take specific care and cannot base arguments on the GPL 
text as the GPL is in conflict with the US Copyright law. See:

http://www.osscc.net/pdf/QualipsoA1D113.pdf
http://www.cs.berkeley.edu/~tlavian/publications/article/Berkeley%20Law%20Journal%20softwarecombinations060403.pdf
http://www.osscc.net/en/gpl.html

US Copyright law title 17 paragraph 106 disallows to redefine the definition
if a "derivative work" for a license like the GPL, so the related definitions
in the GPL text are void.


> However the current reviewer points out that this is in contradiction
> with the guideline
>
> --
> 2. The source code contains some .c files which are GPLv2 and some other .c
>    files which are GPLv2+. They're compiled together to form an executable.
>    In this case, the stricter license wins, so the resulting executable is
>    GPLv2. The License tag should read: License: GPLv2
>    Note that you do NOT need to list GPLv2 and GPLv2+ in the License tag.
> --
> from https://fedoraproject.org/wiki/Licensing/FAQ#How_should_I_handle_multiple_licensing_situations.3F
>
> So I am back where I started. There is clearly a contradiction between
> what I was advised here on last December and the above guideline.
>
> Which one is correct?

If there is a single file under GPLv2, you need to ignore the "GPLv2 or any 
later" tag in the other files except you plan to create a "collective work". 
In this case, the related files need to be part of different works.

Note that unless you like to combine the code with code under a GPL 
incompatible license (such as the GPLv3), there is no problem.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



More information about the legal mailing list