Contributor Agreements
Considered Harmful

Richard Fontana

Open Source Licensing and Patent Counsel

Inbound and outbound

Two legal planes of existence for FLOSS projects

• Similarities:

  • involve transfer of code + rights
  • conditions on transfer may limit subsequent use

• Differences:

  • Outbound case: project presents FLOSS license to world
  • Inbound cases vary from project to project

• Example: GPL’d patch vs. CLA’d patch to GPL’d project

Policies vs. agreements

• What do I mean by “agreement”?

  • Formal contractual instrument requiring formal assent
  • Typical FLOSS licenses are not “agreements”

• Most projects have a contribution policy (implicit/explicit legal rules governing contributions)

  • Exceptions?

• But vast majority don’t use contributor agreements

Three policy categories

• Majority rule: inbound=outbound

• Contributor agreements

  • maximalist (most common minority approach)
  • minimalist (uncommon)

• Miscellaneous: nonagreement, non-pure-inbound=outbound (uncommon)

I am mainly critiquing maximalist agreements

Inbound=outbound

A custom that reflects traditional FLOSS norms: licensor equality + transactional informality

• Contributions licensed in under project’s outbound FLOSS license (or contributor’s license passed through by project)

  • “Outside” contributors legally equivalent to project/insiders
  • Pure FLOSS solution

• Usually undocumented

• Most contributors do not explicitly license

Maximalist contributor agreements

• Two types:

  • copyright assignment
  • (typical) “CLAs” (lack of standard terminology)

• Why “maximalist”? Extent of:

  • power transfer to project entity
  • legal risk allocation to contributor
  • departure from customary FLOSS licensing norms

Copyright assignment

• Complete transfer of ownership (Sun version: joint ©)

  • No intrinsic constraint on outbound licensing
  • FSF, FLA: try to contractually constrain project to free software licensing

• Most often used with outbound GPL/LGPL projects

• Typical features:

  • grant-back of maximally broad © license covering patch
  • fallback maximally broad inbound © license
  • patent license grant by contributor (never reciprocal)
  • provisions shifting risk to contributor

CLAs

• Essentially equivalent to © assignment agreements

  • Formal difference: maximal © license instead of transfer
  • Any real differences? (standing, marginal vulnerability)

• Apache ICLA/CCLA, widely adapted by ‘corporate’ projects; used with permissive and copyleft projects

• Confusion surrounds CLAs

  • Anti-assignmentists assume CLAs raise no similar issues
  • Some assume CLAs are copyright assignments
  • Some companies using CLAs may be exploiting confusion

Minimalist agreements

• Elaborate formalization of inbound=outbound (Eclipse, Mozilla committer agreements)

• PSF CA: contributor licenses in under choice of AFL or Apache License 2.0; PSF can license out under open source license approved by PSF Board

• Old JBoss CA: elaborate LGPL license grant to project

• Fedora FPCA (2011): default licensing of nonexplicitly licensed code (MIT) and content (CC BY-SA) + right to opt out through explicit licensing

Miscellaneous

• CiviCRM: documents policy of AFL inbound, AGPL outbound

• Give contributors a choice

  • KDE: inbound=outbound or FLA
  • MariaDB: joint copyright assignment or 3-clause BSD

• Lightweight exception to maximalism for small contributions

• Linux kernel DCO: “signoff” on patches certifies right to license inbound=outbound

Why maximalist model is bad

• Several reasons:

  • Institutionalizes inequality within project community
  • Kills tradition of transactional informality
  • Secondary community-building toxicity
  • Casts doubt on FLOSS licensing system
  • Ethical concerns

• Some arguments apply more weakly to minimalist agreements

• My assumption: natural FLOSS community development model is socially and economically optimal

Inequality

• Inbound=outbound attenuates natural inequalities that emerge in community projects by creating legal equality

• Maximalist CAs give greater legal power to one privileged entity, signalling all others are second-class citizens

  • Worst cases: corporate inbound retains sole right to dual-license outbound code GPL/proprietary

• Maximalist CAs facilitate single-entity control

  • Imbalance of rights allocation may signal danger for contributors

Transactional formality

• CAs introduce red tape, delay, inefficiency, deal-making into development process

  • Reduces significant advantage of community development

• My experience at Red Hat:

  • protracted negotiations with upstreams over badly drafted, overreaching agreements

  • protracted negotiations over our own CAs

  • clashes with “upstream first” ideology

Secondary toxicity

Inequality and red tape have harmful effects on community-building

• Disincentives/barriers for outsiders to participate in project

• Narrower developer communities will limit project focus

  • Limits user adoption: reduces developer community further

• Incentives to partially/fully fork

  • Leads to wasteful work on both sides, further diminishing benefits of FLOSS development

Insufficiency of FLOSS licensing

Maximalism departs from the pure FLOSS of inbound=outbound

• imposes a culturally-foreign legal layer on top of the FLOSS-outbound layer

• seems to signal that there is something legally insufficient or doubtful about FLOSS licensing

• advocates fail to explain asymmetry (why is FLOSS licensing good enough for the outbound side?)

Ethical concerns

• Arises with individual contributor and commercial inbound

• Significant inequality in bargaining power

  • Corporate contributors have access to counsel, greater legal sophistication, clout to negotiate out worst provisions

• CLAs arguably more problematic than copyright assignment (consequences less obvious to individual contributors)

Pro-maximalist arguments?

• Needed for enforcement (© assignment)

• Facilitate relicensing

• “Protect the project”

• Attract business investment in open source

Enforcement

• Copyright ownership for standing to sue?

  • Yes, but nonexclusive licensee can create derivative/collective work and sue on that copyright interest

• Aggregate © ownership to avoid joinder problem?

  • Argument assumes contributor & contributee were joint authors (co-owners of undivided © interest in whole work)

  • But if contributor JA pre-assignment, grant-back license covers whole work → contributor post-assignment can give defendant license

• Germ of truth: the larger your copyright interest, the more likely your case will survive attacks by defendant

Relicensing

• Today relevant only where initial license is copyleft and doesn’t allow migration to desired license

• FLOSS licenses (especially copyleft) are stable by design

  • Get your license policy right the first time

  • Use copyleft licenses with “or later” clauses

• Exercise of “nuclear option” without community consent suggests weak/nonexistent community

• Undergoing relicensing process is typically not that difficult

“Protects the project”

• From what?

  • Argument assumes an atmosphere of high risk that is completely unjustified by experience

  • Inbound=outbound with appropriate FLOSS license gives all the protection the project’s community should need

• Project gets meaningless contract claims against judgment-proof developers

• Makes more sense for corporate contributors, but they often negotiate away teeth of provisions

Business argument

• Ethically problematic/gimmicky dual-licensing (GPL/proprietary) models are generally assumed to require maximalist CA

• Strong case (sabdfl): riches from GPL/proprietary business models will entice proprietary companies into the ecosystem

  • Even if sensible, such models have done substantial harm to copyleft (and are dying out anyway)

• Weak case: scary contributor agreement will make companies feel more comfortable open-sourcing proprietary code

  • These companies should stick to proprietary software

Conclusion

• Inbound=outbound should be default choice of any project

  • But do try to document the custom

• Any benefits of maximalist CAs far outweighed by harm they do to community FLOSS development

• Continue experimenting with minimalist agreements and nonmaximalist alternative approaches to contribution policies

Thank you!

Email: rfontana@redhat.com
Identi.ca: @fontana
Twitter: @richardfontana
See also: opensource.com/law

Presentation text © 2011 Red Hat, Inc.
License: Creative Commons Attribution-ShareAlike 3.0 United States.