help categorise license

Chris H bsd-lists at
Tue Jul 28 05:43:10 UTC 2015

On Tue, 28 Jul 2015 13:24:59 +1000 Kubilay Kocak <koobs at> wrote

> On 27/07/2015 11:18 PM, Vitaly Magerya wrote:
> > 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.
> Not at all intended to offend, I wanted to highlight that a 'better'
> conversation about the License Framework has been sorely needed for a while.
> > 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.
> I agree it's worth discussing what the current gaps might be, how we can
> improve clarity of purpose, and improve the documentation. My main point
> is that what, why and how the current state is, is separate from what
> should be done about it. We may agree entirely on the former, without
> agreeing on the latter.
> > 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.
> There are certainly questions (and use-cases) that the current framework
> either does not currently answer, or does not currently cover.
> This isn't (shouldn't be) necessarily a warrant, by itself, for any
> particular course of action.
> The risk is a slippery slope to 'if a feature doesn't cover *all* cases,
> it shouldn't exist'. This logic applies to things that are both in
> progress (to be committed), as well as things that already exist.
> I think this will eventually lead to the real underlying and contentious
> question "what use-cases *should* or *shouldn't* the framework support
> and why. This is subjective at least, and biked-shed and zero progress
> territory at worst.
> Let's agree we don't want that as a project in general, and for any
> particular feature specifically.
> Elucidating specifically (unsupported?) use-cases and edge-cases is, as
> you've done, a very good thing. However, it follows that *only* these
> cases are ambiguous and/or undocumented. It does not follow that the
> entire framework itself is. This is a subtle, but very critical distinction.
> It also seems reasonable that cases that aren't (or cant currently be)
> handled are undocumented, though I would agree that it's probably worth
> explicitly mentioning them if they are known (you've mentioned a few).
> This is a trivial addition to the file, and I would
> encourage submitting improvements to it.
> > 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.
> Waiting (as we all do at various times) for others to do things, is a
> form of bystander syndrome, and not generally a productive strategy.
> So, some of the questions are:
>  * What cases can the current licenses framework describe?
>  * What cases can't the current licenses framework describe?
>  * If these cases aren't yet documented, should they be documented?
>  * For cases that aren't yet supported:
>    * What cases could be supported easily?
>    * What cases could be supported with more work?
>    * What cases can't be supported without major work (too hard)?
>  * What abilities does the current framework provide consumers?
> The last question in particular leads to another important distinction:
> That the benefit derived from classifying licenses, or anything else, is
> separate from the desire or need to classify/annotate them at all.
> It is *perfectly* reasonable to want to 'describe' something in a
> structured manner, without necessarily doing anything about the
> classification in the first instance.
> It is certainly nice and a good thing if metadata *is* used by a
> consumer (tool or human), but it's not strictly a *requirement*. There
> are other examples, both that exist and could exist in future that are
> similar in nature:
>  * A TODO file for ports
>  * categories for ports
>  * tags/keywords for ports
>  * TEST_DEPENDS for ports
> TLDR: Yes, things can and should be improved. Yes, things should be
> clear and documented as well as possible. No, something not supporting
> everything or everything perfectly doesn't necessarily warrant removing it.

*Very* nicely articulated, Kubilay Kocak. Thanks!

> ./koobs
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at"

More information about the freebsd-ports mailing list