• Post Calendar

    November 2014
    S M T W T F S
    « May   Dec »
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    30  

IP Integrity

Headline: Be sure not to take things that don’t belong to you. Do NOT include code in your software that you don’t have the rights to include.

Motivation

I’ve had to write policies and other documents through the years about proper treatment of Intellectual Property (IP). I’m tried of having to repeat the information of this post again, and again. So I thought I’d post it here. I hope that others find this information useful too. For some reason, many developers hold the belief that “if I can copy it, this I can use it.” That just isn’t right.

Also, I would like to make sure that all those I work with over time don’t jeopardize my integrity by including code in a code base we’re working on together that doesn’t belong to us. Life is too short for legal battles.

Not About Patent Law

I will not talk about patented material at any length here. The patent process was written at a time that most inventors spent time alone in laboratories. In today’s connected world where ideas can spread to millions in an instant, there seem to be some issues. That topic is far too complex to cover here and many people cover it.

It Is About Integrity

For years I’ve used several expressions on this topic.

Personally, if you have your health you have everything. Professionally, if you have your integrity, you have everything.

In matters of law you are innocent until proven guilty in a court of law. In matters of integrity you are guilty until proven innocent in the rumor mill.

So this post is about maintaining your integrity in the software development world. This applies both to individuals and organization.

Do NOT Possess Code You Don’t Have Rights To

This is the simplest rule and if followed, everything else mentioned is this post will follow naturally. What do I mean?

  • When you leave one employer and go to another don’t have any of their code remaining on your machines. (More later in scenarios)
  • Don’t download or copy any code or software that you don’t have rights too.
  • Do credit your sources (if any) and state what the licensing was at the time of your writing. Also include the licensing file if there is one.

Scenarios – Code From Your Old Company

So let’s take a minute to looks at some scenarios.

Millionaire?

Let’s say that you leave one company to join another and take along some of their secret code. And that you implement it in a new product at your new company.

What are the odds you’ll become a millionaire?

What are the odds that that code will make the company millions?

AND

The new company will recognize your for your contribution (in stealing that code)?

AND

The new company will reward you handsomely – i.e., millions of dollars – for that contribution?

AND

The old company won’t find out and file a law suit?

That’s a lot of ANDs and we all know that if you and an AND that the odds go down, not up.

So, if you run some simple risk reward analysis on what might happen with code you carry from one employer to the next you’ll find it’s a bad idea to do that.

I’ve actually faced some challenges in the past as I went out of my way to think, “How can I write some new code that does something similar to a need I had at a previous company so that it doesn’t look like I copied it?” Sometimes that’s really hard. If I am faced with the same problem and I had great clarity, I’ll tend to re-write the same code even though I don’t have access.

In Trouble?

I’ve known several people – all cleared – that were accused of taking code from a previous employer.

What does that look like?

Police might show up at your door and take every piece of computer equipment – every computer, drive, monitor, thumb drive, anything that can store anything. Then you might have to sit on the sidelines not allowed to write any software for many, many months.

Or you might be slapped with a law suit and have to spend much of your own hard earned money to defend yourself.

I could go on, but you get the idea. This is the negative side even appearing to have code you don’t have rights too. This can help you think more clearly about that risk/reward analysis. This too is where one of the quotes comes in. In these cases there was no wrong doing, just the appearance due to such similar functionality. So you might think about this before you do something “too similar” to what you’ve done in the past.

Code From the Internet

So we looked at code you might have access to at your previous employer and bringing that into a new employer (or even out of your old employer for that matter). Now let’s look at copying code from the internet.

There are many ways you can copy code from the internet. But, if you don’t have the rights to use it, you should never include it in your source code or source code you help maintain for your employer.

Let’s look at several scenarios here.

Copy Code Snippet

Say you copy a code snippet that is something non-trivial from stackoverflow. By non-trivial, I mean something that you can’t find anywhere else. So if someone asks “How do I use LINQ to get the first item from a query?” and someone responds, “Use .First() if you want the first one or for an exception to be thrown if there isn’t one or .FirstOrDefault() if you want null in the event there isn’t a first one.” That’s hardly unique. But if there was some algorithm you’ve been looking for and couldn’t find anywhere else, attribute it.

You’ll find lots of links in my code bases.

Licensed Libraries

Now here you might find a full set of code on CodePlex, GitHub, or some other site. Be sure to include the licensing information for that code. In this case it’s probably not mixed in with your code, but off in a Third Party folder as “Code I Use From Others”. Make sure the license is there and that you have rights to use it.

Help Police

It would be nice if everyone knew about these simple standards, believed in them, and abided by them.  But, not all do for various reasons. I’ll cover that in the “Advent of Copying” section below. That is when things really changed.

But since not all do understand this, I feel it’s up to every member of a team working on a code base to help keep an eye out for code that isn’t rightfully part of the code base. Most organizations including all the ones I’ve worked for have some sort of process, even if it is as simple as “Team Leads look at all check ins in their code base to make sure none violate IP rights.” But help your team out. Don’t rely solely on the process. There is a lot of code written each day. Help your team by making sure they stay out of legal trouble.

Advent of Copying

So why are our standards so relaxed? As more items became digital, copying got much easier. I recall when I was very young and people would copy a great album to give to a friend. That didn’t happen with records. But once other recording mediums came along like tape, CDs, and .mp3 files, that all changed. And I also recall how freely people would copy program files around in the early 80’s when the PC first came out. People didn’t really think about it as intellectual property. The music industry has spent a fortune to prevent copying of music and DVDs.

And other cultures have a different view on IP and don’t share the same patent process that the United States has.

But, if you write code for any United States company then you really should follow these rules. I believe they are fair. I make my living creating digital intellectual property. I would be very upset if I couldn’t feed my family because everyone decided to copy it rather than pay a fair price.

Summary

Help your team…

And, maintain your professional integrity.

Leave a Comment