This is all very unpleasant. I read all the emails and I just wanted to drop a 
note, that I am happy to ask our JS developers (at sum.cumo) if they want to 
help rewrite Fauxton. We have a lot of experience with vue.js but I am sure, we 
could also help with other libraries and parts in Fauxton.

All the best

Andy

-- 
Andy Wenk
Hamburg - Germany
RockIt!

GPG public key: 
http://pgp.mit.edu/pks/lookup?op=get&search=0x45D3565377F93D29



> On 19. Aug 2017, at 15:44, Jan Lehnardt <j...@apache.org> wrote:
> 
>> 
>> 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/

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to