Copyright assignment and other barriers to entry
April 8, 2009 1:04 am community, freesoftware, gnomeDaniel Chalef and Matthew Aslett responded to my suggestion at OSBC that copyright assignment was unnecessary, and potentially harmful, to building a core community around your project. Daniel wrote that he even got the impression that I thought requesting copyright assignment was “somewhat evil”. This seems like a good opportunity for me to clarify exactly what I think about copyright assignment for free software projects.
First: copyright assignment is usually unnecessary.
Most of the most vibrant and diverse communities around do not have copyright assignment in place. GIMP, GNOME, KDE, Inkscape, Scribus and the Linux kernel all get along just fine without requesting copyright assignment (joint or otherwise) from new contributors.
There are some reasons why copyright assignment might be useful, and Matthew mentions them. Relicencing your software is easier when you own everything, and extremely difficult if you don’t. Defending copyright infringement is potentially easier if there is a single copyright holder. The Linux kernel is pretty much set as GPL v2, because even creating a list of all of the copyright holders would be problematic. Getting their agreement to change licence would be nigh on impossible.
Not quite 100% impossible, though, as Mozilla has shown. The relicencing effort of Mozilla took considerable time and resources, and I’m sure the people involved would be delighted not to have needed to go through it. But it is possible.
There is another reason proponents say that a JCA is useful: client indemnification. I happen to think that this is a straw man. Enterprise has embraced Linux, GNOME, Apache and any number of other projects without the need for indemnification. And those clients who do need indemnification can get it from companies like IBM, Sun, Red Hat and others. Owning all the copyright might give more credibility to your client indemnification, but it’s certainly not necessary.
There is a conflation of issues going on with customer indemnification too. What is more important than the ownership of the code is the origin of the code. I would certainly agree that projects should follow decent due dilligence procedures to ensure that a submission is the submitter’s own work, and that he has the right or permission to submit the code under your project’s licence. But this is independent of copyright assignment.
Daniel mentions Mozilla as an example of a non-vendor-led-project requiring copyright assignment – he is mistaken. The Mozilla Committer’s Agreement (pdf) requires a new committer to do due dilligence on the origin of code he contributes, and not commit code which he is not authorised to do. But they do not require joint copyright assignment. Also note when the agreement gets signed – not on your first patch, but when you are becoming a core committer – when you are getting right to the top of the Mozilla food chain.
Second: Copyright assignment is potentially harmful.
It is right and proper that a new contributor to your project jump through some hoops to learn the ways of the community. Communities are layered according to involvement, and the trust which they earn through their involvement. You don’t give the keys to the office to a new employee on day one. What you do on day one is show someone around, introduce them to everyone, let them know what the values of your community are.
Now, what does someone learn about the values of your community if, once they have gone to the effort to modify the software to add a new feature, had their patch reviewed by your committers and met your coding standards, the very next thing you do is send them a legal form that they need to print, sign, and return (and incidentally, agree with) before you will integrate their code in your project?
The hoops that people should be made to jump through are cultural and technical. Learn the tone, meet the core members, learn how to use the tools, the coding conventions, and familiarise yourself with the vision of the community. The role of community members at this stage is to welcome and teach. The equivalent of showing someone around on the first day.
Every additional difficulty which a new contributor experiences is an additional reason for him to not stick around. If someone doesn’t make the effort to familiarise himself with your community processes and tools, then it’s probably not a big deal if he leaves – he wasn’t a good match for the project. But if someone walks away for another reason, something that you could change, something that you can do away with without changing the nature of the community, then that’s a loss.
Among the most common superfluous barriers to entry that you find in free software projects are complicated build systems or uncommon tools, long delays in having questions answered and patches reviewed, and unnecessary bureaucracy around contributing. A JCA fits squarely into that third category.
In a word, the core principle is: To build a vibrant core developer community independent of your company, have as few barriers to contributing as possible.
There is another issue at play here, one which might not be welcomed by the vendors driving the communities where I think a JCA requirement does the most harm. That issue is trust.
One of the things I said at OSBC during my presentation is that companies aren’t community members – their employees might be. Communities are made up of people, individual personalities, quirks, beliefs. While we often assign human characteristics to companies, companies don’t believe. They don’t have morals. The personality of a company can change with the board of directors.
Luis Villa once wrote “what if the corporate winds change? … At that point, all the community has is the license, and [the company]’s licensing choices … When [the company] actually trusts communities, and signals as such by treating the community as equals […] then the community should (and I think will) trust them back. But not until then.”
Luis touches on an important point. Trust is the currency we live & die by. And companies earn trust by the licencing choices they make. The Apache Foundation, Python Software Foundation and Free Software Foundation are community-run non-profits. As well as their licence choices, we also have their by-laws, their membership rules and their history. They are trusted entities. In a fundamental way, assigning or sharing copyright with a non-profit with a healthy governance structure is different from sharing copyright with a company.
There are many cases of companies taking community code and forking commercial versions off it, keeping some code just for themselves. Trolltech, SugarCRM and Digium notably release a commercial version which is different from their GPL edition (Update: Several people have written in to tell me that this is no longer the case with Trolltech, since they were bought by Nokia and QT was relicenced under the LGPL – it appeared that people felt clarification was necessary, although the original point stands – Trolltech did sell a commercial QT different from their GPL “community” edition).
There are even cases of companies withdrawing from the community completely and forking commercial-only versions of software which had previously released under the GPL. A recent example is Novell‘s sale of Netmail to Messaging Architects, resulting in the creation of the Bongo project, forked off the last GPL release available. In 2001, Sunspire (since defunct) decided to release future versions of Tuxracer as a commercial game, resulting in the creation of Planet Penguin Racer, among others, off the last GPL version. Xara dipped their toes releasing most of their core product under the GPL, but decided after a few years that the experiment had failed. Xara Xtreme continues with a community effort to port the rendering engine to Cairo, but to my knowledge, no-one from Xara is working on that effort.
Examples like these show that companies can not be trusted to continue developing the software indefinitely as free software. So as an external developer being asked to sign a JCA, you have to ask yourself the question whether you are prepared to allow the company driving the project the ability to build a commercial product with your code in there. At best, that question constitutes another barrier to entry.
At OSBC, I was pointing out some of the down sides of choices that people are making without even questioning them. JCAs are good for some things, but bad at building a big developer community. What I always say is that you first need to know what you want from your community, and set up the rules appropriately. Nothing is inherently evil in this area, and of course the copyright holder has the right to set the rules of the game. What is important is to be aware of the trade-offs which come from those choices.
To summarise where I stand, copyright assignment or sharing agreements are usually unnecessary, potentially harmful if you are trying to build a vibrant core developer community, by making bureaucracy and the trust of your company core issues for new contributors. There are situations where a JCA is merited, but this comes at a cost, in terms of the number of external contributors you will attract.
Updates: Most of the comments tended to concentrate on two things which I had said, but not emphasised enough. I have tried to clarify slightly where appropriate in the text. First, Trolltech used to distribute a commercial and community edition of QT which were different, but as the QT Software Group in Nokia, this is no longer the case (showing that licencing can change after an acquisition (for the better), as it happens. Second, assigning copyright to a non-profit is, I think, a less controversial proposition for most people because of the extra trust afforded to non-profits through their by-laws, governance structure and not-for-profit status. And it is worth pointing out that KDE eV has a voluntary joint copyright assignment for contributors that they encourage people to sign – Aaron Seigo pointed this out. I think it’s a neat way to make future relicencing easier without adding the initial barrier to entry.
April 8th, 2009 at 1:44 am
What you said about Troll Tech is not currently true.
It was technically true before, (there were all of two extra classes in the commercial version, IIRC, one for unique apps, another I don’t recall), but has not been true for months.
April 8th, 2009 at 5:08 am
The situation’s different if the owner is a nonprofit, vs. a corporation that wants the option of making the software closed source.
In the case of FSF projects, I think that the most important documents they get are not the copyright assignments, but the corporate disclaimers from the employers of the contributors. They’ve effectively assembled lots of legally binding promises from a number of companies; those companies now can’t turn around and sue the FSF for patent infringement. Likewise, companies can’t claim that the off-hours contribution of some employee is theft of the company’s “intellectual property”.
On the other hand, you’re right, the paperwork can be a barrier to participation.
April 8th, 2009 at 5:09 am
this seems to speak primarily to the copyright assignment risk to a for profit entity.
What about a non-profit like the FSF? Is the potential risk of harm less when assignments are made to an appropriately constructed a non-profit? Or do assignments to non-profits run the same risks when the “winds of change” blows through the board room?
-jef
April 8th, 2009 at 7:11 am
Like you said, copyright assignments just make another hurdle on the way to contribute to a project. That’s why I never got into Fedora, while the Ubuntu community trusts me to sign their code of conduct with a gpg key (which is easy to do in seconds), Fedora has some legalese which I need to print out, sign, go to the post office, buy an unknown amount of stamps and pray that it gets delivered. Well, I can spend my time doing other stuff…
April 8th, 2009 at 8:51 am
You are wrong about Trolltech. They never took community code and fork commercial versions off it, they did the opposite: they took their internal proprietary code and made it open source.
Significant contributions to Qt required copyright assignment to Trolltech, but most of the time, if there was a significant contributions, they would hire the guy who wrote it and/or rewrite it internally. This is how many KDE contributors became Trolltech employees.
April 8th, 2009 at 10:32 am
I think it’s very important to distinguish between assigning copyright to a for-profit corporation (like Sun requires for OpenOffice contributions) and assigning copyright to a non-profit foundation that are founded on the principle to support free software.
FSF and KDE e.V. are two very prominent examples.
You may not have heard it, but KDE went through a very tough time to relicense some old GPLv2-only code to be GPLv3 compatible. To make sure, that something like this hopefully never happens again, KDE reworked its licensing requirements: http://techbase.kde.org/Policies/Licensing_Policy
On top of that KDE has optional (!!) copyright assignment. If I was a coder, I would totally assign my copyrights to KDE eV. KDE eV was founded by the community and not by some corporations that ultimately only target profit, not freedom.
Projects like GCC work wonderfully with copyright assignment to the non-profit FSF.
April 8th, 2009 at 10:51 am
Copyright assignment is necessary because software projects need to change their licenses as time passes. Having tens of developers with copyright, can easily grow to hundreds, and then to thousands when enough time has passed in a popular project. The problem gets harder and harder over time, as the need to update/upgrade/change licenses grows over time. Future-proofing (buzzword alert!) your software really requires copyright assignment.
April 8th, 2009 at 12:35 pm
I agree with mostly with your analysis, official legal paperwork does indeed create a non-significant hurdle to contribution and often is the major reason a community doesn’t develop beyond the group that setup the original hurdle.
And there are some other solutions besides “enterprises have embraced X” to creating a open, free and safe environment for distributed collaboration around free software. Like a shared patent pool as OIN set up.
But I do think there is still a place for community-run non-profits that do. Personally a major reason to contribute to GNU projects is that I know the FSF has created an legal environment that safeguards the community (not just against outsiders, but also against insiders that have already contributed).
SCAs to for-profit organisations however seem a dead end in the long run, especially if you want to grow the community.
April 8th, 2009 at 1:20 pm
If Trolltech/Nokia, aka Qt, is not a trusted entity as it stands today, being a large body of LGPL’d work, having been a large body of GPL’d for years and years now then there’s really no hope for ever convincing you die hards that, yes, really, Qt is FOSS, and its as free to use as GTK is today. Puhleez, it went from “well its not gpl… well its not lgpl… well you have to assign copyright…” its a new excuse every step of the way. Just get it over with and say you really like the pain of rewritting C++ features in a large set of macros instead of keywords, you sadistic guy you!
Imagine if they simply decided they didn’t want copyright assignment, how much longer would it have taken to go LGPL… or how would they license commercial versions for commercial support, which by the way *pays* their small army of developers and support staff so that, me, being a paying customer, can call and get answers to lots of questions in a few hours instead of days hunting on mailing lists. Can call up and say “hey here’s a bug from me, a paying customer, fix it now” and get a patch in a day that I didn’t myself have to write. I don’t mind paying the cost for such a service when I’m trying to make money by focusing on the app I’m writting not figuring out why libraries are broken on some platform under certain conditions. They also happen to pay several developers for open source projects as well through those “evil” commercial licenses. So really, I don’t see this as a bad thing.
Furthermore, even if they simply took their cookies back, the cats out of the bag and it’ll never go back in. Qt is widely used as is GTK+, do you really think that suddenly Qt would disappear as a LGPL entity? Highly highly unlikely. Comparing it with Digium, something only one company works on and really uses/supports vs a library that thousands of people use is really just not the same.
If your going to troll on some group over copyright assignment, I’d troll on FSF the heaviest for their incredulous “we reserve the right to update the license” crap. For a community run entity thats acceptable but somehow for a corporate entity its now an evil thing? Even when after a decade of FOSS has been built around the entities main product? Really? Maybe for Digium and SugarCRM this is a more serious issue, and I agree copyright assignment to such entities can lead to possible reversal of policies and what then… will people really carry on the torch for those projects, thats the question to ask. In Qt’s case its a clear Yes. In Digium’s and SugarCRM’s maybe not so much.
April 8th, 2009 at 3:43 pm
I’ve been prevented from contributing to any number of projects (like gnutls) by the copyright assignment requirements.
The contract I received from the FSF had several scary (liability) clauses that I could not in good faith sign.
The big effect of this on the the GNU project is “cleanroom implementation” software, rather than “standing on the shoulders of giants” software.
April 8th, 2009 at 4:21 pm
Please, enough GNOME FUD. That stuff about Trolltech has never been true. They’ve always sold a commercial version. It was always their code, and they were free to do such a thing. If you contributed patches to them, you should have known that they intend to sell an additional commercial version. Even with that disclaimer, they managed to produce an excellent toolkit, the only one of its class available on Linux today. GTK+ doesn’t come anywhere close.
And even then, when they adopted some large chunk of community code, e.g., Phonon, they kept it under its LGPL license, even for the commercial offerings.
April 8th, 2009 at 4:53 pm
Bigger barriers of entry are technical, not philosophical.
So, when you remove the shitty AUTOTOOLS (in favor or CMake or other), maybe you’ll get more developers in Gnome.
April 8th, 2009 at 5:04 pm
Oulàlà! Maybe I made a mistake mentioning QT. Apparently any mention of Trolltech by someone associated with GNOME counts as anti-KDE ranting.
Alex: Please re-read what I said. Trolltech sold a commercial version, which included a small number of community contributions received from people who assigned copyright. This is indisputable. It’s objective fact. The developers who made patch submissions and signed the copyright assignment were obviously OK with that. I never said otherwise.
Tom: I specifically talked about Trolltech, in the context of dual licencing models, obviously this no longer applies in the era of Nokia & QT Software. And, for your information, many many companies work on Asterisk, not just Digium. I mentioned Digium in relation to Trolltech as a company which also used a dual licencing commercial/GPL business model with a different “community edition” and “enterprise edition”.
Bluebird: Yes, Trolltech shared the crown jewels. But they also integrated external contributions in the QT Commercial Edition. I didn’t say that they were *wrong* or *evil* for doing so. I am simply saying that this is how it was. When a company asks you to sign a copyright assignment, you have to consider whether this is something you’re OK with. That is *all* I am saying.
April 8th, 2009 at 5:17 pm
I think Dave’s post is raising a lot of important issues, and I believe we should be talking about these issues more in our community. I agree with Joe Buck’s and Mark Wielaard’s, and Markus’s comments. I also summarized some nuances about this in my blog.
April 8th, 2009 at 7:24 pm
DeeJay1,
Fedora’s CLA is now a click through in the updated Fedora account system when creating a Fedora Account. And on top of that its only necessary for a subset of possible Fedora project roles.
And I think you have some misconceptions about what Fedora’s contributor agreement actually does.
Fedora doesn’t have mandatory copyright assignments at all anywhere as far as I know. What Fedora has is a license agreement to ensure that Fedora can continue to make use of all types of contributed content..not just traditional source code that tends to come with a license already. That agreement is there to ensure a license agreement in place with every contributor so as content is contributed the Fedora project has an explicit license to continue to modify and distribute it. Fedora certainly does not make any effort to “own” your contributions.
I’ll note that this is in contrast with how Canonical does things.
http://www.canonical.com/contributors
Every single one of the projects listed on that page require you to sign over copyright ownership to Canonical before you can contribute to the codebase. The Ubuntu situation is not as cut and dry as you make it out to be. Canonical does require copyright assignment for software Canonical takes a lead development role in, including things like bzr and upstart and the yet to be open sourced launchpad.
If Canonical wanted to create a purely commercial bzr, they could as they own all the copyright assignments. Or more realistically if they wanted to in the future take community written code contributed to Rosetta component of launchpad after its released as open source and re-use it in the still proprietary Soyuz component..they will be able to as they will require copyright assignment to Canonical for all code contributions.
-jef
April 9th, 2009 at 1:22 pm
@Dave I get your point, I just don’t think its fair to say “GNU is fine, Trolltech not” when clearly Trolltech has been committed to their open source version for many many years now. To be more with your arguement though, I don’t think contributions outside of the Trolltech developers themselves were often worked in. Lately they opened the repo’s for the masses though so perhaps thats changing as well.
The commercial addons are negligible as I recall, mostly dealing with windows specific wrappers (activex?). I could be remembering incorrectly of course 🙂
April 12th, 2009 at 12:33 am
“There are many cases of companies taking community code and forking commercial versions off it, keeping some code just for themselves.”
While Trolltech did accept contributions those patches went into BOTH the commercial and open source versions which is not keeping code for themselves.
April 12th, 2009 at 11:43 pm
[…] Neary argues that copyright assignment is often not helpful, and sometimes […]