- Two Licenses for Two Philosophies
- How the Licenses Arose
- Effects of Licensing on the Commercial Software World
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Effects of Licensing on the Commercial Software World
The effect of the GPL in the commercial world has been interesting. Some companies, such as MySQL AB, exist by dual-licensing their software. One version is licensed under the GPL, while another is commercially licensed—for a fee, a company can have the restrictions of the GPL removed. A more widespread example, however, is the Linux kernel.
The Linux kernel is one of the most successful pieces of GPL’d software (much to the irritation of the Free Software Foundation, whose own kernel is only now becoming ready for use). A company interested in contributing to the Linux kernel appears to face fewer risks than one contributing to a BSD kernel—their competitors can’t maintain their own private branch and incorporate their contributions.
An example that seems to highlight the open source movement’s beliefs is the KDE project’s KHTML—an HTML rendering library licensed under the LGPL. The LGPL has similar conditions to the GPL, but they apply only to the LGPL’d code itself, not code linked to it. Modifications to KHTML must be LGPL’d; however, a web browser based on it doesn’t have to be so licensed. A few years ago, Apple decided to use KHTML as the rendering library for their own web browser, Safari.
At the start of the project, Apple’s developers were working in secret. Management didn’t want anyone outside the company to know what they were working on before it was announced. When they did release it, they contributed all of their changes at once. The problem with this technique was that Apple had more developers working on their fork (WebCore) than KDE had working on KHTML. The result was that WebCore continued to evolve faster than KHTML.
At this point, it appears as if Apple has almost effectively managed to close the code—updates to KHTML are sent in chunks too big to be used effectively. No one was using Apple’s version, which had several modifications to make it applicable to OS X only. The twist came recently when Apple opened the internal WebCore code base to external developers. Since then, Nokia has started using it, and both companies have benefited. This example highlights the open source perspective—the more people who can contribute to the code, the faster it will improve.
Both licenses are in widespread use, and many people believe that the GPL is superior, citing Linux as an example. In reality, however, both licenses are good at fulfilling their original goals. The GPL is a useful tool for furthering the free software agenda, and the BSD license is a tool for providing code to the widest possible audience. The license of a particular project depends largely on which of these philosophies is more important to the developers. If the free software or open source movement is right, eventually there will be no difference—non-libre software will not be able to compete, and so the issue of incorporating F/OSS into closed software will not arise.