This is one of two posts from the first week. The other, Git and GitHub, is the tools: what they are and how a change gets into a codebase. This one is about whose code you are willing to build on in the first place.

In class we have (or will) spend a little time on open source and licensing -- enough to give you the shape of it and not much else. This is the longer version, for when you need it.

And you likely will need it. Not because you are going to become a lawyer, but because at some point somebody on your team is going to say "let's just use this library," and you are going to be the person who decides. That decision has terms attached to it, and the terms occasionally bite.

Closed and open

Software gets built and brought to market two ways.

Closed-source software is a commercial asset. The code is seen only by the people working on it, and the intellectual property belongs to whoever owns the company. Most software that is sold, whether packaged or as a service, works this way. If a company's secret sauce has anything to do with the code, they are not going to show you the code.

Open-source software has its source code available to the public. That is the whole definition. Note what it does not say: it does not say free, it does not say non-commercial, and it does not say nobody owns it. Plenty of open-source software is built by large companies, for commercial reasons, and is owned by someone specific.

Why anyone gives work away

The reasonable first question is why a developer or a company would put thousands of hours into something and then hand it over.

  • Crowdsourcing. Publish the code and other people find your bugs, and sometimes fix them. The project gets better than you could have made it alone.
  • Knowing what is in your food. Telegram publishes its source so it can prove it is not doing anything malicious with your data. A closed product cannot make that promise; it can only assert it.
  • Reputation. An individual developer open-sources a piece of their work so that employers and future partners can see what they are capable of.
  • Recruiting. A company open-sources something interesting so that the developers they want to hire come and look at it.
  • The ecosystem, which is really marketing. Google does not open-source all of Chrome, but the engine underneath it is open. Other browsers get built on that engine, and when one of those browsers does not work out, moving to Chrome is easy, because it is the thing you were already standing on. Being the foundation other people build on is a competitive position, not charity.

The biggest reason underneath all of those is less strategic than any of them. Software is built the way science is built, by people standing on each other's work. Donald Knuth, the Stanford computer scientist, put it this way:

People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones.

That has never been more true than it is right now. The reason you can build something sophisticated in a quarter is that thousands of people already built the parts you are standing on.

Here is what that looks like in practice. Every application with users has to handle user security: passwords, sessions, encryption. Almost no business is about user security. It is table stakes, it is subtle, it is easy to get wrong in ways that hurt people, and writing it yourself costs you weeks you needed for the thing your product is actually for. So you take a library that already exists, that thousands of other applications have already stress tested, and you spend your weeks on your own problem instead.

Do not fool yourself into thinking you are going to write all of your own code. Nobody does this. You would never want to, because you would spend all your time in the foundations and never get to the interesting part.

Licensing: the two families

Open source is not a free-for-all. Every open-source project carries a license, and the license is a real legal document with real terms. There are many of them and there are endless variations, and when it matters you read the actual text or you ask someone whose job that is. But nearly all of them fall into one of two families.

Permissive. Do what you like. Use it, change it, sell it, bundle it into something closed-source. Most permissive licenses ask for one thing in return: keep the copyright notice around so people can tell where the code came from. The MIT license is the most common one you will see, and Apache 2.0 is the other big one, which adds some explicit language about patents.

Copyleft. You may use this, and you may change it, but if you distribute what you built, the result has to carry this same license. The GNU General Public License, the GPL, is the one you will run into. The point is reciprocity: the code was given to you open, and whatever you make out of it goes out open too. Sometimes it is called "share-alike," which is a better name for what it actually does.

One thing worth being precise about, because the short version in class makes it easy to get backwards: copyleft does not mean the code is frozen. You are absolutely allowed to modify GPL code. Modifying it is the point. What you owe in return is that your modified version goes out under the same license, so that the next person gets the same freedom you got. The obligation is on what you publish, not on what you touch.

It is permissive licenses, not copyleft ones, where "leave it alone" comes closest to the truth, and even there the obligation is usually just to preserve the notice.

choosealicense.com is a genuinely good, short guide to picking one, and it is the right link to send a co-founder who is about to make this decision for your company.

