[OSGeo-Board] Contributor agreements
dmcilhagga at dmsolutions.ca
Thu Mar 23 08:24:51 EST 2006
One further thought:
Is the primary concern about adoption of the CLA revolve around granting
the right to re-license to the Foundation -- in particular for GPL projects?
If this is the main issue - has there been any consideration of allowing
each project to select from one of two CLAs, one that grants the ability
to re-license and one that does not?
Dave McIlhagga wrote:
> Hi Rich,
> Thank you for your detailed email, it was very helpful. I'm just getting
> caught up on some of these discussions, so I apologize if some of my
> questions/comments are redundant with previous discussions.
> I have to say that I'm concerned by the idea that only some OSGEO
> projects would be covered by CLAs and sets a precedent I'm not too
> comfortable with for the future.
> 1. How significant is the 'anti-CLA' sentiment within OSGEO? Is this a
> vocal few, or does this represent the will of project contributors from
> many of the open source projects currently entering the Foundation?
> Would not enforcing a CLA for all contributors prevent any projects from
> 2. Image and Promotion - My hope has been that OSGEO could present a
> strong united message regarding IP. A message that organizations can
> adopt any OSGEO project knowing that it has been through an identified
> level of rigour for auditing purposes and commitments by contributors.
> Commitments that ensure the PSC and the Foundation have the neccessary
> tools to act in the best interest of the Project. Two-tiers of projects
> will inevitably reduce this overall credibility, including the
> credibility of projects that enforce a CLA. A 'lowest common
> demonitator' effect is difficult to avoid.
> 3. Legal Protection - This is one of the key benefits of projects
> joining the foundation. If some projects do not enforce CLAs -- does
> this mean we will require two levels of legal protection for the
> projects in the Foundation? It's a bit like building a house in a
> floodplain -- if you want to, go ahead - but why should everyone else's
> insurance premiums pay for the added risk?
> 4. Confusion for individual developers - Some organizations such as
> Autodesk or our own may restrict development activities to those
> projects that are enforcing CLAs. One of the benefits of the Foundation
> is encouraging cross-polination of projects where contributors may be
> engaged with a number of projects. If only some projects are covered by
> CLAs - then managing contributions to projects based on the existence of
> CLAs for some projects and not others becomes much more difficult.
> 5. Barriers to Contribution - Contrary to the fear that CLAs may inhibit
> contributions - some organizations will not contribute resources and
> efforts to a project UNLESS CLAs are in effect for all contributors.
> This barrier in my mind could be dramatically more significant then the
> loss of a few contributors unwilling to sign a CLA. DM Solutions is
> considering whether we should continue contributing to projects that are
> not covered by a CLA -- clearly, it would be very frustrating to make
> this choice on a 'non-technical' issue.
> These arguments may have been raised previously -- and Rich or others,
> I'd like to know if I'm off base on any of these (I'm no lawyer).
> Obviously, I wouldn't want this issue to be a show-stopper -- but I
> would be interested to hear other's thoughts on what I think is a very
> important issue.
> Rich Steele wrote:
>> 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.,
>> 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://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."
>> This week's issue of the influential weekly The Economist echoes this
>> point in a special report on open source:
>> "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.
>> -----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
>> 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
>> 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
>> 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.
> To unsubscribe, e-mail: board-unsubscribe at board.osgeo.org
> For additional commands, e-mail: board-help at board.osgeo.org
More information about the Board