Quick links
- Overview & Rationale
- An early problem
- Autobiographical Ramblings
- Copyright Assignments
- Weighing Risks vs. Benefits
- Counter examples
- Picturing a Dystopia
- Alternatives to Corporate Assignment
- Recommendations
- Conclusion
- Further Reading
Overview & Rationale
The collaborative model of Free Software development has taken the world by storm; increasingly corporations are contributing to the FLOSS world, and opening up large existing code-bases, while exploring many well-trodden ways of making a return on their investment. This is, of course, to be welcomed. Copyright assignment is one of the perennial tools chosen in the equation around monetization, control, and risk.
This is particularly relevant today; as we are seeing something of a resurgence of interest - with several stake-holders developing a trend towards promoting copyright assignment - even where it was not required previously. I try to bring the perspective of a long-time, pragmatic Free software advocate to the topic, which (of course) intersects with both licensing and governance. This at least, is how I try to understand this area. Hopefully some little experience in the signing, and soliciting of both personal and corporate assignment of copyright to several parties helps. Also, having tried (and sometimes succeeded) to contribute code to the FSF's gcc, Sun's OpenOffice, xpdf by Derek Noonberg, Raph Levien's libart_lgpl, Novell's Evolution & Mono, Moblin (which all require some form of assignment), and a large number of eclectically owned projects - I hope I have a useful perspective.
This relevance is increased by the controversy around the acquisition of MySQL by Oracle: as an aside, I believe there are strong technical and business reasons why MySQL should present no obstacle to an Oracle acquisition of Sun. This post (as always) does not represent Novell's position, but is my own. Great thinkers in our community have taken either side on MySQL: RMS, and Eben, for example; and there was recent controversy over Canonical's new copyright assignment policy, with an interesting LWN article on the topic.
In the past, I have been an enthusiastic advocate of the justice, and reasonableness of copyright assignment (in some cases). I have many friends, who have seen me trying to collect copyright assignment forms like autographs: sign the JCA today. Even in those days, I would meet developers I greatly respected who would politely refuse; indeed, I recall arguing vehemently with Bradley Kuhn that such things were risk free, and necessary. Thus I hope I have seen the argument from several sides.
An early example of copyright assignment problems
The issue of copyright assignment has been present from the early days of Free software. The FSF has, for a long time, required assignment, ostensibly to defend against license violations. Interestingly, one of the early 'religious' schisms in 1993 - XEmacs vs. Emacs was related to copyright assignment (though doubtless other things too: eg. should we require an X toolkit ?). A real problem here, making merging impossible was assignment:
Why are there two Emacsen?
Hysterical reasons. See the public flames if you must know. Currently the largest problems is that Sun owns the copyright for large part of the code. It is copyleft, but they refuse to sign over the changes to the FSF. Some people think it is good to have an Emacs variant where you can contribute code without signing any papers. Feel free to disagree.
One position we often hear these days - is that "copyright assignment does not deter contribution". At a minimum, XEmacs appears to demonstrate that for some companies, even those (supposedly) involved in open development from the beginning - copyright assignment creates a formidable barrier to entry. Furthermore - this is an undeniable reality from near the beginning of this practice. More can be read in Ben's opinion on the split. He also introduces a new (and I believe unrealistic, in the FSF's case) concern:
One of the dangers of assigning copyright to the FSF is that if the FSF happens to be taken over by some evil corporate identity or anyone with different ideas than RMS, they will own all copyright-assigned code, and can revoke the GPL and enforce any license they please. If the code has many different copyright holders, this is much less likely of a scenario.
While this problem appears to be precluded by the current FSF copyright assignment - it is in general, a problem worth considering in when assigning copyright to any entity.
Autobiographical, on-topic ramblings
Moving forward in time to 1995, shortly before I got involved with Linux, we saw a clutch of copyright assignment based businesses setup: Qt - May 1995, MySQL 1.0 - May 1995, xpdf - Dec 1995. Of these the first two are often held up to be resounding successes both exiting via acquisition: MySQL for a large multiple of its true value to Sun; and Qt to Nokia. Today it is often claimed that we must not do, or advocate anything to harm such 'MySQL' business models.
Personally, my initial experience of copyright assignment was (I believe) with the FSF. In mid 1998 I wanted to get a patch into gcc; I wrote and posted the patch to RMS (who graciously replied), and put the assignment machinery into action; after some weeks, I got my company to sign it, posted it, and was done - it even seemed an exciting recognition of my (somewhat trivial) work. Unfortunately my patch lingered for another two years, un-reviewed before being committed. Sometimes I wonder if that sort of first-impression hiatus could be related to the latency of the assignment approval process. Needless to say, I moved onto other projects.
Then in 1996, the KDE project was founded, built on the (at the time) non-Free-Software Qt; and the year after - GNOME was started in response. Propelled by enthusiasm for the FSF's mission, and the fun of hacking with Miguel, I and many others joined the GNOME project. Strategically, this seemed a good move - and, technical debates aside, for years we dueled for different visions of the world: first Open Source vs. Free Software, then - one where any company could write desktop software for Linux vs. one where all proprietary desktop software had to pay a single company (per developer). Even the FSF chose the LGPL for glibc; and so the arguments raged. Seemingly eventually the GNOME vision won (for now), and Qt moved - first to the GPL, and then the LGPLv2; well and good - except for the vast amount of acrimony, duplication and wasteage that continues to this day. Ultimately the choice of asymmetric license plus proprietary option for Qt, at the root of the schism, was enabled by their copyright-ownership, cemented by assignment for external contributions.
Later of course (in 1999) Ximian (née Helix Code), was founded, and from the beginning we insisted on copyright assignment for Evolution: we were building a platform to sell services - travel booking: hotels, cars, flights etc. integrated into your groupware suite (perhaps a vision in need of resurrection on the web today). Later on, those rights allowed us to switch tack to creating a proprietary Exchange Connector. However - the GPL licensing of evolution had an untold impact on its adoption; with several (known) others hindered in terms of their business model, depriving Evolution of contributors and keeping it substantially a single-company project. After Novell acquired Ximian, the Exchange Connector was made Free software, available to all - and this helped grow interest and contribution to the software. Recognizing these problems, as Evolution was re-licensed from GPLv2 to 'LGPLv2 or 3' the requirement for copyright assignment was dropped. The project now has an expanding contributor base from Novell, Red Hat, Intel, Collabora, to the collection of great individuals working on it.
Another experience of copyright assignment was trying to contribute to xpdf whose regimen is GPL + assignment. I was re-writing the renderer to get high quality anti-aliased rendering using the (then) new & exciting Gnome Canvas infrastructure. My recollection was that, in stark contrast to the instant gratification of getting code included into GNOME, xpdf was acutely frustrating. It was really difficult, even despite my willingness to sign the relevant paperwork, and my changes being (I hope) reasonably good. Similarly, it was not so easy to get changes into libart whose regimen was LGPL + assignment. Raph Levien (an hirsute man of immense talent & charisma) wanted to retain copyright to that too. Of course, eventually my changes worked, I had a beautiful, anti-aliased, PDF rendering Bonobo component - but, they were eventually mostly lost. As a footnote, it is interesting to see that in more recent times, braver souls have re-re-written the xpdf rendering to target a new and better rendering library (cairo). The result has been forked as poppler. As a freedesktop project, that is now used by both Evince and Okular. Cairo has long ago obsoleted Libart_lgpl which is being written out of the GNOME stack, along with the canvas that depended on it, and Gnome-Print that depended on the canvas is long dead. I suspect that no small factor in my experience, and the subsequent trajectory of these projects was copyright ownership.
Rolling forwards to 2000, OpenOffice.org was created, and the StarOffice code released under the LGPLv2 - with copyright assignment. As an advocate - I spent much of my time talking about the project at conferences, and trying to whip up support for working on it, while encouraging people of the justice and reasonableness of Sun's copyright assignment regimen. Subsequently, as Sun open sourced other products such as Java, that copyright assignment regimen was expanded, and strengthened with the SCA.
Some time later, Sun - on the ropes financially - decided (despite having no ISV community) that it might be a good idea to try to monetize the OO.o asset by changing the license to GPL to drive proprietary revenue from ISVs. This came as rather a shock to me. Although we had no proprietary pieces at all, it was obvious that building an ecosystem to compete with Microsoft Office would be horrible difficult if every proprietary ISV had to pay a single vendor to write plug-ins. Worse, large companies have high getting-out-of-bed payment threshold. Thankfully, after several wobbles, and considerable uncertainty it was decided not to re-license to a restrictive license.
Subsequently, of course I've had to continue working here and there on various projects with strange and wonderful licensing and assignment terms - always with a negative effect. Even the pain of digging out, cutting and pasting some waiver language into an E-mail forms a real barrier to communication. So - that's the part of my experience available for public comment; but, now synthesizing that into something more concrete, and examining the reality, and potential problems.
Copyright Assignments
What are you signing ?
Of course, there are a diversity of different copyright assignment regimens out there; in many different flavors. The best of these include fall-back to a license for jurisdictions where copyright cannot be assigned, cover accounting obligations, copyright registration and so on. One of the most thorough is Sun's SCA.
you hereby assign to us joint ownership, and to the extent that such assignment is or becomes invalid, ineffective or unenforceable, you hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under those copyrights. This includes, at our option, the right to sub-license these same rights to third parties through multiple levels of sub-licenses or other licensing arrangements;
However this is phrased, this is essentially you transferring (or more usually 'sharing') the ownership right. There is often considerable marketing effort put into the Joint or Shared nature of such assignments, however these provisions are meaningless in most real-world cases. Having a shared right, to a small part of another code-base, is usually not at all useful, indeed it can be argued that this is a mere fig-leaf of reciprocity.
In addition, there is often either a license, or a covenant covering any patents you hold - that read on your contribution, or even some wider, vaguer scope. In contrast to many open-source licenses which have termination clauses to allow the defensive use of patents, these tend not to be present in such assignments. In addition the patent language can be unhelpfully leaky as to what combinations of whose products are covered, and to what extent.
Some - of the better copyright assignments have criteria restricting the outbound license types under which the code could be re-licensed (FSF, Sun, Apache), others focus more on their proprietary licensing intention. Apache's example would be:
In return, the Foundation shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its nonprofit status and bylaws in effect at the time of the Contribution.This hints, interestingly, at some fairly broad, generic protections that come from assignment to a non-profit.
To whom are you assigning it ?
Clearly while studying such a starkly one-sided handing over of your work and rights, it is reasonable to question the integrity, stability and actions of the organization to which you are handing it. Organizations such as the FSF, have traditionally been thought to be good stewards of this trust; although the transition to GPLv3 has diversified views here. Other companies - such as MySQL, appear to have a stable and understood business model built around re-licensing the code; while yet others appear to have no discernible need, or use for such rights.
Other ways to do similar things
Various other methods are used to achieve the same effect. Some common ones - are asking for a very liberal license: BSD-new, MIT/X11, or even Public Domain on the contribution, and then including it into the existing, more restrictively licensed work. These of course have the disadvantage of a lack of clarity over associated patent rights and are often reserved for small code changes. Some use a copyright waiver for small contributions, and yet others don't require much for very small changes.
Weighing the risks and benefits
Of course, what a benefit and a risk is, depends very much on your stance; I've tried to categorize these from the perspective of an active, non-affiliated Free-software contributor. It should of course be noted, that I am not a lawyer.
Benefits
Single owner
Having a single point of contact, a steward for a project, who is simultaneously the legal owner potentially can give flexibility to a project. It is always clear whose code-base this is, governance is ultimately entirely their responsibility and you have a single neck to strangle from a community perspective. This ownership also yields extraordinary power to change things. If change is required that can be a benefit.
re-licensing
On occasion, it is thought necessary to re-license code, this could be for a variety of reasons: to facilitate re-use in some larger context, to meet the changed needs of a stake-holder etc. In these cases, it is easy for a code owner to re-license the code without obtaining consent from all contributors. This contrasts with the real difficulty of obtaining consent from all contributors in an eclectically owned code-base. This is particularly a problem when companies enter administration, transferring their assets to new, expensive, community-disconnected owners. In a similar vein individuals can also (more tragically) expire, leaving new (and potentially unclear) owners of an asset which they are unlikely to understand. On the positive side, my experience of encouraging individuals to re-license their small contributions has been that, for the most part, people are only too happy to help the project they loved.
open-source re-licensing
Re-licensing to a new open-source license might be in response
to a new threat to freedom identified by developing circumstances such
as Tivoisation in the move to GPLv3, or conversely by the FSF
re-licensing some fstype code for gnome-vfs2 from GPL
to LGPL. Having a single code owner makes it easy to negotiate and
effect such transitions.
proprietary licensing
A far more commonly advocated advantage - is to allow proprietary versions of a product to be sold, based on an open source code-base. This has the advantage of providing a simple, traditional, per-unit license based business model, while also having an open source version. In many cases (it is argued) funding technical infrastructure development is hard, and allowing this can provide a large amount of good quality, well maintained, open source software backed by a stable revenue stream.
When making this argument, it is common to look at pieces of software that appear to have been developed only by a single assigning entity, and claim that this is the only way it can be done. Thus eg. - "MySQL was only made possible by assignment: since it was ~all implemented by one company - funded by revenue from re-licensing". This 'all done by one company' issue can appear rather circular, when we consider the side-effects of assignment later.
Proprietary versions can also have features unavailable as open-source, and (often) competitors can be excluded by choosing a license - such as the GPL - that prohibits others from making proprietary pieces. This is often called the 'Open Core' model. Variations on this can exploit a patent licensing advantage available to a proprietary version, and - unavailable in general, eg. perhaps for some Media codec.
'defending' the code
Advocates of copyright assignment frequently make much of the need to 'defend' the code from a potential license infringer. It is claimed that this is easier for a sole copyright holder. As a non-lawyer this seems (to me) one of the least comprehensible explanations - is the GPL really toothless without a single owner ? Some of the highest profile license litigations that have been seen are around Linux (SCO), and BusyBox (20 suits at a time) - where there is no aggregated ownership. It seems to me that this is a hard argument to sustain, and begins to look increasingly self-serving.
Closing the code
While the possibility to close the code, and release all subsequent versions as proprietary software may seem a purely negative benefit - yet perversely the possibility of doing this may well allow timid, or inexperienced management to test the 'Open Source' water. This in turn may lead them (eventually) into a full embrace of Free Software. It is also possible that assignment expedites various accounting problems, such as book values of assets, thus avoiding (nominally) expensive write-downs impacting the corporate bottom-line.
Sun's SCA FAQ claims, in answer to How does the Contributor Agreement help me?
It allows Sun to sponsor the projects to which you want to contribute, while retaining the ability to offer commercial licenses. Without this ability, Sun could not responsibly open source code bases such as OpenJDK or OpenSolaris that represent hundreds of millions of dollars of shareholder investment.
Risks
Single owner
The owner with whom you are in relationship, and have happily assigned rights to - with no doubt many unwritten expectations attached, may suddenly, and without warning change completely. The trigger in a business could be acquisition, change in management, inter-corporate politics, shareholder pressure, or any number of other factors. For a non-profit, there may be similar board-room coups, drifts in attitude and focus, or even bankruptcy necessitating asset disposal to the highest bidder.
With a business, when management changes it is easy to lose the legacy of trust embedded in those relationships. Worse, a business may (simultaneously) hit such hard times - that the relational value of pleasing you (as a community member) pales in comparison with the struggle to stay afloat. Companies on the ropes often suddenly turn toxic with huge switches in strategy - cf. SCO's transition from a contributor to Linux, to a litigation outfit. Even worse, a company will always have some threshold where they have a fiduciary duty to sacrifice the community's valuable (but abstract) long-term community status, in favor of financial gain. Of course, non-profits may have similar problems with changes of control, or perhaps gradual change in attitude of those in control.
Another unfortunate downside of having a single owner, is that it is not jointly owned. With a joint (or eclectic) ownership - each contributor has a valuable ownership right - a part of the franchise. As such, they are potentially more concerned with and interested in the future of that code.
re-licensing
The need to avoid obtaining consent for re-licensing primarily empowers individual community contributors. With a single coporate owner there will typically be an appearance of asking the community, about changes, though large corporate interests will be either threatened, or placated behind the scenes. A single owner can bring about a death of transparency to this process, leading to a corporatist bent. It is entirely possible, that it is a company's duty to twist the screws by choosing more restrictive licensing, to try to 'monetize' an asset they control. It is also quite possible to end up in a situation where you have invested in, and assigned rights for contributions to a code-base, only to find yourself having to pay for the privilege of continuing to use it, or even being unable to use it. So - by assigning away your rights, you effectively deliberately dis-empower yourself.
open-source re-licensing
While changes here may appear benign, there are a huge diversity of (even OSI approved) licenses with many varying restrictions. This makes the world of open-source licensing a political minefield. Enabling the casual adjustment of the license can well be a recipie for endless life-draining politicial discourse and punditry.
While changing license can be positive, it is just as easy to switch an assigned code-base that is popular from LGPL to GPL to QPL, as it is to go in the converse direction. An obvious change here might be the removal of the non-copy-left SISSL option for OpenOffice (something I supported at the time). Particularly retrograde changes here would be to licenses incompatible with the GPL.
Often the very logic of community licensing - to encourage maximum use of Free Software - radically conflicts with the logic of extracting maximum financial advantage from proprietary licensing, driven by the disconnect between open vs. proprietary licensing. This disconnected is created to drive people to purchase a proprietary license - by creating something far less useful (until you pay, or deal with the owner).
closing or abandoning the code
This seems unlikely to be a huge issue for any liberally licensed piece of software that is widely used, potentially this may even be positive: encouraging more contributors to help drive the public version. However, for more restrictively licensed code, the situation is different - this could be the impetus to a support based model, a pure community based approach, or simply the death of the project.
proprietary licensing - FUD
The possibility of proprietary licensing puts a potential sales-man in a rather unpleasant place. He could go around explaining exactly how much freedom (say) the GPL gives you, or he could go for the quick sale option, by bad-mouthing it, and playing up the risks, while down-playing the rights given you. That is something I hear of too frequently.
proprietary licensing - confidentiality
One of the problems of proprietary licensing is its opacity. Whereas open source licenses, necessarily are available for all to inspect and comment on, proprietary licenses are frequently not just unavailable, but protected by severe confidentiality clauses and penalties. This lack of transparency has the ability to hide the terms on which people enter and interact in (what can look like) a community. This can significantly hinder interaction, discussion, code inclusion, and be highly corrosive to trust. If you are unable to explain your actions, or even explain why you can't explain, being in community sucks.
proprietary licensing - surrender of rights
Free software enthusiasts tend to see proprietary licensing as somewhat complementary to Free software licensing; with RMS publicly lauding this Free+Proprietary model. However, in a world of dominant re-licensing monopolies who alone can combine (eg. MySQL) with key plug-ins - it may not be possible to get support from anyone but a single vendor. At this point, it is entirely likely that in your contract you will find terms substantially limiting, not (perhaps) your freedom to modify the code - but certainly your freedom of association: where you can send it (not to a fork), requirements that it must be re-assigned to the vendor, and potentially yet more troublesome terms.
Coming from a community based on openness, these practices are unexpected, and extremely unwelcome, but are entirely commensurate with the normal back-room corporate bludgeoning that occurs daily, safely behind closed doors. Worse - they can yield a spurious uniformity of behavior, which combined with an inability to use forking to encourage positive change can condemn a project to ossification. The appearance of community, without the associated dynamism and substance can yield slow death.
proprietary licensing - portfolio confusion / tying
Another risk of copyright assignment (and the single company dominance that this tends to bring), is of product tying. As a corporation with a diverse set of open source products, it is tempting to form alliances based around supporting one with another. Thus - as a well publicized example contributors to Java - are simultaneously driving MySQL sales, helping promote Microsoft search, and lifting Sun's bottom-line. This is in part made possible by trademark ownership - there are great dangers in building up trademarks you don't control. Nonetheless - a community owned project is unlikely to have made this sort of cross-portfolio choice; and this sort of thing is unlikely to endear Java to a hypothetical PostgreSQL hacker working at Google. There are less well known examples of even greater perversity.
proprietary patent indemnification
If you assign rights, you give the owner of those rights - the ability to offer special indemnity, for patents, unavailable to others covering their proprietary licensed, or sub-licensed versions; creating perverse incentives.
Barriers to entry
The Paralysis of Uncertainty
Since corporate entities may not act rationally, or predictably, it can be difficult to know whether it is a good idea to get involved with that code-base for the long term. That risk of instability creates a barrier of indecision to overcome. Should we re-use this code ? or just re-write it. Sadly far too many programmers, in my experience, prefer to re-write rather than re-use, without any even slightly-convincing excuse like this. Thus, it is more likely, that as an assigning contributor your code will be re-written, and your contribution lost.
The death of trust
In the (fascinating) research paper, in the field of privacy The Best of Strangers it was found that, (paradoxically) presenting assurances as to privacy before asking for data created a significant negative bias against yielding it. While it is extremely hard to measure such a thing, my fear is that the death of trust implied by demanding a signed and faxed legal document before accepting code has a sizeable negative impact - starving your project of contributors.
As an aside, whether it is correct or not, seeing your own, lovingly created software bolted to a Frankenstein (shouting) header reading:
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * Copyright 2008 by Someone Else, Inc.with no trace of who put the work in, tends to breed feelings of a lack of trust with its absence of fair accreditation. Interestingly while this is case for OpenOffice.org, it is forbidden for OpenJDK.
Corporate unwillingness
If Free software development is turned into a corporate land-grabbing activity, then those areas where new work is being done will necessarily attract acrimony over ownership of the new pieces. New pieces will be positioned as extensions of other old ones, and the potential for conflict, and the spread of ill-will can sterilize the space.
Brian Aker summarises this well, from his experience:
"The conflict inherent in trying to reserve rights, and take the rights from others, leads to conflict."
Furthermore, getting a copyright assignment read, reviewed, re-negotiated, approved, signed takes significant time for those with the least available time: corporate executives and legal. Often there are risks, of patent leakage eg. that complicate matters. Furthermore it is necessary to explain to them why they should invest substantially in adding to code that appears as an asset on their competitors bottom-line. Communicating an advantage, high up a corporate chain can be hard indeed - thus starving your project of timely corporate contributions.
Corporate Overhead for Consumption
These days, much open-source development is driven by full-time, paid, corporate contributors, who can bring a lot to a project. However in many cases where public licenses are commercially unfriendly it is necessary to negotiate some form of proprietary sub-license.
Assuming there is no reasonable, boilerplate license, or that there is conflict and competition between companies - the process of negotiating these agreements can be extraordinarily fraught, and take tens of months. This can consume vast executive, business development, legal and technical resources, and still yield nothing. These negotiations can be torturous, involve brinkmanship and tricks. To encourage this in order to attract corporate investment is anathema in a world of rapidly moving development. By the time a corporation has noticed the opportunity, and successfuly concluded negotiation, it is long gone.
Scarcity mentality
Often this mentality grips a copyright owner; the thought that someone else might make a dollar from a combined work, is immediately thought of as a loss for the owner. Thus, perversely, instead of trying to grow the corporate developer base (and creating competition for themselves), the instinct is often to try to suppress and coerce such potential partners and allies. This in turn can make dominance by a single-company self-perpetuating, and further weaken the value and lifetime of your contribution.
Lack of scalability
An assignment based model, tends to lead to the desire to build, and include into the assigned software only pieces that comply with the commercial proprietary licensing needs. This in turn requires the use of liberally licensed components all the way up the stack, until the assigned piece - available under a more restrictive license. eg. X11 below - GPL above.
It is clear, that this is essentially a non-scalable business; it will work well for a single entity in one vertical, perhaps two; but if every component in the stack is owned, and licensed by a different vendor - then all proprietary licenses require a cascade of others. This situation is also of incredible risk - a single malign vendor in the chain could hold the rest effectively hostage. Compared to this, the problem of internet micro-payments is child's play. An example of this failure of scalability might be Pyqt - where Troll-tech re-wrote Riverbank Computing's Python bindings instead of licensing them.
Some companies make their intention here quite clear: talking of a [toll] "... bridge between different communities using the same code under different licenses." How many toll-booths can be erected before no-one uses the road - is left unanswered. If this underlying model does not scale, then it is unlikely that other corporations will become involved and help grow your community and software. Where is the opportunity for multiple bridges in this sort of stack:
Delayed Gratification
When you have (often without asking anyone) disappeared and written something wonderful to contribute - it can often be a shock to discover, that before even reading it, discussing it, empathizing, and encouraging you - it is necessary to delay until you have signed and faxed/sent a form, it has been reviewed, and you have been approved by some paralegal. This is particularly frustrating when the change is acutely cool - and you want to get it in immediately; delay is toxic. Worse - you know, that every minute you delay increases the chance of someone else (on the inside) doing the same thing, denying you the pleasure of getting included.
Duplication
Hopefully, with an Open Development model, decisions are made on the basis of clear, visible-to-all, technical merit - indeed, what is technically best yields quite enough discussion without further criteria. Adding another criteria - which goes way beyond licensing (re-writing for licensing reasons is fairly common) - into ownership is far more pernicious. Re-writing a piece of code, contributed by an assignee unwilling to give over copyright - yielding a re-write with the same out-bound license is particularly controversial. The example of Sun rejecting Kohei's solver for OpenOffice.org was a particularly instructive attempt at coercion here - with predictably community dividing results.
Trying to reason and interact with, and understand the decisions of developers who have non-public, corporate commitments to different technologies can be acutely frustrating. As a (banal) example, recently an Intel / Nokia agreement precluded prior discussion of the rational around oFono / Connman.
Technical separation can itself be highly problematic. If a plug-in does not have to be assigned, but (when bundled with the product) it has to be - then suddenly there are non-technical barriers to creating a well integrated product that have to be engineered around. That can affect code re-use, choice of libraries, and so on. If two products need to be integrated, which place the code lives can be dictated not by good house-keeping, but by ownership requirements.
The kind of communal conflict created by such duplication is entirely caustic to the growth of a healthy developer community.
Community strangulation
The combination of these risks, pragmatically appears to lead to a self-stultifying community. Companies that demand assignment, typically attract very few external contributions; so for example we hear that "it is a fact that MySQL was almost fully developed by employees of MySQL Ab and later Sun's MySQL division". Similar patterns appear to hold for other projects. This in turn can become a self-reinforcing argument: no-one else is contributing, so why should we open up ? When no-one else is contributing because the project is insufficiently open, that is a sad attitude.
The counter-examples
I am not aware of a single project that mandates copyright assignment to a corporation that has a diverse, and thriving developer community. If there was even one, the business model of "communitising" a code-base, then firing all your developers, sitting back, and collecting an effort-free rent might become attractive. In contrast I am aware of many diverse and thriving communities that have eclectic ownership, and also some less thriving ones that are dominated by single entities.
Of course, there are a number of entities run by foundations that aggregate copyright (or a similar ownership right via licensing) that appear to do remarkably well despite that. Common examples are the Eclipse and Apache foundations. Interestingly the Eclipse Committer Agreement is not a copyright assignment, and as such Eclipse is not actually an example of assignment.
How then, do these more bureaucratic organisations appear to neutralize the worst problems of copyright assignment ? Perhaps first by eschewing an asymmetric licensing model ie. all users get the same license - which necessarily is a fairly weak copy-left (Eclipse), or (for Apache - non-copy-left).
Secondly, they provide strong, stable, governance structures, that include the major players, and that avoid the possibility of disruptive change. Finally in the case of Apache they try to exclude politics from the technical sphere of the project; ie. decisions should based as purely as possible on technical merit. Of course Apache seems to get governance right: being an organization based on (roughly) the very same individuals licensing their copyright to the foundation, with no direct corporate engagement. Having said all that, the general "red tape" effect whenever some paperwork is involved is an issue. I asked Gianugo whether he though the apache project would have got going if the whole bunch of Apache policies to abide by (including assignment) had been required from day one, and his answer was "No, probably not." (when exploring these topics as a corporation you could do a lot worse than talking to Sourcesense incidentally).
With Apache - perhaps the only real example of a successful and diverse project that requires copyright assignment, it's license is not copy-left. This is highly unfortunate, and once again can make it harder to attract contributions and grow community, particularly corporate contributions. A prominent example of the effect of licensing can (perhaps) be seen in Apple's non-contribution to the code derived from the BSDs in it's devices, as contrasted to it's deep contribution to WebKit, as required by the copy-left.
Then of course there are the counter-counter-examples; some of the most successful open source projects require no copyright assignment: Linux, Busybox, Xorg, Mozilla/Firefox, GNOME, KDE, GStreamer, and a whole clutch of others too many to mention; indeed this is arguably the normal state of Free software projects.
Picturing a dystopia
Can we imagine a future world where corporate ownership and deal-making runs to it's logical conclusion ? Clearly, there are problems scaling the dual-licensing business-model, which should presumably lead to a large degree of conflict around choices of technology. Whose stack software is built on, becomes then a question of deep corporate concern, and presumably the stacks will do battle in public and private. Of course, who owns which vertical silo, and where exactly the toll-booths are located, and who signs what co-operation agreements to ensure their access to other silos is of great interest. Clearly, those with multiple assets can use them co-operatively to advance the others.
Another thing that will (no doubt) cause grief is the proliferation of platforms, which will be exacerbated by ownership concerns. No sooner than Eclipse created an IDE, than suddenly it became an application development framework to re-write the world in; arguably, GIMP no sooner factored out it's toolkit, than there was a desktop platform springing up around it. With more claims on ownership - expect a plague of yet more 'platforms', and duplication of applications to use them. This has the danger of further fragmenting the Free software developer base, retarding progress, and destroying value.
Acquisition risk also increases here; without good, widely used mechanisms to ensure the stewardship of a codebase in the event of a hostile takeover, the more agreements that are in-place, and the more consolidated ownership - the greater the risk of a hostile entity purchasing and smothering some key piece of the stack.
But is the wide-spread use of assignment really likely ? A Gartner analyst predicts:
By 2012, at least 70% of the revenue from commercial OSS will come from vendor-centric projects with dual-license business models.Personally, I profoundly hope that this will not be so, and that we will continue to see rich collaboration among competitors in the world of Free software. There is, of course hope - that individuals, smaller corporations and consultants will see the dangers, rebel against them and invest and adopt only the truly open technologies.
Finally, perhaps the most destressing aspect of assignment, is the evisceration of influence of even the most productive and valued individual contributors. Deprived of insight into the web of proprietary licensing, with insiginificant personal assets to apply swapping games with, and providing an essentially expendible contribution they are placed at the mercy of forces beyond their control. It would be sad beyond belief to work in an un-forkable project, that gets handed technical decisions based on back-room corporate machination instead of merit.
Alternatives to Corporate Assignment
There are a number of possible solutions, that address some of the risks of assignment, or capture some of the benefits without it. Firstly - without assignment, there are two traditional approaches to re-licensing.
Re-licensing
The first, and most obvious is 'plus' licensing, with subsequent version language:
This of course, relies on people trusting the FSF's governance, continuing grip on reality, and is another way of, giving a powerful ownership like right of the code to the FSF. As such, some corporations are very skeptical of licensing their code under a regimen that may change under their feet, as happened in the transition to GPLv3. Indeed, arguably that transition has provoked many to search for new (more dangerous) ways of enabling license migration, such as copyright assignment.* This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Library General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version.
A similar clause can be found in Sun's CDDL:
Thus, a different license steward can be specified; but of course new versions of the license have to be published.4.1. New Versions
Sun Microsystems, Inc. is the initial license steward and may publish revised and/or new versions of this License from time to time. Each version will be given a distinguishing version number. ... Otherwise, You may also choose to use, distribute or otherwise make the Covered Software available under the terms of any subsequent version of the License published by the license steward.
The GPLv3 enshrines a proxy who can decide whether a new version of the license should be applied (section 14.):
If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.Which is an interesting twist - giving the FSF the sole ability to create new versions, but allowing the delegation / aggregation of the choice as to whether to adopt them.
Another, common approach is to use the Lesser GPL's ability to convert to the GPL:
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library.Interestingly, this is what makes the LGPLv2 more compatible with GPLv3, than GPLv2.
It appears (to me) that choosing a license that can be upgraded and bug-fixed in-flight by a responsible steward or proxy substantially removes the requirement of assignment for re-licensing.
Finally, another - perhaps less optimal - approach to re-licensing is to choose a license so liberal that it can be converted or incorporated into another licensed work, if necessary later, eg. perhaps the BSD-new license.
Assignment with a non-profit
Of course, this can be indistinguishable from assignment to a company if the governance is not open and equitable. However, assuming reasonable governance, this method can allow re-licensing, defense of the code, and stability - without undesirable asymmetry and proprietary antics.
Joint assignment via a non-profit
As a less optimal, but pragmatic approach - where a company is open-sourcing a large existing code-base, with tangled proprietary agreements in-place surrounding it - onward assignment from a foundation might be the best approach. Thus two entities would both, individually own the complete aggregate work.
This has the benefit of ensuring continuity, and stability allowing a company to continue it's proprietary business, and potentially providing community governance too. By requiring suitable voting super-majorities for changing the constitution, and therein proscribing high thresholds for any sunset clause - a clear path via contribution to a level playing field can be provided.
A much more limited, constrained, and less open (yet interesting) foundation, similar to this was created for the FreeQt foundation - that protected Qt from strangulation by acquisition, or sudden death by bankruptcy.
Recommendations
Condensing the risks and benefits, there are perhaps a few clear recommendations - for those corporations and individuals who are interested in open, thriving development communities built around their software.
- As a contributor - avoid copyright assignment to corporate entities wherever possible.
- As a project leader: use a license, or dual license combination that provides the ability to move to another license.
- Use a plus-license of some sort, and include or any later version in your [L]GPL headers. If you cannot stomach this; then when using a specified version of the [L]GPLv3 - specify a proxy whom you trust to approve such things: preferably a well governed, pragmatic non-profit that you feel represents you.
- If you feel you must demand copyright assignment, consider doing so via an onward assignment from a well-governed proxy non-profit. First however consider using an extremely liberal, GPL compatible license as an alternative, preferably one that is copy-left.
-
If signing away your rights appears unavoidable - and all
attempts to change the situation: selecting different software,
re-writing the software, joining forces with others to fork the
software etc. fail, then prioritize assignments that:
- Have strong guarantees, and a commitment to future open-source licensing, eg. the FSF's, or Sun's SCA
- Refuse to sign an assignment that does not ensure that licensees retain their freedom to fork, and contribute to any open source project
- Mandate that all proprietary licenses will be under F/RAND terms, and (preferably) published - this is notably absent from any existing agreements. Failing that, demand that the ownership should be administered by a separate (for profit) blind entity.
- Pressure non-profits demanding assignment to have clean, transparent, and representative governance - so your voice is heard.
- If you contribute to, or build software based around assigned projects where there is, or may be substantial licensing asymmetry, and conflicts of interest - eg. a project under the GPL, be aware that you are entrenching a non-scalable approach that may ultimately harm your contribution. Please do not try to present your project as 'open', or demonise those wanting to change the situation. Also - don't accept sham community governance that has no legal existence or force.
- If you want to open-source your code, choose a license for it that you, yourself could accept. If you are a business, consider what a competitor would want - this way, you can ensure the critical survival of the code-base; if that means using a liberal license, please use the LGPL as well, as an option in a dual license (eg. Mozilla's MPL / LGPL). You should also strongly consider choosing a copy-left license, to encourage contribution back to the project.
- If you are faced with aggression from a copyright owner, turn their asymmetry against them: ask them to accept code under the same terms they provide to others. If they become upset, point out that you're happy for them to assign their rights to you, and license them back. Failing that, just soft-fork the project, a-la MariaDB - paradoxically you may want to collect copyright assignment yourself to be able to affect an eventual reconciliation.
- If you are considering dropping a copyright assignment requirement, and concurrently re-licensing, be encouraged - this is a good way to go. Experience suggests this will diversify the contributor base, and increase adoption of your project. If you have a substantial book-value for the original asset - it is worth re-considering such valuations anyway: do they truly reflect the commercial gap between the public and private license ? are they accurate, given the high degree of volatility between commercial needs and the license of the day ? and their fragility: could they be sustained in the presence of a popular fork ? can the change be viewed as a gradual tax-efficient depreciation of an old re-licensing ability ?
Conclusion
Copyright assignment brings some benefits, but also creates very substantial risks of damage to the Free software developer ecosystem. In more simple terms: do you want to work with other companies and individuals, growing code in a social environment built for the common good ? or do you want to work disproportionately for the good of a single entity ? Viewed from a social perspective - such open development - against the odds, herds competitors together, and excludes business concerns in the single minded, focused quest for technical excellence. Poisoning that arena with corporate edicts, issued from a faceless business elite who are not present is highly unwelcome. The risk of creating a dysfunctional community is of course highest when the assignment is to a corporate entity, and the license is restrictive, yet there is some real risk of backsliding and malfeasance wherever copyright assignment is practiced.
As a thought experiment, if you had two projects to choose from which you felt inclined to help out, or re-use in your project: would you choose the one where you were assured of subnormal community growth, dominance by (and dependence on) a single corporation, regular inter-corporate conflict, unpredictable changes of license and being surrounded by a web of invisible confidential agreements ? Or - would you be more likely to choose a diverse, non-vendor-dominated community ? how about if that community had poorer quality code, and needed more people to work on it ? (incidentally, that is often a great time to join a project).
I believe, that copyright assignment, (in some way like patents) grants a monopoly to the holder to dictate terms to, and coerce others in ways that are not public - and, as such, (depending on the ethics of the holder), is always potentially dangerous - and to corporate entities is profoundly unwise. In the absence of better re-assurances in assignment agreements, it should only be socially acceptable among developers for projects that can be effortlessly avoided.
Of the current clutch of copyright assignments I've seen, I personally think the SCA is one of the most thorough, although I have yet to see an assignment that guarantees the level of fairness and transparency necessary when sub-licensing.
When assessing whether to assign rights pragmatics needs to rule; in some cases there will be an alternative that seems more expensive or difficult. I encourage you to, wherever possible choose that - it is likely to be cheaper in the long run. Failing that, trying to ensure that your contributions to the project (at least) are made available to all under fair terms seems a reasonable thing to ask, perhaps by getting a commitment to using an extremely liberal license for a certain element - from the vendor. Ultimately, adding copyright assignment to your project is a huge burden to bear (while swimming) - but to a reasonable non-profit, with good governance - this can (apparently) be compensated for by building an even better, more open and healthy culture.
Finally it is just common-sense - don't move into your partner's ramshackle house, and pour years of your life into renovating it to a level of re-sale-able perfection, without taking your partner to the altar first, and you don't get married in a confidential ceremony. Civil law is there to help prevent the injustice of having your love and support sold out. A refusal to consider protecting the rights of the weaker party tends to confirm an intent to exploit - both for copyrights and trademarks.
Further reading
I will include feedback, and update this article over time as more things come to light. Of course, many others have written on this topic, no doubt far more lucidly than I, and with different perspectives.
- Bradley Kuhn's Open Core Shareware.
- David Neary's Copyright assignment and other barriers to entry
- Sun's: rational
- LWN: community contributions and copyright assignment
- Brian Aker's RMS, GPL, The Peculiar Institution of Dual Licensing
- Matt Asay's (sub-optimal) take on how-to deal with partners.
- RMS' take on whether (C) assignment can be done right in the abstract, apparently so: selling exceptions
- Bradley Kuhn's Not All Copyright Assignment Is Created Equal.
- Bill Weinberg's Open Source is not a verb points out the problems of inorganic assignment based communities.
- My talk on LibreOffice and Code ownership at LWN
- Simon Phipps on Contributor Agreements
- Werner's take on the libgcrypt situation.
- Richard Fontana's nice write-up of RedHat's position (2019)
As of 2019 - I've moved my focus to how Trademarks rather than code copyright can be used to build successful ecosystems - cf. trademarks and open source.
