I have removed most of the CC: on this discussion because I don't believe such spam is appropriate (and it fills my
mailbox with list rejections).
On 12/29/2014 09:54 AM, Alberto Salvia Novella wrote:
> Stephen M. Webb:
>> I think you will find that there is no conflict between any vaguely
>> defined "social contract" and the requirements for acceptable code
>> submission to a software project.
> That social contract is <http://www.gnu.org/licenses/gpl.txt>.
software. It deals exclusively with downstream distribution of software and expressly does not mention how upstream
projects are to be run.
If you wish to reference a social contract from the Free Software Foundation, you would be better off using the GNU
Manifesto  which explicitly enumerates a set of rights and entitlements the Free Software Foundation believes are a
part of the social contract between individuals. Please read it closely: I believe you will not find among those
enumerated rights any kind of entitlement that your changes must be accepted upstream. If you can find such a right
enumerated, please let me know; I have some tasteless "easter eggs" I want to add to some widely-used programs
distributed by the FSF.
As I said previously, all upstream project have a set of conditions, express or implied, they require any contribution
to fulfil before acceptance. Your arguments that having any such set of restrictions contravenes "the social contract"
or is invalid under the GNU General Public License still remains to be made.
> Stephen M. Webb:
>> If you truly believe that the original works of an author or authors
>> belong not to them individually but to some larger collective, you
>> would probably be more effective talking to legislators to get the
>> copyright and patent laws in your local jurisdiction struck down, and
>> best of luck with that. Mean time we will continue asking the
>> authors of contributions to agree to share the specific rights in
>> their work if they want it accepted into a Canonical-led project.
>> That's the best way to guarantee fairness for everyone.
> Putting the agreement under the United Kingdom law wasn't my objection, but to take nearly unlimited power over the code.
Yes, the rhetorical techniques of vagueness ("power over the code") and pathos  ("unlimited power!!!1!") can be
powerful tools, but as an engineer I prefer facts. Here are some of the facts involved when I decide to accept or
reject a contribution in any of the several Canonical-led projects for which I am responsible.
In almost all jurisdictions copyright law grants the original author of a work a set of rights over the use of that
work, including the right to license or restrict the use of that work, either for free or for a fee, to another legal
person (which could be an individual or a business entity). Other users of the copyright work do not have such rights,
even if they have been granted permission by the author to use the work.
Because the power over use of copyrighted works is balanced in favour of the original author (as it should be), it puts
any business that makes use of the copyrighted work at the mercy of that author. For example, an organization that
provides a software program used to operate a general-purpose computer might accept a small contribution to improve the
performance of the program on a particular device. The contribution is then included in the software program and
distributed widely. Subsequently, the author of the contribution revokes or changes the license terms, forcing the
organization to remove the contribution at its expense and disrupting its business, possibly even terminating it. This
is certainly not the intended consequence of copyright or patent law, but certainly a very real possibility, and one
which has been used in practice on several high-profile occasions.
The effective alternatives to preventing this very real threat to a business attempting to use Free or open source
software are: (1) accept absolutely no outside contributions ever or (2) require a non-revokable symmetric grant of
copyright powers from the original author of outside contributions (such as the CLA). A third alternative is that the
business investigate the individual contributor with background checks and judge them individually as worthy
contributors, but nobody wants that and ain't nobody got time for that.
Remember, at no time does the CLA remove or restrict any enumerated rights of the original author nor does it accrue
more rights to the licensee than the original author already has. The CLA simply grants similar rights as the original
author to the licensee. It does restrict the malicious use of the original author's enumerated rights with respect to
the licensee, and that's the point. I can see how some selfish people would object to that restriction, but I am not
convinced by that as a logical argument to remove the CLA as a requirement for the acceptance of an upstream software
Fact is, when it comes time for me to accept or reject a contribution, I must outright reject any from an author who has
not proven good will, and that proof is the CLA.
> Stephen M. Webb:
>> If you could enumerate the abuses engendered by asking for a grant of
>> license I'd be happy to address them individually.
> As I said, this is like telling a autocracy is good because their drivers have never done something bad.
> It's something that elicits distrust itself, and usually finishes with people working less and less for the project;
> even when they are paid for it.
So, you can not enumerate the abuses engendered by asking for a grant of license. That's OK, you simply make my point
for me, thank you. I can certainly point you at cases  showing how "intellectual property" laws are twisted and
It's true that there is a strong element of distrust involved, but trust has to work both ways. The CLA codifies that
trust explicitly. Puts it in writing, all nice and legal-like. If a potential contributor objects to that, I can only
assume they have malicious intent and I do not want their contribution in my project(s).
Stephen M. Webb <firstname.lastname@example.org>
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel