Copyleft and dual licensing for publicly funded software development

Draft version (1.0): July 2003

(C) Copyright 2003 Rishab Aiyer Ghosh.

MERIT/Institute of Infonomics, University of Maastricht

e-mail: rishab@dxm.org

1.    Introduction

There has been an extensive debate on the correct licensing policies for software developed with the use of public funds. Whether such software should be published under a free software or open source license, and if so, whether it should be a "copyleft" license, is a particular matter of contention. What has often been missing from this over-politicised debate, though, is a clear understanding of the goals and principles behind such policy decisions and a discussion of the outcome of specific license choices in furthering these goals. This discussion paper aims to provide some of this clarity. It also proposes a policy of dual licensing (where one of the licenses is a copyleft license) as a solution that arguably results in an outcome clearly in line with the principles of public funding.

2.    Goals and principles of public funding

This paper does not attempt to suggest what the goals and principles of publicly funded software development should be. It only lists goals distilled from official positions and stated principles of different funding public authorities.

1.       The results (i.e. software) from publicly funded research should be available to the general public, at no additional cost, for use and further development.

2.       The results of publicly funded research should remain accessible in perpetuity to the general public, including further developments made on the basis of such research.

3.       The results of publicly funded research, especially if only partly funded by public authorities, should be available for further commercial exploitation by the bodies that carried out the research and software development.

4.       The results of publicly funded research should be available for further commercial exploitation by third parties (i.e. other than those who carried out the research and software development).

At first glance, there may be conflicts between some of these goals: 1 and 2 may seem difficult to reconcile with 3, and certainly 4 seems likely to conflict with 3 (assuming that commercial exploitation by the publicly funded developer is impaired by third-party commercial exploitation). Indeed, different public authorities tend to place different levels of emphasis on these goals - while in the US the public access aspects of research have tended to be emphasised (goal 1, possibly 2), the EU (especially through the Framework Programmes on R&D funding) has shown a clear preference for goal 3. In general, for R&D that is 100% funded through public authorities, there is often a preference for public interest goals (1 and 2) rather than goal 3. Furthermore, goal 4 is rarely, if ever, made explicit, and a corollary to goal 4 that results (probably unintentionally) from certain licensing policies would even seem antithetical to the principles of public funding:

4a.   The results of publicly funded research should be available for further commercial exploitation by third parties (i.e. other than the funded developer - those who carried out the research and software development) without any monitoring, further conditions or costs imposed by either the funding authorities or the originally funded developer.

3.    Developing a licensing policy

A licensing policy should aim to be:

1.       Uniform, and able to address differing goals and situations without several different policies and licenses

2.       Consistent with the goals and principles chosen - preferably, balancing all the goals so that individual goals dont need to be compromised unless an explicit choice is made to do so

3.       Verifiable and predictable: licensing policy should lead to the pre-set goals being met, and minimise unforeseen consequences.

The following discussion assumes that the public-access goals are gaining precedence in funding authorities, otherwise there would be no question at all about free software/open source licensing, and all publicly funded software could be proprietary. A related assumption is that a form of FS/OS licensing is to be considered. Note that this discussion depends on a clear definition of terms. Italicised terms are defined in Appendix A.

4.    Differences between copyleft and permissive licenses

In the selection of FS/OS licenses there is a broad distinction to be made that is relevant to public funding goals:

"Copyleft" licenses, like all FS/OS licenses, allow users to modify source code and build derived works. The condition is that they may distribute such works only if they make the modified source code available (the work remains FS/OS) and they distribute under the same license as the original code (i.e. users of the derived works have the same rights and obligations). "Copyleft" licenses ensure that once a work is made FS/OS, all derivatives will remain publicly accessible and FS/OS. The prototypical copyleft license is the GNU General Public License (GPL).

"Permissive" licenses do not have the above condition. Users may thus distribute binary-only versions of modified works without providing access to the modified source code, and may appropriate the entire work incorporating it into other proprietary software.

How do these license categories affect the principles outlined in section 2? FS/OS licenses all preserve aim 1, but only copyleft licenses support aim 2 - permissive licenses allow the software product to be appropriated when further developments to the software are made by third party developers and not released back to the general public. This also greatly enhances the copyleft licenses support for aim 1, since community developers are strongly motivated by the knowledge that their voluntary contribution will remain accessible to the general public (and indeed to the contributors themselves) rather than being appropriated by third party developers. Proof of this incentive can be found in the fact that the vast majority of FS/OS projects use the GPL or LGPL, both copyleft licenses.

