Important IP and source code tips for developers and clients
One of the most important yet frequently overlooked aspects of software development and consulting is the issue of intellectual property (IP) and software ownership. It can be easy to make assumptions about source code ownership when working with a developer, but both the developer and the client need to be informed and up to date about any and all contracts, copyrights, or licenses associated with a software project.
You don’t need a law degree to understand the basic elements of software licensing and IP, but with the multitude of different licenses and contracts in use, it can get confusing. Pitfalls are everywhere, and ownership disputes can signal doom for a project or startup. Here are a few key things to consider for both developers and clients.
As a software developer, it’s important to receive credit and compensation for any work you’ve done, but it’s also important to know when a transfer of rights occurs. When building unique code on your own, anything you create is considered copyrighted by U.S. law. But modern developers rarely build software from scratch. Open source libraries and APIs are an increasingly common starting point for software projects, and there are specific licenses associated with different open source languages.
Refer to choosealicense.com for details and information about the different licenses that may apply when building with open source code. Some licenses allow for complete reuse, distribution, and sale of products built on open source projects, but other licenses are more restrictive. Make sure to acknowledge the license you are building with before getting to work.
There are also circumstances in which code that you write is automatically owned by someone else. This is called “work made for hire,” and includes any code written as an employee of a larger company, or under a contract with a client. When developing as part of a contract, make sure to iron out details like source code ownership, residual use of source code, or sale and reuse.
TL;DR: Know when what you code is your own, know when to give up the rights, and always know what license you’re working with.
Cuttlesoft takes intellectual property seriously. To learn how we manage ownership in our projects, talk to one of our experts today.
When entering business with a software development firm or an individual, there are certain things to be aware of and certain things to look out for. Don’t make any assumptions about source code ownership or transfer of rights. Make sure to thoroughly read any contracts before signing to make sure you retain full ownership of all the source code you are paying for.
Be wary of developers seeking joint ownership of source code. It may seem like an easy way to solve the issue, but it can lead to bigger problems down the road. When working with a developer, you are hiring them to provide a service, rather than a product. The service they provide should not entitle them to ownership of the resulting software. When hiring a contractor to construct a building, you wouldn’t expect them to ask for partial ownership, so why should a coder expect to own a piece of the source code?
Once a client pays their weekly dues (or whatever period the contract states) they should have full ownership of all source code involved. This ensures that they are free to use, reuse, alter, and sell the code. They should even be able to pick up with another developer and provide them all the information they need to continue where the previous one left off.
TL;DR: Read your entire contract before signing, and make sure you own the entire source code you are paying for.
When it comes to source code ownership, don’t make assumptions and don’t wait until a project is over to find out that your developer owns half of your code. Make concrete decisions about IP, rights of use, licenses, and transfer of rights in the case of sale or bankruptcy before entering a contractual obligation. A trustworthy developer will ensure that the client owns the entire source code for a program, and won’t jeopardize the success of a project by squabbling over ownership.