Way of determining license
nicos at macports.org
Fri Dec 14 21:33:39 PST 2012
Thanks for the clarification. This makes it pretty clear.
On Dec 15, 2012, at 4:13 AM, Joshua Root <jmr at macports.org> wrote:
> On 2012-12-15 05:29 , Nicolas Pavillon wrote:
>> I was just checking some licenses on some ports, and I realised the one of kdelibs4 is wrong at the present time. However, I am a bit confused about determining the proper license. For now, it is set to GPL-2+, which is the most restrictive of what is contained in the codes, but it should be "GPL-2+ LGPL-2+ BSD Permissive" to account for all licenses contained in the code.
>> However, the GPL codes seem to be essentially testing codes, and may not be part of the used executables. Furthermore, kdelibs is commonly considered licensed under LGPL, as it is the one announced by KDE, and Fedora distributes packages for example.
>> I am not fully sure of the criterion in a case like this in order to choose the license. Therefore, I am wondering if I should list everything (GPL-2+ LGPL-2+ BSD Permissive), or if I should limit to what is commonly considered (LGPL-2+ BSD Permissive), which would make the port distributable ?
> The GPL is unusual in that it conflicts with anything that imposes
> requirements other than those imposed by the GPL itself. Thus GPL +
> anything GPL compatible = GPL.
> Only the license(s) of installed files are relevant for determining
> distributability and need to be listed, so if the test suite is not
> included in the archive, don't list its license.
> If it is installed, there isn't much you can do. You have to list the
> license since it does need to be checked for compatibility against the
> dependencies. If a dependent is evaluating as non-distributable only
> because of GPL being in kdelibs4's license, and that dependent doesn't
> reference the GPL'd files at all, you can use 'license_noconflict kdelibs4'.
> - Josh
More information about the macports-dev