Contributor agreements

[Rich Steele]

Hi Folks,

Apologies in advance for the long post.

At this week's meeting of the OSGeo Incubation Committee (http://wiki.osgeo.org/index.php/IncCom_Meeting2), it was decided after a brief discussion on IRC that IncCom would recommend to the Board that a contributor license agreement is not *required* for all OSGeo projects, but that individual projects could still mandate it in the PSC's discretion.  Eric Raymond (ESR) participated in the meeting and made several impassioned arguments against the proposed CLA requirement.  He offered to draft a proposed "position statement" for OSGeo against CLAs and IP review that reflects his thoughts.  With his permission, I have appended his draft statement below.

In the spirit of open debate I thought I would post some thoughts in response to ESR's statement and try to articulate why the MapGuide Open Source project will continue to require a Contributor License Agreement from each contributor.  

I continue to believe that many business users of (and developers on) MapGuide Open Source (Autodesk included) will want comfort that an IP process is in place to ensure at least two things:  First, that the foundation has been granted sufficient rights from developers to their contributions to the code base and, second, that reasonable due diligence has been conducted on code contributions to ensure that the developers of such code have sufficient right to grant the license to the foundation.  Let's address each of these, and then turn to ESR's specific points.

1.  License from committer to foundation.  

Since OSGeo does not hold the copyright to the code that is included within foundation projects, it cannot copy, modify or distribute the code absent a license from the developers (copyright holders have the exclusive right under the copyright act to do these things).  The CLA is the proposed mechanism for making that happen.  It grants a license to the foundation under the developer's IP rights to permit OSGeo to copy, modify and distribute the contributed code.  

Some have argued that a separate contributor agreement is not necessary, and that an easy way to ensure that the foundation has rights to the contributed code is to simply accept the code under the applicable open source license.  To effect this, a committer would include a licensing statement in each source file (i.e., a header saying "this software is licensed under the GPL" and referencing the license).  See, e.g., http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:2241:200008:mjagaiijfhdmomhabjpc

There are two issues with this, one practical and one legal.  First, can we be assured that every developer will include a proper legal statement in each source file?  Is it easier to track compliance with this requirement each and every time a change is committed, or is it easier to simply have the developer sign a contributor agreement *once* as a condition to becoming a project contributor?

Second, the proposed CLA also grants an express patent license to OSGeo, which none of the licenses under which current foundation projects are offered do (Neither the GPL, LGPL or the MIT license contains an express patent license).  While some may argue that there is little risk that a project contributor would assert patent rights in the project code, several people have already asked Autodesk to clarify its grant of patent rights vis-à-vis MapGuide Open Source.  It stands to reason that if one contributor agrees to grant a patent license in connection with its contributions, all other contributors to the project should do so as well.

2.  Due diligence of contributions.

I think it is important (and the Chicago discussion seemed in accord) that there be a process whereby committers to the open source project undertake some reasonable due diligence with respect to code contributions to check against obvious defects in provenance, license conflicts or other IP issues.  An important part of this process is educating contributors regarding the IP issues, and obtaining an affirmative declaration (under a CLA, for example) that the code they are contributing is theirs and theirs alone, or, if not, that they identify third party code in their submissions.  Thus, the CLA doesn't represent the entire due diligence process, but is an important part.

The amount of due diligence performed can (and does) vary from project to project.  For example, Eclipse has an extremely robust IP policy and due diligence process.  Apache is not quite as detailed in their requirements, but still requires a number of steps before code can be accepted.  Compare:
http://www.eclipse.org/legal/committerguidelines.php
http://incubator.apache.org/ip-clearance/
Indeed, a huge part of the Apache or Eclipse "brand" is the perception (reinforced by their legal policies) that the IP offered by these organizations is clean.

