-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom "spot" Callaway wrote: > On Thu, 2007-08-16 at 14:56 +0200, Adel Gadllah wrote: >> Hans de Goede wrote: >>> >>> GPL+, the version in the COPYING file is irrelevant. >> this sounds wrong ... if the source says nothing and the copying says >> gplv2 it _is_ gplv2. > > COPYING does not signal licensing intent (it might not seem intuitive, > but this is what Red Hat legal told us, and we're going by that). > > The order of operations goes like this: > > 1. What does the code say? If it specifies a version, that's what it is. > 2. Does the code conflict with itself? (file1.c and file2.c are compiled > together but have different licensing) > 2A. Are the conflicting licenses compatible? > 2AA. Does one license overpower the other one? (GPL/LGPL does this) If > so, the strictest license wins. > 3. What does the documentation say? This signals the author(s) > intentions from a legal perspective, although, not as binding as in the > source. If the documentation specifies a version when the source does > not, then we can use the documentation as our source. NOTE: COPYING does > not count as documentation, since the author(s) didn't write it. > 4. If neither the source, nor the upstream composed documentation says > anything about the license version, then it could be under _ANY_ version > of the GPL. The version listed in COPYING is irrelevant from this > perspective. > > Now, keep in mind that most upstreams are probably leaving the > versioning out by accident. If you get to case 4, you definitely want to > let upstream know that you are unable to determine the applicable > version(s) of the license from the source and documentation. They'll > almost certainly let you know what their intended license version is, > and (hopefully) correct it in the upstream source. > Actually spot, I have to disagree with you slightly here. If COPYING doesn't signal licensing intent, then those programs which have no license information in the source (like abe, apparently) *are not licensed*. Which means that we can't distribute them. This could even be carried out to mean that a program which lacks licensing information in one necessary source file would make the whole work not licensed for us to do anything with. Either COPYING has a meaning or it doesn't. OTOH, it is probably more common for there to be a COPYING(v2 or v3) file in the source tarball and a source header that says "GPL". In that case, I would say we *should not put GPL+ in the License field* if at all possible. The reason is that whatever the legal technicalities of the situation are, the author of the software included a GPLv3 license file and wrote something that was a common shorthand for that license file at the time the software was written. Whether or not we're legally correct in writing GPL+, we don't want to piss off (and possibly get [unsuccessfully] sued by) an author that says, "I meant GPLvX who the fuck are you to steal my work?" In an even more practical vein, if we put GPL+ in the license field and someone takes our word for it, goes off and starts using it as a GPLv1 instead of GPLv3, then we're right in the middle of causing everybody a lot of pain when the licensing is clarified for all involved. If, OTOH, we write GPLv3+, (which is legal for us to do even if the original is technically GPL+) and someone licenses their code as GPLv3 because of it, the most harm we've done is caused someone to use the GPLv3 when they could have used GPL+. Please, go back to common sense with this one and do what the vast majority of authors intended by putting a GPLv2 COPYING file in their source tarball, not what we know is the most liberal licensing that we can legally distribute their code under. - -Toshi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGxPp2X6yAic2E7kgRAuPmAJ9DvKuJyZAgaQjsCZ5LiwDLcOUJMQCfYAB5 TWMJ6Zqn3bMAmgBsmbXn66k= =c1lx -----END PGP SIGNATURE----- -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
