> On 19. Aug 2017, at 15:37, Jonathan Hall <fli...@flimzy.com> wrote: > > Has an effort been made, or otherwise ruled out, at contacting the > authors/publishers of the other React libraries in use, to see if a > re-licensing or dual-licensing favorable to the ASF might be negotiated?
The other react libs that require most porting effort (css animation, flux) are also published by Facebook under BSD+Patents. But good thinking. Best Jan -- > > > > On August 19, 2017 12:50:42 PM GMT+02:00, Jan Lehnardt <j...@apache.org> > wrote: > Thanks for getting the ball rolling Joan, > > If you are interested in the licensing/policy details, I’ve summed things up > on my blog: > http://writing.jan.io/2017/08/19/understanding-the-facebook-vs-asf-license-kerfuffle.html > — if you want to comment on this, please start a new thread, or email me > privately. This thread is only for what we do next with Fauxton. > > * * * > > To take a bit of pressure out of this decision making process, I want to > bring up an option that unblocks us indefinitely for making new releases at > the expense of end-user experience. > > It’s a little bit of work, but not as much as anything approaching a rewrite. > > 1. move apache-fauxton to its own GitHub organisation outside of the ASF > (we can always re-integrate it later) > 2. publish release builds as tarballs somewhere on the web. > 3. replace /_utils in CouchDB with a custom route that displays a simple web > ui with a button “install Fauxton” that goes away once Fauxton is installed, > that then fetches a Fauxton release tarball from outside the ASF and installs > it on the user system. > > There is some infrastructure work to be done, and the added inconvenience for > our end-users is not something I’d like to keep up for long. > > But should we decide to take this option (or one like it), it would allow us > to not have to rush with a Fauxton adaptation, or be blocked on releases, or > have no admin UI in a release. > > * * * > > Garren has already done some experiments with preact[1] (a react-API > compatible rendering library with a compatible license) and has a basic > prototype running. Since we are also using additional React libraries that > have no corresponding equivalent in preact-land, Garren expects to migration > work to take 1-2 months of development time, something I’m not sure we are > able to afford at this point. > > [1]: https://preactjs.com > > * * * > > Moving to a library that isn’t React-API compatible would be close to a > complete Fauxton rewrite which would likely take years at our pace, and would > break compatibility with downstream addons (that we know Cloudant are using). > > As such, my preference would be to stick with the React-API and find a > minimal replacement for what we need. But I’d like to leave the final > decision to the Fauxton team. > > * * * > > I’d be happy to help with a recruiting drive to get more folks helping to do > the port. > > Best > Jan > — > > > > > > On 19. Aug 2017, at 02:40, Joan Touzet <woh...@apache.org> wrote: > > Hello everyone, > > <Joan puts her Apache CouchDB PMC hat on> > > I have some difficult news to communicate. > > Those of you who are more tuned in to the JavaScript world will be aware > that the Apache Software Foundation (ASF) has placed the so-called "BSD > + Patents" license that Facebook uses in licensing some of its open > source technologies, such as the popular React library, into "Category > X." This means that we are no longer able to ship React in Apache > CouchDB, nor have it as a build dependency, after August 31, 2017. > > Subsequently, we asked Facebook if they would consider changing the > React license to avoid this conflict, as they chose to do for their > RocksDB database. About an hour ago, they publicly announced that this > would not be forthcoming: > > https://code.facebook.com/posts/112130496157735/explaining-react-s-license/ > > This means that we must replace the use of React in Fauxton completely > (with something like Vue or preact), and ship CouchDB without Fauxton > until the former can be completed (or simply not ship until the rewrite > is complete.) > > No one in the PMC is suggesting we remove Fauxton completely from > CouchDB either now or in the future - we consider our web UI a defining > feature of the product and would consider a Fauxton-less release of > CouchDB incomplete. > > I would like to open the discussion towards the Fauxton rewrite, and > specifically: > > * Which replacement library do we like the best? Why? > * Who is willing to step up to lead this change? > * Do you know any good JS devs willing to help us? > > Those who are interested in the reasons why this policy decision was > reached by the ASF are encouraged to read the following links: > > https://issues.apache.org/jira/browse/LEGAL-303 > https://issues.apache.org/jira/browse/LEGAL-319 > https://github.com/facebook/react/issues/10191 > > PLEASE do not devolve this thread into discussion about Facebook's > decision, or why the ASF has made the policy decision that they have; > such discussions lead nowhere, and CouchDB is not in a position to > influence either organisation to change their decisions. > > On behalf of the CouchDB PMC, > Joan Touzet > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
