Saturday, December 31, 2016

IP Considerations for Releasing OSS (part 3 of 3)

Continued from IP Considerations for Releasing OSS Part 2



Trademarks.  Trademarks in the form of individual or organization names, symbols, designs etc. are often one of the most valuable aspects of intellectual property applicable to software.  Purchasing and or OSS utilization decisions can be heavily influenced by a well known trademark's reputation for quality, performance and stability.  Many practitioners agree that a trademark would be lost if included as part of a software's OSS licensing terms.  This is because trademark law encourages an owner to maintain control over product quality bearing the mark.  Since a basic principle of OSS licenses is to allow creation of derivative works, such control would be untenable in an open source scheme.

Consequently, open source licenses do not include a trademark license and many explicitly preclude use of the copyright owner's name or other identifying marks as endorsement or promotion of derivative works.

Trade Secrets.  IP which an organization chooses to protect through trade secrecy restrictions should never be part of an open source project since the source code is published to the world.

Please see these sources for a more in-depth discussion of these topics.

Saturday, December 24, 2016

IP Considerations for Releasing OSS (part 2 of 3)

Continued from IP Considerations for Releasing OSS Part 1

Patents.  Unlike copyrights which provide creators with exclusive rights to do certain activities, patents can be thought of as providing owners with the right to prevent others from doing certain things with the subject matter of their patents.  Examples according to the U.S. Patent Act, 35 U.S.C. § 154 include:
  1. right to exclude others from making products embodying a patented invention
  2. right to exclude others from using products embodying a patented invention
  3. right to exclude others from selling or offering for sale products embodying a patented invention
  4. right to exclude others from importing products embodying a patented invention
Since commercial exploitation of these rights is often the reason for investing in patent prosecution, entities should weigh the "cost" of OSS licensing which implicates such patents against other goals such as market disruption or advantage of quickly establishing a public industry standard.

Software published under an appropriate OSS license can still assert patent ownership, but the OSS license chosen should explicitly license any implicated patent rights to the OSS consumer as necessary for full software utilization.  Otherwise adoption will be severely limited.

Additionally, several OSS choices include what is sometimes called a "Patent Peace" provision.  Such a provision can take various forms but usually terminates a licensee's rights to the original work if the licensee initiates  a patent action against the licensor or often any licensee of the covered work.  The intended effect is to specifically deter over reaching by downstream consumers while also discouraging such litigation in the OSS community at large.

Next, trademark and trade secret considerations.

 Please see these sources for a more in-depth discussion of these topics.

Tuesday, December 20, 2016

IP Considerations for Releasing OSS (part 1 of 3)

The decision to release software under an open source license has some nuances requiring careful consideration to ensure desired goals are achieved.  For purposes of this discussion, I will be approaching the question from the perspective of releasing an original work, though the same considerations apply when contemplating contribution to an existing community project with an established license and contributor policy.

The first concept to understand is that software is the result of an intellectual endeavor resulting in the creation of both:
  • intellectual property rights
  • rights to control copies of IP and any resulting distribution through any medium 
It is important to realize the original creator (or their employer) has the right to separately license one or both types of property rights to as many different parties as desired.

An organization considering publication under an open source license has multiple options to choose from varying by type and degree of IP protection.  OSS allows and in fact encourages very liberal downstream distribution by nature so I will focus this series of posts on basic IP rights and related factors which should influence an OSS publication decision.

Copyrights.  Copyright protection subsists ... in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device ... (17 U.S.C. § 102.)

Even the simplest of OSS licenses tend to adequately provide for the reservation of copyright to the creator.  But an OSS publisher should understand that many exclusive rights accruing to a copyright owner are immediately licensed to an OSS consumer under most OSS choices:
  1. right to make copies
  2. right to prepare derivative works
  3. right to distribute original or derivative works
It is probably best to think of an OSS license scheme as preserving basic copyright protection while actively encouraging the easiest path to wide dissemination and adoption within target user groups.  Given this generalization, the specific OSS license chosen will then often influence the level of downstream adoption, contribution and further development by an active user community.

Next up, Patent considerations.


Please see these sources for a more in-depth discussion of these topics.

Thursday, December 15, 2016

OSS License Types (Part 3 of 3) - Reciprocal Licenses

This third post in the license type series will review the category of licenses often referred to as having a reciprocal nature.
  1. Permissive licenses
  2. Corporate licenses
  3. Reciprocal licenses
This group of licenses are called reciprocal because the licensee is usually required to adopt the license of the consumed component when creating and distributing any derivative works.  Since the terms of the licenses generally require full source code disclosure, the ramifications of such reciprocity should be carefully considered.  Sometimes we will see these licenses referred to as:
  1.  "copyleft"  - a play on the IP term "copyright", or
  2.  "viral"  - because they "infect" any larger bodies of work upon incorporation, or
  3. "hereditary" - because once these reciprocal terms take hold on a project they are passed down through the progeny of the software line
