Examples of companies undercutting smaller companies using FOSS? [closed]

Question

When speaking to my friends about FOSS, a common concern comes up that if they release their code under a free and open source license, this might encourage companies to 'steal' their hard work without giving them compensation. Obviously if the code was released under a free and open license it wouldn't be stealing but the sentiment remains.

My question is:

Are there cases where individual contractors or small companies (1-5 employees, say) have released their source code under a free and open license and had a bigger company under cut them, take customers or profit away from them or drive them out of business?

Ultimately I think there are stronger arguments to make source code free and open than "bigger companies won't take business away from you" (i.e. "that doesn't happen") but I'm curious if there are any real world cases where making software free and open have significantly hurt a small software shop.

Answer 1

"Stealing" code is copyright infringement, which is obviously avoided by most legitimate companies. Losing a copyright infringement suit can easily destroy most companies. On the other hand, without patents, reverse-engineering and feature-matching is perfectly legal and done all the time. Some unethical companies can very well be doing the former whilst pretending to do the latter, and this is where access to the source code lets them do that easily. But as soon as these companies become big enough and of consequence, they quickly clean up their act - DivX being a prominent, closed-source example, where it's suspected that the initial release was based on infringing Microsoft's source code.

Therefore it highly depends on how visible and active those FOSS projects are. It's important to remember that not all FOSS projects are Linux, GCC or Mozilla, and it also depends on your adversaries.

• Large and active projects are practically immune; their tremendous goodwill and visibility makes it very risky to "steal" from, and their pace of development makes it hard to out-compete them regardless.

• Medium-sized projects can suffer but the damage is limited. The reason is, again, if unethical competitors get large enough, it also makes them more attractive targets of lawsuits, so they either stay small or clean up. For example, FFmpeg - a suite of FOSS audio/video codecs - is a popular target of copyright infringement. Although most are minor infractions of their (L)GPL licenses, no doubt some are blatantly infringing.

• Small projects can indeed be undercut. If the market is small enough to stay under the radar of lawsuits, an unethical company can easily claim the code as their own, release a closed-source competitor and crowd out the market through providing superior value. Here's an example:

  A competitor [to DikuMUD], at the time, also had based theirs on the same codebase, and they opted to blatantly ignore the copyright, rip out all traces of it, and basically lie to everyone including themselves. Their logic was "none of the original code exists" and "we have done massive rewrites and improvement" and generally ignoring the fact that they started with 20,000 lines of code. They were charging for items in the game, and making too much money to stop.

Answer 2

Plausible, an open source alternative to Google analytics, released a blog post detailing their move from MIT licensing to the AGPL (Affero GNU Public License).

In it, they have the following claim:

Here are a couple of events that made us aware of the risks with a permissive open source license:

• There’s been at least one case where a corporation has taken parts of our code, made it closed source and started selling it as a direct competitor

...

As of this writing, Plausible looks to have two full time employees.

Answer 3

I'm going to answer your question from the perspective: what is the risk to open sourcing the technology that your friend's business has developed. I try to tackle your more specific question at the end.

TL,DR If your friend's company is built around the technology the company would open source, it's a real risk that their company would not be financially viable if the make the code available as open source, but it's unlikely to be as the result of a competing company forking their code.

If you venture outside the GPL-only ecosystem, I classify companies that support major open source projects in two categories:

1. The open source project is an important part of their infrastructure but not central to their business (think Microsoft with .NET Core or Facebook with React)
2. The open source project is the central to their business (think Cassandra and DataStax)

Within each category there are different ways to try to monetize the open source, but I think this high level view is sufficient for this question.

If your friend's company finds itself in the first category, putting the code out under an open source library is minimal risk to them in terms of other companies adopting it and using it to compete against them. For example, having access to React would not immediately let another company recreate Facebook's business and compete against them.

If your friend's company finds itself in the second category, they need to more carefully think about their business model. There are two major risks here:

1. The vast majority of people and companies that use the open source project will do so without paying for it. The business must be sustainable based on income from the minority that chooses to pay. If the technology is in a niche business area where the pool of potential users is small, this may be unsustainable.
2. If the business is too closely linked to the technology (e.g. all they do is provide consulting services to enhance the technology and help people install it), it would be possible for another business to provide the same service and do it better, whether that is with the same or with competing technology.

Your question is really about the second risk here, but the first risk will be the bigger one. Unless the company has convinced itself that there are enough users that are actually willing to pay for the use of the technology (or services associated with it, etc), then the company will not be viable if they make it open source.

How big a risk the second one is really depends on how unique and complex the technology is and how big the market for it is. Forking an open source project is kind of like any software maintenance work: there is a body of code that costs time and money to understand and improv. If the potential reward for doing this is not greater than the cost and time to do it, then it's not worthwhile.

If your friend's company's codebase is not that big and the market for it is not that large, it's probably not worth the effort for a competitor to fork the code and compete against your friend's company. If the codebase is not that big and the market is huge, then the risk is potentially real, but, because the codebase is not that big, it's equally likely a competitor would come in with their own implementation.

The most likely scenario for head-to-head competition based on a fork is large codebases with large markets. A ground up rewrite would be painful so a competitor would want to start with something it can already monetize. Companies built around Linux distributions as examples of this. StarOffice / OpenOffice / LibreOffice is another example.

Answer 4

The late Pieter Hintjens, responsible for ZeroMQ, included an interesting story in the ZeroMQ manual. He gave it the title Eat Me and it's about the proud developer of some software that he released under a permissive license. He was happy giving talks about his project and doing a consultancy gigs here and there. He even hired an employee.

