OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
Thanks,
~spot
On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote:
Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL Compatibility Matrix?
Regards, Till
On Fri, 2007-07-27 at 01:13 +0200, Till Maas wrote:
On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote:
Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL Compatibility Matrix?
Because the FSF makes no distinction. I don't think there would be any difference, since there is not currently a "later".
~spot
On Thu, 2007-07-26 at 19:24 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-07-27 at 01:13 +0200, Till Maas wrote:
On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote:
Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL Compatibility Matrix?
Because the FSF makes no distinction. I don't think there would be any difference, since there is not currently a "later".
If this is true, I have a slightly cosmetic comment:
GPL and LGPL get an "or later" clause while other licenses would have to jump through the dual license hoops to achieve the same thing. Perhaps it would be better to define an "operator" to mean or later?
(And I nominate "+=" as the most logical and ugliest operator for the job :-)
-Toshio
On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote:
On Thu, 2007-07-26 at 19:24 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-07-27 at 01:13 +0200, Till Maas wrote:
On Friday 27 July 2007 01:27:59 Tom "spot" Callaway wrote:
Why are no "(L)GPLv3" columns and "(L)GPLv3 or later" rows in the GPL Compatibility Matrix?
Because the FSF makes no distinction. I don't think there would be any difference, since there is not currently a "later".
If this is true, I have a slightly cosmetic comment:
GPL and LGPL get an "or later" clause while other licenses would have to jump through the dual license hoops to achieve the same thing. Perhaps it would be better to define an "operator" to mean or later?
(And I nominate "+=" as the most logical and ugliest operator for the job :-)
A comparison operator (>=) would make more sense
On Fri, 2007-07-27 at 02:16 +0200, Axel Thimm wrote:
On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote:
(And I nominate "+=" as the most logical and ugliest operator for the job :-)
A comparison operator (>=) would make more sense
Your nomination is definitely more logical, but no less ugly :-(
License: GPLv2 >= || MPLv1.1
We could break the version apart from the license tag. I don't know if that makes it harder for spot's use case or not::
License: GPL >= v2 || MPL == v1.1
-Toshio
On Thu, Jul 26, 2007 at 10:05:29PM -0700, Toshio Kuratomi wrote:
On Fri, 2007-07-27 at 02:16 +0200, Axel Thimm wrote:
On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote:
(And I nominate "+=" as the most logical and ugliest operator for the job :-)
A comparison operator (>=) would make more sense
Your nomination is definitely more logical, but no less ugly :-(
License: GPLv2 >= || MPLv1.1
I didn't imply postfix notation.
We could break the version apart from the license tag. I don't know if that makes it harder for spot's use case or not::
License: GPL >= v2 || MPL == v1.1
Me thinks that spot and anyone else will be more than capable to parse anything properly, even if it's "or" instead of "||" and ">=" instead of "+=$%&/§"
The most important thing is to not disrupt current packaging practices too much. What this means is that if 99% of current "GPL >= v2" packages have "GPL" in their License: tag, then simply define "GPL" to mean that and only fix th remain one percent.
Currently it looks like there would be a mass rebuild for License tags only. I'm all for at least one mass rebuild per release, but not for a retagging of Licenses to Polish notation like parsing structures.
Le vendredi 27 juillet 2007 à 02:16 +0200, Axel Thimm a écrit :
On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote:
(And I nominate "+=" as the most logical and ugliest operator for the job :-)
A comparison operator (>=) would make more sense
≥ please
On Sun, 2007-08-12 at 19:11 +0200, Nicolas Mailhot wrote:
Le vendredi 27 juillet 2007 à 02:16 +0200, Axel Thimm a écrit :
On Thu, Jul 26, 2007 at 04:34:00PM -0700, Toshio Kuratomi wrote:
(And I nominate "+=" as the most logical and ugliest operator for the job :-)
A comparison operator (>=) would make more sense
≥ please
Given that we ended up dropping computer-logical operators for human-logical ones, this is not only semantics, but irrelevant semantics. :)
~spot
On 7/26/07, Tom spot Callaway tcallawa@redhat.com wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
I find the reading of && || to be a little hard. Wouldnt it be better to use the or as in the Perl license way? or was there a legal reason for not to.. beyond that I think the two are good.Parenthesis I do not have a problem with.
On Thu, 26 Jul 2007 17:17:30 -0600 "Stephen John Smoogen" smooge@gmail.com wrote:
I find the reading of && || to be a little hard. Wouldnt it be better to use the or as in the Perl license way? or was there a legal reason for not to.. beyond that I think the two are good.Parenthesis I do not have a problem with.
Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and 'and' perhaps? Just guessing.
On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote:
On Thu, 26 Jul 2007 17:17:30 -0600 "Stephen John Smoogen" smooge@gmail.com wrote:
I find the reading of && || to be a little hard. Wouldnt it be better to use the or as in the Perl license way? or was there a legal reason for not to.. beyond that I think the two are good.Parenthesis I do not have a problem with.
Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and 'and' perhaps? Just guessing.
This is precisely why.
~spot
On Thu, 2007-07-26 at 19:23 -0500, Tom "spot" Callaway wrote:
On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote:
On Thu, 26 Jul 2007 17:17:30 -0600 "Stephen John Smoogen" smooge@gmail.com wrote:
I find the reading of && || to be a little hard. Wouldnt it be better to use the or as in the Perl license way? or was there a legal reason for not to.. beyond that I think the two are good.Parenthesis I do not have a problem with.
Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and 'and' perhaps? Just guessing.
This is precisely why.
Looks entirely over the top to me. Can we make packaging any harder ? I'm all for somewhat accurate license tags, but if the goal is to make spec files machine parsable, then why not go to xml straight away ? And what is the purpose of commenting licenses in the file list, apart from making the packagers life miserable ?
On Thu, 2007-07-26 at 19:25 -0400, Matthias Clasen wrote:
And what is the purpose of commenting licenses in the file list, apart from making the packagers life miserable ?
I agree. Or at least, I disagree with the example and scope in the Draft. I don't think we care what the license of an individual built program is. We might care what the license of a built library is.
Whether it's better to mark libraries with a spec comment or make it mandatory to split libraries that are licensed differently from other code, I don't know, though.
-Toshio
On Thu, 2007-07-26 at 16:47 -0700, Toshio Kuratomi wrote:
On Thu, 2007-07-26 at 19:25 -0400, Matthias Clasen wrote:
And what is the purpose of commenting licenses in the file list, apart from making the packagers life miserable ?
I agree. Or at least, I disagree with the example and scope in the Draft. I don't think we care what the license of an individual built program is. We might care what the license of a built library is.
Whether it's better to mark libraries with a spec comment or make it mandatory to split libraries that are licensed differently from other code, I don't know, though.
How would we know if there is a problem if program X links to lib Y if we don't have the licenses of both available.
-sv
On Thu, 2007-07-26 at 20:08 -0400, seth vidal wrote:
On Thu, 2007-07-26 at 16:47 -0700, Toshio Kuratomi wrote:
On Thu, 2007-07-26 at 19:25 -0400, Matthias Clasen wrote:
And what is the purpose of commenting licenses in the file list, apart from making the packagers life miserable ?
I agree. Or at least, I disagree with the example and scope in the Draft. I don't think we care what the license of an individual built program is. We might care what the license of a built library is.
Whether it's better to mark libraries with a spec comment or make it mandatory to split libraries that are licensed differently from other code, I don't know, though.
How would we know if there is a problem if program X links to lib Y if we don't have the licenses of both available.
You don't need the licenses to the same granularity to determine the degree to which relicensing will cause problems::
Program changes license. 1) Use ldd to find which libraries we link to. 2) Use repoquery to find out which libraries have incompatible licenses.[1]_ 3) Look at the library spec file to determine which library is incompatible and whether the program even uses the particular library that has the issue. 4) Package maintainers figure out whether we can do anything to save the situation or have to discard one of the packages.
Library changes license. 1) Use repoquery to find out which programs link. 2) Use repoquery on the programs to find out which programs have incompatible licenses.[1]_ 3) Package maintainers figure out whether we can do anything to save the situation or have to throw out one or the other package.
Figuring out which program in a package has an incompatible license doesn't add value for the library maintainer as they have to involve the program maintainer in order to fix the situation no matter what. On the contrary figuring out which library has a license issue could allow the program maintainer to determine that they can fix the issue without involving the other maintainer.
[1]_: Looks like repoquery needs to be enhanced to show the license tag.
-Toshio
On Thu, Jul 26, 2007 at 07:25:58PM -0400, Matthias Clasen wrote:
On Thu, 2007-07-26 at 19:23 -0500, Tom "spot" Callaway wrote:
On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote:
On Thu, 26 Jul 2007 17:17:30 -0600 "Stephen John Smoogen" smooge@gmail.com wrote:
I find the reading of && || to be a little hard. Wouldnt it be better to use the or as in the Perl license way? or was there a legal reason for not to.. beyond that I think the two are good.Parenthesis I do not have a problem with.
Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and 'and' perhaps? Just guessing.
This is precisely why.
Looks entirely over the top to me. Can we make packaging any harder ? I'm all for somewhat accurate license tags, but if the goal is to make spec files machine parsable, then why not go to xml straight away ? And what is the purpose of commenting licenses in the file list, apart from making the packagers life miserable ?
Matthias is right, I start feeling like if we're trying to top Debian on the area of over-bureaucratisation.
On 7/26/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Thu, 2007-07-26 at 19:19 -0400, Jesse Keating wrote:
On Thu, 26 Jul 2007 17:17:30 -0600 "Stephen John Smoogen" smooge@gmail.com wrote:
I find the reading of && || to be a little hard. Wouldnt it be better to use the or as in the Perl license way? or was there a legal reason for not to.. beyond that I think the two are good.Parenthesis I do not have a problem with.
Machine parsing? '||' and '&&' is easier to catch/parse than 'or' and 'and' perhaps? Just guessing.
This is precisely why.
Ahh I figured that and/or could be done by computer while humans have to read the text. I can see the weird questions that will come up over time.
On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
I think that's missing a scenario.
Covered: You can have License A or License B (Dual license)
You can have License A on /usr/bin/foo and License B on /usr/bin/bar (Multiple Licensing)
Not Covered: You can have License A on foo.c and License B on bar.c being linked together to form /usr/bin/foobar (A different kind of multiple licensing)
With GPLv2 as one of the licenses, this shouldn't be an issue because the GPLv2 states that you can't have additional restrictions so for our purposes[1]_, saying the package is GPL is fine. But there could be code under two licenses in which this does matter, for instance BSD with advert clause and a second license which specifies that modifications must be shipped as patches on top of upstream.
[1]_: Provided that "our purposes" is internal package audit and not information for developers. Someone outside Fedora looking for code to include in their project could be interested in knowing that 90% of /usr/bin/foo is public domain and only one GPL source file makes the whole thing GPL.
-Toshio
On Thu, 2007-07-26 at 16:18 -0700, Toshio Kuratomi wrote:
On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
I think that's missing a scenario.
Covered: You can have License A or License B (Dual license)
You can have License A on /usr/bin/foo and License B on /usr/bin/bar (Multiple Licensing)
Not Covered: You can have License A on foo.c and License B on bar.c being linked together to form /usr/bin/foobar (A different kind of multiple licensing)
Wouldn't that effectively be a dual license on /usr/bin/foobar? Except, it would be a dual AND instead of a dual OR.
How about we call that "Mixed Source Licensing":
=== Mixed Source Licensing Scenario === In some cases, it is possible for a binary to be generated from multiple source files with compatible, but differing licenses. For example, it is possible that a binary is generated from a source file licensed as BSD with advertising, and another source file licensed as QPL (which specifies that modifications must be shipped as patches). In this scenario, we'd mark the license as (BSD with advertising && QPL).
~spot
On Fri, 2007-07-27 at 00:28 -0500, Tom "spot" Callaway wrote:
On Thu, 2007-07-26 at 16:18 -0700, Toshio Kuratomi wrote:
On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
I think that's missing a scenario.
Covered: You can have License A or License B (Dual license)
You can have License A on /usr/bin/foo and License B on /usr/bin/bar (Multiple Licensing)
Not Covered: You can have License A on foo.c and License B on bar.c being linked together to form /usr/bin/foobar (A different kind of multiple licensing)
Wouldn't that effectively be a dual license on /usr/bin/foobar? Except, it would be a dual AND instead of a dual OR.
Yes.
How about we call that "Mixed Source Licensing":
=== Mixed Source Licensing Scenario === In some cases, it is possible for a binary to be generated from multiple source files with compatible, but differing licenses. For example, it is possible that a binary is generated from a source file licensed as BSD with advertising, and another source file licensed as QPL (which specifies that modifications must be shipped as patches). In this scenario, we'd mark the license as (BSD with advertising && QPL).
This mixes the operator for multiple licensing with mixed source licensing, though. Since I agree that this is another type of dual license, how about making parens [()] mandatory for dual licensing whether or not there are other licenses involved? Then we have:
Separate built files are under separate licenses QPL && BSD Single built file is under one of multiple licenses (QPL || BSD) Single built file is under more than one license (QPL && BSD)
Versions, as amended by notting:
Specific version: v# Specific version or later: v#+
So, AIUI, Firefox would be under: License: (GPLv2+ || LGPLv2.1+ || MPLv1.1+)
-Toshio
Le jeudi 26 juillet 2007 à 22:33 -0700, Toshio Kuratomi a écrit :
So, AIUI, Firefox would be under: License: (GPLv2+ || LGPLv2.1+ || MPLv1.1+)
This kind of notation is pretty useless. in theory many packages are dual or tri-licensed. In reality the multi-licensing if often collapsed due to deps (upstream or downstream) that impose one particular license. If we go the "or" route no one will check, and everyone will assume the most permissive license applies (even if it's not the case due to the packages fedora builds again)
IMHO in the case of multi-licensing we should choose one of the possible licenses and stick with it. Only revisit the choice if another fedora package forces us to, and let the packager of this other package do the licensing analysis.
This is different from the case where different bits of a component are under different licences. There we have no choice but carefully track licensing boundaries?
On Fri, 27 Jul 2007 09:47:52 +0200 Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
IMHO in the case of multi-licensing we should choose one of the possible licenses and stick with it. Only revisit the choice if another fedora package forces us to, and let the packager of this other package do the licensing analysis.
We can't just do that, as we also provide them the srpm/source which is not yet linked to anything, and thus is not limited to which license the end user chooses to receive/use the source under.
WHEEEEEEE!
On Fri, 2007-07-27 at 09:47 +0200, Nicolas Mailhot wrote:
Le jeudi 26 juillet 2007 à 22:33 -0700, Toshio Kuratomi a écrit :
So, AIUI, Firefox would be under: License: (GPLv2+ || LGPLv2.1+ || MPLv1.1+)
This kind of notation is pretty useless. in theory many packages are dual or tri-licensed. In reality the multi-licensing if often collapsed due to deps (upstream or downstream) that impose one particular license. If we go the "or" route no one will check, and everyone will assume the most permissive license applies (even if it's not the case due to the packages fedora builds again)
IMHO in the case of multi-licensing we should choose one of the possible licenses and stick with it. Only revisit the choice if another fedora package forces us to, and let the packager of this other package do the licensing analysis.
I think the problem is that when Firefox is under GPLv2+, LGPLv2.1+ and MPLv1.1+, differing Fedora packages that want to link to it will each choose the appropriate license that matches it, for linking purposes.
So, we really can't just pick a license and stick with it, because that's just not correct. I'm also not sure I want the packager to bear the burden, and I suspect the various upstreams would get rather angry over our attempts to "simplify" their licensing. :)
We've had a sort of "or" route for a while now (Foo/Bar/Baz), but the problem is that we've also had packagers using that as an "and" where it applies.
Also, I've found that most packagers either don't want to, or aren't qualified to do licensing analysis. I'm getting better at it through practice, but I'm certainly not perfect either (which is why I defer to the thoughts of more skilled folks, either at Red Hat or the FSF, when I have any doubt).
This is different from the case where different bits of a component are under different licences. There we have no choice but carefully track licensing boundaries?
Well, I wouldn't say we have no choice, since we've not been doing this in Fedora so far, but it certainly seems to be a logical continuation (at least to me). Having a list of all the licenses that all the files in a package uses is useful, but when one of those files has a license related conflict (I linked against foo in package bar, was it GPLv3 or not?), it would be very helpful to have a quick way to check at a glance, without exploding a source tree.
~spot
Tom spot Callaway (tcallawa@redhat.com) said:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) and 'GPLv2+' (GPL version 2 or later).
I think the tagging per file in comments is definitely overkill.
Bill
On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) and 'GPLv2+' (GPL version 2 or later).
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
~spot
Tom spot Callaway (tcallawa@redhat.com) said:
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
73 packages that I have installed have some sort of multiple licensing.
Bill
On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
73 packages that I have installed have some sort of multiple licensing.
73 out of how many? How many of those packages could be reworked to use subpackages instead?
~spot
Tom spot Callaway (tcallawa@redhat.com) said:
73 packages that I have installed have some sort of multiple licensing.
73 out of how many? How many of those packages could be reworked to use subpackages instead?
Out of 1279, which extrapolates to ~450 over the whole repository. Are you seriously suggesting we start splitting 400+ packages differently than they are now?
The goal is to get something *simple*.
Bill
On Thu, 2007-07-26 at 20:49 -0500, Tom "spot" Callaway wrote:
On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
73 packages that I have installed have some sort of multiple licensing.
73 out of how many? How many of those packages could be reworked to use subpackages instead?
In addition, keep in mind that truly "dual/triple" licensed packages don't need this, only the "Various licenses" or "Assorted licenses" would.
Listing them all in the License field is only step 1. Step 2 is being able to determine what, in that package, actually has what license, and having the packager do this makes step 2 a lot simpler.
Utopia: RPM could support License(STRING), then we could have multiple license tags for packages. But as said many times before, we work with what we have, and if better things come along in RPM, we move to them.
~spot
On Friday 27 July 2007, Tom "spot" Callaway wrote:
Utopia: RPM could support License(STRING), then we could have multiple license tags for packages.
Provides could be (ab?)used for that, eg:
Provides: License(Apache2), License(BSD) Provides: License(Artistic||GPLv2+)
On Sat, 2007-07-28 at 12:15 +0300, Ville Skyttä wrote:
On Friday 27 July 2007, Tom "spot" Callaway wrote:
Utopia: RPM could support License(STRING), then we could have multiple license tags for packages.
Provides could be (ab?)used for that, eg:
Provides: License(Apache2), License(BSD) Provides: License(Artistic||GPLv2+)
Wow. I can just hear yum choking on itself and dying.
I'd feel very sorry for the first person who did:
yum install "License(BSD)"
~spot
On Sat, 28 Jul 2007 10:49:33 -0500 "Tom "spot" Callaway" tcallawa@redhat.com wrote:
yum install "License(BSD)"
Shortest name would win. You'd get one (maybe two for multilib) packages installed, at most.
On Sat, 28 Jul 2007, Tom \spot\ Callaway wrote:
On Sat, 2007-07-28 at 12:15 +0300, Ville Skyttä wrote:
On Friday 27 July 2007, Tom "spot" Callaway wrote:
Utopia: RPM could support License(STRING), then we could have multiple license tags for packages.
Provides could be (ab?)used for that, eg:
Provides: License(Apache2), License(BSD) Provides: License(Artistic||GPLv2+)
Wow. I can just hear yum choking on itself and dying.
I'd feel very sorry for the first person who did:
yum install "License(BSD)"
Yeah, provides wont do.
Dunno if you saw my "utopia" mail in this thread - some of it might be utter utopia but not all. I'm willing to help from rpm side, we just need to figure out what exactly is it that'd needed. Getting rpm enhacements widely deployed is a slooooooooooooow process so it'd better be reasonably well defined by the first attempt :)
- Panu -
On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
73 packages that I have installed have some sort of multiple licensing.
?? 90% of all perl packages are multiple licensed. These alone make several 100s of packages.
Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL.
Also I am still missing a detailed list of all tags you want to force us to use for BSD*ish, X11*ish and other licenses
Ralf
On Fri, 2007-07-27 at 06:10 +0200, Ralf Corsepius wrote:
On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
73 packages that I have installed have some sort of multiple licensing.
?? 90% of all perl packages are multiple licensed. These alone make several 100s of packages.
90% of perl packages are _dual_ licensed, and thus, wouldn't need to do this.
Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL.
Also I am still missing a detailed list of all tags you want to force us to use for BSD*ish, X11*ish and other licenses
These aren't licenses. Either it is BSD or X11 or it is something else.
~spot
On Fri, 2007-07-27 at 00:29 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-07-27 at 06:10 +0200, Ralf Corsepius wrote:
On Thu, 2007-07-26 at 20:50 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
73 packages that I have installed have some sort of multiple licensing.
?? 90% of all perl packages are multiple licensed. These alone make several 100s of packages.
90% of perl packages are _dual_ licensed,
Yes, GPL or Artistic.
and thus, wouldn't need to do this.
I don't see this.
Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL.
Also I am still missing a detailed list of all tags you want to force us to use for BSD*ish, X11*ish and other licenses
These aren't licenses. Either it is BSD or X11 or it is something else.
BS. Of cause they are licenses.
A RH owned BSD'ish license is something completely different as a UCB owned BSD'ish license. They probably are compatible but that's all.
Different copyright owners, different licensors => different licenses.
This hits esp. when licensors change their licenses, as it had been several times been the case in case of the X11 licenses.
Ralf
I don't see this.
Perhaps I've not been clear on when you would need to generate a license/file list.
When a package has a consistent license (or dual/triple license) for all of its files (not including docs or content), it does not need to have a license file list.
It is only when the package has multiple files with differing licenses that this is useful, and thus, required.
Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL.
Also I am still missing a detailed list of all tags you want to force us to use for BSD*ish, X11*ish and other licenses
These aren't licenses. Either it is BSD or X11 or it is something else.
BS. Of cause they are licenses.
OK, let me rephrase. Yes, these items are licenses, but "BSD-ish" is not a license. Merely changing the copyright holder in the BSD license text does _not_ make the license not BSD. It is only when the terms of the license are altered by the copyright holder that the license stops being BSD. At that point, the license isn't BSD, it is something new. Depending on what those changes are, the new license is either ok for Fedora or it is not. When this new license gets submitted for approval, it will be added to the Licensing table, and given a new short name, with a link to the Licensing text.
"BSD-ish" is as useless as "Distributable", in that it tells us nothing about the potential license compatibility. Two packages with "BSD-ish" as a license could be identical or wholly incompatible, and this is precisely the problem that we're trying to avoid.
~spot
On Fri, 2007-07-27 at 01:21 -0500, Tom "spot" Callaway wrote:
I don't see this.
Perhaps I've not been clear on when you would need to generate a license/file list.
When a package has a consistent license (or dual/triple license) for all of its files (not including docs or content), it does not need to have a license file list.
The problem with dual licensed packages is: "Which license applies in a particular situation" - Your approach doesn't cope with this case.
It is only when the package has multiple files with differing licenses that this is useful, and thus, required.
OK, but the later is the common case on most "non-trivial" packages, which often apply the GPL as "umbrella". Also, these latter packages, are those who often come along with diverging "run-time" licenses (in most cases the "umbrella" rules) and "source-code" licenses (often different licenses on different files).
Your approach is not considering the latter case.
Not worth mentioning KDE/Qt which typically are licensed GPL*+QPL.
Also I am still missing a detailed list of all tags you want to force us to use for BSD*ish, X11*ish and other licenses
These aren't licenses. Either it is BSD or X11 or it is something else.
BS. Of cause they are licenses.
OK, let me rephrase. Yes, these items are licenses, but "BSD-ish" is not a license.
Right, you would have to cite the complete license with its exact wording being applied.
Merely changing the copyright holder in the BSD license text does _not_ make the license not BSD.
That's true, but if you don't track copyright holders, your automatic tracking system is more or less worthless.
* Consider X10/X11's history: The code base still originates back to the X10/Athena/MIT days, but the code's owners have changed several times, the code had been forked many times. If you had tried to track this as "X11" your automated tracking would not have caught the potential license incompatibilities being introduced to other packages relying on X11 being "X11/MIT/Athena"-license (You might recall these incompatibilities having been the cause for X11 to fork several times.)
* Consider the original UCB license: UCB has declared _their_ "ad-clause" invalid. So if you had tracked their packages as "BSD", you would not have caught any of the packages having been affect by their change in policy.
It is only when the terms of the license are altered by the copyright holder that the license stops being BSD. At that point, the license isn't BSD, it is something new.
Yes, it's yet another variant ... one amongst 100s if not 1000s existing around.
Depending on what those changes are, the new license is either ok for Fedora or it is not. When this new license gets submitted for approval, it will be added to the Licensing table, and given a new short name, with a link to the Licensing text.
"BSD-ish" is as useless as "Distributable", in that it tells us nothing about the potential license compatibility. Two packages with "BSD-ish" as a license could be identical or wholly incompatible, and this is precisely the problem that we're trying to avoid.
Exactly: The Fedora License Register would have to track each of these licenses with their copyright holders individually. The point why I am laughing at you and your wiki.
Ralf
On Fri, 27 Jul 2007 08:12:18 +0200 Ralf Corsepius rc040203@freenet.de wrote:
Exactly: The Fedora License Register would have to track each of these licenses with their copyright holders individually. The point why I am laughing at you and your wiki.
Ignoring (or laughing at) the problem does not make it go away. So instead of just telling us how all our ideas suck and we're all dumb and unworthy of working on Fedora, why don't you offer some constructive feedback and help us solve the problem?
Jesse Keating wrote:
On Fri, 27 Jul 2007 08:12:18 +0200 Ralf Corsepius rc040203@freenet.de wrote:
Exactly: The Fedora License Register would have to track each of these licenses with their copyright holders individually. The point why I am laughing at you and your wiki.
Ignoring (or laughing at) the problem does not make it go away. So instead of just telling us how all our ideas suck and we're all dumb and unworthy of working on Fedora, why don't you offer some constructive feedback and help us solve the problem?
Seems to me, that at least in part, Ralf disagrees with the assertion that a problem exists that is worth all this pain of solving.
-- Rex
On Fri, 27 Jul 2007 08:08:21 -0500 Rex Dieter rdieter@math.unl.edu wrote:
Seems to me, that at least in part, Ralf disagrees with the assertion that a problem exists that is worth all this pain of solving.
You mean the problem of mixing thousands of packages together of varying licenses which may or may not be incompatible? I don't see how you can possibly think this problem doesn't exist.
On Fri, Jul 27, 2007 at 10:14:48AM -0400, Jesse Keating wrote:
On Fri, 27 Jul 2007 08:08:21 -0500 Rex Dieter rdieter@math.unl.edu wrote:
Seems to me, that at least in part, Ralf disagrees with the assertion that a problem exists that is worth all this pain of solving.
I also still try to understand where the need for this change comes from, see my other mail in this thread.
You mean the problem of mixing thousands of packages together of varying licenses which may or may not be incompatible? I don't see how you can possibly think this problem doesn't exist.
But didn't we had to deal with this problem on a per package basis until now and will have to do so no matter what overly complex parsing system will be installed?
Take for example madwifi, a "GPL2v += || BSDwhatever" licensed software that should be compatible according to the parser with the "GPL2v || syscalls exceptions" kernel ...
So you'll creating a mesh where elefants can slip through, and at the end we'll only have added bureaucracy for the packagers with no added value whatsoever - packages will have to be checked against their build and runtime depdencies carefully llllike they had to until now.
You can't replace a legal review with a parser ...
On Fri, 2007-07-27 at 16:56 +0200, Axel Thimm wrote:
You can't replace a legal review with a parser ...
This is not the attempt to replace legal review, it is the attempt to enable a first pass check for obvious package incompatibilities.
I'm reworking the draft to try and make it simpler, based on the constructive feedback received.
~spot
(Trying to add some constructive criticism now...)
I think it would be good if we could ensure that the list of "approved" licenses and their official abbreviations would be in sync with what rpmlint considered valid licenses before this is put in place. Even better if rpmlint had knowledge of the new, machine-readable, license tag syntax and could validate that, too.
Matthias
On Fri, 2007-07-27 at 12:38 -0400, Matthias Clasen wrote:
(Trying to add some constructive criticism now...)
I think it would be good if we could ensure that the list of "approved" licenses and their official abbreviations would be in sync with what rpmlint considered valid licenses before this is put in place. Even better if rpmlint had knowledge of the new, machine-readable, license tag syntax and could validate that, too.
Agreed. I can work on that.
~spot
On 7/26/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) and 'GPLv2+' (GPL version 2 or later).
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
Hmmm would it be simpler to just have an included PACKAGE-LICENSES file that you would then audit? That would keep the SPEC file from getting overly ugly in some cases, and make your job a lot simpler by giving out a tool that they could check to see if something matches/doesnt match the PACKAGE-LICENSES. We could then share that with our friends at Debian etc unless they have such a tool that we could use.
On 7/26/07, Stephen John Smoogen smooge@gmail.com wrote:
On 7/26/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) and 'GPLv2+' (GPL version 2 or later).
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
Hmmm would it be simpler to just have an included PACKAGE-LICENSES file that you would then audit? That would keep the SPEC file from getting overly ugly in some cases, and make your job a lot simpler by giving out a tool that they could check to see if something matches/doesnt match the PACKAGE-LICENSES. We could then share that with our friends at Debian etc unless they have such a tool that we could use.
PS. Not trying to be a pain in the ass to the guy who took over something I half assed did back in FC2 or so.. who just drove across the country, and hasnt found where they serve grits in Boston (so he can either have or avoid).
On Thu, 2007-07-26 at 20:07 -0600, Stephen John Smoogen wrote:
On 7/26/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) and 'GPLv2+' (GPL version 2 or later).
I think the tagging per file in comments is definitely overkill.
Most packages won't need it, and for those that do, it will make the task for whomever is auditing the package (re: me) much simpler.
Hmmm would it be simpler to just have an included PACKAGE-LICENSES file that you would then audit? That would keep the SPEC file from getting overly ugly in some cases, and make your job a lot simpler by giving out a tool that they could check to see if something matches/doesnt match the PACKAGE-LICENSES. We could then share that with our friends at Debian etc unless they have such a tool that we could use.
I'm not opposed to that at all.
Again, just to reiterate:
If the package is dual licensed for all of its bits (e.g. perl-foo, License: GPL or Artistic), you wouldn't need to do this.
You'd only need to do this if you had a package with a lot of files with differing licenses.
~spot
On Thu, 2007-07-26 at 20:31 -0400, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
For versioning, I prefer the much shorter 'GPLv2' (GPL version 2 only) and 'GPLv2+' (GPL version 2 or later).
I'm not opposed to that.
I think the tagging per file in comments is definitely overkill.
Again, most packages won't need this, its only in the case of packages with multiple files that are under different licenses. We're talking less than 1% of packages in Fedora. (Note that documentation licensing doesn't trigger this, nor would differing content licensing in the same package).
~spot
On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
-1
As I understand it, you are trying mandate versioned license tags. Such an approach is inapplicable without a "license tags" register being actively maintained by an "licence tag administration office".
In other words, to me your proposal is equivalent to mandating cars carring license tags but allowing car owner to "paint them themselves".
This can't work.
Ralf
On Fri, 2007-07-27 at 05:51 +0200, Ralf Corsepius wrote:
On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
-1
As I understand it, you are trying mandate versioned license tags. Such an approach is inapplicable without a "license tags" register being actively maintained by an "licence tag administration office".
In other words, to me your proposal is equivalent to mandating cars carring license tags but allowing car owner to "paint them themselves".
Ralf, there really isn't any other way to solve the problem without having a list of standard license identifiers.
The http://fedoraproject.org/wiki/Licensing page is the license registry. I'm volunteering to lead the effort to maintain it, since I've effectively been doing that for more than a year now.
I'm more than willing to take on additional helpers to maintain this license registry. I'm very willing to alter the license identifiers to make they more simplistic, but without that baseline standard, it won't be possible to predictably track license data from packages.
~spot
On Fri, 2007-07-27 at 00:34 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-07-27 at 05:51 +0200, Ralf Corsepius wrote:
On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
-1
As I understand it, you are trying mandate versioned license tags. Such an approach is inapplicable without a "license tags" register being actively maintained by an "licence tag administration office".
In other words, to me your proposal is equivalent to mandating cars carring license tags but allowing car owner to "paint them themselves".
Ralf, there really isn't any other way to solve the problem without having a list of standard license identifiers.
Then think your thought to an end and implement the required administration bureau first.
Right now, you are stopping half-ways, and therefore fail to see the bureaucracy you are trying to push onto fedora contributors. RH is going to force Fedora into a more bureaucratic than Debian has ever been.
The http://fedoraproject.org/wiki/Licensing page is the license registry. I'm volunteering to lead the effort to maintain it, since I've effectively been doing that for more than a year now.
ROTFL - You can't be serious to call this an infrastructure.
I'm more than willing to take on additional helpers to maintain this license registry. I'm very willing to alter the license identifiers to make they more simplistic, but without that baseline standard, it won't be possible to predictably track license data from packages.
Whatfor? Somebody from the "dark circles" at RH ordered you to do so and because of the GPLv3 had been introduced. I call this overreaction and hysteria ...
Ralf
On Fri, 2007-07-27 at 06:58 +0200, Ralf Corsepius wrote:
Whatfor? Somebody from the "dark circles" at RH ordered you to do so and because of the GPLv3 had been introduced. I call this overreaction and hysteria ...
Repeat after me. There is no conspiracy. No one ordered me to do this. I volunteered.
The immediate motivation was concern over GPLv3 and LGPLv3 compatibility, as packagers were innocently violating licensing due to a lack of awareness, and there was no mechanism in place to automate basic package license checking due to a lack of standardization.
However, as Smooge pointed out, this is something that a lot of people have known needed to be done since FC2 (and likely, before).
And yes, the Licensing wiki is not the utopian mechanism for this. Having this data in the PackageDB makes a lot more sense to me, but we'll start here and grow.
~spot
On Fri, 2007-07-27 at 01:24 -0500, Tom "spot" Callaway wrote:
On Fri, 2007-07-27 at 06:58 +0200, Ralf Corsepius wrote:
Whatfor? Somebody from the "dark circles" at RH ordered you to do so and because of the GPLv3 had been introduced. I call this overreaction and hysteria ...
Repeat after me. There is no conspiracy. No one ordered me to do this. I volunteered.
OK, then this plan all grow on your own soil?
Then this isn't much more but a: "I, Spot, want my pony"?
The immediate motivation was concern over GPLv3 and LGPLv3 compatibility, as packagers were innocently violating licensing due to a lack of awareness, and there was no mechanism in place to automate basic package license checking due to a lack of standardization.
However, as Smooge pointed out, this is something that a lot of people have known needed to be done since FC2 (and likely, before).
Well, this isn't the first time this issue pops up. We even discussed and rejected a similar proposal on FPC before. Just reiterating and re-proposing something doesn't make a plan/proposal more useful.
And yes, the Licensing wiki is not the utopian mechanism for this. Having this data in the PackageDB makes a lot more sense to me, but we'll start here and grow.
"We'll start here and grow" .. do you sense what you are saying here?
You are saying: "I, Spot, have decided and am dictating the community what to do" 8()
Ralf
On Fri, 27 Jul 2007 08:24:52 +0200 Ralf Corsepius rc040203@freenet.de wrote:
OK, then this plan all grow on your own soil?
Then this isn't much more but a: "I, Spot, want my pony"?
The immediate motivation was concern over GPLv3 and LGPLv3 compatibility, as packagers were innocently violating licensing due to a lack of awareness, and there was no mechanism in place to automate basic package license checking due to a lack of standardization.
However, as Smooge pointed out, this is something that a lot of people have known needed to be done since FC2 (and likely, before).
Well, this isn't the first time this issue pops up. We even discussed and rejected a similar proposal on FPC before. Just reiterating and re-proposing something doesn't make a plan/proposal more useful.
Please lower your tinfoil hat a bit so you can hear this.
The duly elected Fedora Board has decided that due to things like (l)gplv3 it is now painfully apparent that we need a better method of tracking what licenses our various packages are under, and has asked FESCo to make it happen. FESCo has deemed this a Packaging issue and given FPC the mandate to make proposals for how to accomplish this. Spot has volunteered as part of the FPC to create such a proposal for how to handle this for FPC/FESCo/Board approval, and that's where we are. If Spot didn't volunteer, who would? Would you then claim that whomever created the draft is now trying to be dictator? If the idea doesn't come from you does it automatically mean it's coming from a shadowy smoke filled room somewhere within the bowels of Red Hat?
Yes, the FPC rejected one proposal. That was before the Fedora Board voted and deemed it necessary to track this, and that's why we're talking about it again. We don't have the authority to veto the Board in their mandate.
On 7/26/07, Ralf Corsepius rc040203@freenet.de wrote:
I'm more than willing to take on additional helpers to maintain this license registry. I'm very willing to alter the license identifiers to make they more simplistic, but without that baseline standard, it won't be possible to predictably track license data from packages.
Whatfor? Somebody from the "dark circles" at RH ordered you to do so and because of the GPLv3 had been introduced. I call this overreaction and hysteria ...
Ralf, I guess my cover as being the head of the Black Blood Red Hat conspiracy has been found out. I started this effort a long time ago when I was trying to figure out why a non-OSS license package in Fedora was listed as Distributable.. I began a quick listing of packages, but had other issues come up (the moon was in the 6th house, and the its conjunction with Ceres opened a small door for me to commune with my masters). Spot took it up because he thought it was something to be done.
You have seen through my ruse of using this to help move the stars into the proper place for R'yleh to rise again and my dark masters to rule once more. It was so much easier to cause the pain and torment of developers than trying to find virgins to sacrifice these days.
On Fri, 27 Jul 2007, Tom \spot\ Callaway wrote:
On Fri, 2007-07-27 at 05:51 +0200, Ralf Corsepius wrote:
On Thu, 2007-07-26 at 18:27 -0500, Tom "spot" Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
-1
As I understand it, you are trying mandate versioned license tags. Such an approach is inapplicable without a "license tags" register being actively maintained by an "licence tag administration office".
In other words, to me your proposal is equivalent to mandating cars carring license tags but allowing car owner to "paint them themselves".
Ralf, there really isn't any other way to solve the problem without having a list of standard license identifiers.
The http://fedoraproject.org/wiki/Licensing page is the license registry. I'm volunteering to lead the effort to maintain it, since I've effectively been doing that for more than a year now.
I'm more than willing to take on additional helpers to maintain this license registry. I'm very willing to alter the license identifiers to make they more simplistic, but without that baseline standard, it won't be possible to predictably track license data from packages.
<utopia>
Make the wiki-list a real license compatibility matrix, stored in a machine parsable format. Put the matrix into (fedora-)license-matrix (or such) package that contains the actual copy of known license text and require that anything claiming to be of license foo has a license file matching the checksum of the license-matrix copy of that license. Enforce this at build time so that no package with unknown (or incompatible) license can enter the repository.
It'd probably need some additional help from rpm to map the license tag and actual file (while it's often "COPYING" it also often is not, not to mention various homegrown licenses). Something like License(<short name>): <path to file>
</utopia>
Back to scheduled morning coffee break...
- Panu -
Tom "spot" Callaway wrote :
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
That was an interesting read. Thanks for your hard work, spot!
A few comments, FWIW :
- Same as Bill, I prefer the "GPLv2+" style notations.
- To keep using "GPL or Artistic" for perl doesn't make much sense to me, since we are trying to differentiate clearly the different GPL versions. Is it "GPLv2+ or Artistic"? "GPLv2 or Artistic"?
- If we use only " and " and " or " (with spaces around them), wouldn't the field still be reliably parseable, yet easier to read? And more coherent with the "GPL* or Artistic" from the perl packages?
- I find having to detail the licenses in %files quite unpractical, and possibly not the best suited for most cases, as I have the feeling that the most common case of multiple-licensing I've come across is having parts of the source code under a different compatible license, but then having all libs/programs use it. So I think having comments inside the spec file right above the License: tag might be more useful, something like :
# The entire source code is GPLv2+ except foolib/ which is BSD License: GPLv2+ and BSD
Matthias
On Fri, 2007-07-27 at 11:00 +0200, Matthias Saou wrote:
Tom "spot" Callaway wrote :
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
That was an interesting read. Thanks for your hard work, spot!
A few comments, FWIW :
- Same as Bill, I prefer the "GPLv2+" style notations.
Yeah, this makes sense to me, I'm going to change it when I get to work today.
- To keep using "GPL or Artistic" for perl doesn't make much sense to
me, since we are trying to differentiate clearly the different GPL versions. Is it "GPLv2+ or Artistic"? "GPLv2 or Artistic"?
This is a valid point, but I can already hear the perl packagers screaming again. :)
- If we use only " and " and " or " (with spaces around them), wouldn't
the field still be reliably parseable, yet easier to read? And more coherent with the "GPL* or Artistic" from the perl packages?
My concern about having scripts that try to parse "and" or "or" as a separator is that we have to be especially careful about license short identifiers. No "Random", "Korn", "Floor", (or to give an actual relevant example, "Condor", which is currently in the list). Using && and || prevents us from having parsing mistakes. I suppose we could parse on _and/_or...but even then, a hypothetical "Andover" license would throw us off. It's still doable, we'd just have to be very careful how it is implemented.
We'd also still need some way to handle nasty case like multiple licenses where at least one of the licenses was a dual license. Assuming parenthesis are used, it would look like this:
License: "Foo and Bar and (Cat or Dog)"
- I find having to detail the licenses in %files quite unpractical, and
possibly not the best suited for most cases, as I have the feeling that the most common case of multiple-licensing I've come across is having parts of the source code under a different compatible license, but then having all libs/programs use it. So I think having comments inside the spec file right above the License: tag might be more useful, something like :
# The entire source code is GPLv2+ except foolib/ which is BSD License: GPLv2+ and BSD
It seems fine to me. I think I'm going to redraft the wording for that section to simply say that "the package must contain a comment explaining the multiple licensing breakdown", and leave the actual implementation to the packager. This way, one could do as you've suggested, or as I originally drafted, or even say
# For a breakdown of the licensing, see PACKAGE-LICENSING
Thanks for the help!
~spot
On Fri, 2007-07-27 at 08:05 -0500, Tom "spot" Callaway wrote:
- To keep using "GPL or Artistic" for perl doesn't make much sense to
me, since we are trying to differentiate clearly the different GPL versions. Is it "GPLv2+ or Artistic"? "GPLv2 or Artistic"?
This is a valid point, but I can already hear the perl packagers screaming again. :)
- If we use only " and " and " or " (with spaces around them), wouldn't
the field still be reliably parseable, yet easier to read? And more coherent with the "GPL* or Artistic" from the perl packages?
My concern about having scripts that try to parse "and" or "or" as a separator is that we have to be especially careful about license short identifiers. No "Random", "Korn", "Floor", (or to give an actual relevant example, "Condor", which is currently in the list). Using && and || prevents us from having parsing mistakes. I suppose we could parse on _and/_or...but even then, a hypothetical "Andover" license would throw us off. It's still doable, we'd just have to be very careful how it is implemented.
Oh, come on, \band\b is not that hard. Using some awkward notation is making the life of every packager harder, for the benefit of the one person who implements the parser.
Tom spot Callaway (tcallawa@redhat.com) said:
- Same as Bill, I prefer the "GPLv2+" style notations.
Yeah, this makes sense to me, I'm going to change it when I get to work today.
One more change to the license table - a GPL or LGPL licensed package that lacks any statement of what version that it's licensed under in the source code/program output/accompanying docs is technically licensed under *any* version of the GPL or LGPL, not just the version in whatever COPYING file they include. So that would be GPL+, or GPLv1+.
# The entire source code is GPLv2+ except foolib/ which is BSD License: GPLv2+ and BSD
It seems fine to me. I think I'm going to redraft the wording for that section to simply say that "the package must contain a comment explaining the multiple licensing breakdown", and leave the actual implementation to the packager. This way, one could do as you've suggested, or as I originally drafted, or even say
# For a breakdown of the licensing, see PACKAGE-LICENSING
Sounds reasonable.
Thanks for your work on this!
Bill
On 7/27/07, Tom spot Callaway tcallawa@redhat.com wrote:
# For a breakdown of the licensing, see PACKAGE-LICENSING
Actual would it be possible that we cut down the syntax to the following:
License: see PACKAGE-LICENSING
PACKAGE-LICENSING: [Change format so that you can autoparse it better: # Packager fill in the following. Package Reviewer check off. Licenses for binaries: GPLv3+
Licenses for documentation: CC v3 OR GFDLv1.1
Licenses for source code: GPLv3+
# Auto built licenses from rpmbuild-find-licenses.py Known License Files Found: GPLv2+ : /usr/share/pudding-pie-1.1.1/COPYING Mozilla 1+ :/usr/share/pudding-pie-1.1.1/MOZILLA_STUFF
Unknown Licenses Found: Apache 9 : Found mentioned in ./pudding-pie-1.1.1/zapper.cc # License Headers Found: ./pudding-pie-1.1.1/foo.cc GPLv2+ ./pudding-pie-1.1.1/main.cc Mozilla 1+ ./pudding-pie-1.1.1/zapper.cc Apache 9 ....
# No License Headers Found In: ./pudding-pie-1.1.1/foo.h ....
The tool could do a rough draft, and try to pull out any bad stuff that might show up.. or at least help a reviewer think to themselves.. wtf Apache 9 License?
These could be fed upstream to help the authors better protect their IP, avoid a license issue where their code ends up somewhere because it didnt have a license header etc.
On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote:
On 7/27/07, Tom spot Callaway tcallawa@redhat.com wrote:
# For a breakdown of the licensing, see PACKAGE-LICENSING
Actual would it be possible that we cut down the syntax to the following:
License: see PACKAGE-LICENSING
A downside of keeping all the information in a separate file is that it doesn't end up in the metadata and so you have to explode out packages to get at it.
Jeremy
On 7/27/07, Jeremy Katz katzj@redhat.com wrote:
On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote:
On 7/27/07, Tom spot Callaway tcallawa@redhat.com wrote:
# For a breakdown of the licensing, see PACKAGE-LICENSING
Actual would it be possible that we cut down the syntax to the following:
License: see PACKAGE-LICENSING
A downside of keeping all the information in a separate file is that it doesn't end up in the metadata and so you have to explode out packages to get at it.
Well for most single license systems, i could see
License: GPLv2 see PACKAGE-LICENSING for more information License: Complicated see PACKAGE-LICENSING for more information License: Frickin' Complicated see PACKAGE-LICENSING for more information License: Spot Died For This Package see PACKAGE-LICENSING for more information
With that having the gory bits. The problem I see is that for these side cases.. you are ending up with
"SJS" == Stephen John Smoogen smooge@gmail.com writes:
SJS> License: GPLv2 see PACKAGE-LICENSING for more information
This reminds me to ask if anyone knows WTF %license in the %files list actually does. From the RPM source, build/files.c:
VFA_t virtualFileAttributes[] = { { "%dir", 0, 0 }, /* XXX why not RPMFILE_DIR? */ { "%doc", 0, RPMFILE_DOC }, { "%ghost", 0, RPMFILE_GHOST }, { "%exclude", 0, RPMFILE_EXCLUDE }, { "%readme", 0, RPMFILE_README }, { "%license", 0, RPMFILE_LICENSE }, { "%pubkey", 0, RPMFILE_PUBKEY }, { "%policy", 0, RPMFILE_POLICY },
#if WHY_NOT { "%icon", 0, RPMFILE_ICON }, { "%spec", 0, RPMFILE_SPEC }, { "%config", 0, RPMFILE_CONFIG }, { "%missingok", 0, RPMFILE_CONFIG|RPMFILE_MISSINGOK }, { "%noreplace", 0, RPMFILE_CONFIG|RPMFILE_NOREPLACE }, #endif
{ NULL, 0, 0 }
- J<
On Fri, 2007-07-27 at 14:51 -0600, Stephen John Smoogen wrote:
On 7/27/07, Jeremy Katz katzj@redhat.com wrote:
On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote:
On 7/27/07, Tom spot Callaway tcallawa@redhat.com wrote:
# For a breakdown of the licensing, see PACKAGE-LICENSING
Actual would it be possible that we cut down the syntax to the following:
License: see PACKAGE-LICENSING
A downside of keeping all the information in a separate file is that it doesn't end up in the metadata and so you have to explode out packages to get at it.
Well for most single license systems, i could see
License: GPLv2 see PACKAGE-LICENSING for more information License: Complicated see PACKAGE-LICENSING for more information License: Frickin' Complicated see PACKAGE-LICENSING for more information License: Spot Died For This Package see PACKAGE-LICENSING for more information
This is really overloading the License field, and sadly, a "PACKAGE-LICENSING" file wouldn't really be any more legally binding.
Don't get me wrong, I'd be tickled pink if we did this, but it would add a LOT of overhead, unless it was automatically generated at build time and slid into the package.
~spot
On 7/27/07, Tom spot Callaway tcallawa@redhat.com wrote:
On Fri, 2007-07-27 at 14:51 -0600, Stephen John Smoogen wrote:
On 7/27/07, Jeremy Katz katzj@redhat.com wrote:
On Fri, 2007-07-27 at 11:26 -0600, Stephen John Smoogen wrote:
On 7/27/07, Tom spot Callaway tcallawa@redhat.com wrote:
# For a breakdown of the licensing, see PACKAGE-LICENSING
Actual would it be possible that we cut down the syntax to the following:
License: see PACKAGE-LICENSING
A downside of keeping all the information in a separate file is that it doesn't end up in the metadata and so you have to explode out packages to get at it.
Well for most single license systems, i could see
License: GPLv2 see PACKAGE-LICENSING for more information License: Complicated see PACKAGE-LICENSING for more information License: Frickin' Complicated see PACKAGE-LICENSING for more information License: Spot Died For This Package see PACKAGE-LICENSING for more information
This is really overloading the License field, and sadly, a "PACKAGE-LICENSING" file wouldn't really be any more legally binding.
Well I was going for hyperbole on a Friday email.. before I tried sending it to memo-list :). I am not sure that there is any legally binding part of either the Tag or the PACKAGE-LICENSING file if either were wrong.
Don't get me wrong, I'd be tickled pink if we did this, but it would add a LOT of overhead, unless it was automatically generated at build time and slid into the package.
I would like to try and help with this part. Having a PACKAGE-LICENSE, fedora-approved-licenses.rpm, and a find-licences.py would all have to be done together in some stage. The idea is to try and make the life of the maintainer, upstream, and the project easier in the case where unknown licenses creep in, an approved package gets an update that has a bad license in it (Someone changed foo-bar from GPLv2 to MicrosoftOwnsUv1 on this release..). The idea would be to make it as automated as possible, or at least create a report that the maintainer/the reviewer/the board/and the customer could read.
On Fri, 2007-07-27 at 16:30 -0600, Stephen John Smoogen wrote:
Don't get me wrong, I'd be tickled pink if we did this, but it would
add
a LOT of overhead, unless it was automatically generated at build
time
and slid into the package.
I would like to try and help with this part. Having a PACKAGE-LICENSE, fedora-approved-licenses.rpm, and a find-licences.py would all have to be done together in some stage. The idea is to try and make the life of the maintainer, upstream, and the project easier in the case where unknown licenses creep in, an approved package gets an update that has a bad license in it (Someone changed foo-bar from GPLv2 to MicrosoftOwnsUv1 on this release..). The idea would be to make it as automated as possible, or at least create a report that the maintainer/the reviewer/the board/and the customer could read.
I'm not going to write it into the draft now, but we can amend it as needed when you've got this ready.
It seems to me there's a fair bit of code that would need to be written to "find the licenses" before this could occur, but if you're willing to try, more power to you.
~spot
On Thu, Jul 26, 2007 at 06:27:59PM -0500, Tom spot Callaway wrote:
OK, I know this is going to be painful, but we need to solve this (FESCo is waiting for us to do it), and I think this is the cleanest way:
Please review: http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag and http://fedoraproject.org/wiki/Licensing .
We'll vote on it next week.
What I'm missing is the reason this has to change. Obviously someone made lots of noise about it and the current model is inadequate for whomever needs.
Before jumping through loops to understand what which lawyer from where wanted to do with this information, maybe it would be helpful to outline the bird's eye sepcification? All I currently see is a mountain of bureaucracy falling on us. Some background information can make us understand the need and perhaps even heöp us make better counter suggestions.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
Jason L Tibbitts III -
Jeremy Katz -
Jesse Keating -
Jesse Keating -
Matthias Clasen -
Matthias Saou -
Nicolas Mailhot -
Panu Matilainen -
Ralf Corsepius -
Rex Dieter -
seth vidal -
Stephen John Smoogen -
Till Maas -
Tom Callaway -
Toshio Kuratomi -
Ville Skyttä