Orcan Ogetbil <oget.fedora@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin js@xxxxxxxxxxxxxxx (uni) joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ legal mailing list legal@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/legal
