Weekly Edition
Return to the Front page
| |||||||||||||
When does the FSF own your code?
Many pixels have been expended in the discussion of contributor agreements
that transfer copyright from developers to a company or
foundation. But, for developers in many projects, the discussion is moot,
in that the requirement for an agreement exists and the papers must be
signed before
contributions to the project can be made. But, even then, there are some
interesting details that merit attention. A recent discussion regarding
one developer's contributions to the Emacs Org mode project shows how
expansive and poorly understood such agreements can be in some cases.
Some contextOrg mode is a major mode for the Emacs editor that can be used for the maintenance of task lists, project plans, documents, and more; it is a general-purpose tool that is held in high regard by a large community of users. Org mode is run as an independent project but its releases are incorporated into Emacs releases; for that to happen, Org mode must be developed under the Free Software Foundation's copyright assignment rules. So it is not (usually) possible to contribute changes to Org mode without having signed a contributor agreement that assigns copyright to the FSF. Jambunathan K is a contributor to Org mode and an active participant on the project's mailing list; his credits include a module to export to files in the OpenDocument (ODT) format and a rewrite of the HTML export module. It is fair to characterize Jambunathan's relationship with other Org mode developers as "difficult." His mailing list postings are seen as contentious and disruptive by many; he has, at times, been asked to leave the project's mailing list. In February he made a half-hearted attempt to take over maintainership of Org mode; his bid gained little support from other developers in the project. More recently, he has requested removal of ox-odt.el and ox-html.el from the Org mode repository; again, this idea was received with little enthusiasm. So his next step was to take his case to the main Emacs list, saying:
I have some disagreements with current Orgmode maintainer and the
community in general.
I would like to withdraw my pleasure in having these files distributed as part of Org distribution. I would like to register my displeasure in a substantial way. More specifically, I would like to know how copyright assignment works for files that are not yet part of Emacs. Is there is a way I can withdraw my assignment (for a substantial period - say 3-6 months) big enough to create a minor discomfort for the Org community. In such a situation, it would be a natural response to drop the work in question and refuse any further dealings with this developer. Experience has shown that a single difficult developer can create all kinds of problems for a community when given the chance. Somebody who sets out to deliberately create "a minor discomfort" for the Org mode community is showing signs of being just such a developer; his code may well not be worth the trouble. But, in this case, it appears that the request will be refused. The files in question have already been merged into the Org mode repository, so the community appears to feel that (1) it has invested enough of its own energy into that work to have a legitimate interest in it, and (2) the FSF, as the owner of the copyright for that work, has every right to retain and distribute it. It is the second point that Jambunathan would like to dispute; since the files have not yet been distributed with Emacs, he says, the Emacs copyright assignment agreement should not apply to them. One could argue that he is almost certainly wrong and should be dismissed as an obvious troll, but there is still an interesting point raised by this discussion.
When copyright transfer happensThere are numerous contributor agreements out there that include either copyright assignment or the grant of a broad license to the work in question. The agreement used by the Apache Software Foundation, for example, includes a license grant for any software that is "intentionally submitted" to the Foundation, where "submitted" is carefully defined:
For the purposes of this definition, "submitted" means any form of
electronic, verbal, or written communication sent to the Foundation
or its representatives, including but not limited to communication
on electronic mailing lists, source code control systems, and issue
tracking systems that are managed by, or on behalf of, the
Foundation for the purpose of discussing and improving the Work...
Once the work is submitted, the grant applies. The Harmony Agreements, which can involve either copyright assignment or licensing, have a very similar definition. The Python agreement requires a specific annotation in the source indicating that the agreement applies. The agreement for Emacs is not publicly posted, and a request to the GNU Project for a copy went unanswered as of this writing. Numerous copies can be found on the net, for example, including this one, which mirrors the language found in a set of template files shipped with the gnulib project:
For good and valuable consideration, receipt of which I
acknowledge, I, NAME OF PERSON, hereby transfer to the Free
Software Foundation, Inc. (the "Foundation") my entire right,
title, and interest (including all rights under copyright) in my
changes and enhancements to the program NAME OF PROGRAM, subject to
the conditions below. These changes and enhancements are herein
called the "Work." The work hereby assigned shall also include any
future revisions of these changes and enhancements hereafter made
by me.
Unlike the other agreements listed above, the FSF agreement has no requirement that the work actually be submitted to the project; it simply has to be a "change or enhancement" to the program in question. So it could easily apply to changes that were never intended to be contributed back to the original project. In the discussion started by Jambunathan, Richard Stallman has made it clear that this expansive interpretation is intentional:
Our normal future assignment contract covers all changes to Emacs.
Whether it is considered a "contribution" or a "fork" is not a
criterion.
Or, going further:
A diff for Emacs is always a change to Emacs.
I will think about the questions raised by a separate Lisp file.
It is worth noting that Jambunathan's work would be considered a submission under the language used by most projects requiring contributor agreements: he posted the code to the project's mailing list with the clear intent of contributing it. The fact that the Org mode project had not yet gotten around to including it in an official release (version 8 is due soon) and feeding it into the Emacs repository is immaterial. So the broad scope of the FSF agreement is not relevant to that particular dispute. But anybody who has signed such agreement might want to be aware that the FSF thinks it owns their changes, regardless of whether they have been publicly posted or explicitly submitted for inclusion. One could argue that entirely private changes made by a signatory to that agreement are, despite being seen by nobody else, owned by the FSF. Even an entirely separate function written in Emacs Lisp — something which is not necessarily a derived work based on Emacs and which thus might not be required to be distributed under the GPL — might be subject to a claim of ownership by the FSF, at least until Richard has a chance to "think about" the situation. That may be a bit more than some signatories thought they were agreeing to. For the record, one should immediately point out that the FSF has absolutely no known history of ever abusing this power or claiming ownership of code that was not clearly submitted to the project. But organizations can change over time and Richard, who just celebrated his 60th birthday, will not be in charge of the FSF forever. A future FSF might choose to exploit its perceived rights more aggressively, possibly resulting in regret among some of those who have signed contributor agreements (which, incidentally, have no termination provision) with it. In truth, even the FSF appears not to know what is covered by its contributor agreement; Richard had to respond to some questions from Jambunathan with a simple "I will study these questions." Whatever the outcome of his study might be, it seems reasonable to suggest that the FSF's contributor agreement may be due for a review. Even if the FSF still feels it cannot live without such an agreement, it would be good to have one that clearly defines which code is covered — and when. (Log in to post comments)
When does the FSF own your code? Posted Mar 19, 2013 15:26 UTC (Tue) by drago01 (subscriber, #50715) [Link] In truth, even the FSF appears not to know what is covered by its contributor agreementThis is a bit OT but what the FSF (and Canonical) seem to ignore in this whole copyright assignment discussion is that in some (most?) European countries (at least this is true in Austria and Germany) you cannot transfer copyright to a third party, it is legally not possible. The only way to move copyright from person A to B is by inheritance when A dies. You can grant a license to whomever you want, but you cannot assign copyright to someone else. The copyright remains owned by the author. So it seems like indeed the FSF does not seem to understand its own contributor agreement.
When does the FSF own your code? Posted Mar 19, 2013 15:40 UTC (Tue) by jelmer (subscriber, #40812) [Link]
FWIW Canonical has for a while used one of the Harmony CLAs (http://www.canonical.com/sites/default/files/active/image...), which involves providing a broad license to the code (and some other things) but no transfer of copyright.
When does the FSF own your code? Posted Mar 19, 2013 16:24 UTC (Tue) by mjw (subscriber, #16740) [Link]
I think that is covered by requiring a license if copyright alone would not be enough. My FSF papers say that the "Developer hereby agrees that if he has or acquires hereafter [...] intellectual property interest dominating the work, [...] such dominating interest will not be used to undermine the effect of this assignment, i.e. the Foundation and the general public will be licensed to use, in that program or programs and their derivative works, without royalty or limitation, the subject matter of the dominating interest. This license provision will be binding on the assignees of, or other successort to, the dominating interest [...] nonexclusive, royalty free and non-cancellable. (Sorry for any typos, only have a paper copy here.)
When does the FSF own your code? Posted Mar 19, 2013 17:03 UTC (Tue) by joshuagay (subscriber, #88423) [Link]
"you cannot transfer copyright to a third party, it is legally not possible."
It was explained to me that this is more a semantic difference than a material one.
I was told that US Copyright law is more similar to German "Exploitation Rights" laws. So an "assignment" would be about granting "exclusive right to use" a work under these laws. I was also told that German Copyright law is more like US Moral Rights laws.
When does the FSF own your code? Posted Mar 19, 2013 17:11 UTC (Tue) by drago01 (subscriber, #50715) [Link]
> It was explained to me that this is more a semantic difference than a material one.
I am not a lawyer but an agreement that states "I hereby assign my copyright of work $foo to person/company/entity $bar" is simply void. You could as well just write "nffiprfiporkwkojkfdowef3#+32313+#23+1" in the agreement it has the same effect.
As for the second part of your comment, I'd have to read up on that, thanks for the pointer though.
When does the FSF own your code? Posted Mar 19, 2013 18:16 UTC (Tue) by niner (subscriber, #26151) [Link]
You should probably talk to a lawyer about this some time. While it's true that in German and Austrian law, you cannot transfer copyright (Urheberrecht to be precise), any judge would simply ask the question what was meant by "assign my copyright". And it's very obvious that the owner wanted to give the Werknutzungsrecht (in Austria, Nutzungsrecht in Germany) to the recipient. And that's an unlimited exclusive license that effectively transfers all rights.
The only right one really cannot transfer is the right to claim authorship. So you may still say that you have written the thing, but you may not even use it without permission of the new rights holder.
IANAL myself, so really, ask a lawyer :)
When does the FSF own your code? Posted Mar 19, 2013 19:58 UTC (Tue) by hummassa (subscriber, #307) [Link]
Down here (Brasil), our Author's Rights Law says that an author or its successors can transfer all rights given by the same law, except the moral rights (basically assignment, like the right to have your name cited when your work is cited and the right to have your name excluded when the execution of your work modifies it, among others).
When does the FSF own your code? Posted Mar 19, 2013 23:09 UTC (Tue) by drago01 (subscriber, #50715) [Link]
OK if you look at it that way it makes sense but I'd rather spell out what is meant in a contract rather then hopping that a judge gets the intent right ;)
When does the FSF own your code? Posted Mar 29, 2013 22:15 UTC (Fri) by JanC_ (guest, #34940) [Link]
I don't think the owner of the exploitation rights can prevent you from using it personally: even if your author's rights won't allow it (which I doubt), you have a "legally obtained" copy already, and "fair use" allows you to use it.
When does the FSF own your code? Posted Mar 19, 2013 22:53 UTC (Tue) by Seegras (subscriber, #20463) [Link]
Yes and no. There are actually two rights: "Urheberrecht", which basically is only the right to be attributed, and "Nutzungsrecht", usage right, which covers everything else. To confuse things, both are lumped into a corpus of law generally called "Urheberrecht".
The first one can't be transferred. At all. Not even with heritage, since you can't claim you wrote it, when your father wrote it.
However, the whole discussion (and all the controversies) are about the second one, the usage rights.
When does the FSF own your code? Posted Mar 20, 2013 0:29 UTC (Wed) by marcH (subscriber, #57642) [Link]
There is similar and very common confusion in French: "Copyright" is almost always translated to "droit d'auteur" but this translation is inaccurate.
Just like pretty much everywhere else there are two quite distinct types of "droits d'auteur": the "droit moral" on one hand and the "droit patrimonial" (basically: usage/economic rights) on the other hand. The former is indeed inalienable and perpetual but the "right to copy" is only relevant to the latter.
Unlike German ones, French speakers don't have the excuse of confusing names yet most people only ever heard about the very general "droit(s) d'auteur".
While there seems to be some minor differences all this is surprisingly consistent across the world; probably thanks to the Berne convention.
When does the FSF own your code? Posted Mar 20, 2013 0:46 UTC (Wed) by neilbrown (subscriber, #359) [Link]
Chuckling to myself that if it is "droit moral" on the one hand, then maybe it should be "gauche patrimonial" on the other ... abusing language is so much fun.
When does the FSF own your code? Posted Mar 20, 2013 8:50 UTC (Wed) by mpr22 (subscriber, #60784) [Link] Not everywhere that has moral rights legislation has the "droit de retrait et de repentir", though.
When does the FSF own your code? Posted Mar 19, 2013 16:01 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
I actually wonder, without having looked at that code, whether a project should _want_ to have code from a non-cooperative developer, especially when he's the sole author of a big feature. It certainly is buggy, certainly needs maintenance, and that might be a huge burden. It's actually why I'm wary of gsoc, too, these days.
When does the FSF own your code? Posted Mar 19, 2013 16:16 UTC (Tue) by nix (subscriber, #2304) [Link]
Of course, one reason why Richard has to study these questions is that no past contributor has ever before tried something as unfriendly as Jambunathan K is trying now. Jambunathan K might want to meditate on that for a while...
When does the FSF own your code? Posted Mar 20, 2013 2:04 UTC (Wed) by brooksmoses (subscriber, #88422) [Link]
You might want to look up the history of Andy Vaught, G95, and the GCC GFortran front-end fork before making that claim.
When does the FSF own your code? Posted Mar 20, 2013 8:25 UTC (Wed) by ewen (subscriber, #4772) [Link] For the benefit of other travellers, these appear to be the two most easily found summaries, one from 2004 and one from 2007. Quick skim reading suggests that the code was "less contributed" in that case (eg, not submitted at all) than in this one (posted for inclusion, but not included in an actual official release yet). So those two situations could be distinguished from one another, on that basis, were one inclined to do so. (But as this article points out, a literal ready of the contributor agreement might say something else again, from what the common practice has been, which may arguably cover both situations.) Ewen
A bit of a mountain out of a molehill, I think. Posted Mar 19, 2013 16:32 UTC (Tue) by bkuhn (subscriber, #58642) [Link] Speaking as a member of FSF's Board of Directors, I can tell you that the FSF copyright assignment agreement is under near-constant review, and has been for decades. The agreement can be canceled by the developer and further changes made thereafter wouldn't be assigned. It sounds to me like Jambunathan is exploring whether or not he wants to cancel this assignment. That's his right, but it's interesting to note that Jambunathan hasn't canceled yet. Presumably, he is exploring the cost-benefit analysis as to whether he'd like his new code to continue to be concluded in the FSF's canonical distribution of Emacs or not. Anyway, it's unfortunate the Corbet's article above doesn't reiterate the advantages of assigning to FSF to developers. Specifically, the FSF takes on the obligation of being the publisher of the code (which can sometimes be a dangerous act in today's world), and also, FSF handles enforcement of the GPL for the codebase. Finally, FSF gives a liberal license back to the developer (i.e., Jambunathan could have always made proprietary software out of his own assigned works after doing the assignment), and FSF further promises never to publish a proprietary version of the software itself. Finally, given the liberal license grant-back and the realities of the general nature of private changes, the comment in the article about what happens with private changes seems like a red herring to me.
A bit of a mountain out of a molehill, I think. Posted Mar 19, 2013 17:05 UTC (Tue) by corbet (editor, #1) [Link] Hmm...a few points:
A bit of a mountain out of a molehill, I think. Posted Mar 19, 2013 20:23 UTC (Tue) by bronson (subscriber, #4806) [Link]
I thought the article illustrated the concerns well, and even reiterated them in the concluding paragraph. Not sure why Bradley's response missed them entirely.
Personally I'm really glad the article didn't "reiterate the advantages of assigning to FSF to developers." Even if the grumpy editor could make it interesting (it's possible!), that's hardly news.
A bit of a mountain out of a molehill, I think. Posted Mar 19, 2013 20:56 UTC (Tue) by tzafrir (subscriber, #11501) [Link]
I'm not sure I follow.
Suppose this was not Emacs. Suppose this was KDE (copyleft, no copyright assignment) or Xorg (non-copyleft).
A contributor commits code to one of the version-control repositories of those projects. As soon as this was done, the code is already published. He can't (legally) retract the code that was published (Right? AINAL). You don't need any extra permission from the author to use that code.
A bit of a mountain out of a molehill, I think. Posted Mar 19, 2013 21:35 UTC (Tue) by ewan (subscriber, #5533) [Link] True, but it is emacs, and that project requires a copyright assignment. If the author can withdraw that assignment, the project (and everyone else) would still have the right to use the code under the relevant Free software licence, but this project would have to reject it, or waive it's own rules on requiring assignment, so in this case it makes a difference to the project.
contributions without copyright assignment Posted Mar 22, 2013 22:06 UTC (Fri) by giraffedata (subscriber, #1954) [Link] A contributor commits code to one of the version-control repositories of those projects. As soon as this was done, the code is already published. He can't (legally) retract the code that was published (Right? AINAL). You don't need any extra permission from the author to use that code. I've always wondered about that. I don't think "published" affects anything at all except for when the clock starts for copyright expiration. I like to think that when someone sends a patch to a project mailing list and says, "here's a patch," but does not mention copyright at all, that there is some kind of copyright assignment or license implied, but I wonder just what, and a part of me says that under those circumstances, the project has no rights at all. I've heard of companies that immediately delete patches sent to them for their non-open-source products for fear of violating copyright by even accidentally using them.
A bit of a mountain out of a molehill, I think. Posted Mar 19, 2013 21:40 UTC (Tue) by bkuhn (subscriber, #58642) [Link] Jon Corbet wrote:by signing the FSF's agreement, one may be giving away ownership of code that was never intended to be submitted to the project, and even RMS can't say where the boundaries are. The FSF's "liberal license grant-back" (30-day notice required) may be cold comfort in such cases. I believe that issue is worthy of attention and discussion. Difficult questions about scope of copyright are always likely to receive a The FSF's "liberal license grant-back" (30-day notice required) may be cold comfort in such cases. I'd note your article doesn't say which cases you're talking about here where the license grant-back wouldn't solve the perceived problem. AFAICT, (and admittedly IANAL and TINLA), about the only thing one can't do with the license grant-back is enforce the copyright license itself (e.g., enforce the GPL). There's been a debate about the question of assignors wanting to take back GPL enforcement for themselves instead of entrusting FSF to do it, but if you're trying to relate this discussion to that one, you're being awfully (and unnecessarily) circumspect about it. And, if we're talking future works, the author could cancel the agreement anyway for future works, and then have copyright control going forward regardless. What Jambunathan is exploring is how he can stir the anthill, make a mess, and get attention. That's not really relevant here either. If you believe that it's not relevant, I'm now pretty confused why you'd use it as the primary example in your article at all. I understand you want to raise an important issue, but why use an example that you agree is designed to make mountains out of anthills (to mix our two metaphors fully :).
A bit of a mountain out of a molehill, I think. Posted Mar 20, 2013 12:47 UTC (Wed) by corbet (editor, #1) [Link] Bradley, how about the simple case where you want to own the copyright to your own code? Or what if you want to contribute it to a different project which also requires copyright assignment? I don't get why "I wouldn't want the FSF to claim ownership of code I never intended to submit to it" is such a hard thing to understand?As for why I used this example, that is easy: because it was there and easy to understand. Even a gadfly might raise an interesting issue.
A bit of a mountain out of a molehill, I think. Posted Mar 21, 2013 13:53 UTC (Thu) by bkuhn (subscriber, #58642) [Link] Jon Corbet wrote: how about the simple case where you want to own the copyright to your own code? Then don't sign the copyright assignment form in the first place, and cancel it if you change your mind.
"I wouldn't want the FSF to claim ownership of code I never intended to submit to it" is such a hard thing to understand? This is the question that RMS said himself needed further study. I can't speak for him — nor am I privy to any internal FSF discussions on this issue at this point — but I'd suspect that FSF would want to figure out a way to be flexible if possible. Indeed, I am privy to many discussions inside FSF that have been ongoing about trying to be more accommodating to the needs of contributors to FSF-copyrighted projects. However, these questions and issues are complex, FSF is a small and underfunded org with a very small staff, and therefore FSF can't change complex, time-honored policies quickly like a wealthy, for-profit company could with lots of resources to hire a team of lawyers to study complex legal questions. Most of FSF's lawyers, by contrast, are pro-bono and don't always have time to spare to give advice.
A bit of a mountain out of a molehill, I think. Posted Mar 22, 2013 4:21 UTC (Fri) by rusty (✭ supporter ✭, #26) [Link]
Your article *was* something of a beat-up, Jon.
The question at what point submissions can be revoked is a general one, not tied to CLAs, and it's come up in the past (eg. in Samba). The musing about whether the FSF owns copyright on stuff you haven't submitted seems both unimportant and an invitation to armchair lawyery.
Now, I don't like CLAs either, but this didn't really add any useful data. It read more like FSF-baiting :(
Cheers,
Not really a beat-up Posted Apr 3, 2013 16:32 UTC (Wed) by ARealLWN (guest, #88901) [Link]
IMHO I didn't feel the article was really a beat-up. It might have brought up issues that have been raised before but I feel that those might be seen in a different light given the recent events mentioned. I do feel that "The question at what point submissions can be revoked is a general one, not tied to CLAs, and it's come up in the past" is indeed a valid point but I also feel that copyright assignment and when it occurs is an important issue which is worth mentioning when it arises. Please forgive me if I repeated myself in this post.
A bit of a mountain out of a molehill, I think. Posted Mar 21, 2013 12:40 UTC (Thu) by richmoore (subscriber, #53133) [Link]
> It sounds to me like Jambunathan is exploring whether or not he wants to
> cancel this assignment. That's his right,
That's a very different response to the one that was given to the gnutls maintainer http://lwn.net/Articles/529560/
Rich.
A bit of a mountain out of a molehill, I think. Posted Mar 21, 2013 13:47 UTC (Thu) by bkuhn (subscriber, #58642) [Link] Rich wrote: That's a very different response to the one that was given to the gnutls maintainer. Rich, I believe that you're conflating two different issues: one is about a copyright assignment and the other is about a formal volunteer role with the GNU project.
Contribute statement says it is automatic if assignment papers exist Posted Mar 19, 2013 17:18 UTC (Tue) by southey (subscriber, #9466) [Link] According to the How to contribute to Org? page, unless that code is just in the contrib/ part of repository excluding the contrib/ part then the copyright has already been assigned. Granted that it is not in writing but page does say (emphasis added):If at the time you submit or push these changes you do have active copyright assignment papers with the FSF, for future changes to either Org-mode or to Emacs, this means that copyright to these changes is automatically transferred to the FSF. The Org-mode repository is seen as upstream repository for Emacs, anything contained in it can potentially end up in Emacs. If you do not have signed papers with the FSF, only changes to files in the contrib/ part of the repository will be accepted, as well as very minor changes (so-called tiny changes) to core files. We will ask you to sign FSF papers at the moment we attempt to move a contrib/ file into the Org core, or into Emacs.If the code is in the contrib/ part of the repository then the copyright assignment must depend on the actual agreement signed. Also that code would be still covered by the GPL so that the code could be distributed.
When does the FSF own your code? Posted Mar 19, 2013 20:06 UTC (Tue) by alvieboy (subscriber, #51617) [Link]
I've contributed a few times for the FSF effort in the past, and I am author of several projects released under open-source licenses, mostly BSD and GPL (v2). I'm proud of my contributions for the free software effort, but, frankly, I'm about to decline any more contributions for the foundation. I'll still release open source software and hardware, because I personally feel that there's a higher chance of my projects to survive if I do, and because I always have benefited from open-source projects, like GNU, the Linux Kernel, and other thousand more projects.
I was not aware of these restrictions to developer freedoms by the very own FSF - which claims everything should be free as in speak. What I read here is that not even the contributors get to hold any rights to *their own* ideas, code, and contributions generally speaking.
I am a fierce defendant of the individual rights. I am a strong defendant of the community progress by individual contributions, but *never*, *never* to put the individual rights in jeopardy.
You cannot transfer authoring rights in most Europe, because if you did, it would be catastrophic. Each photo is (C) its photographer, each song is (C) it's author, although the *usage rights* of the author's outcome can (and, IMHO, should not, but nevermind) be transferred to another entity (the newspaper you work for, your music editor and distributor). If, as it is right now, the music composers receive close to nothing for their creative work, imagine what would be if they gave *all* the rights to the music editors. Not only they would receive close to nothing, probably would have to pay for having their creative work on the shelves.
I am in strong disagreement with FSF, and I blame Stallman for it. I am not willing to contribute (money and moral support) to a foundation that does not respect its members, and their individual rights.
Perhaps it's time to throw a little revolution inside FSF. Or a big one.
(sorry for bad english)
When does the FSF own your code? Posted Mar 20, 2013 3:13 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] I think that you are confused. The only freedom at risk here is the alleged freedom of a developer to take back code that he already promised to give, just to be a jerk (he openly admits that he wants to make life worse for other developers).In countries that separate moral rights from economic rights, the FSF transfer agreement transfers only the latter, and furthermore they grant back the code to the author, so he/she can still use that code in a proprietary app or whatever. But your misunderstanding of what is going on has evidently led you to believe that there is some monstrous abuse taking place, though you don't seem to be clear on what that is. This is hardly a unique situation: if you publish a paper in a scientific journal, with very rare restrictions you are forced to sign a grant of rights that is far less friendly to the author than the FSF's terms are.
When does the FSF own your code? Posted Mar 25, 2013 19:51 UTC (Mon) by alvieboy (subscriber, #51617) [Link]
"Stallman Calls Ubuntu Spyware; Asks FLISOL Not to Recommend It at Events in South America"
http://www.groklaw.net/article.php?story=20130324114340352
what can I say ?
When does the FSF own your code? Posted Mar 28, 2013 16:59 UTC (Thu) by Dahoon (guest, #90115) [Link]
That Stallman is a wise man - and also correct on the subject discussed in the link - would be a good start (:
When does the FSF own your code? Posted Mar 19, 2013 23:52 UTC (Tue) by gdt (subscriber, #6284) [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. 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.
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.
When does the FSF own your code? Posted Mar 20, 2013 16:06 UTC (Wed) by dps (subscriber, #5725) [Link]
IANAL but I know my employment contract says all the rights, including the moral ones, belong to them. The propaganda I have heard it that this is standard language and whoever wrote that contract presumably *is* a lawyer.
Many other organisation have similar rules: if you, as a student, do something of commercial value at a university then expect them to take at least a substantial cut of any profit derived from it. I expect that is enforcible.
I have raised this matter and said that presumably my employers don't want to do anything to prevent their employees improving their qualifications.
Almost everywhere if you transfer a transferable right then you don't have it any more. Ergo a right transferred to the FSF belongs to them.
When does the FSF own your code? Posted Mar 20, 2013 19:01 UTC (Wed) by hummassa (subscriber, #307) [Link]
> IANAL but I know my employment contract says all the rights, including the moral ones, belong to them.
Do you live in the US? In our law (and in the Geneva internation author's rights convention IIRC) it is stipulated that moral rights are inalienable. You are not permitted to transfer them at all.
When does the FSF own your code? Posted Mar 27, 2013 5:44 UTC (Wed) by rickmoen (subscriber, #6943) [Link] Jonathan wrote:One could argue that he is almost certainly wrong and should be dismissed as an obvious troll, but there is still an interesting point raised by this discussion. Under USA statutory law, "A transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed or such owner's duly authorized agent" (17 U.S.C. section 204(a)). So, it seems reasonable to conclude that formal title passes precisely whenever that signed note or memorandum gets written and conveyed from donor to recipient. I don't believe the question of whether Jambunathan's work has yet been redistributed by the recipient has any bearing whatsoever on the ownership question, and don't understand why this is being asserted or debated. It has no obvious relevance. (The statute's phrase 'by operation of law' encompasses situations like inheritance or various other possibilities other than a sale or donation.) Best Regards,
Consideration Posted Mar 28, 2013 3:40 UTC (Thu) by SEMW (guest, #52697) [Link]
> For good and valuable consideration, receipt of which I acknowledge
Given that the FSF presumably doesn't give consideration for code contributions in general , how could that provision do anything?
IANAL (yet), but at first glance, I don't see how asserting that there's consideration, if there actually isn't, could be effective. Trying to contract out of the consideration requirement is circular - without the consideration there isn't a valid contract in the first place. (For that you need a deed). And asserting in the contract that there was consideration had and received surely isn't itself evidence of that, a court'll ask what the consideration actually was.
(Or do they? Do the FSF mail cheques for $1 or something for signing their CLA?)
The only way I can see that sentence working is some kind of estoppel by representation (the contributor represents he's been given consideration and the FSF relies on that to their detriment, so the contributor is estopped from denying that he got consideration). But that seems like a dubious argument given that the representee here knows the rep is false.
Actual lawyers (or anyone more familiar with the effect of that wording): what am I missing here?
Consideration Posted Mar 28, 2013 14:35 UTC (Thu) by foom (subscriber, #14868) [Link]
> (Or do they? Do the FSF mail cheques for $1 or something for signing their CLA?)
They actually mail you a USD $1 bill, last I checked.
Consideration Posted Mar 28, 2013 20:21 UTC (Thu) by nix (subscriber, #2304) [Link]
They certainly don't do that for everyone. Maybe only people within the US?
Consideration Posted Mar 29, 2013 11:02 UTC (Fri) by SEMW (guest, #52697) [Link]
Not all legal systems need consideration for a contract. It's possible it's only common law countries (US, England, Canada, India etc.) that need it, I'm not sure (I'm not familiar with any civil law systems). If so would that be consistent with your experience?
Consideration Posted Mar 29, 2013 15:40 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, I'm in the UK, and got the 'consideration' note in my assignments, but nothing actually accompanied it. I thought that was fishy at the time, but what the hell I have a patch to submit. :)
Consideration Posted Mar 30, 2013 17:15 UTC (Sat) by rleigh (subscriber, #14622) [Link]
I got a GNU sticker with the reply for each of my assignments, which I assumed was the "consideration".
Consideration Posted Mar 31, 2013 19:15 UTC (Sun) by nix (subscriber, #2304) [Link]
Oh. I might have got a sticker or something, but if so it was so 'valuable' that I entirely forgot about it :)
|
|||||||||||||