How to capture / protect an open-source project

There is an interesting article on Ars Technica about how Google is gradually closing Android. This is a classic game Capture the Flag, which is fought against the open-source community. I'm going to explain how this capture works, and how to prevent it.

Why Capture the Flag?

As Ars Technica says: “It's easy to give something away when you're in last place with a zero market share, as was the case with Android at the beginning. When you're first, it's a little harder to be so open and friendly. ”

Android, to be honest, is probably Google’s biggest investment. You can argue about whether they have the right to turn an open system into a closed one, and you will be right. However, this is the same as arguing about whether the central bank has the right to print too much money and create a devaluation. Of course, he is authorized to do so. But at the same time, there is a price that other people will pay. The issue is not legitimacy, but the acceptability of the price that society will pay. And if it is unacceptable, then how to prevent it?

Android, like any open source system sold to the market on this basis, is public property. When someone privatizes it, he increases his profits, like the central bank printing money, at the expense of the rest. By forking such Android applications as search, calendar, music, and creating improved versions of them, Google is competing with other companies using Android on their devices.
')
The question of capturing, how it happens and how to prevent it, is especially important if you are not Google, i.e. if you are a user or participant in an open-source project. Android has many patches from other companies, such as LG, Samsung and others. As Google turns the operating system into its own private garden, these patches begin to be used against the very people who made them.

I’m sure Google is making a huge mistake by changing the rules of the game in this way, simply because it will condone Android competitors. However, I'm not talking about that. I am simply interested in learning any lessons that will help me with my work and my projects.

I will note two things:

• Out of pure interest, I will not participate in an open-source project that will not give me, the participant, guarantees that my patches and changes will not belong to anyone else and will not be used against me.
• For reasons of ethics, I will never create an open-source project that will not provide such guarantees to its members.

Usage scenario

I will try to express myself unequivocally about usage scenarios. We are talking about Android: one company starts an open-source project, using it as a “bait product”, intending to penetrate the market, and asks for support from others. This is a classic strategy that can be very successful. However, this is definitely not the same as a student research project or trash like “let's make an open-source payroll accounting system” or “five of us gathered in the garage and decided to make a new framework”.

There is a partial coincidence, and I think the findings can be applied more widely (and I apply them systematically ), again, my use case is “open-source for a breakthrough into the market”.

It is important to know that the success of using an open-source project to break into the market depends on the community, which is taken for it. Any market depends on the behavior of several influential players that dominate the market, and the efforts of most other players are insignificant. The point is to promise this depressed impotence crowd, to convince them to invest in something new and open, which could potentially change the rules of the game.

Most of the open-source projects fail (seriously, go, read about some random project on GitHub and see how many of them are adequate), and even those successful in a very modest sense of the word are insignificant in themselves. While there is no serious change in power, the project can remain a potential breakthrough in the market for a very long time. He can look very stable and happy. Well, it's easy to be friendly when money is not at stake.

If and when a project becomes successful, the rules of the game change, the smart guys who have launched a breakthrough project, try to pick a ripe fruit and take it for themselves. And only then it becomes interesting.

The field with equal conditions of the game is not under the "ban"

There are several ways to capture an open-source project, including trademarks and patents. I will only consider copyrights, because this is the most common case. The key agreements that govern the copyright of an open-source project are a) a license and b) participation policy.

A common misconception is the idea that an open-source project cannot be captured. This is absolutely not true. Roughly speaking, there are three types of copyright agreements:

1. “Closed” license, which does not allow to re-process the material, classic copyright, plus some restrictive licenses;
2. license "free to take", which allows one-way processing of material, such as Apache / BSD / MIT;
3. A “share-alike” license that allows two-way processing of material, such as the GPL, LGPL, and cc-by-sa.

Imagine a DJ who releases a popular beat in a “free to take” model. The lead music label remixes a beat and releases it. That one becomes a hit. And now this new version is closed. DJ can not remix this new work, and, perhaps, can not even play a remix. Of course, he can take his old version and improve it, but the commercial version will bring money.

I hope you understand what I'm getting at. Even the best individual talent will not be able to compete on equal terms with a large company with its marketing and financial resources. The only way to guarantee equal playing conditions in the war for control of development is a bilateral agreement on the processing of material. Bilateral means both sides.

When people call this guarantee a limitation, it remains only to sigh about it. It's like calling a lock in my car a “restriction” because it stops the rest from misappropriating my car. To call protection against thieves "limitation" is .... well, at least inability to analyze. When the rules work for both parties, this is not a limitation, OK ?!

How is the capture?