FS/OS licenses in general weaken support for aim 3 in that the avenues for commercial exploitation are somewhat limited when the source code is distributed to the public - business models need to be based primarily on services and customisation.

However, copyleft licenses to some extent support aim 3 since the publicly funded original developer, as copyright holder, is the only entity not bound by the usage conditions of the license. The original developer is free to further develop the software product without publishing modifications, and to appropriate and exploit such developments commercially (at least according to the copyleft license conditions - whether the funding conditions allow this is another matter).

Permissive licenses very weakly support aim 3 since members of the general public have the same ability to appropriate the software and commercially exploit modified versions. Furthermore, the original developer cannot benefit from the developments and modifications made by third party developers who choose to appropriate the modified software and distribute it without access to the source code.

Aim 4, which is not universally shared by public authorities but is cited as important by certain members of industry, is well supported by permissive licenses. Indeed, permissive licenses also automatically result in supporting aim 4a, which is rarely a stated aim of policy, and arguably not even in the public interest. The support of aim 4 by permissive licenses comes at the cost of hindering aim 3, as noted in the previous paragraph, since third party developers benefit significantly more than the original developer relative to their effort invested in developing the software product.

Copyleft licenses seem prima facie not to support aim 4. Of course, third parties are able to commercially exploit the software product under a copyleft license if they adopt a service- or support-oriented business model, but not if they want to appropriate the software in order to commercially exploit it. As was seen previously, it is precisely by this weak support for aim 4 that copyleft licenses support aim 3, i.e. with copyleft licensing the original developer has an advantage over third party developers when it comes to commercial exploitation of the software, while with permissive licensing this advantage is lost.

As it turns out, copyleft licenses can support aim 4, they just dont automatically support aim 4a. I.e., copyleft licenses can allow third party developers to appropriate and commercially exploit the software, just not without the control of the original developer or public authority. This is achieved through dual licensing, incorporating the strong support of copyleft licenses to aims 1 and 2 with a private license to support aim 4. A summary of the policy impact of different license types is in table 1.

5.    The dual licensing solution

Since a license is a contract (operating in conjunction with copyright law) between the copyright holder(s) and a licensee, a software product can be provided under different licenses to different users. In the proprietary software world, this is standard practise - educational, government, software industry and retail consumers receive software packages not only at different prices but with significantly different licensing conditions.

With publicly funded software, there is no obvious need to distribute it to all users under the same conditions. Different users have different needs, and the contradicting aims of policy may be better served with multiple licenses appropriate to each situation. At least three distinct user groups are clear in the policy aims discussed in section 2. Aims 1 and 2 address the general public. Aim 3 addresses the original developers who received funding from public authorities resulting in the development of the software product. Aim 4 (and 4a) addresses third party developers. It should be clear that the very possibility of recognising these different groups negates aim 4a, which is only supported if third party developers are not distinguished from members of the general public.

As it turns out, the original developers are also the copyright holders and therefore subject not to licensing conditions but perhaps additional conditions related to the use of public funding itself (these conditions may involve the assignment of copyright, turning the original developer into a licensee after all, but that is still a result of funding conditions). So there are two different groups to address with licensing conditions.

The general public is best served by a copyleft license, which best supports aims 1 and 2 (see table 1). The table shows that the group best served by permissive licenses is third party developers, who benefit more from such licensing than the general public or even the original developer.

The table shows a third type of license, the private license, which is a license under which rights to the software product are granted to third party developers, (or indeed, third parties of any sort who have licensing needs different from those of the general public). Unlike copyleft licenses, which dont support aim 4, and permissive licenses, which provide stronger support to aim 4 than to aim 3, a private license can provide support to aim 4 while keeping in mind the relatively high investment made by the original developer in the development of the software product. This can be in terms of requiring fees or royalties from third party licensees to be paid to the original developer (supporting aim 3), to a fund operated by a central agency, cross-licensing or other conditions. Of course, the private license could simply allow third party developers similar rights (to modify and appropriate without payment) as a permissive license, but even in that case it provides the original developer and/or the public authority the advantage of being able to exercise some control over third party development.

