License Framework: Develop Best Practices
Wesley Shields
wxs at FreeBSD.org
Tue Jun 15 21:22:36 UTC 2010
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 ...
More information about the freebsd-ports
mailing list