Let's once again decide on the goal. It is necessary to prevent the open-source seizure of the project by someone with a lot of money and power, who aimed to harvest the project for their own personal benefit, at the expense of the community that helped develop or create the project. I don't care how “legitimate” this capture will be, I just explain how to prevent it.
The license and participation policy are two halves of the same puzzle.

Who owns the copyright? Are they “concentrated” by the founders of the project or are they divided among all the participants? This is a vital question. If they are concentrated, then it is a trivial task to buy copyrights, branch a project, change the license unilaterally, and you can move in a closed direction. However, if the rights are distributed, i.e. many people own the work, jointly own, then you need the approval of all (not the majority, but 100% unanimity) to change the license. And this is logistically impossible.

By the way, if you only knew how many people offered me money for a commercial license for ZeroMQ, you would be amazed (very much). The offer is simple: I sell them a non-LGPL license, they pay me good money and make their own versions of ZeroMQ. If I had not specifically taken care of the impossibility of this option a long time ago, I would have been very rich. And now the realization that ZeroMQ will survive me helps me to put up with poverty.

Let's go through the problem again with a proposal for commercial licenses for collaboration. Imagine a club that invites DJs and mixes their beats. Then the club reserves the copyright and sells them to the record company, which makes its remix album, which the original DJs can no longer play for free. So yes, I consider dual-GPL / commercial licensing perverse practices.

No one will pay for the commercial license of the free to take project, because they can simply take the code and use it. In a certain sense, I believe that this is already wrong, because violates the equality of the rules of the game for all. After all, it is obvious that a large company will benefit from this more than small teams. Again, imagine an independent DJ resisting record labels with all of their marketing and media connections and concert earnings.

We now turn to step number two: hiring developers.

“But the code is still free!”, People say. Of course. We return to the label vs DJ. Let the label hire only one DJ, a key employee, and use it to push through the album’s commercial mix. Where will the public go then?

You do not need to hire all members in the community to capture it. In any project taken at random, there will be two or three top participants and a huge mass of younger ones. Hire two tops and you can pick up the project anywhere. If the results can be reprocessed (remixable), then this journey will be completely fair to those who participated in the project before. And if not remixed, then all other participants will find that their investments are used against them.

Preventing seizure

I know only one model that prevents the seizure of an open-source software project:

1. GPL family license (or MPLv2, which works in a similar way).
2. Distributed copyright.

This is how I build open-source projects from the very beginning, and this is a requirement for any community I join. Your right to make money does not include my right to use my work as a competitive advantage, unless it is mutually beneficial.

To be continued...

---

about the author

“Unfortunately, we do not choose death for ourselves, but we can meet her with dignity so that we will be remembered as men.”
- the movie "Gladiator"



Pieter Hintjens - Belgian developer, writer. He held the position of CEO and chief software designer at iMatix , a company that produces free software , such as the ZeroMQ library (the library takes care of some of the data buffering, queuing, connection establishment and recovery, etc.), OpenAMQ, Libero , GSL code generator , and the Xitami web service.

• Author of more than 30 protocols and distributed systems.
• Founder of the Edgenet project to create a completely secure, anonymous global P2P network.
• President of the Association for a Free Information Infrastructure (FFII) , which fought with patent law.
• CEO of the Wikidot Wiki Project.
• He was an open standards activist and founder of the Digital Standards Organization .
• In 2007, Peter was named one of the 50 most influential people in the field of “Intellectual Property”.

Much detail here: Thirty five years I, as a necromancer, inhaled life in dead iron with the help code

It's time for my last article. I could write more, there is time, but then I will think about other things: how comfortable it is to sit in bed, when to take painkillers, and about people around me.

... I want to write one last model, the last protocol, which is dedicated to how to die, having some knowledge and time in store. This time I will not format the RFC. :)
Death report

Peter Hinchens website
Wikipedia article

about the project

I, with the support of Filtech-accelerator , plan to publish on Habré (and, perhaps, in paper) the translation of the book “Social Architecture” . IMHO, this is the best (if not the only adequate) manual for managing / building / improving communities focused on product creation (and not on mutual grooming or “worship” to the leader, sports club, etc.).

Thoughts and ideas of Peter Hinchens on Habré:

• Death report
• Optimistic Merging: First people, then code. Build the right community and it will write the correct code
• Social architecture: stratagem for success of open source projects
• How to build a community. Translation of the book "Social Architecture": Chapter 1. Toolkit

Call to action

If you have projects / start-ups with a high share of technologies aimed at public benefit in the first place and to receive profit as an auxiliary function (for example, like Wikipedia), write in person or register for an accelerator program .

If you send links to articles, videos, courses on the Coursera on managing / building / improving communities, focused on creating a product , with me chocolate.