When does the FSF own your code?
Posted Mar 19, 2013 23:52 UTC (Tue) by gdt
Parent article: When does the FSF own your code?
Interesting that there's no discussion of the correct ethical response, which would be to agree to the request. The change is yet to be formally released, so agreeing doesn't harm others by removing a feature they were relying upon.
From a legal perspective it's simple enough to see the likely arguments for both parties.
The broad language of the Contributor Agreement is admitted by the FSF to be intentionally ambiguous. You'd argue that ambiguity-as-a-legal-strategy must benefit the non-drafting party to the utmost; that is, the CA doesn't take effect until the FSF accepts the contribution for formal distribution. You might go as far to argue that the Contributor Agreement is deceptive -- the effect is that copyright in derivative works passes to the FSF on the creation of the work, but the CA obfuscates that with admittedly-ambiguous language.
I'd be surprised if the argument succeeded, simply because the counter-argument is "what was the intent of the contributor when they e-mailed the change to the Org list?" I'd think that a fact-finder would readily agree that the intent of e-mailing a contribution to a mailing list where contributed software is received is to activate the Contributor Agreement if it were not already activated sooner.
The whole point of agreements is to prevent the need to ask a court for clarification. In this way the deliberate ambiguity by the FSF in its Contributor Agreement is abusing its ready low-cost access to legal representation compared with the other party to the Agreement. Which brings us back to my opening point of the need for a ethically-founded organisation to act ethically rather than the to maximum legal claim.
to post comments)