Story Time: When I was new in Berlin in 2007, I had worked from home as a freelance consultant for many years and I was ready to think about getting an office. One of the reasons why I was moving to Berlin was to have more opportunities to meet likeminded people.
In the city I moved to Berlin from, that is otherwise lovely, everybody was very much doing their own thing. Open source and community was not a topic at the time, and I didn’t feel rooted enough to start something. From Berlin I knew there was a PHP user group that people I knew regularly attended. That sounded exciting to me, I wanted to be part of something like that. One day, I found myself in a U-Bahn towards RailsConf EU randomly meeting @langalex on our way to RailsConf EU and we started talking. His company with @freaklikeme had just moved moved into a new office space, but they had a few desks to spare. At the time coworking wasn’t really a thing, but we had heard of it, so the idea to move in with them made immediate sense. Some time in 2008 I became the first renter of what was later to become @co_up. Soon joined by…
Soon joined by now Berlin veteran luminaries like @kriesse, @klimpong and @roidrage we had a lot of fun working our respective jobs, share lunches in good company and exchange knowledge about the technologies we were interested at the time. @langalex positively spent weeks teaching me git on the side.
At the time, I had occasion to go to California where I met @dreid, who I knew from my open source work on Erlang and CouchDB. He introduced me to the concept of a Super Happy Dev House (SHDH). Basically a weekend of hacking on fun stuff at the office.
One of the most mindblowing (to me at the time) things about SHDH was that it came with instructions on how to run your own: http://termie.pbwiki.com/HowToDevHouse. I thought how hard can it be? We have a nice office space, we had many friends who might be up for it.
So we ran one. Introduction and recap links: http://jan.prima.de/plok/archives/161-Introducing-DevHouseBerlin.html http://jan.prima.de/plok/archives/163-DevHouseBerlin-1.html It was a great success.
I met many fun people there over the weekend, many of which are still active in Berlin actively doing community work. In the recap, you can read about how the @SoundCloud founders popped by and hacked up a web-iTunes using jQuery UI on top of their API.
Just to highlight a single connection here, every single developer event I have done in Berlin that required sponsorship has since been supported financially by SoundCloud. And all attendees have countless of similar stories each.
Long story long: we caught a first glimpse of what benefits to the community it had to run open and accessible events, and we all would double down hard after this.
Our little office community quickly outgrew the original office space and we started looking for a larger place and settled eventually on what became the original @co_up: a larger coworking space, and success didn’t stop there.
On top of the coworking, we also kept organising events, like @berlinjs and @upfront_ug, which have since long been surpassed in number and frequency by multiple events every week (h/t’s @rmehner @sheley @carolstran. And most recently the inaugural @queerjs (h/t @nikkitaFTW.
A few years in, we again could make good use of a larger office space and a new floor had opened up in the same building and put up a little fundraiser to be able to cover renovations. In particular, we ordered custom-built folding tables that allowed us to transform the floor from coworking by day into a meetup space by night in the matter of five minutes. The @co_up third floor you all know and love today was born and we started to run events down there, and kept the coworking separate on the fifth floor.
One special one-off event, heavily inspired by the @RailsGirls project, we ran a JavaScript for Absolute Beginners workshop (JSFAB. h/t to @theophani and @marijnjh for the inaugural teaching materials https://writing.jan.io/2012/07/22/jsfab.html
JSFAB brought willing learners and willing teachers together in a safe space to enjoy technological education. For free. Even while planning the event, it became clear that this model of well-educated people with well-paid jobs using their privilege giving back to the community wasn’t limited to JavaScript, and Open Tech School was born at the same time, as an umbrella organisation for community-teaching, but for any topic. http://www.opentechschool.org— Open Tech School is worth its own thread, but they have run many hundrends of meetups for any and all topic imaginable. They’ve enhanced the initial teaching weekends with continuous learning groups that kept people growing, a proper, completely volunteer run school, for anyone, for free.
I frequently get asked about how to transplant, for example, @berlinjs into another city, and while donated office space is often available, there is usually a commercial quid-pro-quo, when a company opens their doors, which often is to the detriment to the event itself.
My first reaction usually is: well, for starters, you need a @co_up. A not-for-profit community space, centrally located, lots of tasty street food nearby (so you can avoid terrible pizza sponsorships), that is free to use for free community events. That’s then usually where the conversation stops, and I have to reflect that what @langalex and @freaklikeme have set up with @co_up and what the rest of the community has done to run with that is properly unique.
I am no longer able to remember and recount all the magical things that happened when one community or another came together. 10s of 1000s of people have been through @co_up events. 1000s have used events at @co_up as a first step into the community, like I did with PHP all those years back. Again 1000s have found new friends, new employers, new co-founders, even new partners and the collective benefit of bringing all these people together in the past 12 years is immeasurable.
Unfortunately, as you already know, capitalism. All this success has downsides. One of which is property speculation in the city going rampant. We finally have a rent break in place, but that’s after rent hikes of over 2x in 10 years just a few blocks away from @co_up.
Over the years, we have seen the building @co_up is located in transform from predominantly producing industry to IT. A lot less of which likely would have happened, if @co_up didn’t prove the viability of the location. None of that, however, counts today.
The @co_up third floor rent is getting jacked up significantly in January and @co_up is running a fundraiser to get the community to support paying the new rent. For me, this is an extreme no-brainer. Even after moving out of @co_up, @neighbourh00die kept supporting it.
From what I can tell, the fundraiser is mainly supported by individuals who experienced the benefit of a not-for-profit event space first hand and this warms my heart. However, the funding goal is mere peanuts for Berlin’s well-funded tech companies and startups.
The equation that supporting @co_up quickly amortises your recruiting costs, some of which are many times the monthly rent required to keep @co_up open, seems not to sink in.
Aside from a few trusted partners, Berlin’s startups are, unsurprisingly, happy to exploit the free support system, but I think it is a disgrace. If your company has any budgets left for 2019, or if you are ready to commit, even just a little monthly donation (say 100€), you can help make one of the pillars of Berlin’s community sustainable for the long term. Give generously, and #SaveCoUp. Take a minute to scroll through the hashtag and see how many people, how many user groups and meetups you could be supporting.
Bonus Story
One more bonus story. In 2015 during the West African Ebola crisis, a non-profit running vaccination programs in the region started setting up a development team in Berlin to be able to move faster. because @co_up was a natural fit for such a team, they settled quickly.
At the time, the Ebola-affected countries were dealing with many compounding crisis, including a lack of infrastructure. The non-profit set out to build tools to help first responders that turned pen-and-paper-based processes into mobile web apps.
That allowed first-responders to help more people faster, and make their work more organised and collaborative. When trying to contain an epidemic, time and speed are a factor.
Because of the lack of infrastructure, the team had already settled on @CouchDB and @pouchdb for their technological foundation, because no other technology was readily available and open source that would allow them to quickly build mobile web apps that worked offline.
One day over lunch, they asked around if the others at @co_up knew anyone who knew @CouchDB. As @CouchDB project management chair and longest standing contributor, I’ve had talked to each and every person at @co_up about it, if they didn’t stop me quickly enough and so we quickly got put together.
In the course of about 12 months, my team at @Neighbourh00die and I fully joined @eHealth_africa to build out the Berlin development team. We grew from ~6 to 29 in the course of six weeks and helped build tools that eventually ensured that the Ebola endemic could be stopped.
We also worked on the apps that ran the first clinical trial that later lead to the first Ebola vaccine in history.
A lot of things came together to make this happened, but if it weren’t for @co_up, it would likely have gone a lot slower.
❧
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.
❧
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:
- you can’t use the Apache project’s name or trademark(s).
- you must include a copy of the license and a notice that the project in question is being used by your project.
- if you changed anything in the Apache project, you need to mention that too.
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).
FAQ
What are the options for ASF projects now?
-
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.
-
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:
-
React is more than just it’s core, but there is a wide ecosystem for many related tasks around building web apps. Many of those related projects are also licensed under BSD+Patents, so they can’t be used either, and few or no replacements exist for those. So “moving to X” is not as trivial as it might sound, depending on the level of other projects that are used on top of React. As a point of data, for CouchDB’s Fauxton admin interface, the porting work is estimated at 3+ months of dedicated developer time for switching away from React. In our case, it’s a significant time investment that takes valuable developer time away from other pressing matters.
-
React includes a number of technical innovations, some folks have suggested to move to another framework that includes a subset of these innovations (say JSX), but not any of the other ones, including API compatibility. Moving to such a framework is significantly more work than the previous option. In CouchDB/Fauxton’s case, that is very likely prohibitive, but we’re still exploring options.
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?
Nothing.
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.
Nothing.
What does this means for me/my Open Source project/my company that is using React?
Nothing.
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?
Yes.
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.
❧
