Weekly Edition
Return to the Front page
| |||||||||||||
Project Harmony decloaks
The "Project Harmony" name has a long and not entirely encouraging history;
it is usually applied to projects aimed at obnoxious licensing situations
(examples being Qt and Java), and the projects have, on the face of it,
failed to achieve their goals. The most recent use of this name looks like
a variation on that theme: this project, which seeks to create a set of
standard agreements for contributors to open source projects, has been
widely derided as a secretive attempt by a specific vendor to push
copyright assignment policies on the community. During a session at the
Linux Foundation's Collaboration Summit, this project came out and actually
showed the world what it has been doing.
Harmony was represented by none other than Allison Randal, perhaps best known for her work on Parrot and her current role as the technical architect of the Ubuntu distribution. Allison has put her hands into the legal realm before; among other things, she played a major role in the creation of version 2 of the Artistic License. She joined Harmony as a community representative prior to taking the job at Canonical, and, she said, she still is not representing her employer in this endeavor. The idea behind Harmony is that contributor agreement proliferation is no better than license proliferation. A lot of the agreements out there are poorly thought out and poorly written; they are also causing developers to sign away a lot of their rights without always knowing what they are agreeing to. Corporate lawyers are also getting tired of having to review a new and different agreement every time an employee wants to participate in a new project. A smaller set of well-understood agreements, it is hoped, would make life easier for everybody involved. Allison started off by stating that the project recognizes "none of the above" (no contributor agreement at all) as an entirely valid option. The Linux kernel was cited as an example of a successful project without an agreement in place, even though the kernel does, in fact, use the Developer's Certificate of Origin as its contributor agreement. The real point, perhaps, is that the Harmony project does not believe that its agreements are suited to every project out there, and that there will always be reasons for some to use something else. Assuming that one of the project's agreements are used, contributors (and the projects they contribute to) will agree to a number of conditions, many of which can be thought of as standard. Both sides disclaim any warranty, for example, and the contributor has to certify that he or she actually has the right to contribute the code. There is a "generic" patent grant which applies only to the contributed code itself. After that, though, there are a few options which must be selected for each specific project, starting with how the code is to be contributed. There are two choices here:
Missing from this list of options is one which says "the project may use this code under the terms of its open source license, and needs neither ownership nor a broader license to do so." Those are the terms under which many projects actually accept contributions. A similar effect can be had with a proper selection among the other set of options, but it's not quite the same. The second choice controls what the project is allowed to do with the contributions it gets under the agreement. All of the options require the project to release the contribution under the project's license if the contribution is used at all; the sort of "we will ordinarily release your work under a free license" language found in Canonical's contributor agreement is not present here. Beyond that, though, the project can choose between the promises it will make to contributors:
The agreement also allows the specification of an additional license to apply to the "media" portion of any contribution. The intent here is to allow documentation, artwork, videos, and so on to be licensed under a Creative Commons license or under the GNU Free Documentation License. After describing the agreements that the project has produced, Allison acknowledged that Harmony "failed" at marketing its work. In an attempt to do better, the project has set up a web site describing the agreements and allowing the public to comment on them. Comments will be accepted through May 6; there will be a meeting held on May 18 at the Open Source Business Conference to discuss the next steps. The discussion in the room made it clear that there is some marketing work yet to be done. It's still not clear who was participating in the project, and it seems unlikely that the mailing list archives will be made available. There was a strange and tense interlude during which some members of the audience tried to bring out who actually drafted the agreements. It turns out that the Software Freedom Law Center had participated in the discussion, but had explicitly withdrawn (for unstated reasons) from the writing of the legalese. It eventually came out that the author of the agreements was Mark Radcliffe, who is a bit of a controversial figure in this area; his previous works include Sun's CDDL license, the SugarCRM badgeware license, and The CPAL badgeware license. Bradley Kuhn also said that Mark has defended GPL violators in the past - a history which makes Bradley rather nervous. The unsolved mystery of who actually paid for Mark's time doesn't help either. Ted Ts'o suggested, though, that, now that the agreements are public, they should be read and judged on their own merits rather than by making attacks on the author. Bradley had another complaint: the current agreements, with all their options, look a lot like the Creative Commons agreements. Some of them are more moral than others, but there is no moral guidance built in, and no way to guide projects away from the least moral alternatives. It will be, he say, confusing for developers. Just like "under a Creative Commons license" says little about what can be done with a work, "a Harmony agreement" does not really, on its own, describe the terms under which contributions are made. It took ten years, he said, to make some sense of the Creative Commons "quagmire"; the Harmony agreements will create the same sort of mess. Allison responded that we already have that kind of mess, only worse. Ted said that, with the Harmony agreements, at least we'll have a set of reasonably well understood contracts which don't suck. We may disagree about some of the choices, he said, but they will at least be built on a decent base. He expressed hopes that Harmony would help end the problem of developers blindly signing away their rights. What happens now depends, at least partly, on how the discussion goes; now that comments are in the open, the project will need to either respond to them or risk discrediting the entire process. Anybody who has an interest in this area should probably read the agreements and submit their comments; the alternative is to live with whatever they come up with in the absence of your input. (Log in to post comments)
Project Harmony decloaks Posted Apr 11, 2011 16:23 UTC (Mon) by aliguori (subscriber, #30636) [Link]
I really hope they remove some of the options. For those that haven't looked, the options are 1) turn over copyright with no promise on future licensing 2) promises to only relicense under ____ 3) relicense under an OSI approved license 4) relicense under a FSF approved license.
I don't think it makes a ton of sense to have (2) and yet also have (3) and (4). You can also collapse (1) into (2) by saying "any license we choose".
Project Harmony decloaks Posted Apr 11, 2011 18:25 UTC (Mon) by tetromino (subscriber, #33846) [Link]
> I don't think it makes a ton of sense to have (2) and yet also have (3) and (4)
You are assuming that the set of OSI- and FSF-approved licenses will never change. That is an unwarranted assumption. Entirely new free licenses might appear, new versions of existing non-free licenses might become free, and new versions of existing free licenses might become non-free. The future is unpredictable, and licenses can evolve in strange directions.
Project Harmony decloaks Posted Apr 12, 2011 9:48 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
I think they meant that you could get rid of (3) and (4) and just keep (2)
______ can be replaced by "an FSF approved license" just as easily as by any other text. So having these explicit options serves no legal purpose.
If we envisioned this as a web form, it might be slightly easier to click (3) than to pick "an FSF approved license" but if this is to be paperwork that requires signatures and so on then you've shaved a few seconds off what's perhaps several hours of work.
Project Harmony decloaks Posted Apr 19, 2011 11:18 UTC (Tue) by jamesh (guest, #1159) [Link]
While it might make sense to make the legal jargon similar for the four options, there is value in having separate names for the four contributor agreements. That way people can easily communicate the intent of the agreement with the name, rather than requiring you to read through and see which option has been checked in a multi-choice template agreement.
Project Harmony decloaks Posted Apr 11, 2011 16:28 UTC (Mon) by AlexHudson (guest, #41828) [Link]
Interesting that the article repeats the "has been widely derided as a secretive attempt by a specific vendor to push copyright assignment policies on the community" meme without mentioning the actual vendor involved :)
I think the main problem with this effort is that $vendor aside, there really isn't much demand for these types of documents at the copyright-assignment end of the scale. It feels like they've created a spectrum to make their end seem more acceptable, when most of the projects I can think of that use them (Fedora, Zend Framework, etc.) are clustered at the other end and many simply don't use such documents.
Seeing copyright-assignment as simply another choice on the spectrum is just plain wrong. It isn't, there's a huge divide there, and frankly it wouldn't even be appropriate (IMHO) for the FSF to be doing it if they didn't have the long history and non-corporate status that they do have.
Project Harmony decloaks Posted Apr 11, 2011 18:45 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
I think you've hit on the next battle ground. For those of us who see problems with assignment policies, we'll have to decide how we deal with Harmony. When Harmony releases its final documents we'll all have to decide if we can support Harmony as a concept to simplify the legalese while at the same time continuing to speak out against the specific Harmony options which we do not find acceptable.
The real danger here is that support for the simplification aspects of Harmony will turn into an out-of-context sound bite to imply support for all Harmony options by those who want to continue to make use of assignment.
I'm not sure people who agree with Ted Tso's and who are trying to highlight the benefit of simplification and publicly praise Harmony for the simplification work will continue to be authentic voices of criticism if they also speak out against specific Harmony options. Mixed messaging about Harmony won't help to push back against an encroachment of business interests on the interests and rights of contributors.
Harmony does nothing to address the trade-offs of giving entities proprietary re-licensing rights to contributed code. The devil remains in the details, even if the language is simplified. And I think everyone should be wary of championing Harmony in the abstract. And if you do decide to champion Harmony, go out of your way to be specific about which of licensing options to lift up.
-jef
Project Harmony decloaks Posted Apr 12, 2011 5:22 UTC (Tue) by skvidal (subscriber, #3094) [Link]
What are you talking about wrt fedora forcing copyright assignment.
the CLA and the FPCA are not copyright assignment agreements:
http://fedoraproject.org/wiki/Legal:Fedora_Project_Contri...
are you referring to something else?
-sv
Project Harmony decloaks Posted Apr 12, 2011 7:04 UTC (Tue) by AlexHudson (guest, #41828) [Link]
I didn't say it was a copyright assignment agreement - in fact, I specifically said it was totally different.....
Project Harmony decloaks Posted Apr 12, 2011 13:00 UTC (Tue) by skvidal (subscriber, #3094) [Link]
then I must have misunderstood.
Project Harmony decloaks Posted Apr 12, 2011 19:28 UTC (Tue) by rfontana (subscriber, #52677) [Link]
I initially read your comment the way skvidal did, though I then realized what you were saying.
Fedora, in fact, is not simply using an agreement at the other end of some spectrum of contributor agreements, in some static sense. It has actively moved away from the maximalist approach to contributor agreements represented not only by copyright assignment agreements but also by that style of CLA popularized by the Apache Software Foundation.
Project Harmony decloaks Posted Apr 11, 2011 16:53 UTC (Mon) by josh (subscriber, #17465) [Link]
What purpose does copyright assignment serve, versus just retaining the copyright and granting an all-permissive license? If the project requiring a contributor agreement has permission to do anything they want with the code, why would they also need to hold the copyright on all of it?
(Presumably the project already holds the copyright on some of the project code, which should allow them to enforce the project's license on that basis.)
Project Harmony decloaks Posted Apr 11, 2011 18:42 UTC (Mon) by tetromino (subscriber, #33846) [Link]
> What purpose does copyright assignment serve, versus just retaining the copyright and granting an all-permissive license?
The ability to file lawsuits. If the project holds the copyright, it can sue (or decide to not sue!) those who violate the terms of the license.
Project Harmony decloaks Posted Apr 11, 2011 19:05 UTC (Mon) by josh (subscriber, #17465) [Link]
As I said in my comment, I assumed the project already held some copyrights, which gives them standing to file a lawsuit over copyright infringement. (As evidenced by the many GPL violation suits by people who hold a subset of the copyrights in a project, such as Busybox and Linux.)
You make a good point about the ability to *not* sue, though; copyright assignment does indeed ensure that the original contributor can't sue, at least not without going through the copyright assignee first. However, the article here points out that Project Harmony's agreements (can) include a covenant not to sue; as long as that extended to third parties, and handled the case where the project has the right to offer a different license than the original contribution, that would remove the need for copyright assignment as a way of preventing the original contributor from suing.
Any other reasons a project would want to hold the copyrights rather than just having an agreement in place?
Project Harmony decloaks Posted Apr 11, 2011 23:13 UTC (Mon) by cyd (guest, #4153) [Link]
> as long as that extended to third parties, and handled the case where the project has the right to offer a different license than the original contribution
The easiest way to do that is a copyright assignment.
Project Harmony decloaks Posted Apr 12, 2011 0:00 UTC (Tue) by josh (subscriber, #17465) [Link]
That doesn't make it the right way, just the easy way. A project that wants to solve these problems only one time and get everyone to adopt the solutions ought to get the solution right.
Project Harmony decloaks Posted Apr 17, 2011 16:54 UTC (Sun) by daf (subscriber, #27590) [Link]
I don't understand the need for covenants not to sue. Are contributors and projects suing each other? Over what?
Project Harmony decloaks Posted Apr 11, 2011 19:13 UTC (Mon) by jmm82 (guest, #59425) [Link]
If they want to change the license or sell exceptions the would have own copyright to whole project.
Project Harmony decloaks Posted Apr 11, 2011 21:51 UTC (Mon) by bradh (subscriber, #2274) [Link]
Changing / upgrading the license (e.g. GPLv3 -> GPLv4) is probably the only real reason for a true community project.
If you have a commercial + contributor type project, then there are a lot of potential reasons.
Project Harmony decloaks Posted Apr 12, 2011 4:26 UTC (Tue) by wahern (subscriber, #37304) [Link]
It's not just merely to bring a law suit. Each author of a joint work has an independent right to grant nonexclusive licenses. So if you and I were joint owners of project Foo, I could grant a nonexclusive license to Microsoft to use the entire work even if it was your intention that our work only be licensed under the GPL. You could sue me, but not Microsoft (and Microsoft might even be able to indemnify me).
This is why the FSF wants all the copyrights. When they bring a suit they don't want damages, they want an injunction. But all the company being sued needs to do is pay some random joint author for a nonexclusive license and then the company is effectively off the hook as long as they can absorb any monetary damages. That joint author must account for payment received by sharing with all the other joint authors, but that hardly changes the equation.
Also, things get very muddy when you're talking what constitutes a joint work, versus a collective work, versus an insubstantial contribution. If you're the FSF that makes negotiating with an infringer more difficult. It you want the threat of litigation to be taken serious, you need to get rid of all of those sources of doubt and confusion.
But note that most people cannot actually transfer all of their interest to the FSF or anyone else. An author of a work not done as a work for hire (as with much Free Software) has an inalienable termination right. (See S.203 of the Copyright Act.) 35 years after the original transfer or license an author can unilaterally terminate those rights. Counting from 1985, that means that by 2020 it's possible (though I suppose very unlikely) that some people would rescind their grants to the FSF.
In fact, it's theoretically possible for someone to even rescind their GPL licenses! This is why lawyers say that it's impossible to put something into the public domain--if you die your successors can exercise that termination right. But there are lots of technical issues--like notice--with terminating license to an indeterminate number of people.
Project Harmony decloaks Posted Apr 12, 2011 13:54 UTC (Tue) by pboddie (subscriber, #50784) [Link] It's not just merely to bring a law suit. Each author of a joint work has an independent right to grant nonexclusive licenses. So if you and I were joint owners of project Foo, I could grant a nonexclusive license to Microsoft to use the entire work even if it was your intention that our work only be licensed under the GPL. You could sue me, but not Microsoft (and Microsoft might even be able to indemnify me). Do you have a link to something that actually states this is possible? It seems to me that any author only holds the copyright to their own contributions, and you can't release the other authors' contributions under a different licence than the one they've applied to their own work themselves. Although Microsoft could claim that they've licensed the entire body of code in good faith, it doesn't mean they have successfully acquired the right to use it under those terms, just like someone acquiring stolen goods, for example, isn't entitled to keep them upon it being pointed out that such goods are indeed stolen, even if they did buy them from someone who claimed complete ownership of them.
Project Harmony decloaks Posted Apr 12, 2011 14:15 UTC (Tue) by Trelane (subscriber, #56877) [Link]
s.a. Jeff Merkey.
Project Harmony decloaks Posted Apr 12, 2011 16:20 UTC (Tue) by pboddie (subscriber, #50784) [Link]
Can you be more specific? Searching for the name brings up various "Jeff Merkey is on <social networking service>!" pages and all the peripheral parasite services referring to those pages, plus gossip about some incidents around the turn of the century which may have something to do with the person in question trying to "buy Linux".
Project Harmony decloaks Posted Apr 12, 2011 16:22 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Jeff Merkey spent some time trying to find someone with copyright over some portion of the kernel who would sell their copyright to him. The implication was that he planned to claim that the kernel was a joint work (rather than a collective one) and that he would then use his rights to sell proprietary licenses to the kernel to anyone who didn't want to follow the GPL.
Project Harmony decloaks Posted Apr 12, 2011 16:37 UTC (Tue) by corbet (editor, #1) [Link] See this article from 2004.
Project Harmony decloaks Posted Apr 12, 2011 16:40 UTC (Tue) by Trelane (subscriber, #56877) [Link]
Ha. You beat me to it; I was going to post precisely that. :)
Project Harmony decloaks Posted Apr 12, 2011 16:49 UTC (Tue) by Trelane (subscriber, #56877) [Link] The money quote is Unlike many other large free software projects, the kernel does not require any sort of copyright assignment from contributors. Those who get code merged into the kernel retain their copyrights on that code. As a result, the kernel has hundreds - if not thousands - of copyright holders. Getting them all to agree on a licensing change would be a challenging task. Simply finding them all is likely to be beyond just about anybody's capabilities.(bolding and italicizing mine) Of course, this assertion does not provide any references to back it. OTOH, he'd hardly need to track down every contributor if only one could relicense the entire work as they wished. Indeed, there would almost certainly be a GPLv3-licensed and a BSD variant as well. That they do not exist suggests heavily that a single contributor cannot simply relicense the whole multi-contributor project as they wish. (If I understand the original assertion correctly). Jeff Merkey's attempt to relicense a single snapshot of the Linux kernel is only a prominent example of the concept.
Project Harmony decloaks Posted Apr 13, 2011 8:34 UTC (Wed) by pboddie (subscriber, #50784) [Link]
Right. So as I thought, a bunch of random contributors can't be considered to be co-authors of a "joint work", which for all I know is a concept peculiar to certain jurisdictions. Indeed, merely accepting contributions which are appropriately licensed might well be a strong indication that each contributor regulates their own work and how it is used, severely undermining any claims that everyone is acting as a single entity whose intentions can be subverted by paying off one or more contributors.
I still think contributions through the normal practice of distributing code under a project-compatible licence is the way to go: that way, a project and its contributors have equal standing, and no extra magic is required. Indeed, as others have pointed out, there needs to be some convincing justification for having that extra magic around.
That said, a set of bumper stickers to communicate that magic (or lack thereof) would be a helpful thing, and maybe that could be the principal benefit of the initiative in question.
Project Harmony decloaks Posted Apr 12, 2011 17:17 UTC (Tue) by wahern (subscriber, #37304) [Link] The law that governs joint works is almost entirely Common Law. The 1976 Copyright Act punted because the issues become extremely complex. The House Report on S. 201 (Ownership of Copyright) had this to say: There is also no need for a specific statutory provision concerning the rights and duties of the coowners of a work; court-made law on this point is left undisturbed. Under the bill, as under the present law, coowners of a copyright would be treated generally as tenants in common, with each coowner having an independent right to use or license the use of a work, subject to a duty of accounting to the other coowners for any profits. As far as I remember the only portion of the Copyright Act which has anything substantive to say is the definition of a joint work in section 101: A "joint work" is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole. 17 U.S.C. 101. But you have to understand that there are "joint works", "collective works", "compilations", "works for hire", and a host of other legal definitions that touch upon how rights are apportioned. What you describe is more like a collective work, but it's certainly possible to have a joint, collective work. Whether something is or is not a joint work can be an extremely contentious issue among judges and scholars alike. (I have a PDF of Title 17, including all the committee commentary, that I found on a Congressional FTP server. I don't have the link anymore, though.) The best case I can find on the subject of joint work licensing says: A co-owner may grant a non-exclusive license to use the work unilaterally, because his co-owners may also use the work or grant similar licenses to other users and because the non-exclusive license presumptively does not diminish the value of the copyright to the co-owners. Davis v. Blige, 505 F.3d 90, 100 (2d Cir. 2007) The court goes on to explain that to grant an exclusive license the co-owners must [unanimously] agree. (If I said majority earlier I got that wrong, it seems.) The reasoning and dicta in that case actually bolsters my point. It involved a joint work where one co-owner tried to retroactively grant a license to an infringer. The appellate court wouldn't allow it for all the obvious, intuitive reasons (notwithstanding that the trial court bought the argument). But my argument isn't about retroactive licensing, it's about prospective licensing to cut off injunction. I didn't spot any citations or holdings on foreclosing injunction, but it stands to reason and it's entirely in harmony with the 2d Circuit's explication. But I AM NOT A LAWYER, and I'M NOT GIVING LEGAL ADVICE. I'm just a programmer and law school student. Needless to say, if you ever have a serious legal question, talk to a practicing attorney. At least they have insurance you might be able recover against if they screw up.
Co-owners? Posted Apr 14, 2011 14:19 UTC (Thu) by david.a.wheeler (guest, #72896) [Link]
I'm not a lawyer, but I can throw in my two cents.
I suspect that the Linux kernel is NOT an example of co-ownership in the legal sense. I think co-ownership means that multiple people JOINTLY hold the copyright to the same larger work. But that's not the case here. Copyright can only be assigned to someone else (including a group) by a written agreement, and there's no such agreement in this case. What's more, there are clear records of who contributed what, so at least in principle you can found out who contributed what (see "git blame", though obviously that is imperfect). Therefore, there is no co-ownership. So presumably the copyright for each patch continues to be held by the contributor.
So what we have is a bunch of separate works, the copyright of each is held by different people.
I think this is bolstered by Linus Torvald's statements over the years explaining why he does NOT want copyright assignments. Courts are supposed to examine the intent of the community, when there is one.
But I'm not a lawyer. I'd love to hear what a REAL lawyer would say.
Co-owners? Posted Apr 15, 2011 15:26 UTC (Fri) by butlerm (subscriber, #13312) [Link] So what we have is a bunch of separate works, the copyright of each is held by different people.That may be the case with regard to a module or driver written substantially by one contributor, but it isn't remotely sustainable with regard to unitary subsystems with hundreds of patches from many contributors. By any reasonable standard, for a work to be "collective" rather than "joint", each individual contribution must have some independent merit as a work in and of itself. See the definition of "joint work" in 17 USC 101. The termination rights issue here is an interesting one, but it is worth noting that termination requires majority consent of those with termination interests in a work. This is unequivocally a good thing. It means that several decades from now a contributor might be able to terminate a license to a contribution (such as a driver) that has independent merit, but would require tracking down and obtaining the consent of at least a majority of other contributors to terminate an interest in a portion of the total work that many have contributed to. See 17 USC 203(a)(1).
giving legal advice Posted Apr 15, 2011 22:29 UTC (Fri) by giraffedata (subscriber, #1954) [Link] I'M NOT GIVING LEGAL ADVICE Sure you are. What else would you call it? But there's nothing wrong with a nonlawyer giving legal advice. If there were, pretty much everyone would be in trouble. What you're trying to avoid, because you aren't licensed for it, is practicing law. Giving legal advice is practicing law when you do it in a way that someone could think he's getting professional advice. Having said you're not a lawyer, you've completely covered your ass. But you wasted your time even on that sentence, because nobody has a right to assume a comment from a stranger in a forum like this is professional advice. Actual lawyers have to be a little more careful in making sure people can separate their professional advice from their other legal advice (because the former carries liability for correctness), but not much. It's usually pretty obvious when you haven't engaged a lawyer.
Project Harmony decloaks Posted Apr 11, 2011 16:59 UTC (Mon) by josh (subscriber, #17465) [Link]
One positive thing about these agreements: they only offer "all-permissive license" or "copyright assignment with all-permissive license back to the contributor", both of which allow the contributor to do as they wish with their own code; they don't offer an agreement which restricts the contributor's use of their own code.
On the other hand, this does indeed seem like it conveys a lot of legitimacy to the more restrictive copyright transfer agreements, by presenting them as variations on more reasonable options.
When, exactly? Posted Apr 11, 2011 19:40 UTC (Mon) by JesseW (guest, #41816) [Link] I'm a bit confused. You (and all the other announcements) refer to a discussion at the Linux Foundation Collaboration Summit involving Allison Randal explaining the Harmony Project. I can't find any such discussion on the schedule (linked above). Which day was the session?
When, exactly? Posted Apr 11, 2011 20:03 UTC (Mon) by rfontana (subscriber, #52677) [Link]
Allison Randal spoke at the very end of the 'Legal' track moderated by Bradley Kuhn on Thursday afternoon. Her talk was not part of the original schedule.
When, exactly? Posted Apr 11, 2011 21:08 UTC (Mon) by allison (subscriber, #56202) [Link]
I asked Bradley if I could hang out and answer questions after the Legal track, and he generously went the extra mile and offered me his closing discussion slot for a presentation.
Thanks to all for the valuable feedback, not just on the agreements themselves, but on project structure, transparency, and more. We're working on integrating changes, so please keep letting us know how we're doing and how we can improve.
Thanks to you both. Posted Apr 12, 2011 0:09 UTC (Tue) by JesseW (guest, #41816) [Link]
I thought it was probably one of those sessions. Thanks for the prompt clarification!
a dissenting opinion: this is useful Posted Apr 11, 2011 21:22 UTC (Mon) by zooko (subscriber, #2589) [Link]
> projects aimed at obnoxious licensing situations (examples being Qt and Java), and the projects have, on the face of it, failed to achieve their goals. The most recent use of this name looks like a variation on that theme
Jon, that is below your usual standard of fairness. Fortunately the rest of the article was up to your usual standards of fairness.
For what it is worth, I'm happy that they've done this work and I expect to make use of it in the future. The variant which seems closest to what the Tahoe-LAFS project has been doing so far is the one where "The contributor grants a broad license to the project, but retains ownership of the contribution." and "we can use it under any license we choose". It might be better to switch to "The contributor transfers ownership of the contribution to the project and gets, in return, a broad license for further use of it." and "we can use it under any license we choose", so that we (in this case the Tahoe-LAFS Software Foundation) have standing to sue people who use it without satisfying the licence.
By laying out the options like this (and by Jon's recounting of them in this article), it has helped me to think more clearly about what I want. Thanks!
Also, by having a widely-known, widely vetted agreement that we can point to it will facilitate communication between us and contributors about what each side wants. Thanks again!
And yes, both in the old way and the new way we would retain the ability to give or sell proprietary licences.
I know there seems to be a consensus among a certain circle of people that this is a terrible bad idea and/or evil, but I doubt that is the consensus among larger groups of people. I, for one, certainly don't agree to that.
a dissenting opinion: this is useful Posted Apr 11, 2011 22:28 UTC (Mon) by cmccabe (subscriber, #60281) [Link]
> For what it is worth, I'm happy that they've done this work and I
> expect to make use of it in the future....
> And yes, both in the old way and the new way we would retain the
Since, as I understand it, Tahoe-LAFS is designed to be used in hosted environments, the practical difference between BSD and GPLv2 is pretty small. Why not just license the system under the 2-clause BSD license, and forget about copyright assignment? The BSD license allows you to sell all the proprietary add-ons you want.
Personally I don't have a problem with most of the OSS licenses out there. But if I contribute code under a certain license, I would like it to stay under that license, and not morph into something else. It's only fair.
a dissenting opinion: this is useful Posted Apr 11, 2011 22:49 UTC (Mon) by zooko (subscriber, #2589) [Link]
> Why not just license the system under the 2-clause BSD license, and forget about copyright assignment? The BSD license allows you to sell all the proprietary add-ons you want.
That would allow anyone to sell proprietary derivatives, which is not what we (speaking loosely for the collective group of Tahoe-LAFS contributors) want.
On the other hand we (again, loosely speaking) don't mind if one specific entity, formerly allmydata.com and currently The Tahoe-LAFS Software Foundation has the ability to sell proprietary derivatives.
> But if I contribute code under a certain license, I would like it to stay under that license, and not morph into something else. It's only fair.
So how would you feel about contributing code to Tahoe-LAFS under the "proposed new agreement" that I sketched out? "The contributor transfers ownership of the contribution to the project and gets, in return, a broad license for further use of it." and "we can use it under any license we choose"
Again, I find it really useful to have this terminology to refer to.
Regards,
Zooko
a dissenting opinion: this is useful Posted Apr 11, 2011 23:16 UTC (Mon) by wingo (subscriber, #26929) [Link]
With very much respect to your work on Tahoe-LAFS, I don't think that I would contribute with any copyright assignment conditions. I'll do FSF assignments, but I don't even like those. (Speaking as a GNU maintainer, even.)
a dissenting opinion: this is useful Posted Apr 12, 2011 1:45 UTC (Tue) by zooko (subscriber, #2589) [Link]
You won't contribute to projects (excepting GNU) with *any* copyright assignment? So, of the menu of options described in Jon Corbet's article here, you won't agree to any in which the first choice is "The contributor transfers ownership of the contribution to the project and gets, in return, a broad license for further use of it." but will agree to some of them in which the first choice is "The contributor grants a broad license to the project, but retains ownership of the contribution."?
Or did you mean something else?
For the third time, I'd like to emphasize that I'm very glad the Project Harmony folks have done this work so that we can have this conversation. It would be a shame if my licensing policies were turning off potential contributors unnecessarily.
Regards,
Zooko
P.S. When I create a project for facilitating collaboration among Software Freedom-loving pirates I'm going to name it "Project Arrrrmony".
a dissenting opinion: this is useful Posted Apr 12, 2011 2:26 UTC (Tue) by corbet (editor, #1) [Link] Copyright assignment policies do tend to turn off contributors, especially when the beneficiary is a for-profit corporation. That's part of why quite a few companies and projects have moved away from the practice. I wrote about this issue some in late 2009; Michael Meeks's article on the topic is also well worth reading.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 12, 2011 4:17 UTC (Tue) by zooko (subscriber, #2589) [Link]
Thanks, Jon. I've read these articles when they came out and I just now read them again for good measure.
I recognize that there are legitimate concerns, especially several of the sagas around SunOracle (which you, Jon, correctly predicted and which I at the time dismissed as FUD).
But on the other hand, I think the community consensus on lkml and lwn.net is too one-sided.
My own experience with Tahoe-LAFS is that whenever contributors would offer patches that were substantial, I would politely ask them if the for-profit company that I then worked for (allmydata.com) could please have the rights to do whatever we wanted with the patches. With two exceptions they all said "sure". The two exceptions said they didn't want to give those rights to a for-profit company, and so we said "fine". (Their two contributions were in auxiliary modules rather than in the core and they turned out to be modest.)
It didn't seem to me that anybody was deterred from contributing because of my practice of asking for this permission, and it didn't seem to me that we suffered from communication problems because of it.
My experience in this parallels the recollections of L. Peter Deutsch about Ghostscript in his interview with Stig Hackvan: http://devlinux.org/deutsch-interview.html . (Note: Raph Levien told me in personal communication that later there were problems with Ghostscript's dual-licence model which is why they changed it to be GPL-only. However, I don't remember him telling me specifically what the problems were and his recollections aren't in the public record where I can look them up and cite them.)
Re-reading Michael Meeks's article today gives me more reservations about his position. For example, he says it took a few weeks to get his first copyright assignment to FSF and then his patch languished without review or merge for years, which deterred him from contributing further. Then he says that he wondered if the delay due to copyright assignment partially caused the larger delay. Well maybe, maybe not! The real deterrent was the years of not-accepting his patch, not the weeks of waiting for paperwork, and failure to review a patch happens far too often, with or without copyright assignment.
For another example, he cites the existence of XEmacs as a demonstration that some people prefer not to assign copyright (in this case to FSF for GNU Emacs). Okay, that's fair, but at the same time the greater rate of contributions to GNU Emacs and the more vibrant community of contributors must be taken as a demonstration that some people are fine assigning copyright and this doesn't necessarily derail a project.
I just think we don't need to be doctrinaire about this. Maybe one size doesn't fit all. Maybe it's okay if some projects try different copyright assignment policies.
Almost all open source projects fail to attract any contributors at all, and that's true regardless of whether they require copyright assignment or not. A few open source projects attract lots of contribution, and both approaches are present in that set too.
People have asked me how I succeeded at attracting contributions to Tahoe-LAFS. My answers are: (a) we just got lucky, (b) we had (and have) an exciting and potentially important system with working code (which was more due to Brian Warner than to me), and (c) our community is friendly and polite.
Regards,
Zooko
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 12, 2011 7:09 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
I don't think you can ignore the ample examples of major projects including Openoffice.org, Upstart and Java where copyright assignment agreements have caused significant strain on the project and forks or alternatives that explicitly promote the fact that there is no copyright assignment required in their projects. Libreoffice and systemd being the most recent examples of this.
Yes, you might able to get away with it and yes, it might not have affected your project much but it is not easy to assert that and I do wonder how many didn't even bother to send patches because they were aware of this requirement. If you want to lower the barrier to entry and create a neutral ground for all contributors that doesn't favor one company or individual over other, then I would certainly recommend that you consider dropping it.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 3:11 UTC (Wed) by vonbrand (subscriber, #4458) [Link] In the upstart -- systemd case there was not really a fork (there are several "dependency-based" init systems floating around in any case), but a fundamental technical difference in handling of dependencies. The other cases are as you state, AFAIU.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 3:54 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
I did say forks or alternatives. You seem to have overlooked that.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 16:31 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
I still think its a stretch to lump in systemd and upstart into this argument. I think the difference of opinion there is primarily one of technical design not the politics of copyright. The assignment issues around upstart may have complicated things and kept people from communicating, but I'm not sure removing the assignment policy would have changed the course of events. At least that is my reading of things.
I think it weakens the argument you are making to include them as examples, unless you can point to some sort of previous discussion in the context of upstart development where good-faith contributions from contributors were turned aside by the assignment policy requirement. I'm not aware of that ever happening.
I think what is happening right now with LibreOffice stands up by itself as an unfolding relevant case study to make the point.
Though I would like to see if the clutter development experience has something interesting to add. When clutter dropped its assignment policy did contributor activity rise in a noticable way?
A certain individual has argued in private with me that business entities,such as the one that previously required assignment to clutter, only drop the assignment requirements after they are no longer incentivised to lead the development. Essentially the argument made to me was that dropping assignment is a "we wash our hands of it..throw it over the wall..and let the community have the scraps" action on the part of most business entities. Pardon me from interpretatively paraphrasing from a private conversation. I did have the foresight to obtained permission to archive and republish the short conversation. You can read the argument in the context of the conversation from Sept, 2010 here:
I don't think opinions on the matter have changed. The people who walked into the Harmony discussion in favor of for-profit assignment still feel that way. The people who came in against it, still feel that way.
Nor do I think Harmony as drafted are going to change the character of the dispute. Harmony is a codification of the battlelines. I know some people are _hopeful_ that some for-profit entities who switch from in-house contributor agreements to Harmony drafted agreements will be choosing more contributor friendly options. But I don't see any evidence of that. And I don't plan to give any for-profit entity the benefit of the doubt on that score. Whether you choose a Harmony statement or not is not important. It is the specific choice and the details that matter. I don't plan to pat any entity on the back for choosing a Harmony option that requires assignment to a for-profit with sufficient promisebacks to protect the long term interests of the uncompensated contributor.
The Harmony drafts allow for pretty much all the bad for-profit behaviour that is currently allowed now. At best Harmony will make it easier to identify. At worst Harmony will give for-profits political cover that they can hide behind when their choose unfair/unbalanced assignment policies instead of the more reasonable Harmony options.
-jef
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 17:26 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
"I think it weakens the argument you are making to include them as examples, unless you can point to some sort of previous discussion in the context of upstart development where good-faith contributions from contributors were turned aside by the assignment policy requirement. I'm not aware of that ever happening."
Technical design might be the more important reason for systemd but it is clear that copyright assignment requirements played a role and while what you have suggested is one way to look for the impact, I think it is far from the only way. For instance, the questions one can ask include, how many developers were turned away from ever submitting patches because of the requirement? Among the active systemd developers, which ones felt more motivated to systemd because it explicitly advertised the fact that no copyright assigned is required? Did it influence adoption by distributions? and so on. I don't purport to know the answers to these questions but I disagree that it is not a valid example although it might not be as big a instance as Openoffice.org vs Libreoffice.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 17:34 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
"What ifs" when it comes to trying to estimate the number of people who refused to engage because of assignment is difficult to use effectively as a rhetorical tool. We don't have a reliable measure or even estimate on that. From a strategic messaging standpoint I shun making that particular argument unless I can find at least one example of a specific contribution submitted in good faith which was turned away because an assignment wasn't agreed to. I have such historic examples for other codebases that require assignment. I don't have one handy for upstart.
-jef
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 18:07 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
My goal is not rhetoric or strategic messaging or whatever. I can reliably point out that when systemd was launched, the first blog post describing the project pointed out the lack of copyright assignment as a advantage when comparing itself to upstart and it is clear that developers involved view it as such. No doubt about that and that by itself establishes the negative impact.
Whether patches submitted to a project were rejected on the basis of such a requirement is not a very interesting way to measure the impact as far as I am concerned because anyone who looks at contributing to a project and realizes there is a requirement to assign copyright would just not bother submitting any patches in the first place. If you are interested enough, you can talk to the developers involved and find out more. I have but there is no public reference for you so you will have to do the leg work yourself to find out more.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 18:06 UTC (Wed) by zooko (subscriber, #2589) [Link]
> I do wonder how many didn't even bother to send patches because they were aware of this requirement.
I'm pretty sure this wasn't the case, as we didn't publicly mention this requirement anywhere.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 18:40 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
I remember discussing the strategies for copyright assignment for this project with you right here in LWN which is a public forum and if you haven't mentioned such a requirement in the developer oriented documentation, you should and do so prominently. I would consider it cheating and would be deeply disappointed if I spend time and effort writing a patch for a project only for the maintainers to let me know after the fact, that need me to sign over a legal agreement that grants them rights to use the code however they please before accepting my patch.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 20:08 UTC (Wed) by zooko (subscriber, #2589) [Link]
It's not so much a "requirement" as a polite request. Two people politely declined, around a dozen or so (including all of the most prolific and valuable contributors) readily agreed. I don't want to complicate the developer documentation and distract people from writing code by adding that fact to the developer documentation.
Which, I suppose, definitely proves one of the points against such contributor agreements. Perhaps I should reconsider and add a mention about that to the developer docs.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 21:01 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Requests are entirely different than a codified requirement.
I think its entirely ethical for a central authority, even a for-profit one, to make that sort of request as long as they contributor really does have the ability to say no. As long as the incorporation of contribution in question is not held up because of a lack of requested assignment, then I don't see a problem with.
I have no problem with contributors choosing to gift their copyrights as long as its a gift freely given with no explicit or implicit strings attached with regard to their standing as a contributor or the incorporation of their submitted work.
-jef
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 14, 2011 5:02 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
"It's not so much a "requirement" as a polite request."
Unless you would accept a patch without the contributor signing the legal agreement, I would say it is still a requirement albeit a politely worded one. There is nothing inherently wrong with requirements as long as they are explicit.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 14, 2011 14:54 UTC (Thu) by zooko (subscriber, #2589) [Link]
Actually we *did* accept patches to add-on modules without this grant of rights. I don't actually *know* if we would similarly accept patches to the core without that grant of rights. Maybe somebody reading this should test my resolve by writing some really awesome patches and then offering to support them in Tahoe-LAFS but not to grant us all the rights. :-)
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 12, 2011 7:55 UTC (Tue) by spaetz (subscriber, #32870) [Link]
> I would politely ask them if the for-profit company that I then worked for (allmydata.com) could please have the rights to do whatever we wanted with the patches. With two exceptions they all said "sure".
Why don't you just license your project under an MIT license then? The issue that I see, is that of complexity. Licensing is already hard to understand. Even for lawyers, not to speak of code contributors. So when there are licenses out there that can solve the goals that you have in your project, why not simply use these?
By introducing *another* complex legal document that interacts with the first one, the legal subleties become so complex that they are very hard to grok.
Reading the harmony options is hard, then thinking about how those options interact and interfere with the rights and limitations set out for various licenses is HARD:
I know all these questions are probably answered somewhere, but they are questions that come on top of licensing issues, and that puts me off.
Using 2 complex legal agreements when most of the goals can be reached with a single one does not sound appealing to me, I mean there are plenty of people who haven't even fully gotten the GPL, and now you expect contributors to become lawyers just to submit a bugfix? :-)
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 12, 2011 13:52 UTC (Tue) by wahern (subscriber, #37304) [Link]
"If I contribute as part of my job, is it legal for me to sign away my copyright (ie in might be my employers copyright in the first place and they might have opinions about giving away their copyright)."
I scanned over the text of one of the documents and what struck me was that the contributor represents that he has authority to transfer the copyright. That means that if you're wrong, they're protecting their ability to sue you. Such things are boilerplate in rights transfers, but what, exactly, are you getting out of the exchange for potentially opening yourself up to more or easier liability?
With that clause in there, unless there's no doubt about your rights in the work (i.e. you're unemployed and a hermit), a prudent person should think twice about making such an open ended representation without any compensation.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 12, 2011 21:22 UTC (Tue) by wahern (subscriber, #37304) [Link] Looks like the FSF assignment has similar representation language:I hereby represent and warrant that I am the sole copyright holder for the Work and that I have the right and power to enter into this contract. I hereby indemnify and hold harmless the Foundation, its officers, employees, and agents against any and all claims, actions or damages (including attorney's reasonable fees) asserted by or paid to any party on account of a breach or alleged breach of the foregoing warranty.(http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/assign.changes.manual) Fraud is illegal. Erroneously authorizing rights is also illegal, and has the same strict liability as use infringement. Subject to sections 107 through 122, the owner of copyright under this title has the exclusive rights to do and to authorize any of the following.... 17 U.S.C. 106. It just seems a little gratuitous for individual contributors (as opposed to corporate contributors) to indemnify the FSF when the contributor already has every motivation to be honest. A lone programmer is not much of a target for litigation, but the FSF is a larger target, and by indemnifying the FSF a contributor has significantly increased their own exposure. But I guess if the chance of the FSF actually being sued is miniscule, it hardly matters. Interestingly, the Ubuntu agreement seems much more favorable to the contributor: 9. I have not created or assigned to Canonical the Assigned Contributions in breach of My employment or any other contract.(http://www.canonical.com/system/files/Canonical%20Contributor%20Agreement%2C%20ver%202.5.pdf) Two noteworthy differences here. There's no express indemnification. But also the catch-all clause 10 requires knowing breach or infringement, which is infinitely more fair to the contributor. So unless he gets wrong the work for hire status or other contractual interest in the contribution (strict representation in clause 9), his exposure is much less. Although, the applicable law is nominally English law according to clause 12. But unless English law implies those things just discussed then on first blush, kudos to Ubuntu.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 14, 2011 2:26 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]
You're not reading the indemnification language correctly. The only thing you're indemnifying the FSF for is if it turns out that your claim that you are the sole copyright holder turns out to be incorrect (e.g. you passed off others' work as your own).
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 14, 2011 4:04 UTC (Thu) by wahern (subscriber, #37304) [Link]
Right. But that can happen accidentally. But per the terms it doesn't matter whether it was an accident or not.
By way of example, let's say that hypothetically some court says that interfaces are copyrightable, like Oracle claimed for Java. All of a sudden that contribution of code implementing the Java API is infringing. Or rather, it was always infringing, but only now do you know that.
Or you're an employee of a software company. The free software code you wrote happens to be so related to your company's business interests that it falls within the scope of your employment, so the code is theirs. The FSF probably tries to screen these people in their questionnaire, but they can't always be right about it.
There are tremendous grey areas in copyright law, and the FSF clause shifts most of the repercussions of this onto you. That's its very purpose. If they didn't want to do this, they would have qualified it with a variant of something like "known or should have known". The Ubuntu language, "to the best of my knowledge", is even more pro-contributor.
Also consider that you're indemnifying for any "alleged breach." So maybe you were in the right, but the FSF chose to settle out of prudence. You're still on the hook. But now let's say you can find a way around the language, or that my interpretation is totally bogus. My interpretation isn't so bogus that you won't be forced to spend thousands of dollars on an attorney to make your case.
But now let's say that we all agree none of the FSF officers would ever willing do any of this. (Which probably goes without saying.) I don't know much about non-profit governance, but if it were a for-profit corporation the benevolence of the officers doesn't matter much. If they don't sue they could possibly be on the hook for shirking their duty to protect the corporation.
None of this is worth discussing anymore, though. Frankly, I was just surprised that these organizations would use this language, and even more surprised that Ubuntu didn't. In reality we all take much greater legal risks every day.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 14, 2011 9:53 UTC (Thu) by mjw (subscriber, #16740) [Link]
Not disputing that there are always legal risks in whatever activity you do, but I think at least some of your worries in this case are somewhat covered.
> it was always infringing, but only now do you know that.
In my contract with the FSF it explicitly says "(to the extent known to Developer)".
> The free software code you wrote happens to be so related to your company's business interests that it falls within the scope of your employment, so the code is theirs.
They also send you a separate company disclaimer of rights which you can then let your company sign. You can keep that on file (or also send to the FSF) to show they were aware and approved of your actions.
> Also consider that you're indemnifying for any "alleged breach."
In the FSF contract I got it says "Developer is not obliged to defend FSF against any spurious claim of adverse ownership, but will cooperate with FSF in defending against any such claim"
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 13, 2011 21:43 UTC (Wed) by zooko (subscriber, #2589) [Link]
> Why don't you just license your project under an MIT license then?
Because we didn't want (other) companies to be able to make proprietary derivatives and redistribute them. At least not without paying us.
in defense of "contributor agreements" or whatever they are called nowadays Posted Apr 21, 2011 16:04 UTC (Thu) by farnz (guest, #17727) [Link] At a really, really trivial level: I work for a company that uses Linux. When I work on an open source project, I am permitted by my contract of employment to contribute my work upstream under the licences the upstream project offers me, provided my employer retains ownership of the copyright. If you ask for a copyright assignment, I have to get the Board of Directors to approve the resulting paperwork. So, I can contribute to the kernel under GPLv2, to X.org under their permissive licence, without going up to the top; I can't contribute to GCC easily, due to the need to get copyright assignment in place, although I can offer a patch under GPLv3 or any later version as long as my employer retains the copyright. Practically, this means I'm keen on throwing patches at upstream if they don't need copyright assignment, and doing major rewrites as needed to get them to take the feature, where I don't have to maintain it (I'm in the middle of a rewrite for upstream now - and doing the work requested has explained and indicated a fix for at least one bug). If you need copyright assignment, I'm going to be put off contributing due to the hassle.
a dissenting opinion: this is useful Posted Apr 12, 2011 8:28 UTC (Tue) by wingo (subscriber, #26929) [Link]
Hi Zooko,
It's something of a moot point, as I haven't hacked Tahoe-LAFS. But yes, other than to the FSF, and in a pinch to some other organization with similar structure (non-profit), credibility, and guarantees (that my code would not be used in proprietary software), I would not do assignment under any conditions. It's too unequal of a transaction.
Even if I wanted to permit my code to be used in proprietary software, I would not assign: an MIT or similar license should be sufficient.
I would enjoy listening in to a conversation between you and Meeks, some time ;-) He's really on-message these days about the evils of copyright assignment, and I basically agree with him.
a dissenting opinion: this is useful Posted Apr 12, 2011 8:30 UTC (Tue) by wingo (subscriber, #26929) [Link]
I should clarify that, in the case of allowing my code into proprietary software, I meant an MIT or similar license /on my contribution/; the terms applying to the work as a whole could obviously be different.
a dissenting opinion: this is useful Posted Apr 14, 2011 15:10 UTC (Thu) by zooko (subscriber, #2589) [Link]
Dear wingo:
Context: I'm currently in the midst of constructing a non-profit foundation for Tahoe-LAFS and also a business of my own. The business doesn't have any special access to licensing—it is so far a pure open source strategy. (Perhaps a bit of a rare beast nowadays.)
Although, there would be nothing preventing my business from in the future *buying* a license to use Tahoe-LAFS in a proprietary way from the foundation! I think Mozilla gets some funding that way, although I'm not sure. If anyone could confirm or deny I would appreciate it.
(Of course the Tahoe-LAFS Software Foundation, which is not controlled by me, would have to agree to sell such a licence.)
Let's see, so you are strongly averse to letting your code be used in proprietary software at all. That's easy to understand. So for example if the non-profit foundation sold rights to make proprietary derivatives then you wouldn't want to contribute your patches to that project at all, right?
Does this also imply that you never contribute patches to any code base which isn't copyleft? No BSD/MIT/Apache-licensed contributions from you?
Another interesting twist to this whole thing is the Transitive Grace Period Public Licence. That licence is like the MIT/BSD/Apache licence in that it allows people to make proprietary derived works, *except* that they are required to release their derived work under the TGPPL within 12 months. So it is a sort of time-delay copyleft. How would you feel about contributing code to a project that used that? http://tahoe-lafs.org/~zooko/tgppl.pdf
Tahoe-LAFS itself is currently distributed under your choice of GPLv2+ or TGPPLv1+:
http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/READM...
Thanks for sharing your thoughts about this issue.
Regards,
Zooko
a dissenting opinion: this is useful Posted Apr 14, 2011 15:22 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
There is a important difference between a entirely permissive licensed codebase and a copyleft codebase where a single entity has the right to sell proprietary licenses. In the former, everyone has the same rights but not in the latter case.
a dissenting opinion: this is useful Posted Apr 14, 2011 16:34 UTC (Thu) by zooko (subscriber, #2589) [Link]
> There is a important difference between a entirely permissive licensed codebase and a copyleft codebase where a single entity has the right to sell proprietary licenses. In the former, everyone has the same rights but not in the latter case.
Yes, of course, but wingo didn't indicate that *that* was his concern. I guess there are many separate concerns here and different people care about different ones. It makes it easy to argue past each other I bet.
a dissenting opinion: this is useful Posted Apr 25, 2011 14:12 UTC (Mon) by wingo (subscriber, #26929) [Link]
Hi Zooko,
Thank you for your reply, and apologies for the delay in the response.
The question at hand is not my aversion to having my code be used in proprietary software; while it does exist, it's not an overpowering concern. I mostly work on Guile these days, which is an LGPL project, so it can form part of a proprietary application. I contribute code under other, more permissive licenses occasionally as well, though it's not my preference. I prefer to work towards a world of sharing, and copyleft is one way to do that. The TGPPL is another way; not as good, but it could be warranted, strategically.
No, my real concern is about the way in which the different contributions come together. Are we on equal footing or aren't we? If we are, then let's all work together, cooperating via the permissions we grant in the licenses, but with no need to assign to some other party. What having a contributor agreement says to me is that "in this project, some contributors are more equal than others." Obviously a properly-governed foundation as the holder mitigates this to a degree, but I don't even think that the FSF assignment policy is necessary for any purpose, and is clearly detrimental to getting casual contributors.
Regards,
Andy
a dissenting opinion: this is useful Posted Apr 25, 2011 14:38 UTC (Mon) by zooko (subscriber, #2589) [Link]
Thank you very much for sharing. That's very interesting. :-)
a dissenting opinion: this is useful Posted Apr 12, 2011 14:40 UTC (Tue) by clint (subscriber, #7076) [Link]
I'm in the same boat. Furthermore I'd advise anyone who isn't being given substantial monetary compensation for such contributions to fork the software rather than sign such an agreement.
a dissenting opinion: this is useful Posted Apr 12, 2011 20:03 UTC (Tue) by ballombe (subscriber, #9523) [Link]
I agree. Maybe an alternative to money would be getting voting rights in the organization that receive the agreement with each contributions and require that some actions of the organization (including relicensing) be subject to a vote with says, at least 35% quorum and 65% voters approval.
a dissenting opinion: this is useful Posted Apr 13, 2011 3:19 UTC (Wed) by zooko (subscriber, #2589) [Link]
That's an interesting idea. I wonder how people would decide how many voting rights you get for a given contribution, though? By voting, I guess! I would be interested to see someone try something like that.
Project Harmony decloaks Posted Apr 12, 2011 14:08 UTC (Tue) by clugstj (subscriber, #4020) [Link]
I wouldn't call this "decloaking", when the author of the agreements is a shady character who won't even say who paid him to write them. This isn't really a good way to build trust.
Project Harmony decloaks Posted Apr 13, 2011 0:09 UTC (Wed) by gdt (subscriber, #6284) [Link] Most lawyers are guns for hire, that doesn't necessarily say anything about their character. I can't imagine any lawyer volunteering the name on a cheque used to pay for their work, they would see that very much as part of lawyer-client privileged material and would want to be forced by a court order. However, there is no reason why Project Harmony itself could not reveal its sources of funding and its brief to its lawyer.
Project Harmony decloaks Posted Apr 13, 2011 12:26 UTC (Wed) by clugstj (subscriber, #4020) [Link]
"Most lawyers are guns for hire, that doesn't necessarily say anything about their character."
I would say that that says everything about their character.
Project Harmony decloaks Posted Apr 15, 2011 15:44 UTC (Fri) by butlerm (subscriber, #13312) [Link] I would say that that says everything about their character.That's a pretty credible claim, if you, yourself, abstain indefinitely from ever working for another party as an agent, employee, or independent contractor. Nice world to live in where you have no fiduciary responsibility to anyone else. Master of your own ship, captain of your own soul - no one can tell you what to do. So there.
Project Harmony decloaks Posted Apr 27, 2011 9:24 UTC (Wed) by wvholst (guest, #67089) [Link]
As someone who provided input to the various authors of the agreements, I find this rather offensive. As far as I understand it none of the contributors to the agreements are 'shady' characters.
Project Harmony decloaks Posted Apr 13, 2011 0:39 UTC (Wed) by gdt (subscriber, #6284) [Link] Also notable is the patent grant: You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the Patent Claims, with the right to sublicense... That's a bit different to a commercial patent grant. Firstly, you don't get access to the patents of "Us" in return. Secondly, you can't terminate the patent license should "Us" sue you concerning one of their patents. I wonder if either of those terms commonly seen in commercial agreements is worthwhile for a free software agreement. I'd argue that the second term should very much be included.
Project Harmony decloaks Posted Apr 15, 2011 16:01 UTC (Fri) by butlerm (subscriber, #13312) [Link] Firstly, you don't get access to the patents of "Us" in return. Secondly, you can't terminate the patent license should "Us" sue you concerning one of their patents.The first item should be part of the license used by the project as a whole. You would be foolish to sign away patent rights unless you have at least an implicit license to the patent rights of other contributors necessary to use the resulting software. I agree the second part should be a standard component of any patent license or transfer to a commercial party, again with regard to the patents necessary to use the software itself. A blanket license to any and all patents of a commercial enterprise isn't likely unless you have patents to license in return.
Project Harmony decloaks Posted Apr 14, 2011 16:05 UTC (Thu) by ssam (subscriber, #46587) [Link]
do people need to care about copyright assignment? take openoffice as an example. Sun hasd very strict rules about what got into the official OOo tree. Various people wrote patches that sun did not want. they lived outside in go-oo. once this reached a critical mass it was able to split into libreoffice.
thats slightly oversimplified, but the group hurt most by the copyright assignment was sun/oracle. the opensource community just moved on.
now suppose company X has written some nice opensource but copyright assignment requiring program (perhaps a flashy DE, or boot manager). want to contribute without signing the agreement. just make a branch, DVCSs make it easy. you get all their patches, they refuse to accept yours. you win.
|
|||||||||||||