Common examples include:
  1. GPL (all versions) - GNU General Public License
  2. LGPL - Lesser General Public License - this one is a little less onerous from a compliance perspective
  3. AGPL - Affero GPL
  4. OSL - Open Software License
Downstream reciprocity requirements imposed by these licenses require very careful use case analysis when contemplated in a commercial context to ensure business goals align with any required source code disclosures.  Special attention must be directed to the definitions of derivative and collective works since the licenses themselves do not always use the generally accepted terms or definitions as established by copyright law.  In addition, reciprocity is often triggered by distribution which is not always clearly defined by the terms of the license itself.  There are a handful of reported interpretations by various courts which are somewhat informative and will be the subject of another post.

In summary, advising clients on the use of OSS components subject to this category of licenses requires careful scrutiny of both the applicable license terms and the business intent driving a proposed use case.  These licenses do serve a particular purpose within the broader market but must be approached with caution in order to avoid undesirable consequences.

Tuesday, December 13, 2016

OSS License Types (Part 2 of 3) - Corporate Licenses

This second post in the license type series will elaborate on what can be referred to as the corporate license category.
  1. Permissive licenses
  2. Corporate licenses
  3. Reciprocal licenses

We refer to these licenses as "corporate" because they are usually created by companies as a middle ground between permissive/academic licenses and  reciprocal licenses.

Downstream obligations for this category require careful use case analysis but can often be acceptable in a commercial context given proper planning and attention to license restrictions.

Examples include:
  1. Apache - Apache Software Foundation
  2. MPL - Mozilla Public License (Netscape)
  3. CPL - Common Public License (IBM)
  4. EPL - Eclipse Public License (IBM)
  5. CDDL - Common Development and Distribution License (Sun Microsystems)
  6. Microsoft Code Sharing License (Microsoft)

Unlike the other two categories, these licenses show clear signs of professional, attorney led draftsmanship.  As a consequence, many of them address traditional intellectual property concerns one would expect to find in a more formal license agreement.  These express terms are often welcomed by consumers and publishers alike since they directly address issues often left open to interpretation by the other two license groups.  Examples include:
  1. Trademarks, often in the context of promotional use restrictions
  2. Patents, often in the form of a patent peace provision
  3. Warranty disclaimers and limitations of liability
  4. Indemnification provisions
  5. Clear definitions of important terms and concepts
  6. Choice of law provisions
  7. Export restrictions
  8. Integration provisions
From a practical perspective, these licenses tend to take more time to evaluate.  They are more extensive in their terms and more exact in their language.  However, most in-house counsel and their outside counterparts appreciate the clarity these licenses can bring to a potential project.  It is often easier to line up business objectives cleanly without the ambiguity of the simpler academic licenses and the sometimes obtuse language of the principle driven reciprocal options.

Next up, reciprocal license alternatives can be challenging but workable in appropriate circumstances.

Wednesday, December 7, 2016

OSS License Types (Part 1 of 3) - Permissive Licenses


I like to create frameworks for recurring risk analysis scenarios in order to follow consistent processes as well as allow me to establish a baseline from which to improve quality and or efficiency whenever possible.

One of the primary inputs for an open source software governance framework is of course the applicable license(s) to any given component under scrutiny.  I like to group OSS license types into three primary categories to begin my review process:
  1. Permissive licenses
  2. Corporate licenses
  3. Reciprocal licenses
This first post in the license type series will elaborate on the permissive license category.

Permissive licenses are sometimes called academic licenses since many of them originated at educational institutions.  Examples include:
  1. BSD (2 clause and 3 clause) - Berkley Software Distribution
  2. MIT - Massachusetts Institute of Technology
  3. AFL - Academic Free License
  4. Artistic License - originally written for PERL

These licenses share a common characteristic in that downstream obligations are generally not burdensome.  As such, components subject to a license in this category tend to be easily compatible with most any use case scenario in academic, corporate or government arenas.  Typical obligations include:
  1. Accept absence of warranty or liability
  2. Acknowledgement of earlier contributions
  3. Inclusion of license file(s) in downstream distributions
While each license is somewhat unique and should be carefully considered to ensure full compliance, as a category they tend to share common provisions regarding retention of copyright protections for their subject matter along with express disclaimers of the normal warranties.  Other than such basics, the licensed software is generally made available for most any purpose including the often desired right to include as a component in the preparation of derivative works.

On a practical note, these licenses are so brief and common that they are often found embedded in an open source project readme.txt or license.txt file and not, for example, explicitly labeled as an "MIT" or "BSD 3-clause" license.  They could even be included within a source code header or comment section.  This does not change their nature, but it is helpful to learn to recognize them quickly in order to save time.

 

