People are often surprised to learn that employers sometimes try to claim ownership in an employee’s intellectual property for inventions that are not related to their job.

Like many attorneys who work with startup companies, I am a huge fan of California Labor Code 2870.  This law says that an employer in California may not require an employee to assign IP created by the employee during the time of that employee’s tenure if it’s created on the employee’s own time, without using the employer’s resources (use your own non-company owned computers and network connectivity, people!), and so long as it is not related the company’s research and development.

An untold number of start-up companies have been created by founders in California who did the initial IP development on the side while holding down a salaried job with an employer.  Statutory protection of inventor rights in independent inventions (alongside a prohibition against most post-termination non-competes) is often cited as one of the reasons the vibrant startup ecosystem in Silicon Valley and throughout California exists.

Unfortunately, I’ve seen many contracts where employers purported to own all (or much more than California allows) of the intellectual property created by the employee during their employment.  Thanks to California Labor Code 2870, the overreaching portions of those contracts are unenforceable in California.  In California, founders who create IP for their next startup (or FOSS developers who work on unrelated FOSS projects) can feel comfortable that the IP created in their moonlighting, hobbies, side hustles, etc. are their own property if they follow the rules.

I knew that a few other states had similar inventor rights statutes on the books, but it had been a while (let’s be honest, probably a decade) since I’d looked into it generally.  So, in preparation for a lecture I was giving to new engineering graduates (with job opportunities all over the United States), I did some Internet searching.

I was very surprised to learn that Delaware has an inventor rights statute.  How had I not heard about/internalized this before?

As you may know, Delaware has more corporate entities than people.

According to the Secretary of State’s 2016 Annual Report, there were more than 1.2 million corporate entities registered in Delaware, and at that time, more than 2/3 of the Fortune 500 were Delaware corporations.

In other words, Delaware is the most popular US state for corporate formations and many, many companies (especially big public companies) that employ lots of people are Delaware corporations.

Because of this, many of the contracts with overreaching IP terms I’ve reviewed in the past were with Delaware corporations.  Most of those employees were not working *in* Delaware, and I’ve always looked to the labor code of the state in which the employees were employed.  However, if a company chooses to avail itself of Delaware law by incorporating there, it is subject to Delaware law, public policy, and jurisdiction.  I don’t know why it hadn’t occurred to me that all employees who work for a Delaware corporation can point to  19 DE Code § 805 (2017) :

Any provision in an employment agreement which provides that the employee shall assign or offer to assign any of the employee’s rights in an invention to the employee’s employer shall not apply to an invention that the employee developed entirely on the employee’s own time without using the employer’s equipment, supplies, facility or trade secret information, except for those inventions that:

(1) Relate to the employer’s business or actual or demonstrably anticipated research or development; or

(2) Result from any work performed by the employee for the employer.

To the extent a provision in an employment agreement purports to apply to the type of invention described, it is against the public policy of this State and is unenforceable. An employer may not require a provision of an employment agreement made unenforceable under this section as a condition of employment or continued employment.

Those of you who know California Labor Code 2870 will find this language very familiar. The Delaware version is just a slightly different version of the same law.  In general, I think the Delaware drafting is slightly tighter, although I don’t like the lack of the “at the time of conception or reduction to practice” limitation. I do, however, love the clear final sentence, which I will be using to argue against over-reaching IP provisions in Delaware corporation employment agreements.

Sure, a greedy corporation could claim that even though Delaware won’t enforce an egregious IP assignment, perhaps another state where the employee is working will.  But it’s not a good look for the employer to intentionally go against the public policy of the state where they are availing themselves of corporate protection.  Most employers don’t sue to acquire employee IP, but rather point to contracts and demand assignment from employees who are scared to incur legal fees.  I suspect they’ll be even less likely to sue if they realize their employee is aware of a public policy of Delaware that specifically prohibits the contractual term they are trying to enforce.

California adopted Labor Code Section 2870 in 1979.  Delaware adopted Labor Code Section 805 in 1984.  I’ve confirmed that as of today, at least the following states (I need to do a 50 state survey) have an inventor rights statute:

Including the weight of all of the Delaware corporations plus employees working in and corporations incorporated in all of the other green states above means that inventor rights statutes are not a leading-edge policy that only applies to a few select states and companies.  Inventor rights is actually a legal norm that applies across the majority of large technology employers in the United States, and even employers who are not expressly required to respect them should consider that failing to do so is likely to cause them to lose out on top talent in their employment pool.

For more information, see the redline below for a detailed display of the differences between California’s and Delaware’s statutes, or click on the links to see the specific statutes for each state.

California https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=LAB&sectionNum=2870

Washington http://apps.leg.wa.gov/rcw/default.aspx?cite=49.44.140

Nevada https://law.justia.com/codes/nevada/2010/title52/chapter600/nrs600-500.html

Utah https://le.utah.gov/xcode/Title34/Chapter39/C34-39_1800010118000101.pdf

Kansas https://law.justia.com/codes/kansas/2006/chapter44/statute_18289.html

Minnesota https://www.revisor.mn.gov/statutes/?id=181.78

Illinois http://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=2238&ChapterID=62

