13 posts categorized "Licensing"

Provisions restricting assignment can be tricky

It can be tough to get a firm grip on a contract's assignment provision.

This truth was brought home again by a decision last week from the Delaware Court of Chancery, the highest court in *the* state known to set the standards in corporate law.

The case is Meso Scale Diagnostics, LLC v. Roche Diagnostics GMBH, and DLA Piper's Trent Dykes has posted to the Venture Alley blog about it.

The assignment clause at center stage in the case reads in pertinent part as follows:

"Neither this Agreement nor any of the rights, interests or obligations under this Agreement shall be assigned, in whole or in part, by operation of law or otherwise by any of the parties without the prior written consent of the other parties . . . . Any purported assignment without such consent shall be void."

Sounds tight, no? You might expect that if the licensee sold its company to another party - and wanted to be paid in the transaction for the value of the license - the consent of the licensor would be required?

But contract law is not always intuitive and the structures of a transaction and the words written in contracts can make critical differences.

Trent links to a detailed summary of the case by his partner, John Reed, in which we find this helpful upshot:

"[T]he Court granted summary judgment that a reverse triangular merger was not an assignment by operation of law or otherwise, meaning that the acquisition of the company holding a license to valuable technology did not require the consent of the entity that granted the license."

I went to the underlying case asking myself the question, "so just what kind of assignments would require consent, under the assignment clause in the case?"

Bill of saleLet's take as a given that a purported sale, transfer or assignment of just the license itself - not as part of a merger or sale of a company - would trigger the consent requirement of the contractual assignment clause above. Let's also grant that a sale of the licensee's business, structured as an asset sale where the buyer was purchasing all or substantially all of the assets of the licensee, would trigger the consent requirement. Those kinds of transactions involve straight out assignments.

More interesting, and more problematic, is what kinds of structures are implicated when the concept of "assignment" is broadened to include the additional concept of an assignment "by operation of law." The Meso case is telling us that a reverse triangular merger is *not* an "assignment by operation of law."

Vice Chancellor Parson's opinion in the Meso case does get into a discussion of how to giving meaning to that phrase, "by operation of law." Generally speaking, an assignment "by operation of law" can be found or inferred when the party under the contractual restriction on assignment is not the surviving entity in a merger. The court stated that certain cases cited by the effective licensor "are distinguishable because they involved forward triangular mergers where the target company was not the surviving entity, whereas in this case [the effective licensee] was the surviving entity in a reverse triangular merger."

In short, the entire question of whether or not consent was required under the assignment provision may well have turned on the choice, in an M&A context, on what entity would be legally deemed to be the survivor.

Photo: Josh Bancroft/ Flickr.

What is licensing?

Bear with me, it may take a minute to set this up right.

Last week on IP Draughts, Mark Anderson asked the question, aren't licenses essentially covenants not to sue?

Rodin thinker close upHe approached his inquiry in a provocative way, the better to tease out how "license," as a term, might have denotations or connotations that could not be captured by the contractual promise, "I will not to sue you over your use of my software."

That's the perspective of the legal craftsperson, one who wants to find the tools to properly outfit a contract for the job at hand.

Leap over to Fred Wilson's blog this morning, where a discussion is ongoing in the comments over whether a subscription model is really just a form of license model, subscriptions being merely the business terms for hosted application licenses.

The consensus of Fred's community is that, for licensor and licensee alike, pay-as-you-go models are vastly superior to enterprise and other up-front license models; but a "subscription" remains a kind of license.

I buy it, though the contract drafter in me wonders if consistent use of the term "subscription" may end up making a legal difference. Just as "license" may resonate with more meaning than a covenant not to sue.

To the extent that "subscriptions" are eventually expressed more like "terms of service," or the rent of a seat to get from A to B (to use commercial airline travel as a metaphor), might there be fewer property-like rights entwined in a subscription relationship? Arguably, "license" carries connotations that go deeper than a contract right, almost as though a licensee has an IP interest (delimited by the scope of the license, to be sure) in the software itself, not simply the use of it. 

Photo of Rodin statue: Todd Martin / Flickr.

Unpacking the Significance of LinkedIn's Open Source Disclosure

Note from Bill: The following is a "re-posting" of a comment Jeremy left on this blog, and posted to his own blog, yesterday. Jeremy is writing about the following risk factor in a registration statement filed Thursday with the SEC in anticipation of LinkedIn's planned IPO:

"[W]e use open source software in our solutions and will use open source software in the future. From time to time, we may face claims against companies that incorporate open source software into their products, claiming ownership of, or demanding release of, the source code, the open source software and/or derivative works that were developed using such software, or otherwise seeking to enforce the terms of the applicable open source license. These claims could also result in litigation, require us to purchase a costly license or require us to devote additional research and development resources to change our solutions, any of which would have a negative effect on our business and operating results."

Let me see if I can do this succinctly (in-joke):

1. What’s the issue with open source?

Chances are that, even if you’re building a proprietary software application, it will include some open source. This will either be a deliberate decision to take advantage of pre-existing, tested, and free (or affordable) code, or a reality that comes from developers choosing to incorporate open source into a product despite corporate policy to the contrary, most likely for reasons of perceived efficiency.

