XMPP: janlehnardt@jabber.ccc.de
GPG Fingerprint: D2B1 7F9D A23C 0A10 991A F2E3 D9EE 01E4 7852 AEE4
OTR Key: DD971A73 2C16B1AB FDEB5FB4 571DECA1 55F54AD1

Community Legacy

Berlin’s most influential & groundbreaking coworking space Co.Up is closing shop. Their famous event space remains open.

As Co.Up’s first ever renter, nine years ago, about a year before it even became Co.Up, I feel obliged to say a few words. This is, however, not a eulogy.

On the surface, a coworking space is office space with tables for rent, and there’s at least one in every major city today. When what eventually become Co.Up started in fall of 2008, coworking was decidedly not a thing, not usual, not common.

Of course, people have shared office space since there was office space, but a dedicated office sharing culture, a notion of a temporary home for digital nomads with globally shared values, that was new. And Co.Up was at the forefront of this now ubiquitous movement.

sad to hear about the closing of @co_up as a coworking space. your atmosphere was formative for me. thank you, @freaklikeme and @langalex. — @electricgecko

In the past ten years, and without hyperbole, Co.Up has been the foundation and nurturing space for sustainable communities that started with technology, but now spans culture, education and the arts.

How is Co.Up different from other coworking spaces in this regard? The openness and willingness to try things that are different, that are unconventional, but ultimately the right thing to do.

Co.up was born out of the desire of Upstream founders Alex & Thilo to have a nice office they can share with others. Alex’s & Thilo’s community involvement made it an attractive space for other technologists to hang out. Later, and with Aleks’s initiative and support, other communities found a home at Co.Up.

These communities and the coworkers participating in them enabled thousands of people per year to connect, start out their careers in Berlin, find jobs, find partners in crime^Wbusiness, found companies, start user groups. Even OpenTechSchool, a global initiative in volunteer education, has its roots at Co.Up. On top of all this, countless friendships have found a beginning at Co.Up that have since long outlived the confines of the offices at Adalbertstraße. And this is only a tiny sliver of groups that started out at Co.Up.