North Carolina https://www.ncga.state.nc.us/EnactedLegislation/Statutes/PDF/ByArticle/Chapter_66/Article_10A.pdf

Delaware http://delcode.delaware.gov/title19/c008/index.shtml

Wow!  That was fast.

I”ve been running my own law firm for over a year.  It’s been a blast and I’ve been very fortunate — quite a bit of exciting and interesting work came to my door last year.

Some of the highlights include:

• Managing a dispute from initial demand letter to arbitration award — on my first day running my own firm, one of my clients received a cease and desist letter which we believed was invalid.  We pitched the case to litigators, hired them, and I was able to act as in-house counsel for the 7 month JAMS arbitration: editing and adding factual clarity to filings, attending all depositions and hearings, and eventually delivering the news after judgment.  In general, this is not my day-to-day practice, but it was very educational and modified my perspective on how contracts should be drafted and disputes relating to contracts should be approached.
• Acting as on-site in-house technology counsel one day a week — sitting in the legal department of one of my larger clients gave me a very different understanding of the role that attorneys play within an organization.  I supported the third party inputs to software (reviewing both open source and third party proprietary licenses) and the enterprise licensing division and often witnessed first-hand the delicate balance that must be maintained between legal risk and business risk within a corporation.
• Negotiating against the big guys — it’s part of the typical start-up experience.  Sure, you often negotiate and partner with other start-ups, but at some point, you will need something from one of the big established players.  It may just be Internet connectivity.  Or, large companies may be your sales targets.  Regardless, negotiating against a large company who insists that *we never change our forms*,  *everyone signs this without edits* and *this is completely standard* requires the expertise of someone who has seen many *standard* offerings in the applicable industry.  Over the years, I’ve dealt with Fortune 100 and Fortune 1000 companies in almost every industry, and this year was no exception.  Examples from this year include: Advertising Agencies, Amazon, Barclays, Blue Cross Blue Shield (of America and of various States), Bank of America, Chubb, Credit Suisse, CUNA Mutual Insurance, Discover, DOE Pacific, Earnst and Young, Experian, Facebook, Fidelity, Google, Honeywell, Horace Mann, Humana, JP Morgan Chase, KPMG, Lloyds, Lockheed Martin, Mass Mutual, Microsoft, Morgan Stanley, NBC Universal, Nationwide, PWC, Safeway, Samsung, State Farm, T-Mobile, Toys R US, Viacom, Walmart, and Warner Brothers.
• Setting up the legal side of the business (forms) — a large portion of my job is limiting the amount of work I do.  I try to get my start-up companies into a position where their internal IP creation departments, online systems, sales forces, and business development teams can function with minimal legal input.  This involves an up-front investment of time to create forms that are correct for their business models.  I talk to my clients and truly understand their businesses before drafting, which avoids the extra legal fees companies often incur when their attorney starts with a square hole for a round peg.  Examples include:  Enterprise license agreements, Software-as-a-Service Agreements, trademark license agreements (branding/endorsement/certification programs), software development agreements, click-throughs (standard terms, privacy policies, API license agreements, payment obligations, revenue share, and more), commission agreements, reseller agreements, professional services agreements, master purchase agreements, NDAs, partner program agreements and technology assignment agreements.
• Open Source — I went to law school because I was fascinated by the legal rights issues in Open Source Software.  I even wrote an award winning student note on the topic.  This year, I continued my commitment to Open Source legal issues with projects in several areas:  (i) aided a client in cleanly open sourcing a proprietary language they had developed (open source license evaluation and selection, branding issues, IP contribution agreements); (ii) performed open source audits of client codebases with the engineering teams and cleaned up any issues found; (iii) acted as special open source counsel in an Asset Purchase and Leveraged Buy-Out to help the acquirors become comfortable with the state of my clients’ open source uses; (iv) represented (and continue to represent) two clients whose business models are built around open source software projects that they manage (with monetization through professional services, support, maintenance, priority bug fixes, and bespoke development); (v) aided clients in the development of open source policies and approval processes to maintain the codebase in the proper state.
• Everyday advice, counseling and communications — this catch all category is where the most surprises come.  Sometimes it’s just a phone call asking for a sanity check — Can we do this?  But sometimes there are more exciting issues such as requests from law enforcement, lawsuits that have been filed against clients, high level discussions about IP strategy (should we talk to patent counsel?  Should we file a TM?), letters hinting that lawsuits may be filed, formal letter writing in response to unfortunate situations, termination of contracts, privacy concerns, and much more.

Overall, last year was a great year full of good work, great learning opportunities and wonderful clients.  I can’t wait to see what this year brings.

I spend quite a bit of time talking through *theoretical* risks associated with using third party software in products, particularly with respect to software that’s been developed in connection with some type of promise of openness.

I try to explain to my clients that just because things have gone smoothly thus far with respect to a particular piece of code does not mean that it will continue to go smoothly.

Oracle has just made this explanation *much* easier for me by suing Google for its use of Java in Android.

The complaint is pretty straightforward (I guess he likes it here, because after spending so much time here with respect to the Prop 8 litigation, David Boies is named as pro hac vice on behalf of Oracle).

