What is Package Management and why do I care?

Package Management is now almost ubiquitous in modern software development circles due to the layers upon layers of dependencies between software components which are pulled together to achieve an end result.

For a simple overview of the topic, start with this Wikipedia entry.

This is especially true in the open source world where the very nature of community and crowd source development encourages re-use of code at every opportunity.

From a licensing standpoint, this code combination and inheritance phenomenon has the potential to introduce wrinkles when investigating the provenance and or applicable licensing for a particular component.

Two of the most common package repositories for open source components are:

1. The Maven Repository containing almost 7 million artifacts as of the date of this post
2. The NuGet Gallery currently hosting about 1 million artifacts concentrated on the Microsoft development platform.

I was recently researching the licensing for a component automatically included in a project when a developer using the Microsoft Visual Studio IDE was working on a web based application.  In effect, this "package" was pulled into the developer's work without their direct knowledge or choice from the NuGet Gallery repository.  Apparently it was necessary for some foundational functionality related to processing java script.

Upon investigation, I discovered the original component was released by the copyright holder under an MIT license, but had apparently been bundled together and re-released by Microsoft under its own NuGet license.  Nothing in the MIT license restricts this practice as long as primary attribution is maintained and promulgated, however there are additional terms in the NuGet license a consumer of this component might be more concerned about than when taking the code under the pure MIT license.  For example, the NuGet license specifically grants Microsoft the right to collect certain information from a package consumer's computer and or project as a condition of use.

The lesson here is that package management can impact a user's rights to open source code if used indiscriminately. Depending on the use case, it might be worth some investigation to determine if a component is available under more benign terms.

 

I thought that was Open Source???

I am often asked to look into a product or component where there seems to be confusion as to the licensing model.  It is understandable as copyright owners often evolve their products and services in different directions in response to market demands.  Here are some of the scenarios I commonly discover:

1. The product is truly open source, but has changed licensing models at least once if not multiple times throughout its life span.  This scenario is fairly easy to address; the user simply has to decide if the latest version with its attendant features and bug fixes is worth the conditions to be compliant with the current license.  If so, great.  If not, then the user can move back in time to a version released under a more palatable license and start from that fork, understanding that there may not be an active community for support and continued development.
2. The product is not open source at all, but instead is released under some version of the "freemium" model.  A version with restricted functionality or which is time limited can be downloaded with no purchase required.  However, since source code is not provided accompanied by a license allowing perpetual use, creation of derivative works, and further distribution, it is definitely not open source.  Users are often the most disappointed in this outcome as it has somewhat of a deceptive feel.
3. The product was released under a valid open source license up to a certain point in its development, but then the copyright holder chooses to evolve the code in a proprietary fashion and only offer new releases under commercial licensing terms.  Most often the open source community which grew up around the original code line falls away once they understand there will be no further commitment from the copyright holder to the open source branch.  While this scenario is understandable from the copyright holder's perspective, it can be seen as "burning a bridge" to the open source community.  It would be very difficult to once again leverage the benefits of the open source contribution models once a project owner had followed this path.
4. By far the most common discovery is that a product has both a community edition and a commercial offering; the latter offering support and the latest features with the community edition lagging behind one or two releases.  This is often encouraging to potential consumers as it gives them a "try before you buy" option or even a chance to influence both versions of the product by becoming an active member of the community.  I usually encourage clients to begin with the community version, get involved and see what they can achieve.  Then if the product becomes a crucial part of their business plan, they have the option to upgrade to the commercial level at any time.

Each of these scenarios can present problems to potential consumers, but with solid information as to licensing lineage there are also opportunities to be found.

 

OSS Governance Policy

Open Source Software governance in the corporate context is the first step to both realizing the many benefits of OSS as well as mitigating any potential risks.  Any good governance process should begin with a corporate policy spelling out the parameters of its applicability and purpose.

• Policy Applicability:  The policy should explicitly indicate who is covered.  For OSS purposes, the most common actors are employees, vendors, outside agents or contractors who use open source software in the performance of their responsibilities on the company's behalf.

• Policy Statement:  The policy should include an affirmative statement of what is permitted subject to any review and approval processes.  At the policy level it is best to avoid laying out specific operational processes as these are often subject to change.  But it is helpful if the policy delineates the parameters and purpose of what expected governance processes will cover.  Examples might include:
• ensuring license compliance
• understanding provenance
• evaluation and mitigation of risk to company intellectual property
• indication of the various stakeholders to participate in review; legal, architecture, security, quality etc.
• establishing an executive owner and providing for waiver discretion

• Business Purpose: Since all corporate policies should exist for the purpose of achieving organizational goals, a good open source policy will describe the nature of the OSS ecosystem and why it is desirable to participate.  This background information will be useful as the policy is interpreted over time as necessary to evolve specific governance processes to meet new challenges and opportunities.

