Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Jul 2015 22:43:08 -0700
From:      "Chris H" <bsd-lists@bsdforge.com>
To:        <freebsd-ports@freebsd.org>
Subject:   Re: help categorise license
Message-ID:  <aa8492207fc75a772514f9a2b2d6dd15@ultimatedns.net>
In-Reply-To: <55B6F60B.2080204@FreeBSD.org>
References:  <201507270859.t6R8xSL3093427@mech-as222.men.bris.ac.uk> <55B5FBB3.8020805@gmail.com> <55B60D5B.8010902@FreeBSD.org> <55B62FB5.3020702@gmail.com>, <55B6F60B.2080204@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Jul 2015 13:24:59 +1000 Kubilay Kocak <koobs@FreeBSD.org> 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 bsd.license.mk 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!

--Chris
> 
> ./koobs
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aa8492207fc75a772514f9a2b2d6dd15>