Author: matakagi Date: Tue Aug 7 04:01:37 2007 New Revision: 887 Log: merge r678.
Modified: trunk/ja/ch09.xml Modified: trunk/ja/ch09.xml ============================================================================== --- trunk/ja/ch09.xml (original) +++ trunk/ja/ch09.xml Tue Aug 7 04:01:37 2007 @@ -651,30 +651,32 @@ <sect1 id="copyright-assignment"> <title>Copyright Assignment and Ownership</title> -<para>There are three ways to handle copyright ownership of free code -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 <firstterm>contributor license agreement</firstterm> -(<firstterm>CLA</firstterm>) from each person who works on the -project, explicitly granting the project the right to use that -person's code. 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 assignments from -contributors, so that the project (i.e., some legal entity, usually a -nonprofit) is the copyright owner for everything. This is the most -legally airtight way, but it's also the most burdensome for -contributors; only a few projects insist on it.</para> - -<para>Note that even under centralized copyright ownership, the code -remains free, because open source licenses do not give the copyright -holder the right to retroactively proprietize all copies of the code. -So even if the project, as a legal entity, were to suddenly turn -around and started distributing all the code under a restrictive -license, that wouldn't cause a problem for the public community. The -other developers would simply start a fork based on the latest free -copy of the code, and continue as if nothing had happened. Because -they know they can do this, most contributors cooperate when asked to -sign a CLA or an assignment of copyright.</para> +<para>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 <firstterm>contributor license +agreement</firstterm> (<firstterm>CLA</firstterm>) 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 +assignments from contributors, so that the project (i.e., some legal +entity, usually a nonprofit) is the copyright owner for everything. +This is the most legally airtight way, but it's also the most +burdensome for contributors; only a few projects insist on it.</para> + +<para>Note that even under centralized copyright ownership, the +code<footnote><para>I'll use "code" to refer to both code and +documentation, from now on.</para></footnote> remains free, because +open source licenses do not give the copyright holder the right to +retroactively proprietize all copies of the code. So even if the +project, as a legal entity, were to suddenly turn around and started +distributing all the code under a restrictive license, that wouldn't +cause a problem for the public community. The other developers would +simply start a fork based on the latest free copy of the code, and +continue as if nothing had happened. Because they know they can do +this, most contributors cooperate when asked to sign a CLA or an +assignment of copyright.</para> <sect2 id="copyright-assignment-none"> <title>Doing Nothing</title> _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
