<div dir="ltr">I created the "Field of Endeavor" clause because of my experience with the license that UC Berkeley applied to the SPICE analog electronic circuit analysis software and our desire to include that software in Debian. This license prohibited the use of SPICE software by the police of South Africa. Obviously this term was written during the time of Apartheid, but it remained in effect after the South Africa Nationalist party lost power and a democratic government arose in South Africa. Indeed, as far as I could tell the police of South Africa were employing Black individuals as officers and they were still prohibited from using SPICE.<div><br></div><div>I contacted the licensing staff at UC Berkeley and they were unwilling to consider changes to the license or to offer Debian an exception.</div><div><br></div><div>From this, I developed a perception that field-of-use restrictions, no matter how well-meant, could easily end up being harmful to the community.</div><div><br></div><div>I think it was the general acceptance of the Open Source campaign that eventually convinced people at the University to change that license to be something OSI-approved.</div><div><br></div><div>I do not believe that the creation of derivative works falls under "use restriction". Use and creation of derivative works are two separate rights under copyright law.</div><div><br></div><div>Obviously we operate in the context of copyright law as it exists where our users are. This is really worldwide, but I personally am more informed of US law. There is the unfortunate tendency of the US to impose its law on other nations through treaties, and whatever nation a work originates in it is likely to encounter US law as it is exported, so wherever nation I speak in I am generally welcomed to discuss copyright law from a mainly US context.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 23, 2017 at 12:44 PM, Florian Weimer <span dir="ltr"><<a href="mailto:fw@deneb.enyo.de" target="_blank">fw@deneb.enyo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Kyle Mitchell:<br>
<span class=""><br>
>> Clause 4 seems to restrict the use (running) of the software to<br>
>> open-source development.  This is pretty close to a restriction on<br>
>> fields of endeavor.  Even the most restrictive open source licenses<br>
>> (like a common interpretation of the Sleeypcat license, or the QPL)<br>
>> permit arbitrary use for your own internal purpose.  From a practical<br>
>> point of view, this is very important because it allows you to avoid<br>
>> complex license management for purely internal applications.<br>
><br>
> OSD criterion 6 has come up a few times.  Recapping my part<br>
> in those discussions:<br>
><br>
> If development of proprietary software is a "field of<br>
> endeavor" against which Open Source licenses cannot<br>
> discriminate, then distribution-triggered copyleft<br>
> conditions like GPL's would fail the criterion, too.  That's<br>
> clearly not the case.  So "field of endeavor" must mean<br>
> something else.<br>
<br>
</span>For this reason, I assumed that “field of endeavor” always referred to<br>
activities which do not involve the creation of derivative works.  So<br>
“you may incorporate this program into open-source software only” is<br>
acceptable, but “you may use this program to write open-source<br>
software only” is not, because it disallows writing poetry with the<br>
program.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
License-review mailing list<br>
<a href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
<a href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review" rel="noreferrer" target="_blank">https://lists.opensource.org/<wbr>cgi-bin/mailman/listinfo/<wbr>license-review</a><br>
</div></div></blockquote></div><br></div>