This has been brought up in discussions before:
https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html
Let's please not get into what the License Tag should hold. I really do not want to have packages that look like this:
License: (GPL v2.0 or GPL v2.5) and ((MPL <= 1 or MPL =3) and (...))
and so on and so on... I think it should be clear to people that the Header fields are not meant to be used for this type of thing. A License tag should be something like:
License: GPL or Artistic
And actual license files should be placed in %doc. If we are to make any kind of standard on this, this is what it should be. Complicating the header tags is only going to complicate a lot of other things and confuse new packagers.
The bottom line is that Header tags SHOULD not be used to determine the license.
We want to encourage people to read the ACTUAL license itself, not our header tags.
All licenses header tags should be as generalized as possible with just "GPL" for this very purpose. We do not want new packagers creating new header tags with all kinds of add ons..
License: GPL (except for clause 4 paragraph 2) and Artistic (with this added on....) etc...
Once we go down the road of getting specific on the License tags then we will be adding all kinds of crap to the tag. Please let's not go there.
Christopher Stone wrote:
This has been brought up in discussions before: https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html
Thanks for the link, although there was no obvious conclusion there. The most interesting thing was the survey of existing licenses, which illustrates the current inconsistent and confused usage - which is my key point here.
Let's please not get into what the License Tag should hold.
I don't particularly want to discuss this any more than you do, but I do think there needs to be conclusion & consensus. As before, I'll respect whatever policy is agreed and documented, but (as the fact this has come up at least twice in three months shows) ignoring it just means it will keep coming up and inconsistency will continue.
I really do not want to have packages that look like this: License: (GPL v2.0 or GPL v2.5) and ((MPL <= 1 or MPL =3) and (...))
Me neither, but that's an extreme example and I don't think many packages have such complex licensing. And don't forget that in such a case you could always say "Complex; see documentation".
Complicating the header tags is only going to [...] confuse new packagers.
Telling new packagers that they can't use a License string for Extras package "foo-bar" which is the same as the identically-licensed Core package "foo" is arguably even more confusing.
The bottom line is that Header tags SHOULD not be used to determine the license.
Is it not redundant then?
We want to encourage people to read the ACTUAL license itself, not our header tags.
Then perhaps the License field should always be omitted, or populated with "See documentation".
All licenses header tags should be as generalized as possible with just "GPL" for this very purpose.
Whilst I do genuinely follow your train of thought, and I actually wish the situation was that simple, you've not addressed:
a) the fact that this is misleading
b) the very shaky legal basis of arbitrarily renaming licenses (someone in the thread you linked to pointed out that it may not be binding, but a packager misleading users could arguably have some liability)
c) the fact that what you're saying is inconsistent with what at least some Core packagers are doing
Tim
On Thu, 2006-06-29 at 09:23 +0100, Tim Jackson wrote:
Christopher Stone wrote:
This has been brought up in discussions before: https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html
The bottom line is that Header tags SHOULD not be used to determine the license.
Is it not redundant then?
IMO, the License:-tag should be considered to be a short informative abbreviated description for the actual licensing, and not to be considered a legally binding description.
We want to encourage people to read the ACTUAL license itself, not our header tags.
Things in practice are much more complicated. Developers wanting to use a package for development will have to dive into the source code in any case. For normal Fedora users, the License-tag, a "LICENSE" file and the source files are equally uninteresting.
Ralf
On 6/29/06, Ralf Corsepius rc040203@freenet.de wrote:
On Thu, 2006-06-29 at 09:23 +0100, Tim Jackson wrote:
Christopher Stone wrote:
This has been brought up in discussions before: https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html
The bottom line is that Header tags SHOULD not be used to determine the license.
Is it not redundant then?
IMO, the License:-tag should be considered to be a short informative abbreviated description for the actual licensing, and not to be considered a legally binding description.
After trying various variations of strings.. I would prefer that this is the definition of the License tags. I would prefer that we have a standardized list of them in order to make searching/sorting easier. The main problem right now I am having is with Core packages... where there are many variations on GPL, and combo licenses or just the very useful Distributable tag which does not tell me is it Free, Libre, Open, or Closed.
On 6/29/06, Tim Jackson lists@timj.co.uk wrote:
Christopher Stone wrote:
This has been brought up in discussions before: https://www.redhat.com/archives/fedora-packaging/2006-March/msg00004.html
Thanks for the link, although there was no obvious conclusion there. The most interesting thing was the survey of existing licenses, which illustrates the current inconsistent and confused usage - which is my key point here.
It is not inconsistant: 734 GPL 1 GPL version 2 or newer
The one package that uses "GPL version 2 or newer" should be fixed to just say "GPL" to conform with all 734 other packages.
This was pretty well established in the thread.
We want to encourage people to read the ACTUAL license itself, not our header tags.
Then perhaps the License field should always be omitted, or populated with "See documentation".
Yes, or how about "Fedora friendly" with a link showing valid Fedora licenses. But I don't think it's is going too far to provide a minimal amount of information such as GPL or BSD.
All licenses header tags should be as generalized as possible with just "GPL" for this very purpose.
Whilst I do genuinely follow your train of thought, and I actually wish the situation was that simple, you've not addressed:
a) the fact that this is misleading
No, it's misleading to let users think they can actually determine a software package's license agreement from the RPM's header tag.
b) the very shaky legal basis of arbitrarily renaming licenses (someone in the thread you linked to pointed out that it may not be binding, but a packager misleading users could arguably have some liability)
If it is legally binding, then we are legally bound to include the entire text of the License in the header tag. This is why the header tag should not be used to indicate anything more than the most general license "concept".
c) the fact that what you're saying is inconsistent with what at least some Core packagers are doing
I agree, let's make a standard and stick to it. But please try to see the logic in the arguments I have presented. It is simply a tag and should not be taken for anything more than that.
Christopher Stone wrote:
[current usage of License]
It is not inconsistant: 734 GPL 1 GPL version 2 or newer
plus 1 GPL version 2 or later. 1 GPL version 2 or later 1 GPLv2
OK, there's certainly a majority.
The one package that uses "GPL version 2 or newer" should be fixed to just say "GPL" to conform with all 734 other packages. This was pretty well established in the thread.
There were also some convincing arguments the other way, that I don't think were repudiated.
Then perhaps the License field should always be omitted, or populated with "See documentation".
Yes, or how about "Fedora friendly" with a link showing valid Fedora licenses. But I don't think it's is going too far to provide a minimal amount of information such as GPL or BSD.
OK, so what we're talking about really is treating "License" like "License group" or something. Fair enough.
b) the very shaky legal basis of arbitrarily renaming licenses (someone in the thread you linked to pointed out that it may not be binding, but a packager misleading users could arguably have some liability)
If it is legally binding, then we are legally bound to include the entire text of the License in the header tag.
There is a difference between "legally binding" and "misleading in a legal sense". Hypothetically, I may not have a duty to tell you the license of a file at all, but if I assertively tell you it is "XXX" and you go ahead and distribute it under "XXX v2" when actually its license is "XXX v3" which has different terms that you breach, then at the least I have misled you and caused you to do bad stuff that you might not otherwise have done (notwithstanding the fact that you should have checked the details), regardless of whether or not this in any way makes me liable to you. (It probably doesn't, but I don't want to encourage people to do stuff with free software which goes against the author's wishes and, for example, GPLv3 is shaping up to have notable differences to GPLv2 in at least some ways)
c) the fact that what you're saying is inconsistent with what at least some Core packagers are doing
I agree, let's make a standard and stick to it.
That's all I'm getting at really :)
But please try to see the logic in the arguments I have presented. It is simply a tag and should not be taken for anything more than that.
I do, honest I do. And I for one treat it exactly like that when I'm deciding how to use a bit of software: I wouldn't dream of relying on the License: tag; I would always go and check the actual source docs/source code etc. But I also don't want to mislead people who might, without any ill intent, not be so diligent.
All I'm looking for I suppose is a reasonable, reasoned and "approved" (in some meaningful sense) wiki page (not archived list thread) that is linked from PackagingGuidelines and which I (and everyone else) can look at each time I do a package and know what to put in the License field. Whether or not it corresponds to my personal preferences is not really important; I'll follow it if it's generally agreed (and preferably given the nod by FESco).
The fact that this issue has come up several times means that a *conclusive* resolution is definitely needed.
Tim
I missed this week's FESCo meeting so I don't know if it was brought up, but there should be a FESCo descision on "best practices" when the packager is in doubt.
Personally I want as little liability on me as a packager as possible. I would like to be legally forced to use a license specified by rpmlint only in my agreement with packaging for redhat, and therefore any liability I would have as a packager regarding the license tag would be transferred over to redhat.
There should also be legal text somewhere indicating that the license tag should only be considered as an indicater to the type of the license and has no legal binding whatsoever.
I'm just covering my ass here, I don't like discussions about packagers being sued over what is in the License tag of the RPM ;-)
"CS" == Christopher Stone chris.stone@gmail.com writes:
CS> I missed this week's FESCo meeting so I don't know if it was CS> brought up, but there should be a FESCo descision on "best CS> practices" when the packager is in doubt.
Actually this is no longer in the FESCo bailiwick. The packaging committee is now deciding these things for both Core and Extras, and you're essentially reaching the committee by posting here.
So let me see if I can correctly summarize the open questions:
1) How accurately does the license need to be described in the License: tag?
a) Is it sufficient to specify a license that is "close" to the actual license?
b) Are tags like "BSDish" and "GPL-like" acceptable? (rpmlint doesn't warn when it sees them.)
c) Is it necessary to specify the version of a particular license? If so, what is the proper way to do this?
2) When does the license text need to be included in the package? Current behavior is "include if in the upstream tarball, otherwise don't include".
a) Is this sufficient?
b) If not, what situations would require the license when it's not in the tarball?
CS> Personally I want as little liability on me as a packager as CS> possible.
Note that this would essentially require no interpretation of the license whatever.
- J<
On 6/29/06, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"CS" == Christopher Stone chris.stone@gmail.com writes:
CS> Personally I want as little liability on me as a packager as CS> possible.
Note that this would essentially require no interpretation of the license whatever.
If indeed there is some liability issues on the packager on the License field, I think then it should be discussed about placing a weblink in the License field and have some type of standard such as:
License: Fedora Approved (GPL) http://fedoraproject.org/wiki/..
The wiki page would then explain the different class of licenses acceptable by Fedora and note that the (GPL) indicates a class of licenses associated with GPL, etc.
Or even omitting the (GPL) part.
This would be ideal, but probably on a more realistic standpoint the status quo will remain, that is the License field is up to the packager and should just remain a should item on reviews.
However, I think there should be a consensus on what should be considered "best practice" if the packager is in doubt.
On 6/29/06, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"CS" == Christopher Stone chris.stone@gmail.com writes:
So let me see if I can correctly summarize the open questions:
Here are my questions:
1) Is there truely any liability on the packager for what is contained in the license tag? 2) What is the actual purpose of the license tag? A definition should be in place on what this actually is. 3) Clarification on if there is any legal binding to the license tag. 4) Should rpmlint be enhanced to allow version numbers on license tags?
Jason L Tibbitts III wrote:
"CS" == Christopher Stone chris.stone@gmail.com writes:
CS> I missed this week's FESCo meeting so I don't know if it was CS> brought up, but there should be a FESCo descision on "best CS> practices" when the packager is in doubt.
Actually this is no longer in the FESCo bailiwick. The packaging committee is now deciding these things for both Core and Extras, and you're essentially reaching the committee by posting here.
OK, thanks for the interest. I think your summary of issues was good there, plus I agree with the additions Chris S made.
Tim
On Thu, 2006-06-29 at 09:23 +0100, Tim Jackson wrote:
Christopher Stone wrote:
The bottom line is that Header tags SHOULD not be used to determine the license.
Is it not redundant then?
Redundant or not, the License tag is mandated by rpmbuild. As long as it stays that way, IMO including a reasonable approximation in it is the best way to go. Users and distributors should dive into the actual licensing/copyright information anyway to determine if they find it acceptable for their particular use cases.
packaging@lists.fedoraproject.org