This post addresses the most important issues that are raised in negotiating software licenses.
I will assume that parties have agreed on pricing. (Otherwise, there is no point negotiating license terms!) In addition, I will ignore the lengthy legal “boilerplate” that appears in most software license agreements.
Four Critical Issues in Negotiating Software Licenses
In my experience, there are four issues that must be examined closely, and often result in much discussion, when negotiating software licenses. (more…)
Software developers may have decided to provide open source software, but they may not know which open source license to use. This post describes three resources developers can consult to help make that decision.
First, Open Source Initiative maintains a comprehensive list of open source software licenses. Licenses are grouped into categories, starting with the most popular licenses. However, the OSI site does not provide any tools to help decide which open source license to use.
We all have seen a typical copyright notice (e.g., “Copyright 2013 Anyhow, Inc.”) countless times. However, every once in a while, someone will see a copyright notice with multiple years (e.g., “2010-2013”) and will wonder whether it is legitimate.
- The symbol © (the letter C in a circle), the word “Copyright”, or the abbreviation “Copr.”
- The year of first publication.
- The name of the copyright owner.
I have written, on several occasions, about the importance of assigning copyrights (and other intellectual property rights) when work is done by an independent contractor. (See, e.g., Independent Contractors: How to Assign Copyrights.) Sometimes, however – as suggested in a comment to What is a Derivative Work, and Why should I Care? – it is appropriate not to assign all rights.
Many startups have software developed offshore to save money. There is good reason to be concerned, however, about loss of money or, even worse, loss of intellectual property when a developer is located half-way around the world. This post discusses ways to minimize those concerns.
I recommend the following:
- Ensure that the agreement with your overseas developer assigns all rights to the software (including all intellectual property rights) to you.
- Don’t send your “family jewels” offshore. For any portion of the development that requires disclosure of your most important trade secrets, use a local developer.
- Time deliverables and payments such that you never will be too severely financially exposed. If your relationship with the developer sours, you can go somewhere else without a catastrophic financial loss.
If you take care of these three points properly, everything else should be pretty routine.
Dana H. Shultz, Attorney at Law +1 510 547-0545 dana [at] danashultz [dot] com
This blog does not provide legal advice and does not create an attorney-client relationship. If you need legal advice, please contact a lawyer directly.
This post is adapted (with editing) from a Quora question that I answered. Q. I developed a software application on my own, then adapted it for my new employer, where it is used enterprise-wide.? What are my ownership rights in this situation?
A. It would help to know whether you signed any type of proprietary information and inventions agreement with your employer. If you did, its terms (obviously) will be of great importance. You did not mention any such agreement, so I will assume, for the purposes of the discussion below, that there is no such agreement.
Many software companies rely on a combination of copyright and trade secret protection for their products. There is a potential problem, however: The requirement to submit source code with a copyright registration is somewhat at odds with the confidentiality requirements of a trade secret.
Fortunately, the U.S Copyright Office offers some flexibility in its deposit requirements for software containing trade secrets. The applicant may deposit any of the following: (more…)
Developers of proprietary software typically rely copyright and trade secret protection of their works. A recent California case (Silvaco Data Systems v. Intel Corporation) illustrates how far trade secret protection does, and does not, go.
Silvaco develops and markets electronic circuit design software. Silvaco won a suit against Circuit Semantics, Inc., claiming that CSI, with the help of two former Silvaco employees, misappropriated Silvaco trade secrets, in the form of source code, by incorporating them into CSI’s software. Silvaco obtained an injunction against continued use of the technology incorporating its trade secrets.
I recently met a software developer who wants to start a business. He immediately started talking to me about obtaining a patent. Condensed a bit, our conversation went roughly as follows:
- Dana: Without giving away information that would jeopardize your ability to obtain a patent, what would the software do?
- Developer: It is enterprise customer relationship management (CRM) software.
- Dana: What is novel and non-obvious about it?
- Developer: It will be based on a unique algorithm.
- Dana: You cannot patent an algorithm.
- Developer: I can get a patent on software that implements an algorithm.
- Dana: Perhaps. But there are other means, such as trade secrets, that might adequately protect the software [cut off in mid-sentence]….
- Developer: VCs want to invest in companies that have patents.
Leaving aside the singular focus on VC funding – something that few entrepreneurs obtain (see Realistic Financing Options for Startup Companies) – the would-be entrepreneur was similarly myopic in focusing on a patent as the only type of intellectual property that matters.
Update: On September 10, 2010, the Court of Appeals for the Ninth Circuit (in Vernor v. Autodesk) reversed the District Count decision discussed below. Supporting software licensors’ reasonable business expectations, the Court held “that a software user is a licensee rather than an owner of a copy where the copyright owner (1) specifies that the user is granted a license; (2) significantly restricts the user’s ability to transfer the software; and (3) imposes notable use restrictions.” [Emphasis added.] Accordingly, Vernor, as a licensee, was not protected by the first sale doctrine when he sold copies of Autodesk’s software.
* * *
In Vernor v. Autodesk, the U.S. District Court for the Western District of Washington told Autodesk that despite the restrictions in its license agreement, Autodesk could not preclude its customer from selling AutoCAD software to a third party.