User:Toshio/Licensing FAQ

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page. These are additional questions that come up about Licensing that haven't been added to the official FAQ. I'm compiling them here for later answering by Legal. In some cases where the answer seems to fall out of other answers in the FAQ I've added answers but they have not yet been run by legal. I've plainly marked these as needing legal review. Do not take anything on this page as official. Consult the official Legal FAQ for only the questions that have been run by legal and answered. If you need something on this page answered immediately, please run it by spot (Tom Callaway) or the Fedora Legal list; do not accept what's written here as an answer without approval from them.

Frequently Asked Questions about Fedora Licensing

General

Does the License: tag cover the SRPM or the binary RPM?

Answer needs fedora-legal review

It covers what is shipped in the binary RPM. Usually you'll find that packages have a single license so the SRPM and binary RPM are the same but in some cases there are multiple licenses in the source code. See #Multiple licensing situations for how to deal with these.

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.

We do make a notable exception for firmware files, since many common hardware devices cannot function without them.

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

Fedora Project itself has no interest in this. Third party repositories exist for such purposes.

Multiple licensing situations

What is "effective license" and do I need to know that for the License: tag?

Needs Fedora Legal review
Answer slightly revised from http://lists.fedoraproject.org/pipermail/legal/2010-July/001342.html

When you have a combined work that contains source files under multiple, compatible licenses, the combined work is "effectively" under the strictest license; the one that has all of the terms and conditions of the others (and possibly additional ones as well). For example, if the source of the package contains code licensed under the GPLv2, GPLv2+, and LGPLv2+, the resultant binary is "effectively" GPLv2 because that represents the strictest set of licensing terms, and by complying with those terms, you also satisfy the other license terms (GPLv2+ and LGPLv2+). If none of the licenses is a full superset of the terms and conditions of all the other licenses then none of the licenses may be used as the "effective license".

Obviously, this can quickly get complicated and confusing, but if your package is a compilation dependency for other packages (e.g. a library), then presenting the effective license can be beneficial to others attempting to determine cross-package license compatibility.

So, if you are comfortable calculating the effective license it can be helpful to others to use that in the License: field. If you're not comfortable, or you wish you be precise in how you populate the License: field, you may list all of the licenses in the source that were compiled together to make the combined work in the binary rpm.

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+

Does it matter if the compiled rpm is both a combined work and usable as multiple files?

Unknown. Needs Fedora Legal answer

For instance, a static library, libfoo.a, is compiled from mit.c (licensed MIT) and gpl.c (licensed GPLv2). The functions in the source file might not depend on each other but the combined work would be licensed as GPLv2 according to the above.

A python module, %{python_sitelib}/foo/, might contain several python files mit.py and gpl.py, licensed like the above and containing functions that do not depend on each other. Code that uses this module might only end up importing the mit.py file or might only end up importing the gpl.py file. Since these files are independently accessible, the package license tag should reflect both MIT and GPLv2 licenses.

Linking and multiple licenses

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 if the package is linked statically to the GPLv2 library?

Unknown. Need Fedora Legal answer

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.

Specific Licenses

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.

BSD with advertising

What's the deal with the BSD with advertising license?

The original BSD license is commonly found in FOSS code, but it contains an "advertising clause" which makes it incompatible with the GPL (all versions).

The advertising clause was removed from the official BSD license text on July 22, 1999 by William Hoskins, the director of the office of technology licensing for Berkeley. From: ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change

July 22, 1999

To All Licensees, Distributors of Any Version of BSD:

As you know, certain of the Berkeley Software Distribution ("BSD") source
code files require that further distributions of products containing all or
portions of the software, acknowledge within their advertising materials
that such products contain software developed by UC Berkeley and its
contributors.

Specifically, the provision reads:

"     * 3. All advertising materials mentioning features or use of this software
      *    must display the following acknowledgement:
      *    This product includes software developed by the University of
      *    California, Berkeley and its contributors."

Effective immediately, licensees and distributors are no longer required to
include the acknowledgement within advertising materials.  Accordingly, the
foregoing paragraph of those BSD Unix files containing it is hereby deleted
in its entirety.

William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley

So, this means any code which is under the old BSD with advertising license where the copyright holder is "Regents of the University of California" or "University of California, Berkeley" is effectively under the regular BSD license. You can use that code without the advertising clause, and you should also ask upstream to remove the advertising clause from their code. For purposes of spec labeling, use "BSD".

NOTE: This does NOT apply to any code where the copyright holder is not "Regents of the University of California" or "University of California, Berkeley". In that situation, the advertising clause is still in effect, and if it causes a compatibility issue, you will need to ask the copyright holder to drop the advertising clause.

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).

What's the deal with the OpenSSL license?

Needs Fedora Legal Review
Some information taken from http://people.gnome.org/~markmc/openssl-and-the-gpl.html and some from http://lists.fedoraproject.org/pipermail/legal/2009-May/000715.html

Similar to the #BSD with advertising license, the OpenSSL license contains a couple clauses that don't make it non-free but do make it incompatible with the GPL (all versions).

  * 3. All advertising materials mentioning features or use of this
  *    software must display the following acknowledgment:
  *    "This product includes software developed by the OpenSSL Project
  *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
  * 6. Redistributions of any form whatsoever must retain the following
  *    acknowledgment:
  *    "This product includes software developed by the OpenSSL Project
  *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"

These two clauses are restrictions that aren't present in the GPL and therefore are incompatible with the portion of the GPL that says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."

However, we consider that the OpenSSL library is a system library, as defined by the GPL, on Fedora and therefore we are allowed to ship GPL software that links to the OpenSSL library. Treatment of OpenSSL as a system library does not extend to other operating systems or even some other Linux distributions, however, so upstreams that do this should definitely be encouraged to add an exception to their GPL licensed code that allows linking to OpenSSL. The Free Software Foundation has a FAQ entry on how to write such an exception.