[Koha-devel] ReactJS license problems

Jesse pianohacker at gmail.com
Tue Jul 25 08:42:43 CEST 2017


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 <kohadevel at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20170725/ee007c8e/attachment-0001.html>


More information about the Koha-devel mailing list