In my opinion, there is a responsibility for such organizations to identify, define and manage risks related to the responsibility of oversight of what is a very valuable item: the intellectual and creative work embodied in the software products. This is ignored only at great risk to the software, its users and those responsible for the continued development of the software. As a whole, the Free software ecosystem fails more than it succeeds in this, though it is getting better every year.
As a result, I see on a disturbingly regular basis non-profit foundations causing problems for the projects they were formed to support because such oversight was not well defined or managed. (Personally, I feel that a professionally managed service to create and build in the right oversight tools would be invaluable to the Free software community; too many hackers screw this up badly with significant consequences, which is understandable in the sense that they are hackers not lawyers or business people. Linux Foundation, FSFE: are you listening? :)
I also see copyright violations by third parties being brought into the light regularly and distributed copyright often getting in the way. One way to mitigate that is copyright management agreements, such as the FSFE's or KDE e.V.'s Fiduciary License Agreements (FLA), which empowers a trusted third party to act on contributors' behalves without removing any of their original rights while simultaneously setting out firm boundaries on what those third parties are allowed to do. (Such as: "they can't change the license to a non-Free one.")
I also see huge issues popping up around patents, with various remedies with varying levels of utility being put in place as stop-gaps while people work towards actually fixing the patent system (a lifetime's work, really). These include the Open Invention Network (OIN) and including patent clauses in copyright licenses.
Managing the risks around intellectual property law is critical to maintaining the reward of the wide open green pastures of Free software and open source development in a world of business, government and intellectual property law. I am quite firmly in favor of such risk management, to the point that I was one of the people who helped ensure KDE e.V.'s FLA came into existence and that KDE e.V. signed on with OIN.
Now, I'm not a lawyer, and as such I would never, ever give legal advice to others. I can only share my thoughts based on my experience and explain my own personal decisions so that others may, at their discretion and risk, factor them into their own thinking on the matter.
This is all a very long preamble to me making this statement:
It is my personal opinion that Canonical's Contributor Agreement program is, in its current form (as of Sept 2010), flawed such that I can not participate in it due to the risks it brings me and my Free software contributions.
I am making this statement because I was recently asked to sign Canonical's agreement, but I could not. I sent an email of declination today along with the following explanation for my decision:
Normally i would have no problem with doing this, except that the contributor agreement is flawed in a number of ways.
I'll ignore the dubious legality of "signing" the agreement by email, because that's really Canonical's risk, not mine.
However, while I can ignore that oddity, what i can't ignore are the following items in the document:
- Para 3 allows Canonical to adjust what is covered at their discretion with no boundaries. By adding an entry to http://
canonical.com/contributors Canonical gains access to my copyrights in that project. There is no express boundary or definition to what Canonical can add to that list. As a result I can not guarantee that my contributions to any possible project listed there could be held under this contract. Therefore, I can not in good conscience sign the document.- Para 4 does not provide sufficient definition of what "submited to Canonical by me" means. In this case, I committed code to a repository. How is that submitting it to Canonical? The problem here is that, due to it being so vague, that nearly anything I commit to a repo that Canonical claims maintainership of (regardless of where it is hosted, it's previous history, etc.) could fall under this wording.
- Para 6 says, "Canonical may also, in its discretion, make the Assigned Contributions available to the public under other license terms." This means that the "ordinarily" wording of the first sentence in the paragraph is a "gentleman's agreement" and not actually meaningful in the least. Canonical is fully within its rights to release such code under, for example, a proprietary license. It could hand those rights over to another party as well, given how this agreement is worded. That runs counter to the ethics I hold which have led me to dedicate my professional life to Free Software.
- Para 8 would put a legal requirement on me to notify Canonical if I even become _aware_ of any possible patent (or other IP) issues relating to my contributions. That is highly onerous, and I do not have the time or financial resources to be able to commit to such an absurd burden.
- There are no termination clauses, meaning that no matter how I feel about Canonical (or Canonical about me) or what actions Canonical (or I) perpetrate in the future, there is no clear provision for how to terminate the agreement cleanly.
Since the agreement does not allow for ammendment (see para 13), I regret that I can not enter into an agreement with Canonical based on this document. I am not opposed to such agreements in principle, as I have signed similar agreements with other parties. The material difference in those cases was that the terms were reasonable and well defined and were accompanied with clear guarantees as to how the rights I am signing over will be managed.
If Canonical can present me with a reasonable document (the FSFE and KDE e.V.'s assignment documents meet that requirement very nicely, as just two examples), then I'd be happy to sign.
I am sharing this with you, dear readers, because I am sure some of you have also been asked to sign on with Canonical's contributor agreement program and I am concerned that perhaps not all have considered the implications of the wording of their document.
The only thing worse than risk management is bungled risk management, as it creates new and unintended risk (which often means it's also undefined in scope!) for those you care most about. It's a great way of unintentionally damaging your allies and partners.
I hope Canonical produces a better document in the future, for the sake of all involved. It has the right intentions and even some aspects done "right" in my estimation (such as the license-back). As it stands now, though, it is my opinion that it is too broken to be safe for me as a Free software contributor to sign it. I do applaud their efforts to be responsible with the Free software they tend to (and wish more entities in our ecosystem would show a similar awareness of their responsibility), but another go at it with a more thorough and sound legal treatment is in order.
(This blog entry is not legal advice. :)
22 comments:
Have you seen this?
Project Harmony looks to improve contribution agreements
Since you're their upstream, you might be able to get access to drafts.
http://www.h-online.com/open/features/Copyright-assignment-Once-bitten-twice-shy-1049631.html
Copyright assignment is only OK if the FSF does it.(or maybe something as "down with freedom" and as "buyable")
@dmarti: yes, i have. it doesn't address the current situation, however. worse yet, the current agreement provides no stated mechanism for termination or migration to new agreements. it's a real (though probably unintentinal) trap.
as for access to drafts, there are much better people than me for doing so. if they are not already involved, the project will fail to produce good results. if they are involved, they don't need me. :)
i do hope that Project Harmony follows the lead of the FSFE, however, as it is quite evident that they know what they are doing, in contrast to the agreement Canonical produced in their first attempt.
@Tom: "Copyright assignment is only OK if the FSF does it."
it has little to nothing to do with who does it. what's important is how it is done.
it just happens that the FSF (and even moreso imo, the FSFE) does it well.
if other entities do it similarly well, then it can be highly productive.
KDE e.V. provides legal backing and demonstrably valid representation (through membership) for KDE, and as such is the best entity to provide IP oversight for KDE properties and products. KDE e.V. has done it well, mostly thanks to following the FSFE's lead quite closely, availing ourselves of proper legal expertise and making it opt-in rather than mandatory.
it doesn't matter that it isn't the FSF, it matters that it was done right.
that article you link to is all about doing it wrong. and as far as that goes, i agree with it. but others can, and do, manage to do it "right" as well.
Why did you have to sign the copyright assignment?
It's unusual for community members to have to sign it.
Imho, if they paid for the work, they should be allowed to own the copyright and release it under other licenses if they want to.
I agree with you that some of the clauses are way to harsh and open though.
@Jonathan: "Why did you have to sign the copyright assignment?"
because i contributed to a project that they funded, and that is their stated policy.
"if they paid for the work, they should be allowed to own the copyright and release it under other licenses if they want to."
agreed. however, they didn't pay me for my work. i voluntarily gave it to them. then there was a mix-up and their licensing group decided that they should collect a contributor agreement from me. sort of trying to close the barn door after the horses have already escaped, but i really would have no issue with it if the agreement was sensible. unfortunately, it isn't something i can sign.
@aseigo:
I had the very same problem with C.s copyright assignment, I never signed it, because I never got an answer of their legal department about those statements you mentioned (especially the patents one).
Right now, I can only advise anyone to not sign this paper (virtually or in paper form).
But this has nothing to do with Canonical, but their wording of this "agreement".
Regards,
\sh
To me it just looks like Canonical wants to maintain it all options open in the future to close the source.
There are two options.
1. Canonicals lawyers does not know how to write a good OSS agreement.
2. They are trying to be a cunning with the words to maintain their own goals over the ones of the OSS community.
I would want to believe that it is about 1. but what Canonicals actions shows, I am afraid it is the 2.
How many software developer actually reads those licenses very carefully and weights every word what is used in them? The words in the legal agreements are on the field of lawyers and little bit different word can overthrow the control to other party with such meanings what almost any normal user does not even recognize as a trap.
It is good that someone brought this up to KDE as well. I believe there has been many denying the agreement but has not brought it to public.
@Aseigo: Thanks for the answer. I agree.
Do you think the Sun MySQL, OO.org agreement is also good?
@ Aaron,
I concur and have raised this with Mark Shuttleworth via his blog. http://www.markshuttleworth.com/archives/517#comment-334031
Well, what would you expect from a company that's sinking as Novell is?
There's really too many lawyers and general counsels who are justifying their existence with these bits of paper, or not bits of paper, as the case might be.
Is this your code that they removed? Or is this related to something totally different?
http://bazaar.launchpad.net/~agateau/libdbusmenu-qt/trunk/revision/177
Canonical would love to have you donate your copyright. One can expect them to try for it. Even if they have no intention of including your work in their distribution, they may still ask for the donation. What have they got to lose?
But if you generate code under the GPL that Cannonical finds to be of value to them, then they will happily use your copyrighted material under the terms of the GPL. Remember, the Linux kernel was not generated under Canonical's contributor agreement program, and they use that, don't they?
@Leigh: "What have they got to lose?"
respect and trust.
when you offer someone a blatantly abusive legal agreement it is a sign of incompetence, malice or, at the very least, a fundamental misalignment of priorities between the two properties.
that said, i'm less concerned about Canonical here and more concerned about other F/OSS contributors who may not be as experienced in or careful with legal issues such as these entering into an agreement that, if they understood it, would be quite opposed to.
this blog entry is a warning light to my fellow F/OSS contributors.
though that also shines a light on what Canonical has to lose here: contributors.
"But if you generate code under the GPL that Cannonical finds to be of value to them, then they will happily use your copyrighted material under the terms of the GPL."
no, actually they wont. they removed the code i contributed. Kubuntu folk have added it back for Kubuntu with a patch to the package. (!)
"Remember, the Linux kernel was not generated under Canonical's contributor agreement program, and they use that, don't they? "
the Linux kernel is also not a "Canonical owned" project, markedly different than how they view projects like libdbusmenu.
I haven't really been following this, but I wonder: Did this change happen before or after Matt Asay boarded the C bus?
I wrote this before but blogspot errored out and ate it :-( so this one will be a bit shorter.
First off, I work at Canonical but I'm not speaking for them here and I'm not a lawyer.
Para 3 allows Canonical to adjust what is covered at their discretion with no boundaries.
Only to projects which are already Canonical-owned; they can't claim arbitrary code of someone else.
Para 4 does not provide sufficient definition of what "submited to Canonical by me" means
I agree; it should be more clear there's a "please merge this" intention; just putting it on the web shouldn't count.
Canonical is fully within its rights to release such code under, for example, a proprietary license. It could hand those rights over to another party as well, given how this agreement is worded.
Correct. Also, to change to a non-FSF-approved free licence; to forgive GPL-terminating violations; to reassign to the FSF, etc.
Para 8 would put a legal requirement on me to notify Canonical if I even become _aware_ of any possible paten
I don't think this is onerous. You don't need to know about all possible patents or even any patents; you just need to tell Canonical if you do realize your change probably violates a patent. If you never think about patents you're in compliance.
there is no clear provision for how to terminate the agreement cleanly
Presumably you would then stop submitting changes, but an option for explicit termination could be clearer.
does not allow for ammendment
There can be updates. Canonical just doesn't want a bunch of individually-amended agreements.
@mbp: "I wrote this before but blogspot errored out and ate it :-("
doh! :/
"Para 3 allows Canonical to adjust what is covered at their discretion with no boundaries.
Only to projects which are already Canonical-owned; they can't claim arbitrary code of someone else."
that isn't what paragraph 3 says, however. it may be what was intended, but it actually says "all computer programs created as part of a Canonical programme" without defining what "a Canonical programme" means or what "part of" means either (owned? funded? cooperating with a partner?)
the only proviso is that it includes the copyright owned by Canonical. nothing in there about exclusive ownership, etc.
"Canonical is fully within its rights to release such code under, for example, a proprietary license. It could hand those rights over to another party as well, given how this agreement is worded.
Correct."
and that is a deal breaker.
"Also, to change to a non-FSF-approved free licence; to forgive GPL-terminating violations; to reassign to the FSF, etc."
which would be fine if those were the limits as clearly defined somewhere with revocation of rights by Canonical upon violation.
this isn't a gentleman's agreement, it's a legal instrument meant to be used for legal purposes (business, courts, etc)
"Para 8 would put a legal requirement on me to notify Canonical if I even become _aware_ of any possible paten
I don't think this is onerous. You don't need to know about all possible patents or even any patents; you just need to tell Canonical if you do realize your change probably violates a patent. If you never think about patents you're in compliance."
yes, i understand i don't have to be aware of all possible infringement, but i do not have the time to tell every single person i work with every single time i come across a patent that my work may infringe on. there are too many patents and i work with too many people to deal with this kind of requirement.
there's also the sticky mess of "if i become aware of a patent in the course of an NDA'd effort", in which case i'd be in the situation of violating one agreement or the other.
i'm fine granting a no-patent-aggression clause, but i can not reasonably commit to being Canonical's patent ward. yes, it'd be nice for Canonical for me to do that, but i don't get anything out of it, Canonical isn't saying they'll do the same for me and i couldn't do this for everyone i work with.
"there is no clear provision for how to terminate the agreement cleanly
Presumably you would then stop submitting changes,"
that would only impact _new_ contribution. not past contribution. if Canonical (today's Canonical or tomorrow's Canonical) decides to do something i simply can't agree with (e.g. taking my code proprietary), there is no avenue for recourse.
if Canonical decides to place a project on http://
canonical.com/contributors that i had been contributing to up until then, there is no way provided in that contract to make it null at that point, preventing those works of mine from being sublimated into Canonical's control.
that is simply unacceptable.
"but an option for explicit termination could be clearer."
that would be a pre-requisite to me signing it, or recommending others to do so.
(con..)
(... continued)
"does not allow for ammendment
There can be updates. Canonical just doesn't want a bunch of individually-amended agreements. "
that's sensible, but as such there's very little i can do other than communicate my concerns (which i did by email) and warn others of the hot sticky mess of a trap that this agreement currently is.
i do hope that the folks at Canonical do hurry to place an update to the agreement such that it becomes something a sensible F/OSS contributor can engage with Canonical via it.
instead we just have theo dd case of my changes being shipped in Ubuntu's repositories as a patch in the rpm, because patches-to-rpm's apparently don't need copyright assignment. on top of that there's a fork of the code on gitorious that also include my contributions. all because of an amateurish legal performance.
Presumably you would then stop submitting changes," that would only impact _new_ contribution. not past contribution.
That's true, but it seems totally impractical to have people retrospectively withdraw code they previously assigned.
@mbp: "That's true, but it seems totally impractical to have people retrospectively withdraw code they previously assigned."
not randomly withdraw (which would be totally impractical indeed), but withdraw if the other party (e.g. Canonical) oversteps bounds.
e.g. if they add a project to their list and claim it as "theirs" (thanks to the vague wording on that), it becomes useful to be able to terminate the agreement at that point, even though it is over code previously contributed.
and if there were reasonable verbage in the agreement (or in a sibling document, ala the FSFE's FLA) stating that Canonical will only use the re-licensing rights within Free software licenses, then such a mechanism for termination becomes a way to ensure there is penalty for transgression.
it's really combination of the rest of the agreement being overly vague and ill-defined without any escape hatches provided to compensate. one really needs to provide one or the other (or both).
You're not a lawyer if you signed on with OIN, obviously, Did you read the agreement? Just lost a ton of respect for KDE, and as a KDE packager that hits me kinda hard.
Synergy: "Did you read the agreement?"
Yes, as have the lawyers.
"Just lost a ton of respect for KDE"
Care to explain what your objections are, exactly?
I find that in these cases it's often a misunderstanding as to what OIN does and how it works.
Post a Comment