help categorise license

Vitaly Magerya vmagerya at gmail.com
Mon Jul 27 13:18:49 UTC 2015


On 2015-07-27 13:52, Kubilay Kocak wrote:
>> (Also note that our license framework should probably be scrapped
>> entirely, because it is ambiguous and undocumented).
>
> Or it could just be made less ambiguous and documented.
>
> Otherwise, we should scrap entirely all other things that are also
> ambiguous and undocumented.
>
> I imagine this will be a large list, and include large parts of the kernel.

You're right, "ambiguous and undocumented" is not a great summary. My
bad. I did not want to write an essay in an off-hand remark though, so
let me clarify.

What I mean is that it's not clear, not documented, and probably not
widely agreed upon, what guarantees should the framework provide, or
what use cases should it serve. Hence ambiguous and undocumented. If we
where to resolve those questions, and document the result in the
handbook, the complaint would be resolved.

As an example: if a given port consists of a program, a few libraries, a
set of documentation and a test suite -- all under different licenses
(some of which are custom, some of which are dual), with the docs being
optional, and the tests only used in the 'regression-test' target (so,
not installed, but can be used during the build), what should we put
into the LICENSE variable (there will be half a dozen of licenses in
total)? For which users will the resulting LICENSE be helpful?

Another example: if a port comes under a BSD license, but links with a
GPL library, so that the resulting binary is necessarily GPL, what
should the LICENSE be? Why?

Next, let's say a port requires user to read and accept a license before
installation (so, no auto-accept), should I use the license framework to
present the said license to the user?

As you can see, there are questions that arise in some of the trickier
situations, with the end result that I neither know what to put into the
LICENSE of my own ports, nor how to interpret the LICENSEs of other
ports. I don't even have an understanding of what sort of a user
benefits from my ports having a LICENSE.

So, after 7 years (!) of waiting for official clarifications -- with no
visible progress -- I think it is not surprising that I don't see a
clarification to ever be made, and would prefer the framework removed.


More information about the freebsd-ports mailing list