License Framework: Develop Best Practices

[Alejandro Pulver]

On 10/23/2010 2:41 PM, Marco Bröder wrote:
> On Tue June 15 2010 23:22:35 Wesley Shields wrote:

> I neither saw a reply from alepulver@ nor anything else on this subject. Are
> there any further news? There was nothing added to the Porter's Handbook, too.
> So I guess the situation did not change within the last months, right?
>
> Unfortunately, with a recent update to one of my ports (the software is -GPLv2
> or any later version- licensed) the committer added the LICENSE / LICENSE_COMB
> foo at his own without asking. I find this annoying, because I purposely did
> not add it. Something like that should be the maintainer's choice, because he
> is also responsible for the port.
>
> I think the LICENSE stuff should generally not be added until the whole
> subject is clarified and properly documented, which does not seem to be the
> case, especially from the legal point of view.
>
> What should the license framework be? Looks like nobody really seems to care
> (enough).
>
> Will it remain a legally incorrect and unreliable stuff? Then, there is no
> need to actually care about it and the whole license framework is pretty
> much useless in a legal sense. But that must be stated explicitly.
>
> Or should it be as correct as possible? Then it is necessary to have the
> licenses at least correctly defined and used like they exist (see my original
> mail quoted above and below, especially the '[L]GPLv2 or any later version'
> and the three BSD licenses).
>
> Will there be an official consensus? Will there be rules or disclaimers for
> maintainer's and committer's responsibility? Will the whole thing be properly
> documented in the Porter's Handbook? Will the licenses be correctly defined in
> 'ports/Mk/bsd.licenses.db.mk' or will some of them remain incorrectly
> simplified?
>
> The license framework could be very nice and actually useful - if
> properly done ...
>

A few weeks ago I was very busy with exams (now I've started to update 
and clean up some of my ports). But about the PH entry I have previously 
asked about policies regarding creation of files (the first variables in 
bsd.licenses.mk) without answer, and I can't write anything.

About the rest (what licenses to have, how to define them, etc) the only 
thing I could do is to look at what other projects did, but really it's 
not my area (which is writing the code to provide required functionality).

I'm willing to make necessary changes to bsd.licenses.mk and/or write 
documentation if someone else could take care of the "bureaucratic part".

>
>>> I will start with a few points:
>>>
>>> *** bsd.license.db.mk ***
>>>
>>> We really need to rework it.
>>>

I have no problem to others taking care of the file. It was initially 
just an example, and the plan was to automatically classify ports and 
take the license list from there (which might happen after I update the 
fossology port to the recent release and fix a few issues).

>>> It should at least contain the most popular / often used licenses
>>> -and- their -correct- versions. The latter is not always the case at
>>> the moment. And the versions should have only -one- format, not
>>> multiples. I suggest to always use a something like 'LGPLv2.1' and not
>>> 'LGPL21'. At least it has to be consistent across all licenses.
>>>
>>> I find it especially important to have a expression for 'version X or
>>> any later version' (for example 'LGPLv2+'), since the following dummy
>>> example is not adequate:
>>>
>>> LICENSE=        LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2
>>> LICENSE_COMB=    dual
>>>
>>> ... and so on for every future versions - it does not scale well and
>>> has to be changed with every new future version. Instead it should be
>>> just 'LGPLv2+' and stay there unchanged forever.
>>>

These could be achieved with groups, or as you suggested with individual 
names.

Regards,
Ale

P.S.: the mail was re-sent from the correct address (subscribed to the list)