The shaded area in table 1 represents the public policy aims achieved by the use of dual licensing. Obviously, in cases where not all policy aims need to be met, different licenses can be used - e.g. where research is fully funded, a simple copyleft (single license) structure may be sufficient. However, if all four aims need to be addressed, dual licensing using a conjunction of a copyleft license and a private license is clearly the FS/OS licensing option most supportive of policy aims.

Table 1: Impact of licensing choice on policy aims

Policy aim for publicly funded software license

Copyleft

Permissive

Private

1. Initial software product available to the general public for use and modification

Strong

Yes

n.a.

2. Further developments available to the general public for use and modification

Strong

No

n.a.

3. Original developer can commercially exploit product

Yes

Weak

Yes

4. Third party developers can commercially exploit product

No

Strong

Yes

4a. Third party developers can commercially exploit product without approval of original developer or public authority

No

Yes

No

6.    Copyright dispersion issues

One specious argument that is sometimes presented against copyleft and dual licensing for publicly funded software is that the copyright of the software product is rapidly dispersed as new community developers add their modifications to the software, and remain the copyright holders for such modifications. If the original software product were distributed under a permissive FS/OS license, the dispersed copyright would be - following this argument - irrelevant. Both the original developer as well as third party developers could appropriate and commercially exploit not only the original software product but also the modifications contributed by community developers.

In fact, under a permissive license it is easily possible for community developers who feel the need for an incentive in order to contribute their modifications to the public to release their modifications under a copyleft license, such as the GPL, in which case the entire software product so long as it incorporates their modifications must be distributed under the terms of the GPL. (Just as a third party developer can under a permissive FS/OS license redistribute the entire software with some modifications under a proprietary license).

Moreover, while the original developer and (less so) third party developers may have some claim to being able to commercially exploit the original publicly funded software product, there is clearly no justification for them to claim a right to commercially exploit contributions made voluntarily by community developers.

Still, for a dual licensing policy to work, it must be clear that only versions of the software product for which the copyright is held by a single agency can, in practical terms, be licensed to third parties under a private license. In many situations where public funding is provided to entire research communities, rather than a single consortium for a single project, it may be a policy goal to encourage a form of community-contributed development over time, yet allow the commercial exploitation of the combined results of the community. What follows is a simple structure based on dual licensing that allows this, using funding conditions rather than licensing conditions to vest copyright within a single copyright holder that can license out the software to third parties under a private license, while licensing the software to the general public under a copyleft license.

In a situation where there are several organisations funded by public authorities, the funding agencies may wish to support policy aim 4 (and to some extent also aim 3) applied to the software product over its entire lifetime, not merely in its original version. This must necessarily follow the principle that while policy aims 3 and 4 can be supported for modifications to the software contributed by publicly funded agencies (funded developers) they cannot be supported for modifications contributed by community developers from the general public who do not receive public funding for software development. While this may lead to versions of the software that cannot be commercially exploited following aim 3 and 4, the alternative is simply not to have community contributions at all.

Following this principle, a structure can be developed whereby there is a central agency that is always the copyright holder for the entire software product (with the exception of derived works by community developers - though it may be possible to buy or otherwise acquire copyrights from such developers voluntarily). As the copyright holder, the central agency is also the licensor. It distributes the software product - original as well as subsequent versions and derived works - under a dual licensing scheme. The software is distributed under a copyleft license to the general public, including other publicly funded agencies, which could potentially contribute voluntarily to the future development of the software. It is distributed under a private license to third party developers (possibly including agencies that receive public funds, such as the original developer).

When a contribution to the software, after its release, is made by an agency receiving public funding that falls under this scheme, that agency is in effect a funded developer. Although the funded developer is a copyleft licensee of the software, and the modification is made under the rights granted by the copyleft license, the funded developer differs from a community developer from the general public in receiving public funds. Funding conditions, therefore, can require what FS/OS licensing conditions do not - the transfer of copyright over contributions to the central agency. It is important to note that this copyright transfer is a result of funding conditions to the funded developer, and does not require a special license. A special license would probably not be FS/OS, let alone copyleft, and would strongly discourage the involvement of members of the general public in further development and use of the software product.

This structure results in the copyright over all contributions and modifications to the software from entities that receive public funds being vested in a single copyright holder, the central agency. This copyright holder could continue to license out the publicly funded software to third party developers for appropriation and commercial exploitation, and distribute any fees or royalties received back to the public funding system (or indeed, to the funded developers that have contributed to improvements to the software). This central agency would not be able to license out versions of the software based on contributions from community developers from the (unfunded) general public. However, since the software is distributed to the general public as well as funded developers under a unified copyleft license, everyone - the general public, the research community and all the funded developers, as well as the original developer and even third party developers - would be able to use, modify and otherwise benefit from, though not commercially exploit, such contributions. Figure 1 is a graphical representation of this structure.

It should be obvious that the central agency may be different for different software products, there could possibly be a single agency for any specific funding programme, or around specific R&D themes.

Figure 1: Graphical representation of copyright and licensing changes in the evolution of a software product

Time and version changes ----->

Original work

   
 

Contribution from funded developer

 
   

Contribution from unfunded community developer

Key (each cell represents a component or modification of the software):

 

Copyright for this component of the software is held by the central agency, this component can be licensed to third parties for commercial exploitation

 

Copyright vests with unfunded community developer from the general public, this component cannot be licensed to third parties for commercial development but is still available for integrated use and further development by all community and funded developers.

7.    Conclusion

This document has outlined the often conflicting policy aims implicit in the debate on FS/OS licensing for software that results from publicly funded research. It argues that a choice of license type must be based on the impact on these policy aims, so that an informed licensing choice can be made based on the relative importance given to each policy aim. This paper argues that the best coverage of policy aims is served by the distribution of publicly funded software under a copyleft license such as the GPL for the general public, and if required, a second license for selected third party developers for commercial exploitation. Finally, the paper presents a structure for the uniform copyright holding of publicly funded software in order to ensure that dual licensing is a practical possibility. This structure is based not on licensing conditions, but on funding conditions, to ensure that the benefits of copyleft licenses for the general public and scientific community - as opposed to third party developers -  is not lost.

8.    Appendix A: Definitions

Software product: a specific software product resulting from research, development or other activity funded by a public authority.

Original developer: the entity, possibly commercial and possibly a consortium, which originally developed the software product using funds from the public authority. The original developer is usually the copyright holder for the entire work as initially released to the public.

Copyright holder: the entity holding a copyright over the software. While a single entity (the original developer, or another central agency appointed by the public authority, or the public authority itself) is usually the copyright holder for the entire work in its initial version, under copyright law and FS/OS licenses, community developers retain the copyright to their individual modifications to the published work. However, they may assign their copyright to, say, a central agency voluntarily, possibly as a condition for funding from the public authority.

Central agency: an agency nominated by the public authority to be the copyright holder for the software product. Such an agency would be aim to acquire the copyright for all modifications to the software product by community developers, especially funded developers, in order to have a single copyright holder for the entire software product as it develops. Copyright law and FS/OS licenses imply that there may always be versions of the software product that incorporate modifications for which the copyright remains with community developers who may not wish to transfer their rights to a central agency.

Public authority: the taxpayer-funded agency or agencies that fund in whole or in part research leading to the development of software.

Community developer: a member of the general public, individual or corporate, who contributes to the software product under the terms of an FS/OS license. If it is a copyleft license, the community developer cannot appropriate the modified software and must make the source code available upon distribution of the binary version.

Funded developer: a community developer who receives funds from a public authority. These funds may be conditional, requiring the assignment of copyright on modifications made to the software product to a central agency. This copyright assignment would be a condition of funding, not a condition of the FS/OS license under which the software product is used.

Third party developer: an individual or corporate entity wishing to modify and appropriate the software product - i.e. build and distribute a derived work without providing recipients of the derived work the ability to view and modify the source code. Third party developers cannot do this under a copyleft license. However, they may be able to do this if the software is released under a permissive FS/OS license, or under a dual licensing system depending on the conditions of the private license.

Dual licensing: the software product is simultaneously published under two licenses - the public license (an FS/OS license, typically a copyleft license) and the private license.

Private license: a license, typically not FS/OS, that allows the licensee several rights to the software product, possibly including the right to modify and distribute it without publishing the modifications, and to sell it without providing access to the source code. This license may require fees or royalty payments to the copyright holder.

(to) Appropriate: to derive exclusive benefits from the modification and distribution of the software product that are not available to the general public or to community developers. Such exclusive benefits include being able to commercially exploit the software product by selling it without making the source code available. Unlike permissive licenses, copyleft licenses do not allow licensees to appropriate the software product, though the original developer may do so. Private licenses may allow licensees to appropriate the software product, but may also provide the copyright holder with financial or other returns.