Intellectual property issues in software development

The classic example of a trade secret is the formula to Coca-Cola. Many features of software, such as code and the ideas and concepts reflected in it, can be protected as trade secrets. This protection lasts as long as the protected element retains its trade secret status. Unlike patents, trade secret protection will not extend to elements of software that are readily ascertainable by lawful means, such as reverse engineering or independent development.

Their legal status as a protectable intellectual property right will be upheld if the owner can prove the trade secret was not generally known and reasonable steps were taken to preserve its secrecy. Maximizing the economic value of a software asset critically depends on understanding the nature of the intellectual property rights involved and how best to use the available forms of legal protection to protect those rights. Attorney Eric Freibrun specializes in Computer law and Intellectual Property protection, providing legal services to information technology vendors and users.

Patents A patent is a twenty year exclusive monopoly on the right to make, use and sell a qualifying invention. Copyrights While a patent can protect the novel ideas embodied in a software program, a copyright cannot. Trade Secrets A trade secret is any formula, pattern, compound, device, process, tool, or mechanism that is not generally known or discoverable by others, is maintained in secrecy by its owner, and gives its owner a competitive advantage because it is kept secret.

Get a present license to escrowed source code: Bankruptcy can trigger the release of escrowed source code to a licensee. However, bankruptcy courts may characterize a license contingent on a licensor's bankruptcy as an unenforceable transfer of assets from the bankruptcy estate. Drafting the source code license as a present grant of rights i. The developer-licensor may object that it is not allowing your company to presently use the software, but of course the licensee receives no benefit from the license until the escrow agent releases the code.

Bankruptcy complications can be avoided altogether by expanding the scope of escrow release events to include "pre-bankruptcy" warning signs of financial distress, such as licensor's failure to timely pay bills, or concerns expressed by independent financial auditors. Further, a prudent licensee will consider making bankruptcy and other release events an exception to any restriction on hiring the licensor's programmers.

If a release event occurs, your company may find it difficult to use the source code without assistance from the programmers who know it best. Use the present tense in any assignment of rights: Language intended to assign IP rights to your company should reflect a present transfer "hereby assigns" , not a future promise to transfer "will assign" or "agrees to assign".

Under the latter formulation, the developer's failure to deliver the promised assignment may result in a breach of contract claim, but not necessarily ownership of the IP particularly if the developer already assigned the rights to someone else. However, under U. This problem can be avoided by including a present assignment of IP rights to your company together with the "work made for hire" language although under California law including a work-for-hire clause may evidence an employment relationship with the developer and potentially expose your company to employee benefits or workers' compensation claims.

Account for pre-existing rights: If the developer includes any of its pre-existing code or third-party code in developed software intended to be owned by your company, or if a license to other IP rights is necessary to use the software, to avoid IP infringement claims you should ensure the developer identifies those pre-existing rights and grants a perpetual, irrevocable license. In particular, the developer should identify any open source software OSS incorporated in the developed software so your company can take precautions to avoid using it in a manner that triggers the "viral" provisions of the applicable OSS license e.

Software developers often indemnify their customers for third-party IP infringement claims, but the exceptions to this obligation warrant careful consideration. In general, a reasonable middle ground is to allocate infringement risk to the party that bears the greatest responsibility for the allegedly infringing conduct. For example, your developer may seek to avoid responsibility for software designed to your company's specifications, but consider narrowing this to instances where non-infringing compliance with your company's requirements is not possible.

Similarly, developers may seek to exclude infringement claims relating to combinations of their software with your company's or third-party services or materials, or that relate to post-delivery modifications. However, such carve-outs may be inappropriate when the software would have infringed third-party IP rights notwithstanding the combination or modification. The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

All Rights Reserved. Password Passwords are Case Sensitive. Forgot your password? Free, unlimited access to more than half a million articles one-article limit removed from the diverse perspectives of 5, leading law, accountancy and advisory firms. We need this to enable us to match you with other users from the same organisation. It is also part of the information that we share to our content providers "Contributors" who contribute Content for free for your use.

Learn More Accept. You have already decided how you will protect your product once it is ready. But have you ever thought of the challenges you might face during software development process? If you came up with a decision not to develop the whole project from scratch, but to purchase the source code of an already existing app and reskin it the way that it will constitute a new unique project, it is important to know how to avoid possible legal troubles.

Keeping these things in mind, you might prefer creating the project from the ground up to reskinning the existing code. Read more about the pros and cons of both options here and here.

Most of the software projects require not only clean programming code creation, but also beautiful design. In case the designer is going to purchase images, ask him to show you payment documents. If the designer uses free images, you should make sure their usage does not violate ownership rights.

Make sure that while making mockups Provider will not use similar existing interfaces as a basis as well. You will need to check the Terms of Use of the third-party resources and make sure that you can use their materials, and on which conditions.

Most of resources will require giving credit to them. Together with that, you should consider whether the software will be competitively sensitive. If you feel that your Provider can potentially develop something similar for others in future, you might want to obtain IP ownership. To ensure that everything goes smoothly, be sure to check that all these points are stated in your software development agreement.

Guidelines about software patents came from their decision. That's why not all software qualifies for a patent.

The most important include:. You can't patent an algorithm on its own because that's an abstract idea. But if the algorithm has a specific purpose and application in the software, then the software may qualify for a patent.

If your software solves a specific technology problem in a way you can discuss in detail, then you could qualify for a patent. An abstract idea like math or an algorithm that creates a specific or tangible result can qualify for a patent.

Abstract ideas are where most software patent applications run into trouble. Proving that software is not an abstract idea, but qualifies as an invention, is difficult. That's why so much recent legislation has focused on the subject. CLS Bank "Alice" case, which covered software patents and abstract ideas. The ruling was that the software in question was an abstract idea and therefore did not qualify for a patent.

The Alice ruling has made getting software patents more complicated and has invalidated some software patents already granted. Traditional software development involves a series of five steps. A developer completes the first step before moving to the second step or before handing the software off to another developer. The people working on each step don't usually communicate. Clients and customers don't see the software until the developers are finished.

Agile software development doesn't follow a sequence like traditional software development. Instead, developers work together on different parts of the project, communicate as the software evolves, and solve problems as they appear. The developers do this in bursts of work called "sprints. In a traditional software development environment, IP is easier to figure out.

Defining who worked on which piece of code — and therefore owns it as IP — is relatively straight-forward.

Agile development happens more quickly than traditional software development. The fast pace, combined with the teams of people working very quickly, makes it difficult to figure out where IP belongs. Plus, the pieces of software that professionals develop during agile development might only be parts of code and might not function on their own without the rest of the software.

Identifying IP software is important to copyright, trade secret, patent, and trademark. The question of legal ownership gets more complicated when IP gets lost because of development methods. An agile development cycle still produces IP that you or your company can protect.

However, people using agile development have to adjust the techniques they use for finding and detailing IP. In agile development, the client or customer gives feedback on the unfinished software. Protecting IP while showing it to a client is difficult. Before you start agile development for a client, include a nondisclosure agreement or a product advisor agreement. A "feedback clause" within these agreements says that any ideas or feedback that the client produces is free for the developer to use, keeping the client from being able to claim part of the code as their IP.

Some companies start filing provisional patent applications during agile development. A provisional patent application gives you a filing date for your patent, but it isn't your full application. It gives you a year to create the non-provisional application, which is your published patent application and can lead to your approved patent.