However, a more commercially oriented company took his project and released it under a copyleft license. That company respected all the legal obligations of the permissive license, so everything they did was correct from a purely legal point of view, but Patrick was extremely unhappy with the situation and abandoned working on open source in general.

As similar scenario almost happened to me too. I am the original developer of iText, an open source PDF library which I originally released under the MPL/LGPL. This library was used in Google Analytics, Google Docs, and Google Calendar. Google would upgrade to the newest version on a regular basis. I was extremely proud that Google found my software interesting enough to use it. The fact that I didn't make any money with it, wasn't important, or so I thought. However, as more companies started to use iText, it was getting harder and harder to combine my work on iText with my day job.

Then one day, my wife came back from the hospital with our son, informing me that our boy had been diagnosed with bone cancer. Life became hell, but that didn't stop people from sending me tons of mails, asking for help with their project. Even when I explained that I had other worries, some people could be very persistent. In one case, I mailed the employer of one of the developers.

This is the mail I received from that employer (in Dutch):

Instead of translating this mail, allow me to share a page from my book:

In short: I live in Belgium and a Belgian company preferred involving TCS rather than its own IT division (because TCS was less expensive). A developer at TCS used my software and asked me to solve a problem for free. Unfortunately, the developer at TCS failed to provide me an SSCCE that would allow me to reproduce the problem. When I contacted the Belgian company and proposed to work for them directly, which would probably solve their problem, I was told there was no time and no budget to do that.

I would have to start looking for a way to generate money with iText. As I had no clue how to do that, I thought Google would be willing to help me out with some advice. See Chapter 13 of Entreprenerd:

This was one of the mails I received from Chris:

I was extremely frustrated to discover that everyone was very happy to use my software, but no one seemed to care enough to help me out finding a way to ensure the further development and the future of iText.

I remembered the article Google open source guru: 'Why we ban the AGPL' in which Chris DiBona was quoted.

"This might sound a little jerky, but a lot of the [available] AGPL software, we don't need to use," he said. "It addressed areas where we already have software. So there isn't a lot of call for it."

The people I had eventually hired to help me with the business used this article to convince me to change the license from the MPL/LGPL to the AGPL.

Google had been updating its applications with new versions of iText on a regular basis but stopped doing so as soon as iText changed its license to the AGPL.

After the license change, Google had four options:

1. Continue using old versions of iText that were still MPL/ LGPL free of charge for as long as possible. That could work because it’s impossible to change a FOSS license retroactively.
2. Continue using the latest versions of iText free of charge. In this case, they would have to release the complete source code of all its software containing iText as (A)GPL software.
3. Continue using the latest versions of iText in a closed source context. This required entering into a commercial agreement with iText to avoid having to disclose their source code.
4. Replace iText as soon as possible with another library. Obviously, they would have to find one that could be used free of charge and without having to meet any copyleft conditions.

Google initially chose the first option. Even today, Google is still using the more than ten-year-old iText 2.1.6 by 1T3XT in Google Calendar. Google certainly didn’t want to release its code for Analytics and Docs as AGPL software. There were some negotiations about a license for Google’s use of iText in Docs, but those didn’t amount to anything. For Google Analytics, Google chose the fourth option. Initially, it replaced iText with a library called Cairo, which was a huge step backward in terms of the quality and usability of the reports. Cairo was later replaced by Skia PDF.

Initially, I received plenty of angry mails and insults for the license change.

Developing a business for iText was quite a rollercoaster, but eventually, I managed to win the Belgian Edition of Deloitte's Fast 50, meaning that iText Group was the fastest growing technology company in the country. In less than 10 years, we went from a revenue of 0 to more than 10M. Eventually, I was able to sell the company for a grand total of about $50M.

For further reading, see Open Source Survival: A Story from the Trenches. Of course, there's also the book. I've made a coupon with a reduction (valid until June 30) for those who are interested in reading the full story.

Answer 5

The question I posed above is a bit ambiguous. Did I mean a larger player using FOSS and retaining the FOSS license to crowd out the competitor or did I include straight up copyright infringement? Many years later, I think the original intent of the question was the former (bigger player pushes out smaller player while still maintaining the FOSS license) but I didn't clarify.

In lieu of this, here's an example of Sun Microsystems stealing FOSS, stripping the original author's name and licensing information off of it and claiming their own copyright on it.

Brendan Gregg, of Sydney Australia, circa 2005 had been creating FOSS scripts to extend DTrace. A visiting Sun consultant was demoing new functionality to Gregg wherein it became apparent the visiting consultant was demoing Brendan Gregg's own software to him.

Here is a choice quote:

Some of my tools had even included the line:

Author: Brendan Gregg [Sydney, Australia]

And now, here he was, in Sydney, Australia, trying to sell Brendan Gregg's tools to Brendan Gregg.

One of the Australian Sun staff interrupted: "Those say copyright Sun Microsystems." Most of my tools had my own copyright and a GPLv2 or CDDL license. But these only had Sun's standard copyright message, and the open source licenses had been stripped.

"You deleted my name! And the copyrights and licenses!"

The other Aussie added, to the VIP: "You can't do that." A silence fell over the room as the magnitude of what had happened sunk in. While some at Sun were encouraging open source contributions and building a community, others were ripping off that same community. Taking their work, changing the licence and copyrights, and then selling it.

Archive.org link to future proof against link rot.