Tom "spot" Callaway wrote:
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.
You might want to put this in the licensing wiki page. This looks like repeatedly asked for information.
Rahul -- 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