> On 19. Aug 2017, at 12:50, 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
Small update: I’ve revisited the (private) discussion with Garren and the 1-2 months estimate was for the react css animation library only. The other big dependency with an incompatible license is flux which is being ported to redux, but according to Garren is still “quite a bit of work”. No time estimate attached. Apologies for the confusion. Best Jan -- > > * * * > > 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 > > -- > Professional Support for Apache CouchDB: > https://neighbourhood.ie/couchdb-support/ > -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
