When we think about the implications of non-compliance with F/OSS licensing the considerations tend to be around legal exposure and concern that the conditions of a reciprocal license, e.g. the GPL, may propagate into proprietary code. When risk is assessed it is usually in terms of the possibility of litigation and the associated costs, and/or the weakening of business models that are based upon exercising exclusive rights in connection with associated proprietary IP.
However, a lot of damage can be done without a case ever going to court and without any ruling that you must open up your proprietary technology and provide it for use by all via a liberal licence. Firstly, even if you are not subject to litigation there is always the risk of brand damage. Secondly, a healthy relationship with the communities that produce the software your business depends upon will become increasingly important in the future. Companies are beginning to appreciate that to unlock the real potential in F/OSS you have to participate -- we are moving to a hybrid creator/consumer world and innovation is no longer the reserve of vendors. And you want to really lower your costs? You can, if you are prepared to get your hands a little dirty and assume some level of risk. But guess what, you'll need to be part of the community and not on the periphery.
Just this week a third concern in connection with licence violation came to my attention: damage to the health or possible death of a community you depend upon. For example, the creator of the AKRip32 CD digital audio extraction library has ceased development due to alleged violations of its licence, the LGPL:
"All current development of AKRip has been discontinued due to increasing amounts of license violations. This library is my work, and it is copyrighted. The library may be used in commercial applications, but in all cases under the terms of the LGPL. Specifically:
- A copy of the license (LGPL) must be prominently included
- The source code to the library must be included, or at least a link where it can be downloaded
- Derivative works and modified versions must be so marked, and my copyright notice must remain on the source code
It is not permissible to take the code, recompile it, change the name of the resulting DLL and remove my copyright notices."
This to my mind is the worst possible outcome from licence violation, as absolutely everybody loses. The project becomes orphaned - no longer maintained, and downstream consumers need to do one of: 1) take on maintenance of the code (at what cost?), 2) re-engineer their technology to make it use something else (at what cost?) or 3) stick to the last release and pray they never have a problem with it, or that it requires updating due to a security advisory or change in an upstream dependency (at what risk?)
So, next time you are assessing the risks associated with licence violation, take care to ensure that you consider that the ramifications may extend way beyond simply legal exposure.
"take care to ensure that you consider that the ramifications"
I find your analysis extremely intersting, especially related to the orphan project:
"The project becomes orphaned - no longer maintained, and downstream consumers need to do one of:"
There are also other reasons for which a project could become orphaned, not all of them related to licensing issues. It could also be the lack of time, interest, job of the original maintainer (in case of small or single dev projects, which represent a big part of the F/OSS world).
I tend to consider that path as the best option. Of course there is cost associated to entering in a project and maintaining it, but it should be seen as an investment, not a cost ! And the benefits in term of adaptation of the code to your needs as a company outperforms in return that investment. Excellent ROI.
This is of course a good possibility, especially if you rely on ISO stds, RFCs, de facto stds, it's much easier to change a brick by another. However, it won't give you at the end of that investment the same control on the resulting brick, and so the story can start again later on. The ROI of less value IMO.
In our ever chagning SW world, how could company rely on that option ? Even very stable bricks need to be maintained as HW platofrm have a shorter life cycle, OS release as well (all in all 7 years is the maximum you can get, and generally it would be more reasonable to have a 3 years life cycle). So going that way is for me buying problems mid-term, and having poor control on what will hapen in your ecosystem. The worst ROI.
I like that part of you conclusion:
"take care to ensure that you consider that the ramifications"
as it's in total contradiction IMO to the short term quaterly management approach that is seen too many times whan decisions needs to be taken. Product development, and sw dev, and Open Source sw dev needs to be done in a long term perspective, so the points you underlined.
--
Linux Profession Lead EMEA & Open Source Evangelist
http://opensource.hp.com - http://hyper-linux.org
We agree!
Hi Bruno,
"There are also other reasons for which a project could become orphaned, not all of them related to licensing issues."
Agreed, but I'm not sure that folks would generally consider this a possible outcome of licence violation and so I thought it something worth raising.
I also agree that participation in a project should be seen as an investment and not simply a cost. However, if due to a project becoming orphaned you end up with no option but to take it on as a whole, this will cost you more and provide diminishing return compared with if you had chosen to participate whilst it still had a community/developer. And in fact the possibly of projects becoming orphaned (however slim) should also serve as motivation for participation, as the last thing you want to have to do at the point a project becomes orphaned is panic and rush to get familiar with the code. Think of it as insurance -- a small investment now will help mitigate risks further down the line. I've heard of horror stories with regards code escrow, and how once a customer gets access to the proprietary code of a failed vendor it is of little use as they have no familiarity with it. There is no excuse with F/OSS, and I think that all too often people focus too much on savings related to software licensing, and as such miss out on a great many other benefits and of those some of which are much more significant that licensing costs.
I wouldn't consider 'option 3' viable, either. However, I've also heard plenty of horror stories when it comes the use of unmaintanable code in critical platforms, e.g. 15 - 20 year old applications to which the source code has been lost. So, nothing would surprise me when it comes to what some may consider a viable approach to support & maintenance, i.e. none!
In your closing remarks I think you have hit the nail on the head: a long term view is required in the approach taken with F/OSS. Or any software for that matter. All too often people find it difficult to see past opportunities to reduce software licensing costs, and then in their minds this benefit can be mitigated once they discover that they must implement proper governance and cease to be simply an enterprise, but to also become a considerate and appropriately acting member of a global software development community. The more significant benefits such as reduced lock-in and resultant lower switching costs, the wealth of community benefits such as shared best practice, access to core developers and opportunities to recruit etc, and lower integration costs and shared maintenance liability all provide a return over the mid-long term. Impacting the health of development communities and risking damage to their reputation amongst them will ill-serve enterprises in the long run.