Date: Tue, 28 Jul 2015 13:24:59 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: Vitaly Magerya <vmagerya@gmail.com>, freebsd-ports@freebsd.org Subject: Re: help categorise license Message-ID: <55B6F60B.2080204@FreeBSD.org> In-Reply-To: <55B62FB5.3020702@gmail.com> References: <201507270859.t6R8xSL3093427@mech-as222.men.bris.ac.uk> <55B5FBB3.8020805@gmail.com> <55B60D5B.8010902@FreeBSD.org> <55B62FB5.3020702@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. ./koobs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55B6F60B.2080204>