<div dir="ltr"><div>While I personally believe that patent aggression from Facebook would be suicidal for their open-source presence and gain them little, there is enough of a possibility to raise some concern. I keep my fingers crossed that Facebook will do the same for React as RocksDB, and dual-license under the APL.<br><br></div>I have no arguments against using Preact; it is MIT licensed and seems to be drop-in compatible with React (including JSX, if we decide to make use of that in the future) aside from a few small differences. We could start now with Preact and switch to React if the license situation is settled down the road.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-24 9:21 GMT-06:00 Thomas Dukleth <span dir="ltr"><<a href="mailto:kohadevel@agogme.com" target="_blank">kohadevel@agogme.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I take Kivilahti Olli-Antti's response as helpfully encouraging<br>
examination of alternatives to ReactJS.  I also try to emphasise that the<br>
actual sufficiently disqualifying problems with the ReactJS license are<br>
with license incompatibility as opposed to some possibility of problems<br>
over some scenario with patents which might never become an issue for any<br>
Koha user or contributor.<br>
<br>
[Remainder of reply inline.]<br>
<br>
<br>
On Mon, July 24, 2017 10:25, Kivilahti Olli-Antti wrote:<br>
<br>
[...]<br>
<br>
<br>
LICENSE INCOMPATIBILITY.<br>
<span class=""><br>
> I wouldn't be overtly alarmed by this license issue,<br>
<br>
</span>The problem is primarily that the current ReactJS license seems to be<br>
incompatible with GPLv3, the license which we use for Koha as a whole.<br>
All the code which we incorporate into Koha, such as any programming<br>
libraries incorporated into Koha, must be compatible with the overall<br>
license for Koha.  The Free Software Foundation (FSF) have a helpful guide<br>
to various software license and their GPL compatibility of various<br>
licenses, <a href="https://www.gnu.org/licenses/license-list.en.html" rel="noreferrer" target="_blank">https://www.gnu.org/licenses/<wbr>license-list.en.html</a> .  FSF have<br>
not yet included the Facebook BSD+Patents license in their licenses page<br>
which is updated very infrequently and cannot include every variation on<br>
standard license terms.  In the absence of specific comment from FSF or<br>
their lawyers which we could obtain if the issue seemed too unclear, we<br>
may take the issue as carefully treated after consideration over months as<br>
reported by people at the Apache Software Foundation in communication with<br>
Facebook legal counsel confirming intended incompatibility between the<br>
Facebook BSD+Patents license for patent terms in Apache License version 2<br>
(ALv2) where there is some language in GPLv3 which seems to also be<br>
incompatible on the same point of revocation of the implied patent license<br>
in the 3 clause BSD license.  I cited Roy T Fielding's comment in my<br>
original message,<br>
<a href="https://issues.apache.org/jira/browse/LEGAL-303?focusedCommentId=16046579" rel="noreferrer" target="_blank">https://issues.apache.org/<wbr>jira/browse/LEGAL-303?<wbr>focusedCommentId=16046579</a><br>
.<br>
<br>
<br>
FREE SOFTWARE ALTERNATIVES.<br>
<span class=""><br>
> however if there is a<br>
> more free alternative we should use it.<br>
<br>
</span>Some have questioned whether the Facebook BSD+Patents license could<br>
qualify as a recognised free software license at all as the breadth of the<br>
patent license termination terms seem to violate the minimal requirements<br>
for freedom and the patent terms of the Open Standards Requirements of the<br>
Open Source Initiative (OSI), <a href="https://opensource.org/osr" rel="noreferrer" target="_blank">https://opensource.org/osr</a> .  The Facebook<br>
BSD+Patents license has very different terms from the OSI BSD+Patents<br>
license, <a href="https://opensource.org/licenses/BSDplusPatent" rel="noreferrer" target="_blank">https://opensource.org/<wbr>licenses/BSDplusPatent</a> .<br>
<br>
Some alternatives to ReactJS are under licenses for which there are no<br>
doubts about whether they are free software compatible with GPLv3.<br>
<span class=""><br>
> I don't mind having inconveniences due to using more free software.<br>
><br>
> Struggle for our privacy, freedom of speech, and environment is<br>
> inconvenient, but well worth the investment, however costly.<br>
><br>
> The important framework improvements are "one-way data flow" and the<br>
> underlying "state machine" (Redux-compatibility). Maybe server-side<br>
> rendering.<br>
> Looks like atleast InfernoJS proclaims support for those.<br>
><br>
<br>
</span>MINIMISING PATENT PROBLEMS.<br>
<br>
There would be different issues to consider if the ReactJS license had<br>
some problematic patent terms but somehow not so problematic as to be<br>
incompatible with GPLv3.<br>
<span class=""><br>
> Another take on the issue:<br>
> <a href="https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562" rel="noreferrer" target="_blank">https://medium.com/@dwalsh.<wbr>sdlr/react-facebook-and-the-<wbr>revokable-patent-license-why-<wbr>its-a-paper-25c40c50b562</a><br>
<br>
</span>Dennis Walsh ignores the license incompatibility issue of Facebook<br>
BSD+Patents license in relation to ALv2 and also seems to similarly affect<br>
GPLv3 and GPLv2.  He assumes that the primary hazard over patents from a<br>
Facebook BSD+Patents license is from Facebook directly.  He assumes that<br>
no Facebook patents exist which read on ReactJS where he did not find them<br>
easily enough and no one has reported them to him.  He does not treat the<br>
breadth of conditions for patent termination unrelated to any particular<br>
software under the Facebook BSD+Patents license which obviates assumptions<br>
about costs of replacing software relative to the costs of litigation.  He<br>
dismisses any alternative scenarios citing one particular unlikely case,<br>
however, the most likely scenarios are indirect from the breadth of<br>
termination conditions and outside the scope of anything which he has<br>
considered.  Any scenario for which there is an actual problem may be<br>
unlikely, however, if you or your organisation are in the midst of such a<br>
scenario the likelihood of its occurrence is moot for you or your<br>
organisation.<br>
<br>
Problems in patent disputes are often indirect as in the scenario<br>
described by Aaron Williamson which I had originally cited,<br>
<a href="https://github.com/facebook/react/issues/10191#issuecomment-316380810" rel="noreferrer" target="_blank">https://github.com/facebook/<wbr>react/issues/10191#<wbr>issuecomment-316380810</a> .<br>
Starting from Aaron's example I could imagine some scenario which<br>
corresponds to what I am informed is the usual type of problem which is<br>
faced over patents, however, my alteration of Aaron's example may suffer<br>
in some detail from not being a lawyer. A university with a state mandate<br>
in law to pursue patents arising from government funded research could be<br>
be substituted for Cisco in Aaron's example.  An issue covered by a<br>
traditional patent, not one reading on software, could be the issue<br>
pursued against a Facebook subsidiary.  After terminating all patent<br>
licenses granted to the university under the Facebook BSD+Patents license,<br>
Facebook might not pursue a patent action over ReactJS use by the<br>
university especially where the use prior to termination would have been<br>
licensed.  Yet, the university's loss of any Facebook patent license to<br>
assert in defence may be the opportunity for a patent troll (holding<br>
patents without any product using them) to threaten the university over<br>
some patent reading on ReactJS.  The patent troll would know that the<br>
university would be likely to agree to pay protection money to license the<br>
patent held by the troll to avoid the cost of litigation especially<br>
without a Facebook patent license for the university to assert in defence.<br>
 The troll would also not have to risk any possible Facebook patents being<br>
asserted by the university to invalidate any claims in the patent which<br>
the troll would be asserting.  The goal of the patent troll is to obtain<br>
protection money without much risk of actually having to face the<br>
financial costs or other hazards of litigation.<br>
<br>
Even if GPLv3 license compatibility would not be a problem and even if<br>
almost all Koha users would never have even a traditional patent nor a<br>
mandate to pursue patents, we should not create potential burdens upon<br>
organisations which may be candidates for using Koha beyond the relatively<br>
simple obligations respecting free software.  Certainly, we should not<br>
create a burden which Aaron Williamson describes as "compliance requires a<br>
burdensome -- maybe impossible -- degree of diligence."<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Thomas Dukleth<br>
Agogme<br>
109 E 9th Street, 3D<br>
New York, NY  10003<br>
USA<br>
<a href="http://www.agogme.com" rel="noreferrer" target="_blank">http://www.agogme.com</a><br>
+1 212-674-3783<br>
<br>
<br>
______________________________<wbr>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-<wbr>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.<wbr>org/cgi-bin/mailman/listinfo/<wbr>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.<wbr>org/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Jesse Weaver</div>
</div>