License Framework: Develop Best Practices

[Wesley Shields]

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