Learn about intellectual property and how it relates to day-to-day software development.

Disclaimer

This is the "I am not a lawyer" disclaimer. If you're the type of person who finds a relatively obscure personal blog online with musings from an engineer about intellectual property and decides to take it as concrete legal advice you should most definitely stop reading...you should also carefully rethink your strategy there cause it's a good way to get in trouble.

What I can say is I've spoken to a quite a few people who are lawyers about intellectual property and software development. My opinions about that have been formed from those conversations as well as my time contributing to open source.

Why does it matter?

Okay so there's the obvious answer to this question, you don't want to get sued. There's a different answer though, it matters because of basic ethics and morality. Stealing somebody's ideas or even their unique expression of something more commonplace is really just not something you should do! I recognize how easy it is to forget this when, as an engineer, you're just trying to make something work. However, it's important to take a step back every once in a while and think about more than solving a problem or making a feature function.

Licenses

Let's get the basics out of the way, when you use software somebody else wrote that software generally has a license of some kind. The license dictates how you are allowed to use their software and if you do not like the terms of the license your choice is to convince the authors the change it, grant you a different license, or not use the software. Here's the thing, the terms of the license generally apply when you distribute your software. This allows you to play with software locally or in a branch without worrying about a license, but still comply with its term when you share it with others. Consequently, however, this means you must be careful about understanding the terms of a license before you distribute your software. When I've spoken to developers about this I've sometimes heard them say, "But I don't know how to read these licenses." This argument is ludicrous to me, if you're capable of understanding code you're capable of reading a license and getting a general idea of what it's asking for. YES sometimes they contain difficult to parse legal language, but getting a general understanding of the requirements doesn't take a lot of know-how. For most common open source licenses there are plenty of resources to help you understand exactly what the requirements are. In fact, GitHub released a feature that broke them down pretty well! If you are engaging with a vendor or working for a company with a legal department it's as easy as asking the legal team your company pays.

I'll lastly point out that when you as a developer choose to include software, whether that's copied from a website, taken as source from a repository, or pulled in with a package manager, you are acting on behalf of your employer in regards to accepting the terms of that license. This responsibility shouldn't be lost on you as you evaluate that cool open source package that makes your life easier. It's your job as a developer not only to understand whether the technical trade-off is worthwhile but also if the license is acceptable.

Copyleft Licenses

So one potential "gotcha" when you're just trying to write code is copyleft licenses. There are multiple examples of this, the GPL is one that you're likely to run into on GitHub. I love the premise of copyleft licenses. What if we quit acting like software was some closely guarded secret and instead made it open? What if everybody could see exactly what code was executing on their hardware? This utpoic vision of open software is something I firmly believe in! Copyleft licenses (or "viral" licenses) try to force that vision into a reality. When you use a copyleft license you agree that any works you use it in will ALSO use that license. So if you pull in GPL licensed software then you agree that whatever you distribute will ALSO be GPL licensed. Most companies don't like this because then it forces them to open source their products, which they are generally loathed to do. Realistically, I wish companies were less stingy about this because oftentimes what people pay for are services, not apps. Having an open-source app wouldn't necessarily ruin somebody's business. However, most companies are totally unwilling to accept those terms because they want a closed-source system.

Attribution

Most licenses for things you'll run across online have an attribution requirement. Back to my disclaimer up top please, please, go talk to a real lawyer your company employs to understand what they believe satisfies the attribution requirement of licenses. HOWEVER in my experience and opinion you have not satisfied attribution requriements unless end users are able to see the attribution. So NO, it generally doesn't count if you just have a comment in your code that mentions the license or has the license text. Now you may try to get clever here and point out that code comments could potentially be seen by users with interpreted languages and a debug console as long as the code wasn't minified...that's true but it's also sort of a ridiculous argument. Look, for open source software especially somebody put their personal time and effort to give you something you can use that's useful, the least you could do is let your users know that they built a cool thing!

The Stack Overflow Problem

I get it, Stack Overflow is a great website! When you're just trying to solve a problem it routinely has an answer from somebody else who WANTS to help you solve your problem. However, even though this isn't code from a package manager it still has a license. What most people are unaware of is that stack overflow answers are licensed under a copyleft creative commons license. This is particularly alarming because the creative commons license stack overflow uses isn't code compatible. Even if you have open source software you're building that is GPL licensed, GPL isn't compatible with the creative commons license. The CC license is really more to protect literary works or media such as art. Code, because it is executable, has a different set of licenses that typically apply. To be abundantly clear if you just have a code comment that links to a stack overflow answer you have in no way satisfied the license or attribution requirements! All you've done is provided proof that you stole code and stuck it in your codebase.

Intellectual Property Policies

The other aspect to all this is what a company might impose on you. I was trapped by the same thing that so many others get trapped by. When I was a young, early-career software engineer getting my first job in the private sector and I had 1,000 documents to sign for my employment contract I just signed them all happily. I trusted the company to create fair policies and that generally worked out until I started wanting to contribute to open source. So almost every company has the same policy "we own anything you develop while you work for us that is related to our business or you created on hardware we provided you." This seems almost reasonable, certainly your employer should own the intellectual property that you create as part of your job, that's just fair. The ownership over things you wrote using their hardware may be a little overbroad in certain circumstances, but it's acceptable, if you want to develop something not work related you can just go do that on a personal device. Here's where it can all fall apart, what about intellectual property that's related to their business? Well, to some extent this makes sense. If you work for a financial company they teach you a lot about the finance world and they don't want you creating competing projects using industry knowledge they helped you gain. Where this becomes unfair to employees is if you independently acquired knowledge in finance and wanted to build something, now you can't without your company owning it. It's nearly impossible to codify and enforce those differences or prove them in the event of litigation or a lawsuit so generally you just have to accept this. Now, what happens if you work for a consulting company that works across a variety of industries? Or what happens if you work for a gigantic Apple/Google/Microsoft type company that does EVERYTHING? Well, it means exactly what you think it means, any software you write becomes the property of your employer. This is decidedly unfair and you should really spend a lot of time understanding your IP policy for your company. If you do not like the policy DO NOT SIGN IT! This could mean you don't take a job, or it could mean you get a change added to it.

Non-Compete Policies

You know both IP policies and non-compete policies can really kill innovation or the desire to innovate at a company. If your employer insist on hoarding intellectual property and doesn't allow you to work in the same field for multiple years after you leave this can really complicate your ability to innovate or even move on. Once more if you work for a gigantic company that does everything with a non-compete you may find you just have to be unemployed or go work in fast food for the entire non-compete duration if you ever leave. I wish companies spent a little more time thinking about how this impacted employees. There have been research studies that directly link these types of policies to a loss of innovation and employee satisfaction. Most employers don't really buy that, but employees who care about these policies are often employees who really want to innovate. For what it's worth this was one of the contributing factors to me leaving a 5 year employer with an overbroad policy and joining a company that worked in a space that wasn't of interest to me for personal projects.

Tyler Thompson

Tyler Thompson is a Principal Engineer with over 15 years experience. He currently works as a Principal Software Development Engineer for Zillow Group. Before working at Zillow he was a Principal Software Engineer for World Wide Technology and worked across many different industries.