GNOME Foundation Guidelines on Copyright Assignment

"The GNOME Foundation" is referred to as "GF" throughout this document.

Historical Policy

Most FLOSS projects make decisions about copyright and licensing policy at their founding. GNOME is no different in this regard. Meanwhile, considering the context for these initial decisions helps in analysis of any proposed changes.

At the project inception, the GNOME project made three fundamental decisions with regard to its copyrights:

• The copyright license of most applications would be the copyleft license, GPL.
• The copyright license for most GNOME libraries (particularly those that would be fundamental platform infrastructure) would be a weaker copyleft license, LGPL, to encourage adoption of GNOME as the default desktop environment on as many platforms as possible (including proprietary ones).
• Copyrights on GNOME contributions would stay with individual authors — be that author an individual or a corporation.

The last point deserves specific discussion. As GNOME is affiliated with GNU, it has the opportunity (but was not required) to join the standard copyright assignment used by the Free Software Foundation (FSF). A few GNOME contributors have assigned their copyrights to the FSF, but generally the GNOME community has felt that systematic copyright assignment is not a practice that the community wants. The FSF and similar non-profits that accept FLOSS assignment leave these decisions to individual projects, and thus GNOME code was never assigned en-masse to the FSF or any other entity (including GF when it was formed).

Furthermore, neither GF nor the GNOME community at large has ever objected to any given individual developer voluntarily assigning copyright (be it through a work-for-hire agreement or contractual form) to a third-party company. Indeed, large codebases (e.g., Nautilus) began life as corporate-contributed projects primarily under a company's copyright. Some of these such as Evolution required copyright assignment. However, in all historical examples in the GNOME community, eventually other developers contributed to the codebases and the copyright holder community in those packages became diverse over time.

Official GNOME Packages and Unofficial Applications

An important distinction must be drawn with regard to what purview GF has with regard to setting policies about copyright assignment. The GNOME community has always encouraged and welcomed third-party applications outside of the GNOME core. Such applications of course use GNOME libraries and integrate well with the GNOME desktop. No desktop can be successful without many applications targeting it.

The GF neither has, nor wants to have, any specific requirements about third-party applications, beyond the usual required compliance with the terms of either the LGPL and/or GPL (usually only LGPL, but it of course depends on what components the third-party application relies on). While some GNOME contributors may also contribute to third-party applications, these third-party applications are, from GF's point of view, independently developed. The GF does not seek to interfere with those communities and companies.

The question of copyright assignment policy is only put before the GF when either:

1. a change in the default policy outlined above is requested by the individual maintainer of an existing GNOME package, or
2. a GNOME contributor requests that an existing project with a different copyright stewardship policy become officially a GNOME package, or a dependency of a GNOME package.

GF obviously wants to maintain a clear policy for all those things that are officially considered "part of GNOME", yet individual decisions on such matters belong in the domain of the release team.

For-profit vs. Non-Profit Assignment

A distinction should always be made in considering copyright assignment to a non-profit entity vs. an assignment to a for-profit entity. For example, in the simplest case, if someone proposed assigning copyrights to GF, it would be a relatively easy decision, since GF is of course a trusted authority in the GNOME community and would generally be considered by all as a good steward. The only issue of concern would relate to those of "Delayed Gratification" (see below).

Generally speaking, not-for-profit entities are chartered to do some sort of good for the general public. In the USA in particular, 501(c)(3) entities must make sure their purposes are charitable, and such organizations are accountable to governments and ultimately the public that their work has clearly benefited the community they represent. As such, many of the disadvantages below may be mitigated to various degrees if the assignee is a 501(c)(3) non-profit like GF.

There is a spectrum of possible entities, though, from GF, to FSF, to various non-profit entities, all the way to the most insidious for-profit company one can hypothesize, that might be requesting copyright assignment for something that is part of the GNOME core. Indeed, each of the disadvantages listed below are probably all rateable on spectra, and each type of copyright assignee might rate differently on the different spectra.

When considering a change in copyright assignment for a GNOME core package, GF must carefully compare the possible advantages of assigning copyright against all the disadvantages, consider whether the disadvantages are mitigated well or poorly by a particular copyright assignment system, and decide if the advantages ultimately make it worthwhile.

Note that some items appear on both lists. Some aspects of copyright assignment have impacts that can have both advantages and drawbacks.

Disadvantages

Single Copyright Holder == Single Point of Failure

The copyright holder 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 for-profit business could be acquisition, change in management, inter-corporate politics, shareholder pressure, or any number of other factors.

Non-profits are generally somewhat immune to those factors. However, some non-profits can have drifts in attitude and focus, or become insolvent and disband entirely.

Proprietary Relicensing

A single entity holding copyright can engage in a proprietary relicensing business model (sometimes confusingly called a "dual licensing" business model). That entity can offer proprietary licenses to those who want to avoid the GPL and/or LGPL copyleft requirements of the GNOME package in question.

Proponents of this model argue that this is a reasonable way to fund FLOSS development: use revenue from those who want proprietary versions of the code to fund more development of the FLOSS versions.

However, in practice, there is no way to know if the funding acquired through relicensing goes completely to future development, particularly if the for-profit company is privately held, or is publicly held but so large that specific revenue related to propreitary relicensing cannot be traced via their public filings.

More fundamentally, however, proprietary relicensing creates two classes of developers: those bound by the GPL/LGPL and those that aren't. This is wholly different from permissive, BSD-style licenses, because in those cases, everyone has equal right to proprietarize. If a single entity holds copyright and intends to proprietarize an otherwise copylefted codebase, that entity holds an exclusive power that no one else in the community holds.