It is therefore no surprise that beginning in 2004, contributors to the Linux kernel were asked to sign off on code contributions under a "Developer's Certificate of Origin" as a condition to having their code accepted.  (http://www.linuxinsider.com/story/33996.html)  Eben Moglen of the FSF called the move "an important step that's appropriate in a mature software development system."

ESR has labeled this process a "voodoo dance" and derides its effectiveness.  I will concede that no single process can hope to avert all IP challenges.  I will also concede that at some point the addition of process will reach a point of diminishing returns and stifle and/or kill collaborative development of the code.  However, I believe that having reasonable due diligence procedures for new contributions (including obtaining CLAs from contributors) is a better approach than sticking one's head in the sand and hoping that the code isn't tainted.  [note:  I am only talking here about copyright issues.  I agree with ESR that "benign ignorance" is better in the case of patents, given the perverse rule (http://www.internetnews.com/dev-news/article.php/3389071) that your awareness of a patent on which you may infringe can result in a finding of willfulness and the trebling of damages against you.]   As a prominent member of the PHP community recently stated, "When you have an anyone-can-commit-or-submit policy, you have no idea where the newly contributed code has come from." (http://netevil.org/node.php?nid=633&SC=1).  

This week's issue of the influential weekly The Economist echoes this point in a special report on open source:  http://economist.com/business/displaystory.cfm?story_id=5624944

"For the moment, users of Linux say that [litigation] worries have not affected their adoption of open-source software. But they probably would be leery if, over time, the code could not be vouched for. In response, big open-source projects such as Linux, Apache and Mozilla have implemented rigid procedures so that they can attest to the origins of the code. In other words, the openness of open source does not necessarily mean it is anonymous. Strikingly, even more monitoring of operations is required in open source than in other sorts of businesses."

3.  ESR's other points

ESR's position statement makes several arguments against CLAs.  I discuss each of these below.

a) A license isn't required because the act of donating code to an open-source project constitutes some form of implied license or "quitclaim" under the applicable project license.  

ESR concedes that there is no direct case law on this point, but relies by extension on case law relating to ownership of bulletin board postings.  While there is some case law on implied copyright licenses, and many commentators agree that a nonexclusive license can be implied by the conduct of the parties, it is always better whenever possible to obtain an express license and clearly define its terms, rather than relying on a court to grant a license by implication after-the-fact with unclear terms.  The "implied license" argument is generally trotted out only as a last resort in the event of a legal challenge; it should not be relied on if there is a chance to obtain an express license up front.

b) CLAs are not necessary because they only protect against unlikely claims from contributors, but do nothing vis-à-vis unrelated third parties who might sue for IP infringement (e.g., SCO vs. IBM).

Nobody is saying that a CLA requirement is a magic wand to ward off the SCOs of the world.  But as noted above, it is a key component of an overall IP diligence process that could make some claims less likely and/or easier to defend in court.  

c) Requiring CLAs is a "trap" because it unwisely shifts the burden to the foundation to prove the IP is clean, rather than leaving the burden on a potential challenger.

Due diligencing the provenance of contributed code and obtaining CLAs does not shift any burden to the foundation.  Simply asking contributors to sign a CLA does not mean that the foundation has assumed some higher obligation to ensure code purity.  To be sure, this process may ferret out issues in the code, but it does so at a point in time when such issues can be more easily remedied.  When code is proferred for inclusion in a project, it hasn't yet been accepted.  Is it not better to ask at that point about the origin of the code rather than be forced to remove it at a later date in the face of a challenge (when it might be difficult to remove)?

ESR's analogy to willful patent infringement is similarly misplaced.  Patents are public documents that can be researched.  Lawyers generally advise against doing so because this can lead to a finding of willful infringement.  But copyrights need not be registered or made public.  Thus the CLA requirement as part of a due diligence process does not entail searching through some database of copyrights to verify non-infringement; rather, it seeks simply to ensure that the person submitting the code is the original author (and thus the copyright holder) of that code or has permission from the author.  This is a very different inquiry from asking whether the functions or ideas embodied in the code infringe on another's patent.

d) Mandating CLAs is bad for open source because their widespread adoption could somehow lead the courts to conclude that any code not contributed under a CLA is therefore tainted.

Regardless of how many open source projects use CLAs, it requires a olympian leap of logic to conclude that simply because someone contributed code without signing a CLA the code must therefore violate someone else's copyright.  As the present debate is demonstrating firsthand, many developers have very good reasons for not wanting to sign a CLA.  But I have yet to learn that a developer won't sign a CLA because she wants to commit misappropriated code.  I find it equally implausible that any court would create such a presumption.  In any event, even if ESR is right, I would argue that this genie is already out of the bottle.  Many of the most successful and/or prominent open source projects already require that contributors sign a CLA.  Run a Google search for contributor license agreements and you'll be presented with a veritable who's who of projects/organizations that require some form of agreement or certification from contributors:  Linux, Apache, Mozilla, Fedora, Eclipse, OSAF, FSF, Openoffice, etc.

e) Requiring potential contributors to do legal paperwork is a substantial barrier to contributions, and thus damages the open-source process.

