How to Use Open Source Without Losing Your Code, Users – or Sanity

Many startups today open source their products. But it’s not just startups: Microsoft open-sourced VSCode and GitHub Copilot; Meta gave us React and LLaMA; Google opened up Android and the Chrome browser. All of them rely heavily on Linux – itself an open-source operating system.

So for many – especially startups building infrastructure or developer tools – building on open source, or open-sourcing their own product, might seem like the obvious, default choice.

But it’s not. Far from it.

How not to use other people’s open source projects

A year ago, PearAI (a YC-backed startup) forked VSCode and the Continue.dev extension, repackaged them, and presented the result as their own. The move sparked public backlash and led Y Combinator to issue an apology for mishandling the situation.

While PearAI’s intentions may have been good, their actions revealed a lack of understanding (or concern) about intellectual property. This was exemplified by their defense: “Dude, I ChatGPT’d the license. We’re busy building- can’t be bothered with legal.

Recently, another YC startup, Glass, made a similar misstep: they took an open-source project, changed the license, removed attribution, and claimed to have built it in just four days. Public backlash was swift once again.

The issue here wasn’t that they copied or reused the code – the license does allow that. The issue is that they changed the license to something else, didn’t acknowledge they weren’t the original authors, and again demonstrated a profound lack of understanding or care about it.

This “it’s open source, so it’s not stealing – who cares?” mindset from move-fast-and-break-things startups reflects poorly not just on the founders, but also on their investors. Both of these startups are part of YC, which now risks appearing as if it either doesn’t know – or doesn’t care – about intellectual property when it comes to open source.

How not to open source your own stuff

On the other side of the table are founders who open source their product without fully understanding the consequences.

Earlier this year, the author of ColorMagic complained that someone had ripped them off. And yes – if you open source your product, someone can take it, tweak a few things, and host it themselves (as long as they follow the license). Someone did exactly that, and the author was upset.

To make matters worse, the author didn’t even choose a specific open source license that could have protected them while still being open.

I get it – developers, designers, and founders aren’t lawyers. As a developer and founder myself, I can relate. But ignorance of the law isn’t an excuse for breaking it. Open source, in particular, works best when we all try to be good citizens of the community. And that means having at least a basic understanding of open source licensing.

Public humiliation for a two-month-old startup is a minor issue compared to what can happen later in your product’s life, especially if it gets popular or if you’re being acquired.

When licensing missteps come back to bite you

One of the things that prospective buyers will do is make a thorough technical and legal due diligence. This involves tracing the origin and ownership of all intellectual property in your startup.

If this kind of error is detected at that stage, it’s much harder to fix: there may now be years of work and thousands of lines of code done under an incorrect license, which must be retroactively applied. In the end, you might be forced to publish all of your own source code, potentially lowering your acquirer’s interest.

Another high profile example is ElasticSearch, which initially used a very permissive license, with the business model of selling a managed version of the database.

When they got popular, Amazon hosted a version on AWS, allowing it to get revenue without investing in the service development. ElasticSearch overreacted, switched to a non-open-source license, to the ire of many genuine open source users, which flocked to Amazon’s open source fork. ElasticSearch backtracked later, switching to a more strict open source license which does prevent Amazon from doing what they’ve done.

MongoDB and RedisLabs had the same model as ElasticSearch, ending in the exact same situation, with similar results.

Be a good open-source citizen!

When thinking about open sourcing your code, consider these questions:

• Why do you want to open source? What it is that you hope to achieve? You must have a good reason, not “everyone else is doing it”
• What if your competition just takes your code and uses/improves/hosts it? Does it matter? What’s your moat?
• Based on the above, how “open” do you want to be? (open source everything under a very permissive license (MIT, BSD, Apache) OR open source non-core or commodity parts of the code; keep secret source secre OR open source everything under a strict license, so that anyone using it must contribute code back to you (GPL, AGPL))
• Open source “eventually”, but not right now – constrain competition while being “almost” open source  (FSL, BSDL, SSPL)

When using 3rd party open source, especially for a core of your product, consider:

• What does their license require you to do? Are you required to open source your own code? Can you freely host and redistribute it?
• You’ll have many dependencies – how do their licenses mesh together? Some are known to be legally incompatible.
• Keep some kind of log – know which 3rd party code you forked or depend on, what are the licenses, so you can always trace the IP ownership
• Don’t “chatgpt” a legal document. Ask a lawyer, or at least find a template from a reputable source.
• Don’t invent your own license (“enterprise” or otherwise). Use a well known license that your customers will have easier time to evaluate as well.