Contributor License Agreement

back to index

description: copyright terms

2 results

pages: 266 words: 79,297

Forge Your Future with Open Source
by VM (Vicky) Brasseur

If you strongly object to the routes a project uses, rather than complain about it (passive-aggressively or otherwise), I advise you to select a different project to which to contribute. Your complaints will fall on deaf ears, and you’ll simply alienate the community you’d wish to join. Respect their choices and the process that went into making them. Contributor License Agreement/Developer Certificate of Origin A few free and open source software projects require all contributors to agree to either a Contributor License Agreement or a Developer Certificate of Origin before their contributions can be merged and distributed with the software. While the number of projects that require this is still relatively small, it’s increasing every year, as more projects join free and open source software foundations.

What Free and Open Source Can Do for YouFOSS Benefits to Your Skillset FOSS Benefits to Your Career FOSS Benefits to Your Personal Network Benefit from Preparation 3. Prepare to ContributeWays to Contribute Common Project and Community Roles Files You Should Know About Before You Start Issue Tracking Common Communication Routes Contributor License Agreement/Developer Certificate of Origin You’re Ready to Find a Project 4. Find a ProjectSet Your Goals Collect Your Requirements Collect Candidate Projects Select a Project Select a Task What Is “Success”? 5. Make a ContributionPrepare for Your Contribution Craft Your Contribution Gotchas Clone and Branch Atomic Commits Test Your Contribution Submit Your Contribution Review, Revise, Collaborate Tidy Up Special Considerations for Windows-based Contributors There’s More to Contributing Than Just Code 6.

This helps to keep the copyright and licensing complexities more comprehensible. As you can imagine, in a large project, questions of copyright could easily become mind-bendingly complicated. Whatever creative work you contribute to a project, unless you agree to assign your copyright elsewhere (as can happen in a work for hire or a Contributor License Agreement situation, both covered later in the book), you retain copyright over your contribution and—if the project is released under an OSI-Approved License—your contributions will be publicly available. This means you can build a professional portfolio without fear of breaking copyright law or violating someone else’s copyright.

Producing Open Source Software: How to Run a Successful Free Software Project
by Karl Fogel
Published 13 Oct 2005

Managing Participants Community and Motivation Delegation Praise and Criticism Prevent Territoriality The Automation Ratio Treat Every User as a Potential Participant Meeting In Person (Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats) Share Management Tasks as Well as Technical Tasks "Manager" Does Not Mean "Owner" Transitions Committers Choosing Committers Revoking Commit Access Partial Commit Access Dormant Committers Avoid Mystery Credit Forks Handling a Fork Initiating a Fork 9. Legal Matters: Licenses, Copyrights, Trademarks and Patents Terminology Aspects of Licenses The GPL and License Compatibility Choosing a License The GNU General Public License Contributor Agreements Doing Nothing Contributor License Agreements Proprietary Relicensing Problems with Proprietary Relicensing Trademarks Case study: Mozilla Firefox, the Debian Project, and Iceweasel Case study: The GNOME Logo and the Fish Pedicure Shop Patents Further Resources A. Canned Hosting Sites B. Obsolete Appendix (was: Free Version Control Systems) C.

The old Affero license is now rarely used and is more or less deprecated, but to avoid ambiguity, say "AGPL-3.0" or "GNU AGPL" to make it clear that you're referring to the modern GNU version of the license. Contributor Agreements There are three ways to handle copyright ownership for free code and documentation that were contributed to by many people. The first is to ignore the issue of copyright entirely (I don't recommend this). The second is to collect a contributor license agreement (CLA) from each person who works on the project, explicitly granting the project the right to use that person's contributions. This is usually enough for most projects, and the nice thing is that in some jurisdictions, CLAs can be sent in by email. The third way is to get actual copyright assignment (CA from contributors, so that the project (i.e., some legal entity, usually a nonprofit) is the copyright owner for everything.

For example, the SCO Group did something like this to the Linux project, see en.wikipedia.org/wiki/SCO-Linux_controversies for details. When this happens, the project will have no documentation showing that the contributor formally granted the right to use the code, which could make some legal defenses more difficult. Contributor License Agreements CLAs probably offer the best tradeoff between safety and convenience. A CLA is typically an electronic form that a developer fills out and sends in to the project, or even a web-based checkbox that the developer checks before completing their first contribution to the project. In many jurisdictions, such email submission or an online form is enough, though you should consult with a lawyer to see what method would be best for your project.