Network Computingwww.networkcomputing.com

At one time, developers had to worry only about software dependencies and incompatibilities. Now they need to worry about license incompatibilities among open-source projects. For example, Mozilla includes four different licenses. Contributing to this project requires attention to license conflicts.

In fact, borrowing code among open-source projects can quickly become a legal quagmire. Galeon, a Mozilla-based browser, was developed with the GTK+ graphics toolkit distributed under the GPL. Dispensing it caused licensing conflicts between modules protected under the MPL and the GPL. Also, Transarc (an IBM unit) developed a variant of its distributed network file system for Linux using the IPL. Unfortunately, the IPL is incompatible with the GPL, thus preventing its operation on the Linux kernel. Perhaps the OSI should concentrate on licensing conflicts rather than seal-of-approval programs.

Public-License Features Click here to enlarge

Open-source projects enlist the voluntary association of programmers. If a certain project is not following the direction that these programmers believe it should, they are free to leave and begin their own projects.

Forking is not necessarily a bad thing in any market as it increases options and promotes individual choice. At some point, however, the number of choices dilutes the market and its resources to support the mutant versions. BSD is a classic example.

BSD is a strong, mature operating system for the enterprise. Forking, however, has relegated it to supporting niche markets. Wind River Systems' BSD OS lends itself as an Internet server and may also become important in embedded systems, while the free NetBSD focuses on portability. BSD variations reduce the available support network and leave open the possibility that a selected version may fork and leave an enterprise without a mechanism to incorporate new technology if it doesn't have in-house Unix developers.

Forking is not unique to permissive licenses, such as BSD. Open-source software with more restrictive licenses, like the GPL, can also fork. Linus Torvalds' Linux kernel can fork if developers become dissatisfied with the direction. Developers can devise patches, compile them with the kernel and distribute the derivative work as a Linux variant with source code protected by the GPL. Or developers can create separate modules and keep them proprietary. To this end, the GNU Project provides the Library General Public License (LGPL), or Lesser GPL.

The LGPL's aim is to let proprietary software make calls to LGPL-protected software. Under the LGPL, proprietary code can be used with LGPL code, but it can't be compiled with GPL code or statically linked. It can, however, be dynamically linked to GPL code to make calls to the API. This, unfortunately, relies on the vague distinction between static and dynamic linking, and newer technologies introduce ambiguity. For example, CORBA (Common Object Request Broker Architecture) brings software components together without compiling them.

Open-source licenses must account for vagueness and ambiguity in developing and running proprietary software with open source. Otherwise, enterprise developers would not risk commingling their proprietary code with open source, thus defeating the open-source community's drive to make open-source code the dominant developer's kit.

The more open software is used and modified by a growing community of users, the greater the risk that someone's patent rights will be violated. Many open-source proponents favor a "poison pill" provision whereby if you bring a patent action against a copyright holder, you lose your license rights. Although this defends against those within the open-source community, it is open to challenges outside the community. And in a world where corporate developers trade patent rights over the negotiating table, the open-source community often works in the dark. Although patenting open-source software for the community's use adds to the costs, it reduces the chance of an outside patent claim.

All open-source licenses concentrate on distribution or publication of software -- not on performance. It is difficult to define performance where there are minimal differences between code and data. Would changing an Apache configuration file or PERL script constitute performance?

Although the community is split on whether performance rights need to be addressed, technical advances are pushing the envelope. For example, client/server technology lets you exploit code without disturbing it. Software can be invoked from a Web server using a CGI interface. The interface is not distributed but can be used without any legal obligation to contribute.

Detailing performance rights is difficult and may create more problems than it's worth. For software, performance means "usage without distribution." In effect, a performance license becomes an end-user contract between parties and is often implemented with "click to agree." Whether these mechanisms provide the sufficient offer and acceptance elements to form a contract remains to be seen. Also unclear is whether open-source licenses can pass muster in court.

Is it Legal?

Open-source licenses rely on copyright law, which is enforceable by the holder. Although the copyright law provides a solid foundation for copyright owners, transferring those rights to other parties under license often becomes a matter for courts under state commercial laws and perhaps UCITA (Uniform Commercial Information Transactions Act).

Individual licenses negotiated at arm's length between parties often include the requisite offer and acceptance to form a contract. Licenses that are mass-produced for the open-source community, however, may not fare well under state commercial codes. For example, the GPL grants a direct license from the copyright holder to each developer or user with each software transfer. As software passes through the hands of users, offer and acceptance becomes diluted, and courts may find this unenforceable. Also, any license amended by one party without agreement on the terms of sale by the other party amounts to a nonbinding "shrink-wrap" license.

Open-source licensing benefits from a strong community of developers who are more committed to writing good code than to litigation. Vituperation from the community against open-source offenders is enough to bring most license challenges to a halt. This benefit, however, is also a burden where the courts have not been able to interpret the licenses. This may change as more and more enterprises become involved with open-source development.