The Olliance Group has announced
the availability of a white paper entitled "Open Source Intellectual
Property and Licensing Compliance: A Survey and Analysis of Industry Best
Practices." The paper is available
for free download
to those willing to fill in a registration form.
The press release includes a recommendation from the president of the Free
Standards Group, and the paper itself includes a foreward by OSDL head
Stuart Cohen. So one might conclude that it would be a relatively
high-clue work on how to interpret and comply with free software licenses.
The sad truth, however, is that it appears to have been thrown together
quickly (it contains a number of grammatical errors, for example), and the
ultimate goals of its authors are unclear at best.
The purpose of the paper seems to be to help companies figure out how to
avoid "open source risk." But that risk is not defined or justified
anywhere in the paper. The closest it gets is toward the end, where we
The best defense against the risk of losing proprietary IP to
certain open source licenses such as the GPL or Mozilla is through
a sound compliance program that minimizes the risk of inadvertent
commingling of open source code and proprietary code.
In other words, we have the same old "the GPL can cause you to lose your
intellectual property" argument. This line has been debunked numerous
times: there is nothing in the GPL which can legally force a company to
loosen its death grip in its valuable IP. The GPL can subject a
non-compliant company to copyright infringement suits, fines, and
injunctions stopping distribution of a product. These are real risks which
should be understood by any company which is considering incorporating
GPL-licensed code into its products. But it is discouraging to see
representatives of the Free Standards Group and OSDL putting their names on
a report that brings back the "lose all your IP" scarecrow.
Oh, there is one other risk mentioned on the same page:
However, open source licenses, unlike proprietary software
licenses, are generally not irrevocable--meaning that a
company that has violated a license term may have its right to use
the software revoked. While we do not know of any case in which
this has happened, it remains a possibility that companies should
be aware of.
In fact, the revocable nature of the GPL came out at the end of the KDE wars, when
Richard Stallman revoked the right of the KDE developers to distribute the
FSF's code, then magnanimously forgave
them their sins:
More precisely, those who as of
September 4, 2000 have used some FSF code in violation of the GPL
solely by linking it with Qt, and thus have forfeited the right to
use that code under the GPL, will once again have full GPL
permissions to use that code upon switching to a GPL-covered
version of Qt.
The real point, however, is that revocability is certainly not a feature
which is unique to free software licenses. Consider the
Windows XP EULA:
6. TERMINATION. Without prejudice to any other rights, Microsoft
may cancel this EULA if you do not abide by the terms and
conditions of this EULA, in which case you must destroy all copies
of the Product and all of its component parts.
Almost any proprietary software license includes a term like this one.
Olliance's claim that such terms are unique to free software licenses is
So what does Olliance recommend be done to address those scary free
software risks? The first step is to perform an audit of every free
application in use in the company. Employees are to be required to
document every program they use, its version numbers, the dates over which
it has been used, the reason why it is used, the manager who approved its
use, and so on. A database is then to be built containing all of that
information. What then is to be done with this database is not entirely
Some other "best practices" include:
- Requiring written approval by an "open source review board" before any
open source application may be used.
- Requiring a separate approval before modifying any free software.
- Getting warranties from suppliers that they use
no open source software, or that any such use is documented and
In the midst of all this is a recommendation which actually makes sense:
Forbidding the modification of open source software or its
inclusion in any product that is distributed, without further
detailed analysis, and executive level management review, for
companies that have significant intellectual property at risk.
OK, so maybe it doesn't make that much sense. The core of this
recommendation is, however: think before you incorporate free software
into your products. One could extend that to "think before you
incorporate any software copyrighted by others into your products," but
that would be asking a lot of the authors of this particular work.
As far as your editor can tell, the goal of this particular white paper is
to stoke fears about open source licensing, and to urge companies to create
a vast, grinding bureaucracy to impede the adoption of free software
internally. Following its recommendations is unlikely to make many
companies safer, but it will increase the apparent costs of using free
software. There is a place for documentation of the real risks of using
code copyrighted by others - both free and proprietary - and on how to
avoid distributing products which violate free software licenses. But this
paper does not fill that role.
to post comments)