Finally, as a practical matter, I have found it better to address open source consumption policy separately from active participation and contribution to OSS community projects.  Many times an organization will find it beneficial to acclimate itself to the consumption side of the equation first while building confidence through experience.  Active community participation and contribution are a natural progression and often best served by separate policy considerations once the consumption processes are mature and functioning smoothly.

Next up, I will begin addressing ideas for specific OSS governance processes.

Open Source Provenance

It seems like common sense.  In order to analyze potential risks for consuming a particular open source component or application, it is necessary to understand who owns the copyright and under what terms the owner has licensed it to the community.

However, as anyone who has delved into the OSS world knows these questions more often result in muddled answers than crystal clear ones.  Several reasons for the confusion become obvious once you step back and understand the nature of open source software:

• OSS often begins with an individual who was simply trying to solve a particular problem or need and thought others might like to try their solution and perhaps improve upon it.  Such informal circumstances mean not much attention is paid to the OSS license chosen, and of course as is a copyright holder's prerogative, subsequent iterations of the same component are often released under different licenses over time.
• OSS components are often bundled together into derivative works which taken as a whole address some larger problem, business or academic need.  These derivative works are sometimes assigned licenses without regard for terms applicable to the base components or downstream compatibility.
• Communities which manage an OSS project will often have contributors acknowledge a contribution agreement before submitting a new feature or bug fix.  Most agreements I have reviewed contain all the basics one would expect but does the community carefully research the provenance of all the code submitted to ensure license compatibility?
• Automated tools which scan code for license hints or even snippets of previously licensed code through sophisticated text comparison algorithms can often reveal a plethora of resulting "hits" and false positives to weed through.
• It is becoming a common business model for companies to purchase the underlying copyrights for a popular open source project.  This often results in a roadmap where certain versions or features are retained in an open source community edition while the newest capabilities are only provided via traditional proprietary licensing.  And the line between the two is often shifting by design to maximize adoption and exploitation of the intellectual property.

Given all these potential concerns, how best to advise our clients?

How does your organization address such issues?

My approach is outlined next time.

 

Licensing Obligations - Copyleft or Viral Requirements

Copyleft or Viral Requirements:  These requirements are either some of the most onerous in the open source world, or they are the reason open source has flourished.  It is really just a matter of perspective.

At its most basic, copyleft (a play on the word copyright) terms require that a consumer who uses an OSS component to create any manner of derivative work, or perhaps causes such a component to be redistributed to others, or both, to license the entire resulting work product under the terms of the copyleft license at issue.  This attachment of terms and conditions is sometimes why these licenses are referred to as viral in nature.

There are many nuances to these licenses depending on specific use cases and one's interpretation of their obligations.  However, there is agreement among professionals attempting to navigate these waters that it can be tricky at times.

Examples include:

1. GNU GPL - version three found here
2. GNU LGPL - version three found here
3. GNU Affero GPL - version three found here
4. OSL - version three found here

Corporate OSS consumers tend to be wary of these licenses with reciprocal terms because they limit an entity's ability to exploit the code for commercial purposes.  Conversely, those who choose these licenses to protect their intellectual property tend to do so exactly for the same reason, so that the code remains freely available for anyone to use, consistently available under the same licensing scheme without fear that later iterations will be walled off into some unacceptable proprietary licensing framework.

I am firmly convinced these  licenses have their place within the OSS ecosystem.  However, it is imperative that individuals or organizations which contemplate using code subject to their terms fully understand both the freedom of use and reciprocal obligations which accompany the intellectual property in question.


 

Azure IP Advantage includes OSS

I saw this about Microsoft Azure today and was intrigued: 

Microsoft Azure customers now have access to best-in-industry protection against intellectual property (IP) risks in the cloud with Microsoft Azure IP Advantage program. One of the most comprehensive protection programs, it is designed to help customers protect their cloud-based innovations and investments against IP lawsuits and risks. We take seriously our responsibility to help ensure that the cloud is used for good. In partnership with our customers, we are working hard to help create an ecosystem where developers, entrepreneurs, enterprises, and customers can innovate with confidence.

See full information here:  Azure IP Advantage.

For those of you consulting with clients on the benefits and risks of public cloud deployments it appears to be a new development in the industry which should certainly be considered.

Of course this feature is brand new and as far as I am aware untested, but I certainly commend Microsoft for addressing the problem directly. 

I really like the "Springing License" and "Patent Pick" components and am especially impressed that the new policy expressly includes open source code in its indemnity pledge for Azure services. 

See the details in the FAQ and receive a copy of the full terms and conditions from IPAdvant@microsoft.com

I wonder if and when Google and Amazon will respond?

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.

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.

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.

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.

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.

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.