Relicensing

 <  Day Day Up  >  

Relicensing

For some of us, the problem of combining software under different licenses into derivative works is a frustration. License incompatibilities prevent software from being freely used and combined. And with the proliferation of open source licenses, the problem is getting worse , not better.

But copyright and contract law is unambiguous: Open source distributors cannot simply relicense other people's copyrighted software unless they have permission to do so.

One way out is to convince contributors to make their works available under a different license. This might be possible for small projects where there are few contributors who need to agree on a licensing strategy. But convincing everyone in a large project to reconsider their licensing is very difficult.

Are projects, by virtue of the licenses under which they received contributions, prevented from relicensing their derivative works to replace licenses they no longer want in favor of different licenses? Can relicensing be done by projects to make their works compatible with other contributor licenses?

There is a legal answer and a political answer and, for this particular question, the political answer is far more significant. Open source must be a collaborative process. Any licensing change that is made by fiat is likely to result in a fracture of the community. A project may be left without some of its key contributors. Customers will face diverging product development strategies by different groups of developers, each competing for attention and support. Entire product lines may die.

Among the difficult options for software projects that won't relicense by consensus to accommodate contributions for derivative works is to avoid making derivative works. This is essentially what the Free Software Foundation suggests in order to live with Apache despite its incompatible license:

We urge you not to use the Apache licenses for software you write. However, there is no reason to avoid running programs that have been released under this license, such as Apache. (http://www.fsf.org/)

By merely aggregating software from different sources and treating such software as black boxes, one can technically avoid ”sometimes with much clumsiness ”creating derivative works. One can benefit from the software without actually having it available for internal modification and improvement.

This is not so different from what happens with proprietary software products. At some point, customers may demand different licensing terms than the licensor will provide. The choice is obvious: Live within the available license, or find different software.

Sometimes, where derivative works are prohibited , people write special plug-ins, drivers, or other complex workarounds to add functionality to programs they can't freely modify. When software vendors are particularly uncooperative with their licensing terms, creative people simply start from scratch and write the software anew under more favorable licenses.

License incompatibilities are inconveniences rather than barriers. Ultimately, one can get around almost all licensing restrictions to almost all intellectual property by being sufficiently creative and inventive .

 <  Day Day Up  >  


Open Source Licensing. Software Freedom and Intellectual Property Law
Open Source Licensing: Software Freedom and Intellectual Property Law
ISBN: 0131487876
EAN: 2147483647
Year: 2004
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net