From Fedora Project Wiki

Revision as of 22:36, 16 February 2009 by Spot (talk | contribs)

Frequently Asked Questions about Fedora Licensing

Freedom

What does it mean when a license is listed as "FSF Free"?

It means that the license is considered a Free Software License by the FSF, and meets their Free Software Definition .

Does Fedora permit anything under "Non-Free" licensing?

When it comes to software or fonts, the answer is definitely no. We strongly prefer that items classified as content (see Code Vs Content) are under a Free license, but we only require that they be freely distributable without restrictions.

What about putting Non-Free items in a separate Non-Free repository, like Debian/Ubuntu does?

Nope. That would really defeat the point.

GNU General Public License

What does it mean when a license is listed as "GPLv2 compat" or "GPLv3 compatible"?

It means that the license is compatible with either version 2 or version 3 of the GNU General Public License: you can combine code released under the other license with code released under that version of the GNU GPL in one larger program. See: http://www.fsf.org/licensing/licenses/gpl-faq.html#WhatDoesCompatMean

How do I figure out what version of the GPL/LGPL my package is under?

The short answer is to look at the source. Here is the long answer:

The first thing to consider is that you cannot use COPYING to determine license versioning intent because of how the GPL and LGPL are written.
GPLv2 says: 

If the Program does not specify a version number of this License, you may 
choose any version ever published by the Free Software Foundation.

GPLv3 says: 

If the Program does not specify a version number of the GNU General 
Public License, you may choose any version ever published by the Free 
Software Foundation.

LGPLv2 says: 

If the Library does not specify a license version number, you may choose 
any version ever published by the Free Software Foundation.

LGPLv3 says: 

If the Library as you received it does not specify a version number of 
the GNU Lesser General Public License, you may choose any version of the 
GNU Lesser General Public License ever published by the Free Software 
Foundation.

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)
    1. Are the conflicting licenses compatible?
      1. 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 (unless they added text before or after the license text clarifying their intentions).
  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. Technically it could be under any license, but if all we have to go by is COPYING, we'll use COPYING to imply that it is under the GPL, all versions (GPL+).

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 licensing (and/or license versioning) 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.

Multiple licensing situations

How should I handle multiple licensing situations?

It depends on the situation. Here are some common cases:

  1. The source code contains some .c files which are GPLv2+ and some other .c files which are BSD. They're compiled together to form an executable. Since some of the files are licensed as GPL, the resulting executable is also GPL. The License tag should read: License: GPLv2+
    Note that you do NOT need to list BSD in the License tag, the License tag reflects the resulting, packaged, items in the binary RPM.
  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.
  3. A package has multiple binaries, some of them are GPLv2, some are GPLv3, and some are MIT licensed. In this case, you do need to list all of the individual licenses of the compiled binaries in the License tag, so it should read: License: GPLv2 and GPLv3 and MIT
  4. The source code in my package is dual licensed, it says I can choose either the BSD or the GPLv2 license. In this case, you need to specify that there is a choice in the License tag, it should read: License: BSD or GPLv2
  5. The source code in my package is dual licensed, but one of the licenses is a proprietary license (the other is GPLv2+). You do not need to list the proprietary license in the License tag, so it should read: License: GPLv2+

All of the source code in my package is licensed as BSD, but when compiled, it is linked to a separate GPLv2 library. Do I need to use "GPLv2" as the License tag for my package?

No. You should only be considering the utilized source code in your package when determining your License tag.

What about interpreted languages (perl, python, etc)? If I have a package written in an interpreted language, and it pulls in code (of the same language) from a different, independent package at runtime, should I take its license into account when tagging my package?

No. You should only be considering the utilized source code in your package when determining your License tag.

What about the RSA license on their MD5 implementation? Isn't that GPL-incompatible?

The short answer is no, not in Fedora. Here's the long answer: The original RFC1321 reference code is here: http://www.faqs.org/rfcs/rfc1321.html

That code is under BSD with advertising (which is GPL incompatible). The contents of the RFC are explicitly stated to be freely redistributable (not public domain).

In 2000, RSA clarified some of the legal issues: http://www.ietf.org/ietf/IPR/RSA-MD-all

What they said was that:

Implementations of these message-digest algorithms, including implementations derived from the reference C code in RFC-1319, RFC-1320, and RFC-1321, may be made, used, and sold without license from RSA for any purpose.

This means that the RFC1321 reference implementation can be used without the license, and it effectively becomes Copyright only.

Accordingly, Fedora deals with this issue by implementing a policy that whenever we come across C code that implements RFC-1319, RFC-1320, and RFC-1321 (MD2, MD4, MD5) under the troublesome BSD with advertising clause, we will be using it without license from RSA.

In English, it means that we don't need to worry about resolving these conflicts, but we should advise upstream of the situation, and recommend that they "use" this code without RSA's license as well, and reflect that usage in the source code by removing RSA's license (but not RSA's copyright).

Retrieved from "https://fedoraproject.org/w/index.php?title=Licensing:FAQ&oldid=78926"