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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
