Re: help categorise license
On 27/07/2015 7:36 PM, Vitaly Magerya wrote: On 2015-07-27 11:59, Anton Shterenlikht wrote: I'm making a port of http://netlib.org/math. Their license looks like BSD2CLAUSE, but can somebody please check: http://netlib.org/math/license.htm That link should end with .html, not .htm. In any case, the license seems identical to the 3-clause BSD [1,2] (note the Neither the name of ... may be used to endorse or promote ... part). (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. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: help categorise license
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. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: help categorise license
On Tue, 28 Jul 2015 13:24:59 +1000 Kubilay Kocak ko...@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
Re: help categorise license
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
Re: help categorise license
On 2015-07-27 11:59, Anton Shterenlikht wrote: I'm making a port of http://netlib.org/math. Their license looks like BSD2CLAUSE, but can somebody please check: http://netlib.org/math/license.htm That link should end with .html, not .htm. In any case, the license seems identical to the 3-clause BSD [1,2] (note the Neither the name of ... may be used to endorse or promote ... part). (Also note that our license framework should probably be scrapped entirely, because it is ambiguous and undocumented). [1] http://opensource.org/licenses/BSD-3-Clause [2] http://directory.fsf.org/wiki/License:BSD_3Clause ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
help categorise license
I'm making a port of http://netlib.org/math. Their license looks like BSD2CLAUSE, but can somebody please check: http://netlib.org/math/license.htm Thanks Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