Case study: the Linux family tree

Linux is the most widely deployed operating system in the world. Not Windows, not macOS. Estimates move around and depend on what you are counting, but the large majority of the web servers on the internet run some flavor of Linux, as does every one of the world's fastest supercomputers, and so does every Android phone. It was written by Linus Torvalds, who also
later wrote Git, which is the other thing we covered in week one. He has had a productive career.

The core of Linux, called the kernel, is licensed under GPLv2. Copyleft. That single fact shapes an entire industry, and the shape is worth following.

Distributions. Ubuntu, Debian, Red Hat and Fedora are all built around that same kernel. Their kernel remains GPL. They wrap it in package managers, installers, desktop environments and support contracts, and those pieces carry their own licenses. Red Hat built a large public company selling support and certification for software anyone could download for nothing.

Android. In 2008 a team at Google built a phone operating system on the Linux kernel. Android's own layers, the parts Google wrote, are licensed under Apache 2.0, which is permissive. That combination surprises people, and it is worth understanding why it is allowed, because it is the single most useful thing in this whole post.

It is not because Google left the kernel alone. Google modifies the kernel substantially for Android, and those modifications are published under the GPL, exactly as the license requires.

It is because of a boundary. Torvalds attached a note to the kernel's license saying that ordinary user-space programs that call into the kernel through normal system calls are not derivative works of the kernel. They are just using it. Android's own layers sit on the user-space side of that line, so they do not inherit the kernel's license and Google can license them as it chooses. Google also deliberately built Android's C library from permissively licensed code rather than the copyleft one Linux distributions normally use, for exactly this reason.

The lesson generalizes past Android: where the boundary falls between your code and the copyleft code is the question that decides your obligations. Linking a GPL library directly into your application is a very different act from running a GPL program as a separate process and talking to it. If your company is ever seriously weighing this, that is the question to bring to a lawyer, and it is a question you can now ask precisely.

On top of Android. Because Android is permissive, anyone can fork it and build a commercial product. Amazon did, and Fire OS runs the Kindle Fire line. Meta built the software for its VR headsets on it. Peloton runs it on the screen bolted to the bike. None of those companies had to open-source the product they built.

A small correction to something easy to assume here: Amazon is not prevented from charging money for Fire OS. It could. It does not, because Amazon's interest is in selling devices and content, and giving the operating system away with the hardware serves that. The constraint is a business decision, not a licensing one.

Follow that chain once more, because it is the point of the whole case study. A copyleft kernel, given away in 1991. A permissive operating system built on it by one of the largest companies in the world. Closed commercial products built on that, by three more. Your closed-source product will sit on a stack like this one, whether or not you ever look down.

The four questions you asked in class

These came from the room, not from the slides, and they are the right questions.

How is any of this actually enforced?

Mostly the way any contract is: somebody notices. An employee, a competitor, a customer who asks for the source, or one of the organizations that exists specifically to notice. The Free Software Foundation and the Software Freedom Conservancy have both pursued GPL violations, usually by asking first and suing rarely.

The famous case is a router. In the early 2000s Linksys shipped the WRT54G, a wireless router that turned out to be running Linux inside. The GPL obliged them to release the source for what they shipped, they had not, and the community noticed and pushed. Cisco, which by then owned Linksys, released it. The released code became OpenWrt, which is still running on routers today. The violation ended up producing a piece of open-source infrastructure.

Here is the version you are more likely to live through, which happened to a company one of us worked with. They were using an open-source front-end framework. The framework changed its license on a new version. They upgraded, because they wanted the new version, and nobody on the team connected the upgrade to the terms. About a year later somebody worked out that they had been out of compliance the whole time, and it was settled with a payment.

Nobody was reckless. They upgraded a dependency, which is a thing engineering teams do dozens of times a quarter without anyone thinking about it, and the terms had moved underneath them.

Does Linux force updates on you?

No. The project keeps developing, and you run whatever version you chose to run. Nobody can reach into your product and change it.

You will usually want the updates anyway, because that is where the security patches are and because software that stays still gets stranded as everything around it moves. But taking them is your decision, and it is a decision, which matters for the next question.

