Von: Dr. Catharina Maracke
Questions about the connotation of EXPORT_SYMBOL_GPL() and especially its legal effectiveness, if any, came up again when Nvidia’s Robert Morell suggested the removal of the GPL label and change of the function back to the original EXPORT_SYMBOL() for a Linux kernel driver interface.
The actual debate has a somewhat long and complex history. The underlying question is whether proprietary drivers can use interfaces designed for kernel drivers. This has been an issue of controversy for several years and eventually caused some kernel developers to start using the EXPORT_SYMBOL_GPL() rather than EXPORT_SYMBOL() function to export driver interfaces in any new code they have developed. Renaming the function and adding the GPL label was supposed to make clear that only code, which is released under the kernel license, e.g. GPL v2 or compatible, can use these interfaces.
Since then, the exact impact and legal consequences of the GPL label to be used in the respective export functions have been highly controversial. Most importantly, it is questionable whether using the EXPORT_SYMBOL_GPL() directive would effectively implicate changes in the license or whether it would simply help to solve evidentiary problems. While Linus Torvalds was reported as saying that using the GPL label makes “an absolutely _huge_ difference” because “intent matters a LOT”, the situation is not as clear as he may hope for.
Nvidia’s recent proposal to remove the GPL label from the EXPORT_SYMBOL_GPL() directive covering the DMA buffer sharing mechanism (dma-buf) interface has once again raised the debate and caused a couple of interesting comments, including the suggestion that all copyright holders for the DMA sharing mechanism would have to approve the change. Consent of all copyright holders would indeed be advisable, if not required, but only if the EXPORT_SYMBOL_GPL() were considered to be a license restriction itself. Only if the GPL label can be seen to be part of the license, removing it would mean to change the license and in turn require approval by all copyright holders. However, interpreting the EXPORT_SYMBOL_GPL() as a license restriction raises a number of concerns. Firstly, it may impose a conflict with the wording of the GPL, which bans any further restrictions, and secondly, not all copyright holders have approved the GPL label in the first place, which – altogether - will make it quite difficult to consider the GPL label as a legally binding provision.
Consequently, it seems more appropriate to argue that the GPL marker does not provide a license restriction itself, but qualifies as a technical access control mechanism, which can be better described as a digital rights management system (DRM). Whether the removal of such a DRM can have legal consequences under the respective copyright depends on different regulations in various jurisdictions and shall be subject of a separate analysis. But the general approach of reading the EXPORT_SYMBOL_GPL() as a technical rather than a legal mechanism still leads to another delicate question: If modifications in the code are legally permissible according to the underlying license (GPL v2 or compatible) would such modifications qualify as a derivative work according to the license and therefore be subject of the copyleft provision of sec. 2b) GPL?
While there is no clear answer to be taken from the wording of the GPL, solutions must be found in the context of each individual case. Strong arguments in favor of considering software as a work derived from a program can be made if that particular software has been developed as an integral component of the respective program. In other words, if there is a technical connection between the kernel module and the kernel that has been implied from the very first beginning and would make the module some kind of integral component of the kernel, the module is most likely to be seen as a derivative work according the license terms. On the other hand, if the module can operate/run independently and simply communicates with kernel functions through separate interfaces, it will more likely be considered an independent work and not immediately qualify as a derivative work. The latter is especially true for modules developed before the Linux kernel itself as they were originally written for another operating system and thus cannot be derived form the kernel in the first place.
At first glance, Nvidia’s DMA sharing infrastructure seems to be an independent platform as it allows multiple drivers to share a DMA buffer (which can play a significant role for graphic drivers as images will be processed and passed to graphics core with minimum overhead, which in turn can save storage and battery particularly on mobile devices) and therefore gives the impression that it can run independently from the kernel. However, integration and merger into Linux indicate a strong connection to the kernel and suggest solid arguments to consider this module as being integrated instead being of functionally independent. As in many similar cases, there is still room for interpretation and different view points, so that further analysis is awaited with interest and so is the outcome of the EXPORT_SYMBOL_GPL() discussion and especially potential consequences should the change effectively be merged into the Linux kernel.
Even though the recent dispute around the GPL marker is specifically linked to the Linux community and any related governance model should not be expected to apply for other free and open source software projects, the current discussion still raises a number of interesting issues, which are worthwhile to be brought up in this context.
First and foremost, there remains the overarching question about what kind of changes in any piece of collaborative software projects can be made without additional approval from all copyright holders. Changing a project’s direction and potentially changing the outbound licensing model is one of the emerging questions for open source projects. Strategies and business plans can change - and can easily imply consequences for licensing priorities. But what exactly is needed for such changes?
With the growth of open source software projects from the start-up mode to mainstream recognition, those questions are getting more attention. One possible way of addressing them is to consider the usage of contributor agreements. Contributor agreements, to describe them briefly, are agreements between an open source project and contributors to the project that set out what the project can do with the copyright of the contribution: Code, translation, documentation, artwork, etc. The purpose of such agreements is to make the terms, under which contributions are made, explicit and thereby protect the project, the users of the project’s code or content, and often also the contributors themselves. To put it in a nutshell, contributor agreements prevent as far as possible any future legal issues regarding the individual contributions, such as disputes over origin or ownership of respective rights. By using a contributor agreement, any potential debate over which developers would have to consent on which changes, as just described in the EXPORT_SYMBOL_GPL() dispute, can be simplified if not avoided.
In addition, contributor agreements also simplify the process of collaboration with other projects and partners: Since such agreements define ownership of copyright and describe clearly what rights are transferred and what license is granted, they can avoid complications regarding future rights management, collaboration and transactions.
While there are many arguments in favor and against contributor agreements, an increasing number of projects and even established product and service companies, such as Google, can be found to make use of such agreements. There is also an effort underway to work towards a standardized language for copyright contribution terms in order to reduce friction and transaction costs when having to negotiate various different agreements required by different projects. The idea is similar to the concept of standardized “outbound” copyright licenses, such as Creative Commons licenses: Providing a simple way for everyone to clarify which contribution has been added under which conditions to a common project, independently from being associated with open source software or related content.
Whether or not this project can indeed contribute to reduce friction in the use and reuse of open source software and whether it will be able to answer some of the copyright questions involved in drafting standardized terms for contributor agreements remains to be seen but is definitely worthwhile to keep an eye on it.