FLOSS Relicensing

While changes here may appear benign, there are a huge diversity of (even OSI- and/or FSF-approved) licenses with many varying restrictions. This makes the world of FLOSS licensing a political minefield. Enabling the casual adjustment of the license can well be a recipe for endless life-draining politicial discourse and punditry.

While changing license can be positive, it is as easy to switch an assigned codebase from LGPL to GPL to QPL, as it is to go in the converse direction. Particularly retrograde choices here would be licenses incompatible with the GPL.

The Paralysis of Uncertainty

Since for-profit 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 codebase for the long term. That risk of instability creates a barrier of indecision to overcome. Should we reuse this code or just rewrite it.

Single-entity-copyright-held codebases often give a specious but seemingly plausible excuse to developers to not reuse a codebase. Indeed, many programmers who are new to FLOSS might be legitimately confused about what the license of the software is, particularly if they encounter the codebase through the company's website first rather than through GNOME.

Delayed Gratification

Copyright assignment is currently never instantaneous, but patch submission and merging can be. Most projects that have single-entity copyright assignment have lists of patches that have never been assigned and therefore cannot be accepted into the canonical codebase.

Additionally, developers can be turned off by this outcome, because their patches remain unmerged while copyright paperwork is handled. Even an eventual assignor may have lost interest in further contribution, even while their paperwork is finally complete.

It's clearly possible to mitigate this problem with better technology for quicker copyright assignment, but no known system of this nature currently exists.

The Death of Trust

Copyleft licenses create trust relationships between contributors. Each contributor is generally bound by the terms of the GPL or LGPL and must uphold those obligations to every other contribution. Pulling one contributor out of the mix and giving them special rights and control over all the others — unbinding them from any licensing requirement — can poison the trust relationships of the community.

It's not my work anymore

Some contributors work to see their name in "lights". Well, LED lights, anyway, at the top of the file where it says:

          Copyright 2009 © J. Random Hacker

If you have a single corporate entity holding copyright, it looks like it's all their work, and not J. Random's anymore. The notices read:

          Copyright 2001-2010 © BIG FOO CORP

what it should really say is:

          Copyright 2001-2010 © BIG FOO CORP
          Copyright 2009 © J. Random Hacker

to note that J. Random Hacker is a bona fide contributor, just like BIG FOO CORP.

Corporate Land Grab

If FLOSS 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.

Corporate contributions are welcome, but they should be representative of the literal amount of code a company contributed, not that amount PLUS the "number of pieces of paper signing away rights" that the company was able to collect from the community.

Contribution Filtering

An assignment based model, tends to lead to the desire to include into the assigned software only pieces that comply with the commercial proprietary licensing needs, and/or those pieces where assignments have been collected. Contributions are no longer judged by community processes alone, but also by which developers could get a copyright assignment form signed.

In essence, a single copyright holder policy not only gives the single holder the legal rights to relicense, but also allows the use of "no assignment available" as a "spare excuse" for not accepting otherwise good patches or incorporating compatibly-licensed, independently-developed codebases. Thus, the copyright holder's legal department has exclusive power to decide what code comprises the canonical version of the package.

Benefits

Single Copyright Holder == Steward

Having a single point of contact — a "steward" for a project — who holds all relevant legal rights gives some flexibility to a project. It is always clear whose codebase it is. Governance is ultimately entirely the steward's responsibility. You have a "single neck to strangle", from a community perspective. This ownership also yields extraordinary power to change things. If change is required, and positive for community, the steward can help effect that positive change.

This can be particularly beneficial if the steward is democratically accountable to the community. GF, for example, is run by a board of directors elected by the GF membership, which is in turn representative of the GNOME community. GF as a copyright steward, thus, would be a potential way to declare a codebase held not by a loosely organized group of individuals, but rather a defined community.

Relicensing For the Betterment of the Project

On occasion, it is necessary and beneficial to the community to relicense code under another FLOSS license. This could be for a variety of reasons. The following are just a few examples:

• To facilitate reuse of the code in a project with a different culture and license (e.g., offering the BSD community something under the ISC-license),
• A new version of a FLOSS license has been released where the original code didn't have an "or-any-later-version" clause attached.
• Adding a small exception to GPL in cases where software freedom is better served with a slightly weaker copyleft.

This work can still happen with a diverse copyright-held codebase. However, substantial effort must be made to contact authors and otherwise document all necessary consent. Such work is avoided when a single entity can decide unilaterally.

License Enforcement

Most individual developers do want to see the GPL respected by redistributors, but don't have the time nor inclination to enforce the GPL and/or LGPL. A single copyright holder can take on this burden for developers and do enforcement for the entire codebase without bothering the developers on a regular basis. This is indeed a primary reason that developers assign to organizations like the FSF.

It should be noted, however, that most "GPL enforcement" by for-profit copyright holders is actually dubbed "sales". In other words, the GPL violator is told they are infringing copyright, but that the company would be happy for them to continue their would-be infringing activities under a proprietary license. Such enforcement is not done with expanding the Free Software community in mind, and therefore is rarely a desired outcome for developers who are not employees of the copyright holding company.

Liability Protection

There is a some amount of liability protection afforded developers who assign their copyrights on FLOSS code to a separate entity.

Details on how such liability protection may or may not apply in a specific situation should of course be directed to a lawyer.