Even then, whether the open source code may cause a problem for your proprietary model will depend on the license terms that apply to the code. While you should always be aware of the license terms that apply, most people confine their concerns to “copyleft” or “hereditary” license terms such as the GPL or L-GPL license terms.

At a very high level, the terms of copyleft or hereditary open source licenses may require you to disclose or distribute source code for other code you “combine” with the open source (including your proprietary code), or license code “combined” with the open source to the general public to enable them to modify it. In other words, you may be required to make public code you would prefer to keep secret.

If you don’t comply with the disclosure and modification licensing requirements of copyleft or hereditary open source license, then your use of the open source code will very possibly be treated as an infringement of the copyrights of the open source owner (or an organization to which they’ve transferred their enforcement rights) – which exposes you to damages claims (i.e., financial liability) and the possibility that you may be forced either to comply with the requirements (i.e., disclose and share your proprietary code), or to remove the open source from your product (i.e., re-engineer, and force your users to upgrade).

2. Why the reference to the miserable associate?**

The GPL licenses have been well-described as software developers’ revenge on intellectual property lawyers for making software the subject of copyright law. While the copyright law works “OK” for software, it isn’t a straightforward or intuitive fit. With the GPL licenses, software developers attempted to re-define copyright law concepts in a way that they believed both met their “free software” goals, and applied copyright law concepts more appropriately to software. The result, and I genuinely will not pick sides on this, is that it is incredibly complex to try to determine how the courts would apply the GPL license terms in determining the point at which a “combination” of GPL software and proprietary code would require disclosure and sharing of the proprietary code. Every time I get a call from a client saying, “Hey! It looks like we’ve included some GPL code in our proprietary product (and we want to release it tomorrow). Is this a problem?” I open up the GPL license terms and am reminded of Robert Falcon Scott’s words on reaching the South Pole – “Great God this is an awful place …”

3. But everyone’s using L-GPL, and plenty of people are using GPL – why can’t we?

This is true, and there are ways in which you can engineer your products so as to “insulate” your proprietary code from copyleft or hereditary software. But you have to do it right, and there will be some element of uncertainty owing to the challenging nature of the license terms for the open source code.

To be fair, this isn’t always the fault of the people who wrote the open source licenses or the lawyers who interpret them. For example, L-GPL is a less restrictive version of GPL designed to apply to libraries. But some developers don’t realize this and, thinking that L-GPL is simply a less restrictive version of GPL, apply it to code that isn’t a library at all. At that stage, you get an already complex license whose application to the technology it’s intended to cover is now incredibly difficult to interpret.

4. Why did LinkedIn disclose this as a risk factor?

My guess is that LinkedIn’s developers have built a significant portion of LinkedIn’s code using copyleft or hereditary code, but may not have sufficiently insulated LinkedIn’s proprietary code, so they may face exposure for infringement claims. “Ideally,” LinkedIn would have had better controls on their inbound licensing processes – but as those experienced with start-ups and early stage tech companies know, controls and processes are not always a priority.

**Refers to this bit of yesterday's comment thread.

Permission as Weapon

All lawyers trained in the US take a real property class in school. Whether or not a lawyer specializes in real property in her later practice, she's likely to use concepts from real property law in any number of other practice areas.

Take the opportunity or problem (depending on your point of view) of adverse possession. This is a doctrine by which someone may acquire legally enforceable rights in a piece of land, without the consent of the record title holder. Students like me chuckled to learn that one way a titled landowner might defeat a potential claim of adverse possession from ripening would be to simply give permission to the potentially adverse use.

So it's awesome to read a post by Brad Smith, General Counsel for Microsoft, announcing what sounds to me like essentially the same thing, the granting of a blanket permission, in an effort to protect political dissidents in Russia.

It seems that Russian authorities were using software anti-piracy concerns as a pretext to raid and confiscate the property of NGOs "and others engaged in public advocacy."

Mortified, Smith seems to have assembled his resources from around the world and arrived swiftly at a trumping move:

"To prevent non-government organizations from falling victim to nefarious actions taken in the guise of anti-piracy enforcement, Microsoft will create a new unilateral software license for NGOs that will ensure they have free, legal copies of our products."

It will be interesting to read the license once written and to track whether the unilateral nature of it may have unintended consequences. But you can't help but applaud a big corporate entity acting as swiftly and humanely as a startup organization might.

Software and the Range of Copyright Rights

Really glad to see Jeremy Freeland has a new post. Congrats to Jeremy as well on founding his new IP boutique law firm. 

The second part of the post discusses how the various, divisible rights under the Copyright Act - to reproduce a work, and to distribute, display, perform and create derivatives of the work - don't apply to software as intuitively as they apply to novels, plays, movies and songs. Jeremy writes:

