Your company is probably in the business of software. Maybe you offer software as a service (SaaS) or have a smartphone app. Maybe your equipment (industrial automation, robotics, etc.) needs software to run. Regardless of the situation, many companies find that their business involves software solutions at some level. Maybe you created those in-house, or maybe you used a third-party provider to create them for you.
Regardless, you want to own your software and you don’t want anyone else to copy all your hard work. At the very least, you’d probably be unhappy if you found out your competitor was somehow using the proprietary control software built by your team. Or if you discovered another company re-skinned your iPhone app and was selling it under their brand name. What the heck!?
So, how do you prevent that sort of thing? How do you ensure you have your software locked down?
- You aren’t planning to “open-source” your software. NOTE: I love open source software. This article is not an argument against open source. It’s a discussion of how to handle things and actively manage the situation if you’re going a different route.
- You aren’t using someone else’s open source software. Do not do this if you want to protect your own creation. On the other hand, if you’re not worried about that, open source software can be an amazingly useful tool.
- Your software is economically valuable in some way.
How Do I Protect My Software?
In the United States, software is protectable under several aspects of the law, some of which can be implemented simultaneously.
1. Patent Law.
Software is still patentable in the US. That means you have an opportunity to protect the functionality of your software program, to the extent it’s new, not obvious, and meets the criteria for patentable subject matter.
You may have heard that it’s become more difficult recently (in the United States) to protect software under Patent Law. This is true. Ever since the Supreme Court’s Alice decision in 2014, the USPTO has been much more strict about what constitutes patentable subject matter, and courts have shot down many existing software patents. The basic concept is that (1) you’re not allowed to patent an “abstract idea,” and (2) adding a standard computer to the invention doesn’t make an abstract idea less abstract. Unfortunately, even after four years there isn’t a lot of consensus on what the word “abstract” means in this context.
However, here’s the easiest way to think about it:
a. If your software provides a technical solution to a technical problem (e.g., as opposed to a business problem), it’s more likely to be allowed.
b. If your software simply automates something that was already being done, it’s highly unlikely you will get a patent.
That leaves a lot of room for interpretation. The best thing you can do is talk it over with your patent attorney.
When obtained, patents can provide robust protection of your software’s inventive features. This is because patents can prohibit others from implementing the same functionality, even if they recreate the software using a different coding language.
Additionally, design patents may be available in certain situations, for example to cover visual aspects of your user interface.
2. Copyright Law.
Software is also considered a literary work, when it comes to Copyright Law. That means the expression of your software program is protected. Others are automatically prohibited from copying or distributing copies of your code without your permission. Even though copyright protection kicks in automatically, it’s almost always a good idea to register your software with the Copyright Office. Registration is mandatory if you wish to file a copyright infringement lawsuit, and the damages you can obtain are significantly higher if you register before the infringement starts. For various reasons, a good rule of thumb is to be sure to register less than 90 days after you publish your software. As always, there are many things to consider, and you should talk to your attorney about the best timing.
Copyright covers the way you coded the software – basically the source code. That means software protection is less robust than patent protection, because it essentially covers people who directly copy your software. However, it can be a powerful tool against piracy and unauthorized use.
3. Trade Secret.
Any proprietary formulas or algorithms that you incorporate into your software may be protectable as trade secrets, assuming you can actually keep those things secret. If someone can tell how you did it by simply operating the software, or if they can reverse engineer it somehow, that means it’s NOT a secret. If you share the source code, that means it’s NOT a secret. If you blog about how your formulas and algorithms work, that means they are NOT a secret. However, if you take measures to keep everything under wraps, and no one can reverse engineer it, then you can maintain the proprietary portions of your code as trade secrets. Which means you have the full backing of state and federal trade secret laws.
One benefit of trade secret protection is that it lasts as long as the secret does, which means potentially forever.
4. Combinations of These Protections.
You can have a patent and a copyright on the same software program. This is often the best way to go.
You can have a copyright on software that contains trade secrets. You’re able to redact portions of the source code when you register with the Copyright Office.
You cannot have a patent on any feature that you want to keep as a trade secret. By definition, patents require disclosure of how the functionality is attained.
How Do I Make Sure My Company Actually Owns the Rights?
This is much trickier than it sounds. Recall that the default rules are that (1) patents belong to the inventor, and (2) copyrights belong to the author/creator. You MUST do something if you want to change that default rule. Here are some things to consider:
- Make sure you have a rock solid confidential information and invention assignment agreement in place for all employees.
- Make sure any nondisclosure agreements you enter into with outside parties cover the ownership of intellectual property.
- Do not assume that outside coders owe you the code they’re writing just because you paid for it. You should have a clause in the software development agreement that assigns the copyright to your company.
- When it comes to outside developers, software generally does not qualify as a “work made for hire,” even if you say it is.
- Do not assume your software development agreement is okay if it says the developer “will assign” all copyright rights to you. That is a promise to do something in the future. If the developer forgets or refuses to assign the copyright to you, all you have is a broken promise and a cause for breach of contract. You do NOT have ownership of the code. Consider instead saying something like “the developer hereby assigns” all rights to the company.
- Never assume it’s safe to use open source software in your proprietary software product. Open source code frequently comes with a strict license, and that license can prohibit patenting or require that the resulting product also be open-sourced. Don’t end up there accidentally.
Your software is protectable in many ways, as long as you are proactive and watch out for the potential pitfalls. I like to think of it as an exercise in controlling your own destiny. You can ignore all of the items above, or you can take an active role in deciding how people use your product. There are situations where open source or free distribution is the best choice. I think it’s better if you make that choice intentionally.
Blog Post © 2018 Kolitch Romano LLP
Photo © 2013 Dave Bourgeau (Portland, Oregon)
If your company’s intellectual property protection isn’t where you want it to be, book a time to talk to one of our IP attorneys. We’d love to learn about your business, explain your strategic options, and work with you to secure your vital IP assets.
Click the link below and get in touch. We look forward to speaking with you!
DISCLAIMER: This article is intended to give the reader an overview of the topic, and does not constitute legal advice as to any particular fact situation. Facts matter, and every situation is different. In addition, laws and their interpretations change over time and the contents of this article may not reflect these changes. You are strongly advised to consult competent legal counsel regarding your particular situation.