The decision to use OSS in a commercial product may be compelling from the development process perspective but how does it look as a business proposition?
Once the OSS finds its way into your commercial software or hardware, and, once the product is placed into the supply chain various contractual obligations and consequences may be triggered. Besides, each of your customers might have a different expectation and request when it comes to the use of OSS in a product the customer purchases from you. And, maybe you also have certain standards you wish your suppliers to maintain when it comes to OSS?
As an OSS aficionado, you might be thinking “Yes of course, I know about the risks of OSS and how to manage them. So, I am good!” But remember, those risks may change, morph and multiply over time, depending on the particular circumstances you are facing.
Alternatively, you might be wondering ”Where is the catch? I thought open source meant free for all to use, much like public domain.” Well, there’s the catch right there. Open source and public domain are often regarded as synonymous but they are actually quite different animals. Sometimes, it’s not so easy to distinguish between them. Besides, depending on what type of OSS you decide to use and the application it is used for will determine your risk exposure and in terms of choosing the right action.
Curious about what these obligations may be and for whom, why and how they arise in the world of goods and services?
We invite you to continue reading regardless of which camp you are in, i.e. whether you are on the supplier or customer side.
As a rule, software code is considered to be copyrightable. In the case of public domain software, the author has relinquished all claims to copyright. Not so the author of OSS. When offering OSS code or component for use to the market the code creator aka copyright holder typically grants a permission (license) under said copyright. Usually this permission comes free of charge and is considerably more ‘free-range’ than a proprietary software license.
Nevertheless, the permission is conditioned upon certain terms and conditions (licensing requirements) that attach to and are triggered by any subsequent redistribution of the underlying OSS code, whether as part of a software build into a product you build out or as part of a supply chain that culminates in the release of a software driven device or system. Those licensing terms not only include the right to use the OSS code in a commercial product but they may also trigger certain mandatory obligations for you as commercial software supplier, i.e. a person putting the OSS into a particular chain of supply.
End of story?
Not quite. The OSS licensing obligations do not only apply to you as the supplier who first distributes the respective OSS code (by e.g. selling your product to a customer) but those obligations also “impact” (attach to) your customer who pays for or otherwise your product and who either incorporates it (including the underlying OSS component!) into its larger commercial offering or who simply resells it. In such a case, what is it you would want to communicate to your customer? Would you disclose anything about the OSS code or components? If so, what information would your OSS disclosure contain? Would you even consider disclosing anything about the OSS?
One part of above string of questions is relatively straightforward: you are going to want to pass on the information which you are obliged to pass on, as per the OSS license that applies to the OSS component(s) or code you have used to develop and/or incorporated with your deliverable to your customer. If you are merely passing through to your customer the identical OSS package you procured, the due diligence may end there. Unfortunately, it rarely does.
Typically, the imported OSS code or component will have undergone some degree of transformation in your “shop” – reworking, refinement, possibly for performance but often just for interoperability; then potentially combination with other software components or packaging with other software programs. All of this affects the nature and extent of the obligations and the nature and extent of what may need to be disclosed. What if there are various OSS licenses applying to your deliverable?
Can you reliably tell how much OSS code or components are included in your deliverable and, if so, what specific OSS licenses apply (and as such what kind of different terms and conditions apply to your deliverable) when some or all of these components have been combined? Are you sure these OSS components can be combined “legally”, i.e. is this possible under the terms of all the respective OSS licenses that might apply to your deliverable?
What about a ‘copyleft’ effect? Is there a larger component of your own proprietary code (and which is part of your commercial deliverable) that might need to be ‘open sourced’ due to a mandatory requirement to disclose the source code of your commercial product, in order to comply with the underlying OSS license(s) that apply to your deliverable?
Now, what if in the above example you are the customer who is procuring said software product (including incorporated OSS) for the purpose of re-distributing such to the market? What information would you wish/request to receive from your supplier regarding OSS? How would you go about managing risks associated with the use of a e.g. procured software product or component comprising or containing OSS to be integrated in one or more of your proprietary product(s), or which you wish to resell? Do you have the correct internal strategies, processes, tools, documentation, knowledge and analytical skills in place to address all potential OSS risks?
Be aware that the scope of your internal measures to address these questions and manage relevant OSS risk will strongly vary depending on what side of the table you are on. However, what both teams (the supplier side and the customer side) have in common is the need to be pro-active in establishing internal measures for identifying both upstream and downstream risks and manage such appropriately.
The key to create a minimum risk scenario, or even better a win-win-win scenario for all parties involved (i.e. the supplier, the customer as well as the OSS license holder) is to have a robust OSS management infrastructure in place before:
– the actual contract for sale of commercial products or license of a software component or package is signed (Supplier side);
-procuring or licensing (directly or indirectly) 3rd party software which will be incorporated into a commercial product or resold (Customer side).
Whilst most of the OSS related risks may to some extent be reduced through well drafted supply, procurement or licensing agreements, even the most diligently negotiated contract will likely offer inadequate protection for your company.
Why? Because OSS is a unique animal with unique requirements and contractual compromises without a thorough understanding of the facts (based on full and frank disclosure) will always give rise to vulnerability for one or other of the parties and often both.
Rather than assuming that “having a great contract or sound relationship with my supplier/customer will protect my company from OSS risks”, a holistic and multi-level approach is to be strongly recommended. Such approach should take into account the entire process of product development (including customer-driven requirements), supply chain integrity as well as end product deployment (including channels to market, systems integration considerations, maintenance requirements and other lifespan issues).
Accordingly, be inspired and emboldened to ask the right questions (both internally and externally) and assess what can be done in your specific case to create a robust inter-company OSS management program, including your individual OSS strategy including also how to create or improve internal policies and processes to address the variety of specific OSS use cases and related challenges for your company operations or when introducing OSS into your commercial products or services offerings.
Consider carefully why such an OSS management program is needed and how to best support your specific company needs. This is key for not only reducing OSS related risks and maintaining healthy and reliable business relationships with your business and collaboration partners but also to gain the greatest possible benefits from engaging with OSS on a business and commercial level.
We conclude this article with the following core message:
Understanding the impact of OSS use in the round, the importance of developing a company wide and offering specific OSS management expertise should be identified by your company as “must-have requirements” for successfully addressing your company’s engagement with OSS in the overall supply chain, both as a supplier and as a customer, and in terms of your own business gain.
Be prepared and leave nothing to chance!
Your mOSS team
.
:
