Outsourcing development with the GPLv2 and the GPLv3

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

cfarrell's picture
At the beginning of July this year, we will have had the GPLv3 for two years. At this stage, many of the changes which the GPLv3 brought with it are known, not only to those dealing with FLOSS licenses on a daily basis, but also across the industry as a whole. Quite a lot of the discussion focused on issues such as “Tivo-isation” and the new patent clause – this is obvious from the commentary (and the comment frequency analyser) at http://gplv3.fsf.org/comments/gplv3-draft-4.html as well as from the number of blogs and articles which focused on this issue over the last two years. There is, however, another issue which has been somewhat drowned out by the patent and DRM discussions – that of outsourcing arrangements under the various versions of the GPL.

Outsourcing affects a substantial number of IT firms, given that, under the right circumstances, it can provide substantial cost savings. For firms producing proprietary software, who outsource some or all of software development, the actual process of outsourcing will generally be quite straightforward. A suitable agreement can be put in place which adequately deals with copyright, patent and other issues, meaning that all parties are generally clear about “who owns what”. However, in the case of FLOSS development, the fact that obligations may be outstanding to the FLOSS community complicates the matter. The potential complications arise from the fact that a large proportion of FLOSS software falls into the category of “copyleft” - e.g. the GPL in all versions. One of the freedoms which the GPL seeks to protect is “freedom 3” which is: “The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits” (see http://www.gnu.org/philosophy/free-sw.html ).
One way which the GPL effectively protects this freedom is by insisting that, should you modify GPL software and should you “distribute” your modified version, then such “distribution” must be under the terms of the GPL under which you received your “original” copy. Without going into too much detail, the GPLv2 talks about “distribution”, whereas the GPLv3 distinguishes between “propagation” and “conveying”.

It is quite clear from the GPLv2 and especially from the GPLv3, that it is not the intent of the license to force recipients of GPL software to release their modified versions under the GPL if such modified versions have not been distributed/conveyed. This, for example, enables use of privately modified GPL software as a web/cloud service, or internally. The question naturally arises, when does a transfer of GPL software count as a “distribution” or a “conveyance”? If, for example, modified GPL software is passed around inside a legal entity, could it be said that it counts as a “distribution”? What happens if the transfer takes place between a legal entity and one of its subsidiaries? Finally, what happens when an IT firm transfers GPL software obtained elsewhere (either modified or unmodified) to an outsourcing firm in order for the outsourcing firm to make modifications/additions to the GPL software for the IT firm, and what would be the expected outcome if such a firm then used the software modified by the outsourcing company to provide a cloud application?

The GPLv2 is not particularly verbose about the above issue, referring throughout the license only to “distribution” and stating in Section 0 “Activities other than copying, distribution and modification are not covered by this License; they are outside its scope”. The Free Software Foundation's FAQ on the GPL answers the question “Does the GPL allow me to develop a modified version under a non-disclosure agreement” with the statement “Yes. For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA. You can also release your changes to the client under the GPL, but agree not to release them to anyone else unless the client says ok. In this case, too, no GPL-covered code is being distributed under an NDA, or under any additional restrictions. The GPL would give the client the right to redistribute your version. In this scenario, the client will probably choose not to exercise that right, but does have the right.“ It is therefore evident that the contract between the IT firm and the firm providing the outsourcing work should at least cover the ground highlighted above.

The GPLv3, having been drafted with the concerns of the IT industry with respect to the shortcomings of the GPLv2 in mind, addressed the uncertainties caused by the GPLv2's references to “distribution” by distinguishing between “propagation” and “conveying”, whereby the license expressly states that conveying does not include “[m]ere interaction with a user through a computer network, with no transfer of a copy [...]”. With respect to the outsourcing issue, Section 2 of the GPLv3 states: “You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.” The license therefore goes into more detail on the issue of having “others” perform modifications on a work for your company, or having “others” provide facilities for running those works.

Thus, companies seeking to obtain benefit from outsourcing arrangements should carefully consider the implications of transferring code for which obligations to third parties exist – especially if there are copyleft obligations associated with the code.

Open source, Free, and Proprietary

I am an IT student and I am having some difficulty wrapping my head around, what I suspect, to be a fairly elementary concept. I believe I understand the major differences among open source, free, and proprietary software; what I'm not understanding why does it matter to a company or to the market how software is developed?

In working for a large

In working for a large company myself, I can say that companies worry about lots of things.  Here's a selection:

  • Where the software came from.  Is it secure (not everyone believes that open source is more secure than proprietary) ?
  • Who will support it ?
  • What warranties against the software failing and damaging my business do I get ?
  • What indemnification do I get that use of the software will not infringe others patents ?
  • How do I control the unfettered downloading of software (esp when a company is trying to control the portfolio) ?
  • How will I get my requirements built into software in timescales I want ?
  • Won't GPL-licensed code force me to release code I want to keep back ?

These are typical issues within an organisation learning to cope with open source.  We'll get there, but it will take time 

Steveb