Can a project change its license retroactively?

Not for the version you already have. The copy you received came with terms, and those terms came with it.

The next version is a different matter. A project can license its next release however it likes, and if you upgrade, you have accepted the new terms. That is the trap in the story above, and it is worth stating plainly: the risk does not arrive when the license changes. It arrives when you upgrade.

This is not hypothetical or rare. Over the last several years, a number of widely used projects have changed their terms on a new version, sometimes to a license that is no longer open source at all. Redis, MongoDB, Elasticsearch and HashiCorp's Terraform all did some version of this, and in several cases the community responded by forking the last version under the old terms and continuing from there. If your product depends on something, a license change upstream is a real business event, not a legal footnote.

The practical defense is unglamorous and it is the same defense as for every other dependency risk: know what you depend on, and have someone actually look when a major version lands.

Does everything built on copyleft code have to be open source?

No, and the Android section above is the long answer. The short answer is that it depends on whether what you built is a derivative work of the copyleft code or a separate thing that uses it, and that boundary is technical as much as legal.

What is not optional: the copyleft code itself, and your changes to it, stay under that license and have to be available to the people you distributed it to. You cannot take GPL code private. You can, in many architectures, build something of your own next to it.

And one you asked that we could not answer

Somebody asked why the authors of copyleft projects care, since a permissive license would get their code used more widely. It is a good question and it deserves a real answer.

The answer is that for the people who started this, wide adoption was never the goal. Richard Stallman and the Free Software Foundation designed the GPL in the 1980s to protect a commons. The worry was specific: that software written to be free would get absorbed into closed products, improved there, and that the improvements would never come back, leaving the open version permanently behind. Copyleft is the mechanism that stops that. It is a one-way ratchet, and every improvement anyone distributes lands back in the pool.

Permissive licensing makes a different bet, which is that the widest possible adoption is worth more than the guarantee of reciprocity. Both bets have paid off enormously. They are simply different bets, and a project's license tells you which one its authors made.

Reading a repository before you depend on it

The part of this that will matter to you most often is not the law. It is judgment: deciding whether some project you found is something you want your product to stand on. You will make this call many times, and usually in about four minutes.

Open the repository on GitHub and look at these, roughly in this order.

  1. The license. It is listed in the sidebar. If there is no license file at all, the default is that you have no rights to use it, whatever the author intended by putting it in public. "No license" is a red flag, not a green one.
  2. The last commit. Near the top of the file list. A project last touched four years ago is a project you are adopting, not using.
  3. Issues and pull requests. Do not just read the count. Open the tabs. Are maintainers replying? Are pull requests getting merged or quietly piling up? An open issue list is healthy. An unanswered one is not.
  4. Releases. Regular releases mean somebody is still steering.
  5. Who is behind it. One person's side project and a thing maintained by a company or a foundation carry very different risk. Neither is disqualifying. You just want to know which one you are picking.
  6. Stars and forks. Useful, weak signals. Stars are closer to a bookmark count than a quality score, and old popular projects keep their stars long after the maintainers have moved on. Read them alongside the last commit, never alone.
  7. Documentation, and a demo if there is one. Many projects run a live demo page. It is the fastest way to find out whether the thing does what you think it does.

Three worth opening, because they are good examples of different shapes:

  • microsoft/vscode, the editor you are using in your Codespace, maintained by a large company in the open.
  • nasa/openmct, NASA's mission control framework, with a demo page you can click through.
  • chromium/chromium, the engine underneath Chrome and most other browsers, and an example of the ecosystem argument from the top of this post.

What this is really about

You are not going to be the person reading the license text. You are going to be the person who decides whether the team takes the dependency, and who gets asked, a year later, why the company is having this conversation with a lawyer.

The three things worth carrying out of here: open source is not free of terms, the terms change on upgrade and not before, and where the boundary falls between your code and theirs is the question that determines what you owe. Everything else you can look up.

Next: Practice: GitHub, where you run the loop once on your own. If you have not read Git and GitHub yet, read that first; it covers the
difference between the two and how a change actually gets into a codebase.