- Forced assignment of copyright raises the barrier to participation and therefore limits the amount of participation.
- When someone else owns rights over your work, they can do nasty things to them.
Both of these statements are true. They are also not without provisos. Richard noted that the FSF provides a promise that it will never close the software up, for instance, which makes point two a matter of diligence: if you assign your copyright to someone without anything in return, such as a guarantee of how those rights will be managed (including termination of said rights should the other party break that guarantee), then you have just made a huge mistake.
It's not all roses for projects that avoid copyright assignment, though: Richard notes the four years that the Squeak community has spent trying to get a license change through. When it comes time to defend copyrights in the legal system, it's also far more expeditious to have one entity that can represent the lion's share of rights in a project that it is to have a large number of individual (and individually supported) parties.
Unfortunately for all of us involved with Free Software, copyrights assignment is often not handled very well. Too often either too much control is given to one entity (which Richard documented quite well in his article) or nobody pays much attention at all and the project is eventually left with a mess on its hands when it comes to license management and enforcement.
There are two things, in my experience, that lead to projects not having policies in place:
- Not realizing it matters; this often happens with small projects
- Thinking that copyright assignment can't be done well, and therefore shouldn't be done at all
So, are there ways to do copyright assignment well? Yes, there are. In fact, I think KDE handles this better than most. Here's our policy in a nutshell:
- If we rely on a specific technology as a core asset (think: Qt) and the rights are owned by just one entity (think: Trolltech in the past, or Nokia today) we need a legally enforceable guarantee that it will remain open. This is the role of the FreeQt foundation, for instance.
- As a contributor, you do not need to assign your copyrights to any steering body within KDE.
- If you agree to allow KDE e.V. oversight and management of your contributions, you may voluntarily enter into a Fiduciary Licensing Agreement (a legal instrument which we were gifted by the Free Software Foundation Europe) with KDE e.V.
- If you do sign an FLA, in that same document KDE e.V. immediately returns rights back to you, so you don't really lose anything in terms of your future choices.
- KDE e.V. has a clearly documented policy as to how it is allowed to use the rights given to it in those signed FLAs
With this policy, KDE is protected, contributors who want it are protected and KDE's source code is much more easily managed and defended from a legal perspective. Those who couldn't be bothered aren't bothered, and the FLA is never used as a barrier to entry. We also are as careful with the code we use from others, ensuring it's future openness.
Now, I'm not writing this as a means to blow our own horn. I'm writing this because I am very, very concerned that copyrights (and other forms of "intellectual property") are generally handled poorly in most F/OSS projects, even large and significant ones. While at conferences, I often ask people working on F/OSS projects about their safety when it comes to working with upstream dependencies which are owned by a single entity (the "FreeQt principle") or management of their own properties. The results are pretty shocking in that there is almost never a reasonable answer to be had. Most often it is "well, we don't really have anything in place", usually followed up by "I guess we haven't really thought about it.". The rest of the time the answer is usually an overly draconian "one company owns it, we don't have any guarantees on offer to the community".
This worries me, as it puts our ecosystem at legal risk. A similar story can be written about patents, as well, but that's a different topic for another time perhaps. The good news is that we do have some groups that are emerging with good policies that work, policies that I believe we should stand up and recognize as "Best Practices" and promote across F/OSS for others to emulate. KDE is one such group, with the FLA and FreeQt foundation. Qt itself, under Nokia, is another example from the perspective of the "single owner" scenario: they have the FreeQt foundation and open governance.
"Best practice" does not mean "can not be improved", of course, but they are pretty darn good, especially relative to the status quo. We're not on our own, either: in my experience, the Free Software Foundation Europe is an impeccable resource for projects looking to implement similar practices.
It isn't an either/or situation of "control" or "safety and responsibility". You can have both and they can support each other. It just needs to be done right, and we in F/OSS need to start demanding that it is.
I'll get off my soapbox now. :)