Proposal: Use and Require CLA for QA Devel Project Contributions

Tim Flink tflink at redhat.com
Tue May 20 16:13:09 UTC 2014


As this has a decent possibility of being misunderstood, I want to be
completely clear on what I'm proposing, what I'm _not_ proposing and why
I'm proposing the use of a CLA.

I'd want to run anything we decide past legal (enforce-ability,
details of IP law and licensing in various jurisdictions etc.) before
actually moving forward but that's after we discuss the idea of
even using a CLA :)


What I'm Proposing
------------------

 - Start requiring a CLA for all contributions to qa devel projects,
   including libtaskotron, resultsdb, blockerbugs, core checks, etc.

 - The CLA would not change ownership of copyright but allow a bit
   broader license than just gpl2+ or gpl3

 - The CLA would allow for re-licensing contributions under any of the
   licenses specified in the CLA (this list is up for discussion)
    * GPL2, LGPL2, LGPL2.1, AGPL2
    * GPL3, LGPL3, AGPL3
    * other (possibly future) fsf-recommended licenses (GPL4, etc.)
    * Maybe APL2? Not sure on that one since it's not copyleft and we'd
      have to rewrite bits to make that happen.


What I'm NOT Proposing
----------------------

 - Requiring contributors to give up ownership

 - Something sneaky.
    * Seriously, if it seems like I'm proposing something sneaky/evil,
      I want to get that clarified now.


Why Propose Using a CLA?
------------------------

I have three reasons for wanting to start using a CLA for qa devel
contributions:

1. With the gpl2+ vs gpl3 licensing question, I would like to enable
   license switches in the future that are in the best interests of the
   project, whether that means some gpl4 in the future or backing up to
   gpl2. I think of this as attempting to future-proof some potential
   licensing concerns.

2. I want to avoid confusion on how contributions are licensed,
   especially if we go forward with the "project is gpl3, most code is
   gpl2+" route. A properly worded CLA removes any confusion around how
   a contribution is or is not licensed.

3. Suggested best practices for open source projects [1]. I think it's
   highly unlikely that we'll ever need proof of IP provenance but it's
   infinitely easier to start gathering that proof now instead of later
   when email addresses may be dead, people difficult to reach etc.

[1] http://jacobian.org/writing/contributor-license-agreements/


Any thoughts on whether this is a good idea or a bad idea? Any changes
to the concept before I look for some specific verbiage and talk to
legal about it?

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20140520/b75b3f65/attachment.sig>


More information about the qa-devel mailing list