how much right do I have on my project, if there are patches by others?
rick at linuxmafia.com
Fri Jul 6 21:49:59 UTC 2007
Quoting John Cowan (cowan at ccil.org):
> 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 linuxmafia.com
More information about the License-discuss