In Search of a Common License for Industry Standards: Part II

In a recent post, I examined differences among the licenses of four different consortia. By and large, the licenses under which standards development organizations (SDOs) and consortia offer their work are unique to the particular SDO or consortium. Some are similar, but it is hard to find two independent SDOs or consortia using an identical license (can anyone cite examples otherwise?). This diversity of licenses is increasingly problematic as convergence among standards begins to occur and as enterprises look to apply multiple standards to meet cross-industry requirements.

Open source software ("OSS" or sometimes "FLOSS" - for the Free/Libre/Open Source Software variety) licenses have been the target of much scrutiny and the source of much consternation for those wanting to combine work made available under different licenses. However, compared to the current state of SDO and consortia licenses, a bit of progress has been made in the OSS world in reining-in the unnecessary proliferation of new licenses. The Open Source Initiative has helped in this regard. OSI reviews licenses for consistency with the "open source definition" and publishes a list of approved open source licenses. Restraint on the proliferation of licenses also is provided by project hosting venues such as Google Code, which limits projects to one of nine of open source software licenses and to one of two Creative Commons licenses if a separate license is desired for documentation.

My point is that while OSS licensing still carries with it many complexities, we may be reaching a point where there is more certainty and standardization around OSS licenses than there is among licenses of standards organizations and consortia. In the case of OSS licenses, there is enough of a framework to support logical determinations of which licenses are compatible and incompatible in terms combining software from different sources. Here's a good one-page description of such compatibilities and incompatibilities (see the OSI site for detailed descriptions of the particular licenses).

While it might be over-optimistic to hope for a single common license under which diverse industry standards would be available, there is ample room for improvement. As complex as the field of OSS licensing may be, there are patterns and anti-patterns from which standards organizations and consortia could learn. Because most standards are intended to support commercial as well as non-commercial software, you’d imagine that permissive licenses such as MIT and BSD New would be most instructive and relevant. Such licenses, in addition to being business friendly, also better support standards innovation and localization, which are topics I'll leave for a follow-on post.