License Framework: Develop Best Practices

Sat Oct 23 18:09:29 UTC 2010

On Tue June 15 2010 23:22:35 Wesley Shields wrote:
> On Tue, Jun 15, 2010 at 02:46:27AM +0200, Marco Bröder wrote:
> > Hello,
> > 
> > I know the ports license framework is very new and not mature yet.
> > 
> > But it is not very useful in its current state, because several
> > popular licenses are missing and some license foo is not right /
> > specific enough to be considered legally correct (for example there is
> > no 'one BSD License', there are at least three of them, all legally
> > different). The legal consequences of even very small differences can
> > be very huge. We actually have to make this legally right or the whole
> > thing is useless.
> > 
> > Some maintainers already added some license foo to their ports. At the
> > moment there is more guessing than knowing what actually should be
> > done from a maintainers point of view. This is especially true for
> > dual / multi / combo licensing (for example 'GPLv2 or any later
> > version' is not really the same as 'GPLv2 or GPLv3' combo).
> > 
> > Before this even grows, could we please start developing best
> > practices and document them into Porters Handbook, as soon as
> > possible? Thanks!
> 
> I couldn't agree more. I've been holding off until the Porter's Handbook
> has clear documentation on what maintainers need to know. I've included
> alepulver@ on this as he is the one that wrote the initial support for
> this. I'd hate to see this grow into a mess that has to be cleaned up
> later because there isn't proper documentation for maintainers.
> 
> Hopefully Alejandro has a PH update in the wings? If not then I guess
> it's up to someone(TM) to do it.
> 
> -- WXS

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 ...

> > I will start with a few points:
> > 
> > *** bsd.license.db.mk ***
> > 
> > We really need to rework it.
> > 
> > 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.
> > 
> > Here is my suggestion what should be there at a minimum (probably more
> > needed):
> > 
> > ***
> > 
> > ARTLv1.0    # Artistic License 1.0
> > ARTLv2.0    # Artistic License 2.0
> > 
> > ASLv1.1    # Apache License 1.1
> > ASLv2.0    # Apache License 2.0
> > 
> > BSD-2-clause    # Simplified BSD License
> > BSD-3-clause    # Modified or New BSD License
> > BSD-4-clause    # Original BSD License
> > 
> > BSLv1.0    # Boost Software License 1.0
> > 
> > CDDLv1.0    # Common Development and Distribution License 1.0
> > 
> > EPLv1.0    # Eclipse Public License 1.0
> > 
> > GFDLv1.1    # GNU Free Documentation License 1.1
> > GFDLv1.2    # GNU Free Documentation License 1.2
> > GFDLv1.3    # GNU Free Documentation License 1.3
> > 
> > GPLv2    # GNU General Public License 2
> > GPLv2+    # GNU General Public License 2 or any later version
> > GPLv3    # GNU General Public License 3
> > GPLv3+    # GNU General Public License 3 or any later version
> > 
> > ISC    # ISC License
> > 
> > LGPLv2    # GNU Lesser General Public License 2
> > LGPLv2+    # GNU Lesser General Public License 2 or any later version
> > LGPLv2.1    # GNU Lesser General Public License 2.1
> > LGPLv2.1+    # GNU Lesser General Public License 2.1 or any later version
> > LGPLv3    # GNU Lesser General Public License 3
> > LGPLv3+    # GNU Lesser General Public License 3 or any later version
> > 
> > MIT    # MIT license
> > 
> > MPLv1.0    # Mozilla Public License 1.0
> > MPLv1.1    # Mozilla Public License 1.1
> > 
> > PD    # Public Domain license
> > 
> > X11    # X11 license
> > 
> > ***
> > 
> > There are probably more licenses and / or versions to add or to change.
> > 
> > And there are most likely more issues to discuss ...
> 

-- 
Regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20101023/4ddde668/attachment.pgp