"Surprisingly, many software licenses, especially forms pressed upon reluctant vendors by their customers, don’t address any of the exclusive rights under the copyright laws. They simply provide the licensee with the right to ‘use’ the software. This is all well and good to the extent the licensee needs rights under the software licensor’s trade secret and/or patent rights. But, it doesn’t do much in the way of specifying what rights the licensee has under the copyright law. For example, if I have a license to ‘use’ software, do I have a right to make modifications to the software?"

Jeremy goes on to give an example of careful software license wording that deliberately deploys the copyright rights to copy, distribute and create derivative works.  

While I want Jeremy to write more, more, more, I hope he doesn't stop commenting on my blog. His comments here are often more substantive than my posts!

A Secret Is Only a Secret If It’s Secret, Right?

In the recent case of Nationwide Mut. Ins. Co. v. Mortensen (decided on May 11, 2010), the Second Circuit Court of Appeals made it very clear – if you don’t take reasonable measures to keep your trade secrets a secret, then you lose them. In the Nationwide case, Nationwide argued that its policyholder information that it kept in a computerized database was a trade secret that was misappropriated by a number of agents who took policyholder information with them when they left Nationwide to sell insurance policies for a competitor. However, the court found that Nationwide did not in fact have a trade secret in policyholder information, even though it took steps to keep that information in a secure computer database, because the agents also kept paper files from which they entered the information into the system. The district court reasoned that the paper files were not reasonably protected because: 1) there were no contractual provision in the agent's agreement requiring agent to protect the secrecy of the files; 2) agents were free to make and keep their own notes about the contents of the files; and 3) departing agents could retain a list of names of customers (but apparently not the files themselves). The court reasoned that “with customers’ names in their rightful possession, agents can obtain policyholder file information directly from the customers and other sources.”

As a general matter, a trade secret that can easily be figured out isn’t much of a trade secret to begin with. Trade secrets are generally valuable because they convey some sort of competitive advantage and they’re not generally known or easy to figure out by others who could use them for economic gain. The court’s reasoning that there is no secret here because you could go back and ask the customer for their policy information leaves me wondering where do you draw the line. If my insurance agent were to call me up and ask me for a rundown of the premiums I’ve paid and my claims history for the last five years, I’d be hard pressed to remember, not inclined to figure it out, and would likely ask him “isn’t this information you’re supposed to know?” It seems to me that the court is assuming that all the information in the file would be pretty easy to figure out by asking the customer.

The logical conclusion of this line of reasoning seems to me to suggest that anything you can figure out by going and asking a customer is thus not protectable as a trade secret. But that runs contrary to other cases which state quite clearly that “client information, such as data on the types of hardware and software ordered by specific clients, lists of products sold to clients but not yet developed and problems arising in the course of client relations are also protectable as a trade secret.” See Business Intelligence Services, Inc. v. Hudson (S.D.N.Y. 1984). If you knew the right questions to ask, it seems to me that you could also find out this information. Maybe what the court is saying is that on an individual policyholder basis, there isn’t a trade secret in the contents of the file. But what about a collection of policyholder files? Again, where do you draw the line?

At the end of the day, one thing is clear – you have to take reasonable steps to make sure your secrets remain secret. It’s not good enough for it to be protected in one medium if it’s not reasonably protected in another.

Albert S. Chu is an IP attorney based in the Seattle area.

NDAs with a "Residuals" Clause

An NDA is just boilerplate and they're all the same, right?


You've got to read every NDA because one out of every four or five is going to have something squirrelly.

But the good news is, NDAs typically recycle standard clauses, sentences and phrases. This makes it easier to identify the provisions that are non-standard and deserve additional attention.

Here's a common variant of one clause you should always think about whenever you see it in an NDA:

The Receiving Party shall be free to use for any purpose the Residuals resulting from access to or work with the Confidential Information of the Disclosing Party. "Residuals" means information retained in unaided memory by persons who have had access to the Confidential Information, including ideas, concepts, know-how or techniques contained therein. The Receiving Party shall not have any obligation to pay royalties for work resulting from the use of Residuals. However, this clause shall not be deemed to grant to the Receiving Party a license under the Disclosing Party’s copyrights or patents.

This clause is essentially a trade secret license. Is it good to have in an NDA? Depends on whether you are doing the talking or the listening! But the clause is easily misunderstood. Many people who have signed an NDA with such a clause feel bitter about it later, because it seems to them, perhaps not unfairly, to go against the spirit of a mutual NDA.

Usually the companies that propose a residuals clause are bigger companies, who put it in a variant form of NDA they may prefer when talking to smaller companies. If the bigger company refuses to remove it, it is often best for the smaller company to walk away.

I'm thinking about this topic because a friend of mine, the masterful licensing lawyer, Albert Chu, recently sent me a link to a federal case that involves a trade secret license and/or carve out in a confidentiality agreement. The court didn't seem to be too bothered by saying the disclosing company had blown it and was stuck with what it had signed. Moreover, the disclosing party in that case may have compromised its ability to protect its trade secrets as to third parties, as well.

I'm hoping Albert will write a paper (or better yet, a blog post) about the case and its practical implications. In the meantime, suffice it to say that the case reminds us that you can give your secrets away, even in a document that you think is intended to protect your secrets.

Related Posts with Thumbnails