copyright & licensing

all content © VM (Vicky) Brasseur and licensed under CC BY-SA

📖 Open source relicensing: A risk for your business

4 minute read

This is an excerpt from my upcoming corporate open source strategy book, being published by Pragmatic Bookshelf in 2023. All book excerpt content is early in the development process and therefore unedited; the errors are mine alone (and will be fixed before publishing 😉).

Knowing the links in your software supply chain is critical for operating a successful and sustainable business. Among the many business risks software supply chain awareness helps to mitigate is the unexpected relicensing of FOSS links in that chain.

If you remember from Chapter Two, copyright holders get to say who has permission to do what with their works, and that permission takes the form of a license. Once a license is chosen, a copyright holder may change their mind. It doesn’t happen frequently, but FOSS components can be relicensed. The copyright holder (or, more commonly, holders) can release a version of the software that uses a totally different license. Everyone who uses earlier versions of the software can continue to use it under the terms and conditions of the previous license, but from that new version forward the new license applies to anyone who uses the software.

Relicensing like this isn’t especially common because, frankly, it’s a real pain in the butt for a FOSS project to do. It requires getting the copyright holders to agree that their contributions can be released under the new license, and for some projects that can mean tracking down hundreds or thousands of individuals. However for other projects—especially projects with a primary corporate sponsor or those with a Contributor License Agreement that includes copyright assignment—there typically are considerably fewer copyright holders, making the overall relicensing process much easier.

When a project relicenses, the new license doesn’t necessarily have to be an open source (OSI-approved) one; it could be any license at all (unless that project was licensed under a reciprocal license). A project under a permissive license like MIT could relicense to use GPL-3.0 instead. Recently the OpenSSL project released version 3.0, in which it relicensed from dual OpenSSL and SSLeay licenses to a single Apache-2.0 license (resolving a lot of license compliance headaches in the process). Projects could potentially relicense to a proprietary license, even one with unknown and poorly understood terms and conditions. For instance, in January 2021, Elastic announced that upcoming versions of their very popular Elasticsearch and Kibana projects would be relicensed from the open source Apache-2.0 license to the proprietary Server Side Public License (SSPL-1.0). This caught many companies that relied on Elasticsearch and Kibana off guard, and was generally met with negativity from the FOSS community, but Elastic persisted in its planned license change.

Unfortunately, the latter situation is becoming more common in corporate sponsored open source projects that form the core for companies with an open core business model. Companies operating under this business model give their software away for free under permissive FOSS licenses, and then rely on converting those FOSS users into customers who pay for software support or additional functionality. Many open core companies discover that they are unable to generate revenue with their business model and need to switch to a different one. Often this switch includes relicensing the previously open source software, which the company is able to do with ease if it had neither encouraged nor accepted many contributions from external entities, or if they required contributors to sign a Contributor License Agreement allowing the company to make such changes. Typically the new license restricts what users are able to do with the software (such as launch their own product offering based on it) in order to protect the open core company’s intellectual property and share of the market.

Now, consider a case where your company lacks visibility into its software supply chain, and then a link of that chain—such as Elasticsearch or Kibana—is a FOSS component that changes its license. Remember, use of the component equates to acceptance of its license terms, regardless of whether or not you’re aware you’re using the component. In the world of copyright and licensing, ignorance isn’t a good excuse for non-compliance, only a reason why you haven’t complied yet. There’s no way to tell when a license changes on a FOSS project if your company isn’t aware of what the earlier license was in the first place, let alone what its obligations are under either of the licenses.

Risks to your business:

  • Unknown license obligations. The company is using software but is unaware of the obligations to which it has agreed by doing so.
  • Expensive legal fallout. Lawsuits over infringed copyright or unmet license obligations can be expensive both in time and money. They also can damage your company's brand.
  • Expensive software rearchitecture. Removing and rearchitecting around problematic software components can affect product availability and stability, leading to lower customer satisfaction. It also prevents software developers from using that time to fix other bugs and add new features.

The excerpt content is copyright © 2022 The Pragmatic Programmers, LLC and used with permission. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher.

All other content of the post is Copyright VM Brasseur and licensed under CC BY-SA.