Thanks co.up for being my work home for many years, for all the people I got to meet, and everything you did for the community :’( https://twitter.com/co_up/status/908617161308082176 — @kriesse

Co.Up’s probably most radical initiative was the opening of a 100+person event space that was free for events that were open to the public. I keep meeting folks that say they want to start something and they need place to meet and every time it comes down to Co.Up’s generosity to support the Berlin communities pro-bono that enables so much. In other cities and contexts, the deal usually involves a commercial involvement, hindering many initiatives.

Luckily, Co.Up’s event space remains open.

Met lots of great people by way of @langalex and @freaklikeme, and the team at @co_up. All the best on their next journey. — @klimpong

Personally, I’ve given up my desk at Co.Up in 2015 after founding Neighbourhoodie and needing a space of our own, but we continue to support Co.Up’s event space financially, like many other Berlin companies. I’ve simply outgrown the model of a coworking space and now Upstream is going through the same transition. As they mention in their closing blog post, success is a matter of focus, and their focus is now their software business Cobot, a very successful coworking space management software, so they are still very much support the coworking community.

My thanks to Alex, Thilo & Aleks for all their hard work. Your dedication will live on in the DNA of so many Berlin communities, people, and hearts.

Understanding the Facebook vs Apache Software Foundation License Kerfuffle

Translation: French by @gnieh_

Disclaimers: I am not a lawyer. I’m not speaking for Facebook, the ASF, or CouchDB. This is a personal view on the matter.

tl;dr: Projects at the Apache Software Foundation can no longer use dependencies that are distributed under Facebook’s “BSD+Patents” license, including React.

Intent of this post

I’m trying to explain the situation in simple language and without bias. There is a lot of misinformation around this issue that I hope I can clear up here. If there is anything that I got wrong here, please do let me know.

What happened?

Why did it happen?

To understand the conflict, we need to examine what the ASF and Facebook respectively are trying to achieve with their policies and licenses.

Aside: I want to make doubly clear that I’m not trying to take sides in any of this, I’m merely explaining the underlying intentions of very dense legal texts. In my opinion, both Facebook and the ASF can do whatever they want in terms of licensing. And if their goals differ, that might lead to conflict, like in this case. That’s unfortunate, but that’s the messy world we live in.

The ASF Side

It is the ASF’s Policy, that anyone using Apache projects as a dependency for an Open Source or commercial project can do so without (m)any restrictions.

The Apache License 2.0 lists a few restrictions, briefly:

In return, the Apache License 2.0 then grants you a copyright license that lets you do whatever. This is what’s most relevant to other Open Source projects.

It also grants you a patent license, which is most relevant to commercial users of Apache projects.

As an example, this means I can take Apache CouchDB and release it as a new commercial and closed-source database JanDB. Given that I abide by the requirements mentioned in the Apache License 2.0 (as summarised above), with or without modifications, for free or for money or any other purpose I choose.

This “downstream freedom” is a major intention of why the ASF exists in the first place and is as such encoded in their policies and licenses.

Now, the Apache License 2.0 includes one more restriction and its part of the aforementioned patent license. If you are using an Apache project you can’t use any of your patents to claim that the ASF or anyone else who is using that same project is infringing on your patent without losing the patent license to the Apache Project.

In the JanDB example, if I hold a particular patent on database technology, I can’t sue any other CouchDB users over that patent, without also losing my patent license for CouchDB from the ASF. I can still sue them over other matters, including patents infringed on by other software the other companies are using.

In order to make it simpler for Apache projects to decide what kind of licenses its dependencies can have, the ASF has created a handy overview of allowed, and disallowed licenses, and everything in between. The disallowed licenses are classified as “Category X” licenses. This list includes a number of very popular Open Source licenses including the GPL family and many others.

The Facebook Side

Facebook’s focus with its BSD+Patents license is protection against so-called “frivolous” or “meritless” lawsuits. In short: if you are a big company with lots of money and exposure, enterprising assholes will try to come after you for whatever reason to legally extract some of that money or exposure. Patents are a prime vehicle for such asshattery.

The BSD+Patents license is designed to minimise these lawsuits for Facebook, and with the August 18th decision they have confirmed that this remains a high priority.

The Facebook patent clause has a similar restriction to what the Apache License 2.0 states, except, it is broader in definition. Whereas the Apache License 2.0 version specifically restricts its clause to “the Work” (say Apache CouchDB), the Facebook patent license is revoked when any “Patent Assertion” is brought up against Facebook.

So if you have a patent that you think some part of Facebook infringes upon, but is unrelated to your use of React, you lose your patent license to React when you decide to sue Facebook over that patent. In the Apache License 2.0 case, you only lose the patent license if you assert the same infringement for the project you are yourself licensing (say Apache CouchDB in the “JanDB” example).

In October 2014, Facebook switched React from the Apache License 2.0 to BSD+Patents explicitly, because it contains a broader protection and in October 2016 have confirmed their intentions in call between the ASF and Facebook.

What does that mean?

Projects at the Apache Software Foundation can not use any dependencies that are labelled as Category X by the ASF’s Legal team. This includes React + ecosystem projects that are also released by Facebook under the BSD+Patents license. Projects that already use such dependencies can not make any new releases past August 31st, 2017 including these dependencies, and have to migrate away from these dependencies now.

Affected projects are (at least): Cordova, Superset, TrafficControl, Ambari, Allura, Whimsy, Spot, Myriad, CouchDB, Lens, SensSoft, Sling (Updated August 22nd).


What are the options for ASF projects now?

  1. remove the dependency altogether, or find an alternative that has a compatible license, and deal with whatever extra work that needs to be done to make the migration.

  2. move to a plugin architecture where the BSD+Patents licensed plugin is maintained and distributed outside of the ASF, but can be added by end-users.

Aside: it is true that there are projects that have (or claim) API compatibility with React, that come with compatible licenses. “Just use X” is a common recommendation that ignores a bunch of realities:

Why didn’t the ASF do this sooner?

The ASF Legal team doesn’t proactively review any and all software licenses. This issue was brought up on April 20th, 2017, and resolved within the ASF by June 17th.

What does that mean for the license compatibility with other Apache License 2.0 licensed projects using React?


The incompatibility is between the BSD+Patents license and ASF policy.

What does this mean for my (open source or closed source) project that uses both ASF and React software.


What does this means for me/my Open Source project/my company that is using React?


Unless you are part of the ASF or another organisation that has a similar policy regarding the BSD+Patents license. There seem to be a few.

Why was RocksDB relicensed and React et.al. weren’t?

I can only speculate, but React is a much much larger target, was differently licensed from the get go, and Facebook is interested in having RocksDB support in Cassandra and seems to be contributing that work. But I wouldn’t know for sure.

Aren’t Software Patents just the worst?


But I’d rather have the ASF and Facebook be upfront about their intentions than leaving things in the dark like most other Open Source projects and companies.

Comprendre le bazar de licence entre Facebook et l’Apache Software Foundation

Note du traducteur : Ceci est la traduction du billet daté du 19 août 2017. Pour toute correction ou commentaire, contactez moi

Avertissement : Je ne suis pas avocat. Je ne parle pas au nom de Facebook, l’ASF ou CouchDB. Ce billet reflète uniquement mon point de vue personnel sur le sujet.

tl;dr : Les projets de l’Apache Software Foundation ne peuvent plus utiliser de dépendances distribuées sous la licence Facebook « BSD+Patents », y compris React.

But de ce billet

J’essaierai d’expliquer la situation en des termes simples et sans biais. Beaucoup de fausses informations ont circulé sur le sujet et j’espère pouvoir clarifier la situation ici. S’il y a quoi que ce soit que je ne rapporte pas correctement ici, faites le moi savoir.

Que s’est-il passé ?

Pourquoi cela est-il arrivé ?

Afin de comprendre le conflit, nous devons examiner ce que l’ASF et Facebook essaient respectivement d’atteindre avec leurs règles et licences.

Note: j’aimerais mettre doublement au clair le fait que je n’essaie pas de prendre position dans tout ça, j’explique simplement les intentions sous-jacentes aux textes légaux qui sont très denses. Selon moi, Facebook et l’ASF peuvent chacun faire ce qu’ils veulent en terme de licence. Et si leurs buts diffèrent, cela peut conduire à des conflits comme c’est le cas ici. C’est dommage, mais c’est le monde désordonné dans lequel nous vivons.

Du côté de l’ASF

La Politique ASF veut que chacun puisse dépendre des projets Apache pour un projet Open Source ou commercial, et ce sans (trop de) restriction.

La Licence Apache 2.0 liste quelques restrictions, en résumé :

En retour, la Licence Apache 2.0 vous accorde une licence de copyright qui vous permet de faire ce que vous voulez. C’est ce qui est le plus important pour les autres projets Open Source.

Elle vous accorde aussi une licence de brevet, ce qui est plutôt important pour les utilisations commerciales de projets Apache.

Par exemple, cela signifie que je peux prendre le projet Apache CouchDB et le redistribuer en tant que nouvelle base de données commerciale et propriétaire JanDB. Tout cela sous réserve que je respecte les exigences de la Licence Apache 2.0 (tels que résumées ci-dessus), avec ou sans modification, gratuitement ou de manière payante, ou pour tout autre but de mon choix.

Cette « liberté en aval » est la raison première de l’existence de l’ASF et est inscrite ainsi dans ses règles et licences.

De plus, la licence Apache 2.0 inclut une autre restriction qui fait partie de la licence de brevet susmentionnée. Si vous utilisez un projet Apache, vous ne pouvez utiliser aucun de vos brevets pour affirmer que l’ASF ou quiconque utilise le même projet viole votre brevet, sans perdre la licence de brevet sur le projet Apache.

Dans l’exemple de JanDB, si je détiens un brevet sur les technologies de base de données, je ne peux attaquer aucun autre utilisateur de CouchDB sur ce brevet sans perdre dans le même temps ma licence de brevet pour CouchDB accordée par l’ASF. Je peux cependant toujours poursuivre ces utilisateurs pour d’autres raisons, incluant des violations de brevet par d’autres logiciels utilisés par ces utilisateurs.

Afin de rendre plus facile la tâche de décider quel type de licences les dépendances des projets Apache peuvent avoir, l’ASF a créé un aperçu très pratique des licences autorisées et non autorisées, et tout ce qui est entre les deux. Les licences non autorisées sont classifiées dans les licences de « Catégorie X ». Cette liste inclut un bon nombre de licences Open Source très populaires dont la famille GPL et bien d’autres.

Du côté de Facebook

L’intérêt de Facebook avec sa licence BDS+Patents est la protection contre les poursuites dites « frivoles » ou « vexatoires ». En résumé, si vous êtes une grosse société avec beaucoup d’argent et une grande exposition, des enfoirés entreprenants essaierons de vous poursuivre pour quelque raison que ce soit afin de vous extorquer légalement cet argent et cette exposition. Les brevets sont un outil de choix pour ce genre de connerie.

La licence BDS+Patents est conçue afin de minimiser ces poursuites judiciaires contre Facebook, et avec leur décision du 19 août, ils confirment que cela reste un grande priorité.

La clause sur les brevets de Facebook a une restriction similaire à ce que la licence Apache 2.0 exprime, sauf que sa définition est plus large. Là où la version de la licence Apache 2.0 restreint spécifiquement sa clause au « Travail » (disons Apache CouchDB), la licence de brevet Facebook est révoquée dès lors qu’une quelconque « revendication de brevet » est portée contre Facebook.

Ainsi, si vous détenez un brevet que vous pensez être violé pas une partie de ce que fait Facebook, mais qui est sans lien avec React, vous perdez votre licence de brevet pour React dès lors que vous poursuivez Facebook sur ce brevet. Dans le cas de la licence Apache 2.0, vous perdez uniquement la licence de brevet si vous revendiquez cette violation par le projet que vous licenciez vous même (soit Apache CouchDB dans l’exemple de JanDB).

En octobre 2014, Facebook a changé la licence de React de la licence Apache 2.0 vers BSD+Patents, explicitement car elle contient une protection plus large, et en octobre 2016 Facebook a confirmé ses intentions dans un appel avec l’ASF.

Qu’est ce que ça signifie ?

Les projets de l’Apache Software Foundation ne peuvent pas avoir de dépendances classées dans la Catégorie X par l’équipe légale de l’ASF. Cela inclut React ainsi que les projets de l’écosystème qui sont publiés par Facebook sous licence BSD+Patents. Les projets qui utilisent déjà ce genre de dépendances ne peuvent plus publier de nouvelles versions après le 31 août 2017 qui incluent ces dépendances et doivent se séparer de ces dépendances maintenant.

Les projet affectés son (a minima) : Cordova, Superset, TrafficControl, Ambari, Whimsy, Spot, Myriad, CouchDB, Lens, SensSoft, Sling.


Quelles sont désormais les options des projets ASF ?

  1. Supprimer purement et simplement les dépendances ou trouver une alternative publiée sous une licence compatible et assumer tous le travail additionnel qu’une telle migration impose.

  2. Migrer vers une architecture de plugin où les composants sous licence BSD+Patents sont maintenus et distribués en dehors de l’ASF, mais peuvent être ajoutés par les utilisateurs finaux.

Note : il existe des projets qui ont (ou affirment avoir) une API compatible avec React et qui sont publiés sous une licence compatible. « Tu n’as qu’à utiliser X » est un conseil classique qui ignore tout un tas de réalités :

Pourquoi l’ASF n’a pas fait ce travail plus tôt ?

L’équipe légale de l’ASF ne relit pas de manière préventive toutes les licences logicielles. Ce problème a été soulevé le 20 avril 2017 et résolu par l’ASF le 17 juin.

Qu’est-ce que cela signifie pour la compatibilité de licence avec d’autres projets sous licence Apache 2.0 utilisant React ?


L’incompatibilité se trouve entre la licence BDS+Patents et la politique de l’ASF.

Qu’est-ce que cela signifie pour moi/mon projet Open Source/ma société qui utilise React ?


À moins que vous fassiez partie de l’ASF ou de toute autre organisation qui a une politique similaire envers le licence BDS+Patents. Il semble y en avoir quelques-unes.

Pourquoi RocksDB a été relicencié et pas React et les autres ?

Je peux seulement émettre des hypothèses, mais React est une beaucoup plus grosse cible, a été licencié différemment depuis le début, et Facebook semble intéressé par avoir RocksDB pris en charge par Cassandra et semble contribuer à ce travail. Mais je ne peux en être sûr.

Les brevets logiciels ne sont-ils pas juste terribles ?


Mais je préfère voir l’ASF et Facebook clairs sur leurs intentions que de laisser les choses dans le flou comme le font la plupart des autres projets Open Source et sociétés.

Sustainable Open Source: The Maintainers Perspective or: How I Learned to Stop Caring and Love Open Source

If you want your open source maintaining to be sustainable, you need to stop caring.

Wait what?

Nolan wrote a very in-depth description of what maintaining open source projects can feel like.

Mikeal suggests leaving projects is the solution, which I think is only the most extreme option.

I’m offering middle ground: stop caring.

I can relate to everything that Nolan is saying and I must know that Mikeal’s solution is always an option in order to be able to not care effectively.

Inbox Zero Redux

Before I stop caring though, I’d like to address a flaw in how I see people apply “Inbox Zero”. Nolan uses the powerful metaphor of people in front of your door with their problems.

Just because there are people with problems in front of your door, that doesn’t mean they are your problems. You can choose to make them yours, but you want to be very careful about what to care about. Ideally you don’t care about any of these problems and none of these people (more on the people later).

Inbox Zero doesn’t mean you have to have looked at everything, or even handled everything (like replied to every email or commented on every issue), but to have sorted everything into piles that you can work on in batches (it’s more efficient from a context-switch perspective) when you have the time.

When you have the time. This implies that you have to make time to actually resolve issues coming into your inbox. This also means: if you can’t make time, these issues are not going to get handled. And the only way to be okay with this is to stop caring about the issues.

And being very good about being able to bubble to the top what you do want to take time for.

GitHub Notifications, like Email, is often treated as a world-writable todo list. This works for small number of people writing issues, but with a semi successful open source project or multiple small ones, you easily surpass this being a useful model.

As a result I treat all my open source notifications and email as: I might not get to this.


This is from my perspective of maintaining two large-ish Open Source projects: Apache CouchDB and Hoodie and many many small projects I started, or contributed to. CouchDB even went through the birth of the NoSQL database category, so on top of all the Open Source stuff, I had a nascent venture capital infused industry to deal with.

All the advice I have here is for later-stage Open Source projects. For early stage projects, care is the only thing you can give them. But once you’ve shipped version 1.0.0 or even 2.0.0, once you wrote all the documentation, once people start using the project in production with success, once you’ve talked the 100th person through getting started on IRC or Slack, your priorities have to change.

Here’s the list of things I do care about in later-stage Open Source projects:

Not Caring

Here is a list of things that come up repeatedly, with any variety of urgency, anger, and frustration:

“Hey, I found [other database] works better for me.”: Great! I don’t care.

“Hey I’m building this app / solving this university assignment, can you help me with…”: No, don’t care.

“Hey, I see you haven’t released a new version in X days/weeks/months/years”: I don’t care.

“Hey, I found problem X in your tool”: I don’t care.

“Hey, I can’t get started with your thing”: I don’t care (I’ve already written the docs).

“Hey, I reported this issue, but nobody is picking it up”: I don’t care, send a PR and it might get better.

“Hey, I opened a PR and it doesn’t get merged”: I don’t care.

“Hey, I opened a PR and it doesn’t get merged, and now I’m frustrated and I blame you for stringing me along to spend so much time on this.”: I especially don’t care about guilt-tripping.

“Hey, I read on Hacker News…”: I don’t care.

“Hey, your project is shit.”: Don’t care, insta-block.

None of this is to say that I don’t try and address these people’s issues and concerns, as much as I can, too. But on my terms and in my time, and the only thing that lets me sleep at night is not caring about any of these things. I’ll get to them eventually, some may fall between the cracks.

It’s not nice from a project or people perspective, but short of leaving the project and leaving it all behind, I found this to be the only way to make my personal Open Source maintainership sustainable.

Ten Years with CouchDB

I read a lot of biographies. There is a pattern where people move on after ten years on a project, be it a band, a movie franchise, a company, or an open source project. Not everyone leaves whatever they are doing after ten years, but there is a definite trend.

A few years ago, when my ten years with CouchDB started showing up on the horizon, I started wondering whether I’d be one of the people that feel after ten years, they have given their project everything they had to give, and that they had to move on.

I started preparing for the fact that I might feel like I’m done with CouchDB. I started thinking about what that would mean in terms of transitioning my duties at the project.

I never got very far. A scenario where I wouldn’t be part of the CouchDB project just didn’t present itself. So while still being open minded about the ten year mark, I stopped worrying about it.

Getting Started

CouchDB 2.0 just came out. It is a major milestone in the project. In a way it is finally fulfilling CouchDB’s original vision. It occurred around my ten year anniversary, and from a timing point of view, it would be the perfect moment to move on.

But I never felt it. I never felt being done. Instead, I feel we are just getting started. We’ve got the basics down now and there are a large number of topic areas that we can pursue to make CouchDB a lot better for a great number of people.

From the Archive

My first contribution to CouchDB was a Unix-compatible build system (Linux, FreeBSD & Mac at the time). Custom Makefile and everything. It became part of CouchDB 0.5.0 and I threw in a Mac application as well.

I have since worked on every part of the project, and I have a long list of things I’d like to achieve before I feel I’ve given CouchDB everything I’ve got to give.

I feel like I’m just getting started.

Archive →