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>