If you developing or using source code licensed under the common form of the GNU general public licence (the GPL, see www.opensource.org), it is clear that there are licensing issues that have to be taken into account when you develop using such code bases. We will deal with these issues in more detail in future articles. However, if you are merely planning to be a user of an open source product, then the use of a product licensed under the GPL cannot destroy others IP rights.
Certainly, the use of open source products can affect others' competitive position. However, that is not a legal matter unless other issues in competition law, fair trading practices, misuse of monopoly provisions, third-line forcing and other anti-competitive trading behaviours are involved.
At the end, this is about licensing software. Licensing is about not only the cost of ownership but also the bargain: what you get for your money and what you may have to give up, such as rights to privacy, in the various types of licences.
What makes this issue important right now is the new developments in digital rights management or DRM.
Digital rights management is about enabling copyright owners to more tightly control licensing of the use of their copyrighted works when distributed electronically. DRM will enable more than just software suppliers to control the use use of their work. The music industry, Hollywood and other content providers see DRM as a major development to avoid the Napster problem.
The deployment over the next few years of DRM-enabled computers has, however, been suggested as being the potential "killer" of open source products.
This suggestion is certainly not based on any law relating to intellectual property.
The threat to open source is based on the possibility that a proprietary software supplier could use the capabilities of a DRM-enabled operating system to ensure that its programs are aware of the nature of another program to effectively prevent the other program operating without a penalty being paid by the user. How this is suggested would work is that the proprietary software vendor could, using DRM, decide that if open source software was "untrustworthy" its software will, when it detect "untrusted" software loading, cause its own product to unload or refuse to load. This would be very inconvenient if, say, you were loading an open source office product and your email client then unloaded or closed because the program was triggered to do so on the open source office product loading.
The next generation of Intel and AMD chips will have such technology built in to the chips.
It has to be recognised that software vendors will be concerned about the impact of open source software on their competitive position. This is not just an argument based on the fact that the open source competitor's product can be obtained for free. For example, a view that has been expressed is that open source software should not be trusted because it is effectively community-owned and if it affects the operation of software there is no one to sue.
DRM will give vendors new capabilities to control, in every aspect, how their software runs on every computer the software ends up being installed on.
DRM will allow vendors go beyond their current licensing practices and restrictions. Existing restrictions, such as prohibiting making backups, prohibiting reverse-engineering the product, setting how many times a package can be installed, granting rights to use user registration data and coming on to premises to do audits, will be able to be supplemented by much finer controls.
Furthermore, DRM will enable those contract terms to be enforced by the computer, tracked and misuse reported electronically and even cause deletions of offending material.
Under our current law, so long as the software vendor did not mislead the customer during sale, the software vendor has the right to determine how its products are used by the licensee. Using DRM in this way would almost certainly be lawful, provided the rights to do these things are embedded in the contracts that are formed by click-through on installation or contracts as amended during an upgrade.
Despite these new DRM capabilities, there are many vendors of proprietary software that do not see the need for them and integrate with open source software.
For example, Compiere (an open source ERP/CRM program) that uses the Oracle database and is licensed under a modified form of the GPL licence, has an agreement with Oracle which provides its compiled, proprietary database product on its usual licence terms at a very favourable rate to licensees of the Compiere application.
At the application level, SAP, IBM, JD Edwards and other major vendors are promoting their Linux ports and clearly do not regard having their software running in open source environments as a threat, commercially or legally, to their own intellectual property rights in their software.
You might be wondering what the fuss is about.
Much of the fuss about GPL focuses on the issue of the requirement that if you modify the source and seek to exploit the your modified version of the source, your code must be released under the GPL.
This is a gross misstatement of the GPL wordings.
The GPL explicitly recognises other software vendors' rights in the licence wording by acknowledging that where the code calls an “independent work” that work does not become part of the core product.
It is only when a developer makes a change or addition to the core product and seeks to release that work, combined with the existing code base, that the developer also must release that work under the particular version of the GPL adopted by the owner of the original product.
This "requirement", such as it is, is key to the concept behind open source.
That concept is that the huge advantage of access to the source developed by others, and available at no expense to users, works as an economic model only if the people who fix bugs, improve modules and the like also feed back their contribution to the community.
In short, community-developed products thrive because of the open efforts of the community. This is the engine of testing and development that results in reliable, constantly improving open source software.
The licence wording of the GPL is clear, though there may be in future issues around determining whether a program is an “independent work”. This will depend on the care with which the developer both constructs their code to be an independent work and how the developer co-ordinates their licence with the GPL. On the latter, again it is just a matter of skilled crafting of the copyright licence to fit in with the terms of the specific form of the general public licence, the GPL adopted in the "parent" product.
So, despite the confusion, open source products that are licensed to users under the GPL are not some new form of intellectual property that has special powers to destroy others' IP rights, but just another form of licensing of the use of copyrights.
Craig Horrocks is a partner in Clendon Feeney’s technology law team.