Software Development: Who Owns What?

Who owns what when a client hires a software developer?

To avoid costly and disruptive disputes over intellectual property (IP) ownership, the parties’ respective rights should be clearly spelled out in a software development services agreement.

Computer software is a work of authorship that can be protected by copyright law.

US copyright law gives copyright owners six exclusive rights:

• The right to reproduce and make copies of an original work;
• The right to prepare derivative works based on the original work;
• The right to distribute copies to the public by sale or another form of transfer, such as rental or lending;
• The right to publicly perform the work;
• The right to publicly display the work, and
• The right to perform sound recordings publicly through digital audio transmission.

The owner is usually the person who created a work of authorship – in this case, the software developer. However, those rights can be assigned or licensed to others as part of a software development agreement.

The rights can be licensed or assigned either singly or as a group. For example, a copyright owner might license the right to perform a work but retain the right to create derivative works.

When an IP right is assigned, then the original author is giving up all of his or her IP original rights. It’s like selling a car.

When an IP right is licensed, then the original author is just letting one or more others use the IP rights. It’s like renting a car.

Copyright exists “automatically” when a work is fixed in a tangible medium of expression – for example, saved in the cloud or on a computer hard drive.

Copyrighted works can also be registered with the US Copyright Office, which adds important additional protections.

Some software can also be patented. For example, a software patent can cover a stand-alone computer software program, a mobile app, or software that’s integrated into a device.

Typically, when a client pays a developer to create “new” software, the client wants to own 100% of that software. However, that’s often not practical or cost-effective.

“New” software is generally not entirely “new.” It’s created from pre-existing building blocks, including software that may be open source or even of unknown origin.

As Opensource.com explains,

Open source software is software with source code that anyone can inspect, modify, and enhance.

"Source code" is the part of software that most computer users don't ever see; it's the code computer programmers can manipulate to change how a piece of software—a "program" or "application"—works. Programmers who have access to a computer program's source code can improve that program by adding features to it or fixing parts that don't always work correctly.

Source code that isn’t open source is called “proprietary” or “closed source.”

Using pre-existing routines (including open-source code) can benefit the client, since it’s much faster and cheaper to re-use existing code rather than create new code from scratch.

It’s not reasonable or common for a client to insist on owned pre-existing code that’s incorporated into a software deliverable. For one thing, the developer may not own the rights (as with open-source code) and may not be able to grant that ownership. For another thing, it may not make sense for a developer to sell its basic code tools and components.

Instead, a client could expect to get a license to such pre-existing code.

For example, a software development agreement might define Pre-Existing Software as follows:

Pre-existing Software. All computer programs which were developed and owned by Contractor prior to the Agreement Effective Date or outside the scope of this Agreement, and any modifications thereof and derivative works based therein, and which were not designed, developed or installed with Client participation, including but not limited to commercially available Contractor software listed in Exhibit B and proprietary software which is not generally made available as a commercial product by Contractor; and the documentation used to describe, maintain and use such Pre-existing Software.

If Pre-Existing Software is to be incorporated into the software deliverables, a software development agreement would normally include a clause giving the client a license to that Pre-Existing Software to the extent needed to exercise the client’s rights in the deliverables.

Another category of software is the code that’s to be created anew for the client. The client may very well expect to own that so that no one else can use it.

However, this can still be a point of negotiation. The developer may want to have the right to use this new code for other clients. This may or may not be an issue for the original client.

Clearly, a client wouldn’t want to have code that it paid for be used by the client’s competitors. However, the client may have no objection if the code is being used for non-competitive purposes.

The developer may be willing to charge the client less for development if the developer knows that it can re-sell the same code to others. It becomes part of the developer’s collection of building blocks that can be reused and further evolved.

Thus, giving up ownership, and just taking a license (or owning the new software but licensing it back to the developer to be used for others) may have financial advantages for the client.

Yet another software development model involves “software as a service” (SaaS). With a SaaS agreement, the rights in the software are neither licensed nor assigned. The software lives on the developer’s server, and the client is given access to it.

The client doesn’t own the SaaS platform – the SaaS provider does. However, SaaS agreements often say that the client owns the client data on the SaaS platform.

Commonly, many clients – perhaps millions – use the same SaaS platform. For example, Dropbox, ZenDesk, and Salesforce are examples of SaaS platforms.

A client can pay a developer to customize a SaaS platform to suit the client’s needs. This is often done via something called a white-label platform agreement.

The client’s white-labeled platform may have only minor changes, such as including the client’s name, color scheme, and logo. Or a white-labeled platform may have different features than the original version.

In short, when it comes to software development agreements there’s no “one size fits all.”