Developer

How copyright and licensing issues affect programming work


What ever happened to the Perl vs. C# text processing shootout I promised? Well, I will tell you what happened.

Something had been bothering me for ages, but I could not put my finger on it. As I sat down to write the code, I finally remembered what it was: I am not allowed to publish benchmarks of .Net without Microsoft's expressly written permission. This is part of the Microsoft .Net Framework EULA, and it also applies to many of its other products, such as SQL Server 2005. Therefore, instead of writing about Perl vs. .Net, I will be discussing how licensing terms can affect the work of a programmer. Please note: I AM NOT A LAWYER.

In the late 90s, I worked for a small startup. One of my tasks was to research patents and copyrights. The company had a clever system (for the time) on its Web site that it wanted to protect. The Amazon "One Click Shopping" patent had already been used against Barnes & Noble, and my boss wanted to be able to do the same to our competitors if they put a similar feature on their sites. So I became fairly familiar with patent and  copyright laws. I was able to determine that we could probably not get a patent on what we were doing (it was pretty obvious how to do it), but we were implicitly and automatically granted copyright over the code and could argue in court if need be that a competitor's code was based on ours without proper payment.

The lesson I learned from this was fairly striking: Copyright is powerful. Most folks do not realize how strong it is and that you don't actually have to do anything to copyright your work. If I make a doodle on a dinner napkin, I automatically have a copyright on it, which can be enforced. Of course, proof of authorship is always helpful and publicly marking something as being copyrighted makes it clear to all those who view the work that there is a copyright on it. However, the lack of copyright markings does not grant free usage.

How does this work in the world of programming?

For starters, programmers are notorious for going to a search engine when they get stuck on a problem and then copying and pasting code into their code without the necessary modifications. Unfortunately, this is most likely illegal unless the poster of the original code expressly granted usage rights to you. In other words, by hitting the search engine and grabbing some code, you are opening your employer up to a potential lawsuit. Granted, the chances of this being noticed are probably billions to one; but if you aren't granted express usage rights, you are probably in violation of the law.

There are even more problems with doing a copy/paste of code. What happens when you copy/paste a piece of open source into your project? Well, it depends on the type of open source license it has. If it is the BSD license, you are in great shape because the BSD license is forgiving. However, the GPL is a completely different story. You have to be careful when copying/pasting, linking to (in the compilation sense and not in the URL meaning), or otherwise making use of GPL-ed code. The GPL has a sneaky way of injecting itself into projects in a way that can potentially force large amounts of a project (if not the entire thing) to be subject to it.

Microsoft is a huge contributor to the license and copyright headaches. For one thing, Microsoft is one of the largest obtainers of patents in the world, in no small part to the massive amounts of R&D it does. If you are working on a project, there is a darn good chance that Microsoft has a patent on something identical or similar, particularly in some oddball parts of computing. And Microsoft has never been afraid to flex its legal muscles (in other words, when buying out the offender would be more expensive than suing them). Microsoft also has a bad habit of slipping unusual license terms (like the no benchmark clause) in places that you would not expect. Before embarking on a project that makes use of Microsoft technologies, I recommend that you carefully inspect all relevant licenses; if you are unsure about what they mean, consult a lawyer.

Even clip art can turn around to bite you. One of my favorite Web sites, iStockphoto, has reasonable licensing terms for its images. Royalty free may be used on Web sites and marketing collateral, etc., but it's a problem if you want to: use one of the site's images in a template library that you redistribute or use an iStockphoto image at a resolution above 800x600. And so on. You have to be very careful with these types of agreements. For instance, say that your Web developer uses one of these images for your company's Web site, which is a permitted use. Then you decide that you like the photo so much, you will use it in the splash screen for your application. There could be liability if there wasn't clear communication between the person who read and signed the license and the developer using the image.

It is extremely unlikely that your project's miscellaneous and/or accidental violations of copyright and license terms will ever be noticed, unless it receives large enough mainstream usage. In addition, violations within closed source, proprietary code are difficult to find. Nevertheless, there are plenty of lawsuits in the history of IT to show that it is quite possible to have the pants sued off you too.

My general rules of thumb about copyright and licensing

I only use content in a project that I have created or that I know another employee within our company has created. I do not copy and paste code from the Web, and I do not use GPL-ed code within a project unless the project is to be released as GPL-ed code. I carefully check any content, code, images, etc. for copyright and license terms before using them; if I'm confused, I kick it over to a lawyer. If I do not see any explicit rights granted to me, I assume none. I think this is a fairly reasonable and sensible approach.

Basically, think twice before copying and pasting code you dig up on the Web into your project.

J.Ja

About

Justin James is the Lead Architect for Conigent.

Editor's Picks