I agree that too much process is bad, and too much *legal* process can be horrible.  But a principal goal of creating this foundation was to provide a more mature legal and IP regime under which open source geospatial projects are operated.  Just as you can't have your cake and eat it too, you can't have the benefits of that regime without some legal process.  And practically speaking, the experience of the other successful open source projects noted above refutes the notion that requiring a developer to sign a license agreement is a substantial barrier to participation or that it impedes success of the project.

In the end, each project will need to balance the benefits of a reasonable IP policy against the risks of chilling participation due to "blame the laywer" FUD.  As we know, many open source projects have struck this balance in favor of mandating CLAs for all contributors, and many have not.  For MapGuide Open Source at least, I will recommend that we go the route of established organizations like Apache and require that all project contributors sign a CLA.

Thanks,

Rich


-----Original Message-----
From: Eric S. Raymond [mailto:esr at thyrsus.com] 
Sent: Monday, March 20, 2006 3:48 PM
To: Rich Steele
Subject: Re: thanks from OSGeo

Rich Steele <Rich.Steele at autodesk.com>:
> Thanks for joining us today.  Feel free to shoot me your position
> statement on CLAs.  I think you raise some very good points.

First cut:

OSGEO considered having an elaborate structure of contributor license
agreements (CLAs) and continuous code auditing to guard our projects
against IP infringement claims.  We know that some major project 
groups like the Free Software Foundation and Apache have taken the
approach of mandating CLAs.  Nevertheless, we have rejected it.

OSGEO's Policy on Third-Party IP Claims

OSGEO's policy is to respect intellectual-property rights.  We will
not knowingly accept code containing protected third-party material.
Should it come to our attention that contributed code is in violation
of a copyright, patent, or trade secret, we will take the remediating
action required under U.S. law, which is to remove the offending
material.

However, for reasons described below, we will neither mandate that our
projects collect CLAs nor require that they perform IP code audits.

Why We Don't Mandate CLAs:

We believe that under the law as it now stands in the U.S. and Great
Britain, the act of donating code to an open-source project implies
(under the doctrines of laches and unclean hands, among others) a
cession of all rights (whether copyright, patent, or trade secret)
required for the project to redistribute under its publicly advertised
license.  No court has ruled on this issue with respect to software,
but there are case-law precedents with regard to (for example) the
ownership of messages posted on supermarket bulletin boards.  If our
application of this precedent is correct, CLAs are not needed to
protect a project against the contributors who sign them.

The most serious IP threat facing open source is not from contributors
at all but from third parties alleging infringement with respect to
copyrighted or patent or trade-secret material that was never a
contributor's to cede. CLAs offer zero protection against that.

The only undisputed utility in CLAs might be as a way of securing the
project leaders' right to change the license of the software without the
unanimous consent of contributors.

It is sometimes argued that project groups should collect CLAs as a
sort of voodoo dance, a way to reassure potential customers that Steps
Are Being Taken to mitigate IP risk even though the insiders know that
CLAs are not really significant protection.  We reject this approach
as both hypocritical and ineffective.

Actually, CLAs may be a trap.  It is always unwise to accept
the burden of proof when you can leave it on your enemy's shoulders.
This issue is well understood in patent law; attorneys routinely
advise their clients not to audit for patent infringement lest knowing
of a breach make the client a willful infringer.  Instead, clients
are nornnally advised to remain in benign ignorance and deal with 
individual patent breaches (if any) after the fact.  Much the same 
logic applies to breaches of copyright.

There are larger issues as well.  Courts could well come to take
community acceptance of CLAs as a concession that any code without an
audit trail is to be treated as tainted and that failure to mandate
CLAs constitutes culpable negligence.  Thus, even if CLAs are good in
the short term for individual projects (which is unproven), they
present a significant risk to the entire open-source community.

Finally, even if CLAs were merely neutral in their effect on the legal
exposure of open-source projects, experience has shown that requiring
potential contributors to do legal paperwork is a substantial barrier
to contributions, and thus damages the open-source process.

Why We Don't Mandate Code Audits

All the reasons for not mandating CLAs apply equally to IP audits of
submitted code.  The law does not require authors of novels, or music,
or dramatic presentations that they pre-audit their work to prove its IP
cleanliness in advance of publication.  The standards for software
are no different -- works are presumed to be untainted until a 
plaintiff alleges and demonstrates otherwise.

We do not choose to engage in practices that might be taken to 
concede away that protection.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>