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