how much right do I have on my project, if there are patches by others?

Rick Moen rick at
Fri Jul 6 21:49:59 UTC 2007

Quoting John Cowan (cowan at

> Okay, I'm sold.

This portion struck me as particularly interesting:

  The difference is practically relevant because, according to 17 USC 201,
  the holder of the collective-work copyright is legally privileged to set 
  the distribution terms for the package as a whole. (In the statute, this 
  expressed negatively as a statement that the collective-work copyright 
  holder acquires only those rights.)

Community opinion strongly holds that this is _untrue_ -- that a
codebase project leader must first always secure individual signoff of
every single damn contributor back to the Dawn of Time, before he/she
may lawfully issue a revised instance under a new licence (even if
he/she carefully avoids injuring contributors' economic interests).

It turns out that -- as a matter of law, as opposed to ethical norms -- 
the cited community view is pure bullshit.  Which of course doesn't stop
that error being asserted frequently, and with great conviction.

Catherine and Eric comment on the long-term problem of changing the 
licences of complex projects, given those community traditions, in the
section that follows:

  To solve this problem, we need to go beyond recognizing that project
  leads have the legal authority to set licensing terms, and cede them
  the ethical authority to do it as well. Informally we already do this
  for small, single-user projects that are only patched by other people.
  We need to adopt a similar policy about major multi-author projects as
  well, projects as big as the Linux kernel or Apache or SAMBA or the

  The authors have a specific recommendation about this. We recommend that
  major projects elect a "license czar" whose job it is to keep the
  project's licensing technology current, modify the project license when
  needed, and keep in touch with other license czars and expert groups
  like the Open Source Initiative.

  We also recommend that project contributors no longer attach explicit
  licenses of any kind to their patches or modules, and consent to having
  existing contributor licenses removed. Bare copyright notices are OK,
  but explicit licenses on contributions complicate the legal picture in
  unhelpful ways. It's best if every project has one license, incorporated
  by reference in its parts. (Practice has been moving in this direction

  Third: we recommend that project leaders show respect for their
  contributors by preceding major licensing changes with a public comment
  period. It is important not just that the right thing be done, but that
  the right thing be seen to be done.

There are any number of reasons why this advice will probably tend to be
ignored -- but it _is_ good advice.

Cheers,                                        "He who hesitates is frost."
Rick Moen                                                 -- Inuit proverb
rick at  

More information about the License-discuss mailing list