[OSGeo-Board] Contributor agreements

[Dave McIlhagga]

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.