[Horizon] Licensing issue with using JSHint in build
The Horizon build is using JSHint. I am in process of writing JavaScript best practices for Horizon which includes modifying what JSHint Configuration option (rules) are set. Before I consider syncing the Build's JSHint options with the proposed options from the JavaScript best practices (https://review.openstack.org/#/c/117595/), I wanted to double check and be sure Horizon got past the legal problem with the good/evil licensing. Background. JSHint was authored by Douglas Crockford, and he added an extra line in the licensing, "The software shall be used for good, not evil". The issue is in the definition of what is good and what is evil. It is too subjective, what is evil differs from person to person therefore ends up being a liability and leaving users open to frivolous lawsuits. Is this licensing something Horizon needs to be concerned with? If so, did Horizon get permission or find some way around the licensing issue? I had posted this question initially to openstack-dev@lists.openstack.org, in which Jeremy Stanley responded with the following which I though was relevant to include. It's worth mentioning that Douglas Crockford seems to consider the free software legal concerns around his license choice amusing and will apparently, upon request, provide an exception to an organization wishing to use his software for evil[1]. He has no interest in changing the situation[2] in JSLint or derivatives (like JSHint) even if that means that they can not be provided as part of Debian[3] or similar legally-concerned distributions. [1]http://dev.hasenj.org/post/3272592502/ibm-and-its-minions [2]https://github.com/jshint/jshint/issues/1234 [3]http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html
On 09/10/2014 10:56 AM, Aaron Sahlin wrote:
The Horizon build is using JSHint. I am in process of writing JavaScript best practices for Horizon which includes modifying what JSHint Configuration option (rules) are set. Before I consider syncing the Build's JSHint options with the proposed options from the JavaScript best practices (https://review.openstack.org/#/c/117595/), I wanted to double check and be sure Horizon got past the legal problem with the good/evil licensing.
Background. JSHint was authored by Douglas Crockford, and he added an extra line in the licensing, "The software shall be used for good, not evil". The issue is in the definition of what is good and what is evil. It is too subjective, what is evil differs from person to person therefore ends up being a liability and leaving users open to frivolous lawsuits.
Is this licensing something Horizon needs to be concerned with? If so, did Horizon get permission or find some way around the licensing issue?
I am not a lawyer. I do not think there is an issue, although reasonable people disagree with me. The reason that I do not think that there is an issue is that this is a copyright license, and the "use for good" is a usage restriction which is more akin to an EULA than a copyright/copying restriction. Since there is no requirement at USAGE time that the instructions bundled with the copyright be shown, it is unreasonable to expect users of the software to be aware of the supposed usage restriction or to have agreed to them at any point in time. As such I believe it would not stand up to a click-through EULA viability test. If, however, the statement was something like: "this software may not be included in software that is intended for evil use" Then I think that as a portion of a copyright license it would be actionable, since as part of a copyright license it would actually be in some way describing terms related to copying or distribution, which is what copyright has authority over. For that reason, I believe that the statement is line noise and just as meaningful as if he's included a statement about his favorite fruit or a description of Phil Collins' work while with Genesis with no instructions whatsoever. However, I am not a lawyer, and reasonable people disagree with my views.
I had posted this question initially to openstack-dev@lists.openstack.org, in which Jeremy Stanley responded with the following which I though was relevant to include.
It's worth mentioning that Douglas Crockford seems to consider the free software legal concerns around his license choice amusing and will apparently, upon request, provide an exception to an organization wishing to use his software for evil[1]. He has no interest in changing the situation[2] in JSLint or derivatives (like JSHint) even if that means that they can not be provided as part of Debian[3] or similar legally-concerned distributions.
[1]http://dev.hasenj.org/post/3272592502/ibm-and-its-minions [2]https://github.com/jshint/jshint/issues/1234 [3]http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
On 2014-09-10 11:14:26 -0700 (-0700), Monty Taylor wrote: [...]
However, I am not a lawyer, and reasonable people disagree with my views.
I mostly agree with your views (which probably makes me unreasonable). My bigger concern is that we are unlikely to convince, say, Debian to reconsider their position on the non-freeness of the license nor on their desire to be able to rebuild OpenStack components they distribute, so in effect requiring JSHint for generating or running parts of Horizon effectively means we are sending the signal we no longer want Debian to carry Horizon. In this case, though, I think the subject line/problem description is misleading. Digging deeper into the current state of Horizon it appears that JSHint is only a recommended tool for developers and one we also call in automated code style checks[1]. As long as it's not actually required to reproduce a usable version of Horizon from source and run it then I don't think there's likely to be any actual problem. [1] ...at least 'git grep -il jshint' only returns doc/source/ref/run_tests.rst, run_tests.sh and tox.ini -- Jeremy Stanley
On 09/10/2014 11:32 AM, Jeremy Stanley wrote:
On 2014-09-10 11:14:26 -0700 (-0700), Monty Taylor wrote: [...]
However, I am not a lawyer, and reasonable people disagree with my views.
I mostly agree with your views (which probably makes me unreasonable). My bigger concern is that we are unlikely to convince, say, Debian to reconsider their position on the non-freeness of the license nor on their desire to be able to rebuild OpenStack components they distribute, so in effect requiring JSHint for generating or running parts of Horizon effectively means we are sending the signal we no longer want Debian to carry Horizon.
I do not care if Debian re-runs our code style checks. I think as long as we don't run jshint inside of the unittest runs - but instead run it as a separate job like we do with pep8, then I think Debian legal's POV on this is irrelevant. I _do_ agree that if it were a part of actual build or test pipeline that we should avoid it for that reason.
In this case, though, I think the subject line/problem description is misleading. Digging deeper into the current state of Horizon it appears that JSHint is only a recommended tool for developers and one we also call in automated code style checks[1]. As long as it's not actually required to reproduce a usable version of Horizon from source and run it then I don't think there's likely to be any actual problem.
I think we should run it as part of horizon's pep8 job, because that's what we do around here. And I don't think that should prevent debian from doing anything.
[1] ...at least 'git grep -il jshint' only returns doc/source/ref/run_tests.rst, run_tests.sh and tox.ini
On 09/10/2014 02:51 PM, Monty Taylor wrote:
On 09/10/2014 11:32 AM, Jeremy Stanley wrote:
On 2014-09-10 11:14:26 -0700 (-0700), Monty Taylor wrote: [...]
However, I am not a lawyer, and reasonable people disagree with my views.
I mostly agree with your views (which probably makes me unreasonable). My bigger concern is that we are unlikely to convince, say, Debian to reconsider their position on the non-freeness of the license nor on their desire to be able to rebuild OpenStack components they distribute, so in effect requiring JSHint for generating or running parts of Horizon effectively means we are sending the signal we no longer want Debian to carry Horizon.
I do not care if Debian re-runs our code style checks. I think as long as we don't run jshint inside of the unittest runs - but instead run it as a separate job like we do with pep8, then I think Debian legal's POV on this is irrelevant. I _do_ agree that if it were a part of actual build or test pipeline that we should avoid it for that reason.
In this case, though, I think the subject line/problem description is misleading. Digging deeper into the current state of Horizon it appears that JSHint is only a recommended tool for developers and one we also call in automated code style checks[1]. As long as it's not actually required to reproduce a usable version of Horizon from source and run it then I don't think there's likely to be any actual problem.
I think we should run it as part of horizon's pep8 job, because that's what we do around here. And I don't think that should prevent debian from doing anything.
[1] ...at least 'git grep -il jshint' only returns doc/source/ref/run_tests.rst, run_tests.sh and tox.ini
Agree. I can't see how this has any licensing implications as a style check. It's not being linked in any way with OpenStack code. -Sean -- Sean Dague http://dague.net
participants (4)
-
Aaron Sahlin
-
Jeremy Stanley
-
Monty Taylor
-
Sean Dague