Christopher Stone wrote: 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. 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. 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". 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. Is it not redundant then? Then perhaps the License field should always be omitted, or populated with "See documentation". 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 6/29/06, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote: 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. -- Stephen J Smoogen. CSIRT/Linux System Administrator

Christopher Stone wrote: [current usage of License] plus 1 GPL version 2 or later. 1 GPL version 2 or later 1 GPLv2 OK, there's certainly a majority. There were also some convincing arguments the other way, that I don't think were repudiated. OK, so what we're talking about really is treating "License" like "License group" or something. Fair enough. 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) That's all I'm getting at really :) 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

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(a)math.uh.edu&gt; wrote: 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?

On Thu, 2006-06-29 at 09:23 +0100, Tim Jackson wrote: 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.