Monday, December 5, 2016

Rationale for Actively Managing OSS

Open Source Software is at this point ubiquitous in most every industry.  Our clients with any sort of technology footprint are likely reliant on OSS to some significant degree whether they realize it or not.  The relevant risk calculation probably depends on the extent an organization's competitive advantage is tied up in a technology centric product or service.  So here are a few points to consider when consulting with clients or evaluating your own business:

  1. If your client develops software of any type as part of normal operations they need to understand that the best programmers are going to gravitate toward certain OSS platforms and code modules to solve common problems - why reinvent the wheel?  Alternatives such as purchasing commercial software for everything can get expensive.  Insisting that technical talent build everything from scratch, even for functions which are largely a commodity, can be extremely de-motivating and put an organization at a competitive disadvantage.  Modern collegiate and specialized development training programs often place OSS tools and components at the core of their curriculum and rightly so.  The days of insisting all software development remain strictly an internal endeavor without any outside influence in order to maintain purity of intellectual property are largely over.
  2. Since OSS is likely already present, choices involve the degree to which it is actively managed.  Completely unmanaged OSS use and proliferation can put a client's IP and associated revenue streams at risk through a judgment for damages or more likely an injunction order.  Additionally, unmanaged co-mingling of code makes it extremely difficult when preparing for a change of control event associated with divestiture or acquisition.
  3. Finally our rationale should consider the multiple of benefits of an efficient, actively managed OSS governance process.  Specifically:
    • Decreased time to market is often possible if technical resources can focus creative energies on market differentiating features rather than commodity functionality which any competitor can easily acquire.
    • Higher quality and more secure code is often available with thoughtful consideration for choosing OSS platforms and components from active and well managed software communities.  Let's face it, a large complex piece of code with thousands of critical eyeballs invested in its success is by nature going to be of better quality than any purely internal project produced by even the largest, most professional of organizations.
    • Attraction and retention of top talent is a goal of most companies and technology resources are often hard to keep over the long term without substantial investment in their careers.  A well run OSS governance program enables constant evolution of skills vital to a developer's career without requiring a job change every couple of years.  The benefits on this front cannot be over estimated.
    • All of the above can lead to a lower total cost of ownership for most any technology driven capability.  The benefits are tangible and largely measurable which is crucial when building  the business case for investment in active OSS governance programs.
While a discussion like this can never be exhaustive and will certainly vary by industry, I hope this has provided some good food for thought.

As always, thoughtful comments and questions are welcome.

Thursday, December 1, 2016

Autopilot for your Honda!

Okay, so I read about this very early in the morning and had to double-check after my run and some coffee.  Apparently a company, "comma.ai", has open sourced after market self driving software for certain Honda models.  It appears to require hardware components and tinkering well beyond my comfort level, but this is certainly one of the more interesting use cases for OSS I have run across.  According to the article, the company was concerned about US Department of Transportation's safety requirements and decided to just release the software to the community rather than pursue a commercial product launch given the potential regulatory hurdles.

A quick review of the github repository shows they chose an MIT license.  This would appear to add a whole new level to the importance of appropriate disclaimers.

See the article from newatlas.com here.   The github repository is here.

I would love to see some pictures if anyone takes this on as a side project!

OSS Resources

I find that I'm most comfortable delving into a new field when I can quickly identify core resources as reference material in order to establish a reliable foundation for future work.  I keep these key information sources close at hand for repeated reference as each new issue presents itself.  This allows me to begin building perspective and more easily weigh the value of new commentary regardless of source.  It can be difficult to get adequately grounded when the subject matter has such a relative short history and few if any on point legal precedents.  In that spirit I recommend two books I have found invaluable:


  1. Lawrence Rosen, Open Source Licensing, Software Freedom and Intellectual Property Law, (2005) 
  2. Heather J. Meeker, The Open Source Alternative, Understanding Risks and Leveraging Opportunities, (2008) 

Both of these volumes enjoy a permanent place on my desk, complete with dog eared pages and the occasional coffee stain.  They are the type of reference that should probably be read front to back the first time through for context.  But thereafter are easily used as a quick refresher when needed.  I fully credit both Rosen and Meeker for influencing my thinking on many open source topics discussed in this blog.

I should note that while the legal analysis of the open source landscape remains as useful today as when they were first published, you should remember that the specific technology application discussions and software engineering terms have quickly become dated.  Architectural concepts such as cloud based infrastructure, platform as a service (PaaS) and container based resource management were not really on the landscape for Rosen and Meeker to consider.

Of course, there are multiple websites, blogs and other on-line resources as well which can be enormously helpful.  I will continue to reference those in the context of future posts.

I would like to hear about other resources that the community has found worthy of mention as a core reference in the field.  Thoughtful comments are welcome :-)