The complaint alleges infringement by Google in its use of Java technology in the Android Platform. 7 patents held by Oracle America (the new name of the former “Sun” subsidiary) are asserted. It also alleges copyright infringement.

In many ways, this move is shocking. The entire Java mobile development community is going to be reeling. But, in other ways, I think there will be some closure. Many of my clients have been waiting to see how Oracle would treat Java. And now we know…

In particular, I’m curious how the release of Java (including the Hotspot JVM upon which the Google JVM may very well be based) under the GPL v 2.0 by Sun prior to the Sun-Oracle acquisition will play into this. Does the GPL v 2.0 license contain an implicit patent license and/or create an argument for patent exhaustion?

**UPDATE: I have been informed that the Google JVM Dalvik is a completely new implementation, written from scratch by Google, which, assuming it’s true means that any arguments based on the GPL release of the Hotspot JVM are going to need to be much more complicated (e.g. it may play into the damages calculation, or perhaps they will still try to make the patent exhaustion argument).

Stay tuned.

This should be VERY interesting.

Every software start-up company I’ve ever worked with uses (or did use) some form of open source software. And yet, high level executives and board members at many of these companies, when asked whether their company uses any open source software, would regularly answer, “No” without hesitation.

Where is this disconnect coming from? Open Source Software is often perceived as “risky” or “untested” or “a liability nightmare” or, in the worst case, “an infectious disease” by some business folks, while most technical software people believe the correct use of open source software to carry minimal risk.

Risky?

There are risks associated with using any third party’s software. When that third party is unidentified, not bound by a support agreement, based out of a foreign country, and/or impossible to get a hold of, then yes, it is fair to say that using it would be “risky” when compared with an established company with a business reputation to protect and an SLA to cover errors.

Untested?

In some case — it’s true. There are many untested open source projects out there. These tend to be associated with a handful of developers instead of an active community, and a little due diligence should be able to help a start-up understand whether this particular ill is a problem with the open source software they are considering using.

A Liability Nightmare?

This is, by far, the most complicated issue I face as an attorney who deals with open source issues. At its most basic, the liability equation associated with open source software is the same as that associated with any third party component. The third party would like to disclaim liability for your use of their product.

The benefit of many proprietary software licenses is that the licensor may provide limited coverage for Intellectual Property claims related to their software. But, most software publishers go to great lengths to limit the amount and type of liability they will cover relating to a third party’s use of their software.

The typical open source license expressly disclaims all liability associated with the use of the software — effectively, it comes “AS IS” on a pure “BUYER/USER BEWARE” basis. On the other hand, if you read the license agreements of proprietary software carefully, you will find that most software (unless you pay quite a bit for it), comes with an express limitation on liability that is on the order of magnitude of the purchase price. It is consistent with the approach taken by proprietary software publishers that open source authors are liable for damages related on the order of magnitude of the license fee they receive (e.g. $0).

An Infectious Disease?

One flavor of open source licenses places conditions of “freedom” upon the use of the licensed code. The most famous of these licenses are the GPL, LGPL, and the AGPL. Essentially, these licenses require, as a condition of some uses or distributions, that software code combined with code licensed under these licenses must also be made available under the same license.

These conditions make these types of licenses “viral” because they may extend the license terms to some of the additional code (e.g. the start-up’s code) that the licensed code touches.

The key word in the previous sentence is *MAY.*

Actual Risk

The thoughtful evaluation of the issues outlined above and a comparison of the likely downside against the monetary benefit of using an open source component brings a start-up to understand what I call the “Actual Risk.”

By far, the most complicated part of the Actual Risk evaluation is the technical and legal analysis related to viral licenses. However, a technical read of the license by a knowledgeable tech attorney and code review with an engineer is likely to provide a good engineer or architect with comfort that the start-up’s use of a particular open source component is not subjecting the start-up’s code base (or the portion of the code base that they care about keeping proprietary) to any “viral” risk.

The Resource Risk

Investors and potential acquirors will want their own attorneys or possibly even code auditors to assess the Actual Risk, regardless of how correct the start-up’s own analysis may be. This investigation and analysis is a time and resource drain that can be minimized by good record keeping, but can never be entirely eliminated. Even in the event of zero Actual Risk, a company will incur some Resource Risk in connection with their use of open source software.

The FUD Risk

No matter what the final conclusion may be after the Resource Risk and the Actual Risk have been assessed and assumed by a start-up, there is the risk associated with the fact that a board member or a CEO will have to answer “Yes” to the question “Do your products contain open source?” A board member or CEO may not have the time to understand the outcomes and analysis of the folks who have willingly taken on the Resource Risk and the Actual Risk. If challenged, a board member or CEO need to feel confident that they can answer the question honestly, without incurring undue scrutiny or concern. In my opinion, the biggest risk associated with the use of open source software (assuming there is no Actual Risk that hurts the start-up’s business) is the FUD risk.

The best way to combat the FUD risk is to educate board members and CEOs so that they can comfortably speak about the company’s intelligent use of open source software as a cost reduction tool in areas where the Actual Risk is minimal or non-existent and the Resource Risks are less than the costs of the proprietary alternatives.