[OSGeo-Board] Contributor agreements

[Dave McIlhagga]

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



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 
> entering?
> 
> 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.
> 
> Dave
> 
> 
> 
> 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.,
>> 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.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: board-unsubscribe at board.osgeo.org
> For additional commands, e-mail: board-help at board.osgeo.org
> 
>