If a package's source is under a GPL-compatible license (say MIT), and it links against a GPL library (say readline's GPLv3+), what should the license field say? Maybe "MIT and GPLv3", with a comment explaining which library pulls in the GPLv3 requirement?
Thanks,
On 03/12/2011 11:42 AM, Michel Alexandre Salim wrote:
If a package's source is under a GPL-compatible license (say MIT), and it links against a GPL library (say readline's GPLv3+), what should the license field say? Maybe "MIT and GPLv3", with a comment explaining which library pulls in the GPLv3 requirement?
We don't try to calculate licensing across linkage in a package. Just use the license of the code that goes directly into the binaries within your package. So, in your example, it would be just "MIT".
~tom
== Fedora Project
On 03/14/2011 05:15 AM, Tom Callaway wrote:
On 03/12/2011 11:42 AM, Michel Alexandre Salim wrote:
If a package's source is under a GPL-compatible license (say MIT), and it links against a GPL library (say readline's GPLv3+), what should the license field say? Maybe "MIT and GPLv3", with a comment explaining which library pulls in the GPLv3 requirement?
We don't try to calculate licensing across linkage in a package. Just use the license of the code that goes directly into the binaries within your package. So, in your example, it would be just "MIT".
Thanks, Tom. Will revert the change at the next update. In this specific case, it does not really matter, but in cases where the package in question can be further linked with other programs, won't it be a bit misleading if the license is just, say, "MIT"?
I had such a problem recently; the pure package has an interpreter is linkable against either readline or libedit, but is under LGPL -- I switched it to libedit rather than have to worry about licensing issues. Come to think about it, as long as only the interpreter is linked against readline, and the shared library is not, there won't be a problem with GPL terms being propagated to binaries generated from sources written in pure...
Thanks,
On 03/16/2011 01:13 PM, Michel Alexandre Salim wrote:
Thanks, Tom. Will revert the change at the next update. In this specific case, it does not really matter, but in cases where the package in question can be further linked with other programs, won't it be a bit misleading if the license is just, say, "MIT"?
No, because we clearly document that "The License: field refers to the licenses of the contents of the binary rpm." (https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License:_field)
When you think about this, it might seem to make sense to incorporate linking into a package's license tag, after all, your app "foo" links to "libbar", and this seems obvious. But "libbar" links to "libbaz" and "libfish" and "libcat" and "libdog" and "libtree", all of which move and change independently, including new linking and license changes. Suddenly, the license tag on "foo" is constantly in flux.
So, instead, we have packages track the licenses of the contents of the binary rpm, and we use that data to determine cross package license compatibility, separately from the per-package info.
Hope that helps,
~tom
== Fedora Project
On 03/18/2011 05:38 AM, Tom Callaway wrote:
So, instead, we have packages track the licenses of the contents of the binary rpm, and we use that data to determine cross package license compatibility, separately from the per-package info.
Hope that helps,
Definitely, thanks. Would be nice to be able to see a visualization of the license tree for any given package, though.
On 03/18/2011 11:33 AM, Michel Alexandre Salim wrote:
On 03/18/2011 05:38 AM, Tom Callaway wrote:
So, instead, we have packages track the licenses of the contents of the binary rpm, and we use that data to determine cross package license compatibility, separately from the per-package info.
Hope that helps,
Definitely, thanks. Would be nice to be able to see a visualization of the license tree for any given package, though.
Sure, but that's easily enough done with python these days. Proof of concept is left to the reader.
~tom
== Fedora Project