LWN.net Logo

When does the FSF own your code?

When does the FSF own your code?

Posted Mar 19, 2013 23:52 UTC (Tue) by gdt (subscriber, #6284)
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.


(Log in to post comments)

When does the FSF own your code?

Posted Mar 20, 2013 10:35 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

Consider a different case: Author writes some code for a kernel Org module. The code gets submitted into the git tree of a subsystem maintainer, but before it gets pushed to the main Linus tree, the Author decides it is not good and should be retracted.

Suppose someone else does like the code and steps up to maintain it (so it's not an issue of unmaintained code). In that case the code may still get included in Linus' tree. The credit for writing it will still go to the Author.

So why is that case different?

When does the FSF own your code?

Posted Mar 20, 2013 12:19 UTC (Wed) by Tobu (subscriber, #24111) [Link]

This Jambunathan fellow didn't request that the code be removed, he just wanted to know how annoying that would be. I'm sure he would also see himself as a victim if the FSF pre-emptively stopped publishing it without his say-so. It would be funny, albeit annoying to other users.

When does the FSF own your code?

Posted Mar 20, 2013 13:58 UTC (Wed) by ndk (subscriber, #43509) [Link]

> 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.

That's not true: the ODT exporter was released a long time ago and is part of the Org mode that's distributed with emacs. What happened now was a rewrite of the low-level parsing code, and a rewrite of the export engine. That required the exporters (including the ODT exporter) to be rewritten if they wanted to take advantage of the new export engine. It's this version of the ODT exporter (and the rewritten HTML exporter) that is at issue.

It's conceivable that somebody could still use the old ODT exporter, but that is no longer maintained and would bit rot quite fast (if it has not done so already.)

So people *are* relying on the feature.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds