[Fedora-packaging] Re: License tag in packages

[Tim Jackson]

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