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

[John Cowan]

Rick Moen scripsit:

> I doubt that.  I personally find Catherine and Eric Raymond's analysis
> at http://www.catb.org/~esr/Licensing-HOWTO.html#id2790762 persuasive.

Okay, I'm sold.

> --
> "Zees American words are too much.      Zen our culture you'll wrench;
> With 'le parking' 'le weekend' & such.  Wiz our children we'll be out of touch."
> Eef you anglicize French,                -- L'Academie Francaise in a nutshell

See http://recycledknowledge.blogspot.com/2005/06/french-in-all-its-purity.html

--
A rabbi whose congregation doesn't want         John Cowan
to drive him out of town isn't a rabbi,         http://www.ccil.org/~cowan
and a rabbi who lets them do it                 cowan@...
isn't a man.    --Jewish saying

[Rick Moen]

Quoting John Cowan (cowan@...):

> 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
  BSDs.

  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
  anyway.)

  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@...  

[Matthew Flaschen]

Rick Moen wrote:

> Quoting John Cowan (cowan@...):
>
>> 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.

It's far from certain that they are correct about this.  Others, such as
the Apache project, would seem to disagree.  They have clearly defined
coauthors, but still require broad and explicit contributor licenses
(http://www.apache.org/licenses/icla.txt) and take the view that only
the foundation (not the coauthors) can relicense.

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

Why?

Matt Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> It's far from certain that they are correct about this.  Others, such as
> the Apache project, would seem to disagree.

There was a time, and it probably was for around 3 seconds some decades
ago, when I was actually impressed, when informed in this headline-style
fashion that someone had disagreed.  (Then I discovered Usenet.)

> They have clearly defined coauthors, but still require broad and
> explicit contributor licenses
> (http://www.apache.org/licenses/icla.txt) and take the view that only
> the foundation (not the coauthors) can relicense.

Your assumption that the terms of someone's contract somehow indicates
the shape of copyright law is hereby noted with wry amusement.


> >   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.
>
> Why?

As the level of quotation _should_ have made clear, you are asking the
wrong person -- and I'm unclear on why I should be teaching you how to
look up other people's e-mail addresses.  

I _might_ be glad to explain Catherine and Eric's point to you anyway --
did you read the essay, by the way? -- if I weren't a bit mystified as
to why the utility of that understanding towards any large open source
project's long-term management weren't, on the whole, rather obvious.
 

[Matthew Flaschen]

Rick Moen wrote:
> Quoting Matthew Flaschen (matthew.flaschen@...):
>
>> It's far from certain that they are correct about this.  Others, such as
>> the Apache project, would seem to disagree.
>
> There was a time, and it probably was for around 3 seconds some decades
> ago, when I was actually impressed, when informed in this headline-style
> fashion that someone had disagreed.  (Then I discovered Usenet.)

Great.  I'm not impressed that ESR is correct, either, simply because he
happened to publish an essay.

>> They have clearly defined coauthors, but still require broad and
>> explicit contributor licenses
>> (http://www.apache.org/licenses/icla.txt) and take the view that only
>> the foundation (not the coauthors) can relicense.
>
> Your assumption that the terms of someone's contract somehow indicates
> the shape of copyright law is hereby noted with wry amusement.

I'm not citing it as proof of the state of copyright law.  I'm citing it
as proof that there is no consensus that ESR's view is correct.

Matt Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> Great.  I'm not impressed that ESR is correct, either, simply because he
> happened to publish an essay.

Is this some sort of wacky conversational gamesmanship?  The reason I
ask is that I hadn't made any sort of appeal to authority, so declining
one where none was offered seems, at best, an odd response.  

The closest I came to anything even resembling argumentum ad verecundiam
was pointing out that the subject happens to lie within Catherine's
(not, of course, Eric's) professional legal practice.  However, I was
actually perhaps naively hoping that people would _read_ the essay, and
ponder it on its objective merits.

Please do consider that approach, at your convenience.

> I'm not citing it as proof of the state of copyright law.

Wait, were you the Matthew Flaschen <matthew.flaschen@...> who
cited a contract's terms on a question of copyright law, or are you
perhaps some different Matthew Flaschen <matthew.flaschen@...>?

> ...ESR's view...

As an occasional co-author myself, and on behalf of co-authors
everywhere, I'd ask that you please, next time you attempt to read
multi-author essays, not skip half the header data.

[Richard Fontana]

Rick Moen wrote:
> The closest I came to anything even resembling argumentum ad verecundiam
> was pointing out that the subject happens to lie within Catherine's
> (not, of course, Eric's) professional legal practice.  

According to
http://www.cpmy.com/attorneyview.asp?Post=14
Catherine Raymond's expertise lies in insurance law, professional liability law,
and general commercial litigation.

- RF

[Rick Moen]

Quoting Richard Fontana (fontana@...):

> According to
> http://www.cpmy.com/attorneyview.asp?Post=14
> Catherine Raymond's expertise lies in insurance law, professional
> liability law, and general commercial litigation.

I spoke with her by telephone, at the time she and Eric first published
the piece, and she said (paraphrasing, entirely from memory) that she
did a substantial amount of copyright law as part of her work.

However, I don't suppose there's any chance of returning to the merits
of the HOWTO's analysis, which to my knowledge in no way depend on who
or what did or did not write it?  

[Matthew Flaschen]

Rick Moen wrote:
> Quoting Matthew Flaschen (matthew.flaschen@...):
>
>> Great.  I'm not impressed that ESR is correct, either, simply because he
>> happened to publish an essay.
>
> Is this some sort of wacky conversational gamesmanship?  The reason I
> ask is that I hadn't made any sort of appeal to authority, so declining
> one where none was offered seems, at best, an odd response.

You said "It turns out that -- as a matter of law, as opposed to ethical
norms -- the cited community view is pure bullshit."  I merely mean to
point out that it is not settled who is correct, as a matter of law.
Thus, I am reluctant to accept that the community view is "pure bullshit".

>> I'm not citing it as proof of the state of copyright law.
>
> Wait, were you the Matthew Flaschen <matthew.flaschen@...> who
> cited a contract's terms on a question of copyright law

I am indeed the one and only Matthew Flaschen
<matthew.flaschen@...>.  Exactly what comment are you referring to?

>> ...ESR's view...
>
> As an occasional co-author myself, and on behalf of co-authors
> everywhere, I'd ask that you please, next time you attempt to read
> multi-author essays, not skip half the header data.

My mistake.

Matthew Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> You said "It turns out that -- as a matter of law, as opposed to ethical
> norms -- the cited community view is pure bullshit."  I merely mean to
> point out that it is not settled who is correct, as a matter of law.

Actually, I think that's amply clear.  As already pointed out, 17 USC
201 provides otherwise concerning collective works -- and the
contributor of a patch would have even _less_ say if the package as a
whole were judged a joint work.

> I am indeed the one and only Matthew Flaschen
> <matthew.flaschen@...>.  Exactly what comment are you referring to?

Your own immediately preceding message.

  > It turns out that -- as a matter of law, as opposed to ethical norms --
  > the cited community view is pure bullshit.

  It's far from certain that they are correct about this.  Others, such as
  the Apache project, would seem to disagree.  They have clearly defined
  coauthors, but still require broad and explicit contributor licenses
  (http://www.apache.org/licenses/icla.txt) and take the view that only
  the foundation (not the coauthors) can relicense.

--
Cheers,                            To you, this thought         Alot
Rick Moen                          I gently allot:              Isnot
rick@...                                             Aword.

[Matthew Flaschen]

Rick Moen wrote:

> Quoting Matthew Flaschen (matthew.flaschen@...):
>
>> You said "It turns out that -- as a matter of law, as opposed to ethical
>> norms -- the cited community view is pure bullshit."  I merely mean to
>> point out that it is not settled who is correct, as a matter of law.
>
> Actually, I think that's amply clear.  As already pointed out, 17 USC
> 201 provides otherwise concerning collective works -- and the
> contributor of a patch would have even _less_ say if the package as a
> whole were judged a joint work.

I'm not sure joint and collective are the only two relevant possibilities.

>   > It turns out that -- as a matter of law, as opposed to ethical norms --
>   > the cited community view is pure bullshit.
>
>   It's far from certain that they are correct about this.  Others, such as
>   the Apache project, would seem to disagree.  They have clearly defined
>   coauthors, but still require broad and explicit contributor licenses
>   (http://www.apache.org/licenses/icla.txt)

This is my citation on Apache's /view/ of copyright law.  Obviously,
their CLA does not change the law, but it seems to indicate that Eric
and Catherine's interpretation is not universally shared.

Matthew Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> I'm not sure joint and collective are the only two relevant possibilities.

Indeed, I'm quite certain that you're entirely correct about the limits
on your present understanding:  So, you could try reading relevant
statutes and caselaw, to fix that.  Meanwhile, argumentum ad ignorantum
isn't isn't especially useful in public forums.

> This is my citation on Apache's /view/ of copyright law.

It is, actually, your citation of a contract between contributors and
Apache Foundation, which not only necessarily has no effect on copyright
law (except in contributor's grant of a copyright licence in clause 2),
but also is notably useless for learning about copyright law, and in
particular for learning about "who can relicense".

[David Woolley (E.L)]

John Cowan wrote:

> As you know, you can also ask the patch author to transfer the
> copyright; a third way is to ask for the patch to be licensed

However, most will not if they believe that their code might then be
used in a proprietary fork!

> under a permissive license such as the BSD license that is
> compatible with both the GPL and proprietary use.
>


--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[David Woolley (E.L)]

John Cowan wrote:

> It is, however, how patches are accepted and processed: patch authors,
> if the patch is substantial and is accepted into the original work,
> do meet the definition of joint authorship.

I don't believe they do, because the original work was not written with
the specific intention of integrating with that particular patch.
I believe that the second paragraph of the legislative commentary applies.

However, if you were right, that would fundamentally undermine copyleft
licences, as, a contributor could contribute a small but non-trivial
patch and then relicence the whole product under their proprietary licence.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[David Woolley (E.L)]

John Cowan wrote:
> Arnoud Engelfriet scripsit:
>
>> So I *think* any contributor can sue over infringement over his
>> 'contributor version', independently of any other contributor.
>
> Yes, this is fundamental.  Provided a derivative work is made under
> license, the derivator is an author with all the copyright rights

If it is a derivative work, then, in terms of the legal commentary
referenced earlier, it is not a joint work and the authors are *not*
co-owners.  In terms of the examples in that commentary, the original
work is the novel and the derivative is the film.
--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[Fabian Bastin]

Rick Moen a écrit :

> Quoting John Cowan (cowan@...):
>
>  
>> It is, however, how patches are accepted and processed: patch authors,
>> if the patch is substantial and is accepted into the original work,
>> do meet the definition of joint authorship.
>>    
>
> I doubt that.  I personally find Catherine and Eric Raymond's analysis
> at http://www.catb.org/~esr/Licensing-HOWTO.html#id2790762 persuasive.
> (Note that this is within Catherine's legal specialty.)

Just a quick remark. While I find this essay interesting, I fell
uncomfortable on one point: it is oriented towards U.S. legislation.
Most open-source project involves involve contributors from various
countries, so is this analysis enforcable in this international context?
The notion of joint, collaborative, derivative,... work can vary from
country to country, and depending on where the case is disputed, the
conclusion could be different in my opinion. For instance, the notion of
collective work exists in France, but not in Belgium.

An analysis (in French) for the Belgian case is available here:
http://www.droit-technologie.org/upload/dossier/doc/111-1.pdf

Briefly, if I correctly remember the conclusions in this document, the
stated point for Belgium was close to the notion of collective work in
the sense that each contributor keeps the copyright (except in the case
of explicit transfer) on his own code, but as soon as the contribution
is sufficient enough to create an original work (the notion of
"original" being sometimes difficult to assert, but in the previously
cited essay we can say that 20 lines of code were not sufficient), they
become "co-authors" and therefore a change of license for the whole work
require their explicit agreement (even if they have not explicitely
asked a status recognition). The common point in my view with the HOWTO
is that legally speaking, we should make a distinction between
"patchers" and "contributors" and their rights depend on the individual
country legislations. But in most legislations, patchers (that is minor
contributors, so the new work cannot be considered as original) seem to
have very limited rights, whatever the open-source community think about
it. This does not exclude signed agreements like in the Apache, since it
always help to avoid future interpretation problems. BTW, this is not in
condradiction with the Apache view as long as we admit that the required
agreement concerned contributors, not patchers, and in line with the
comment of John in the sense that the patch must be substantial to be
considered as a contribution leading to an original work.

This analysis also leads to the conclusion that with respect to the
Belgian legislation, the work is neither joint or collective work. It is
a joint work in the sense that there are several identifiable
co-authors, but this assertation is not applicable: "Therefore, any
co-author of a joint work is free to distribute the work on any terms he
chooses — including changing the license, and including taking a copy
closed source!" And is a collective work in the sense that "Individual
portions of such a work may (and often do) have copyrights, and there
may also be a collective-work copyright on the work as a whole." but not
in the sense that "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)." This is
close to the commonly community practice.

Once again, this anlaysis is Belgian-oriented, to my knowledge (I am not
a lawyer, but I have lawyer friends) but Belgium benefits for an
important position in Europe since if the European legislation is silent
on one point, the Belgian legislation prevails. In case of a dispute,
which legislation should prevails, the US or the European one if there
are actors on both sides of the ocean?

Fabian Bastin

[John Cowan]

Fabian Bastin scripsit:

> In case of a dispute, which legislation should prevails, the US or
> the European one if there are actors on both sides of the ocean?

http://en.wikipedia.org/wiki/Conflict_of_laws is quite good on the
subject, which is a very difficult one involving the application by
courts of foreign law.  Clicking on the links in the right-hand infobox
will provide a wealth of further information on the subject.
Be prepared, hackers; if you thought ordinary domestic law was
vague and complicated, here's what happens when lawyers get their
hands on such hackerly concepts as recursion and self-reference.

(The .sig below was chosen at random without knowledge of the subject
of this email!)

--
The first thing you learn in a lawin' family    John Cowan
is that there ain't no definite answers         cowan@...
to anything.  --Calpurnia in To Kill A Mockingbird

[John Cowan]

David Woolley scripsit:

> >As you know, you can also ask the patch author to transfer the
> >copyright; a third way is to ask for the patch to be licensed
>
> However, most will not if they believe that their code might then be
> used in a proprietary fork!

I don't know that that's true at all.  I dual-license some of my
code under the GPL and a permissive license so that it can be
used in proprietary applications as well as GPLed ones (I don't
like the BSD and MIT licenses, and the more modern permissive
licenses aren't compatible with the GPLv2.)

--
My confusion is rapidly waxing          John Cowan
For XML Schema's too taxing:            cowan@...
    I'd use DTDs                        http://www.ccil.org/~cowan
    If they had local trees --
I think I best switch to RELAX NG.

[Matthew Flaschen]

David Woolley wrote:

> However, if you were right, that would fundamentally undermine copyleft
> licences, as, a contributor could contribute a small but non-trivial
> patch and then relicence the whole product under their proprietary licence.

It would seem that any interpretation except a series of independent
(i.e. neither joint nor collective) derivative works would undermine
copyleft.  If programs are collective works, the primary author can
relicense contributions (without explicit copyright assignment) to a
copyleft program under a proprietary license.  If they are joint works,
any major contributor can do so.

Matthew Flaschen

[Rick Moen]

Quoting Matthew Flaschen (matthew.flaschen@...):

> It would seem that any interpretation except a series of independent
> (i.e. neither joint nor collective) derivative works...

[USA law assumed for present discussion.]

A third-party patch in _separate_ form is indeed logically treated as
commentary; thus, as an independent work.  Merging it into the original
work strikes me as very likely to create a derivative work -- which then
necessarily falls into either the joint- or collective-work category.

> ...would undermine copyleft.

Doubt it (not that copyright law has a mandate to bolster copyleft).
See below.

> If programs are collective works, the primary author can
> relicense contributions (without explicit copyright assignment) to a
> copyleft program under a proprietary license.

If contributors prove that ye olde primary author has failed to
safeguard their interests or has violated agreements with them, then
nonetheless the primary author may find he/she lacks that option.
Please note that courts tend to measure "interests" for civil-law
purposes in economic terms:  A mere "Hey, your relicensing sucks" isn't
a really promising foundation for litigation.

But, anyhow, in that hypothetical, any party (obviously) can fork
rev. n-1, taking over maintenance under copyleft.

--
Cheers,                                      "Reality is not optional."
Rick Moen                                             -- Thomas Sowell
rick@...