Open Source and Contributor Agreements

[David Barrett]

Ok, so the tally I see is as follows (N=clear no, n=probable no,
.=unknown, y=probable yes, Y=definite yes):

          1  2  3  4  5
          -  -  -  -  -
Matthew  y  Y  N  n  N
     Ben  N  Y  n  n  Y
   Brian  Y  N  N  N  N
   Chris  y  y  N  N  N
    Alex  N  .  .  .  N
     Ian  N  N  .  n  n
   Simon  N  N  N  N  n
   Chuck  .  N  .  .  .

So it looks like Matthew, Ben, and Chris vaguely agreed with a couple
points, but everyone else rejected the argument entirely.  Personally, I
don't think the argument is so ridiculous, and this was a genuine
attempt to verify the board's reasoning.  Indeed, this is the only
coherent argument I can come up with to explain why an opt-out
contributor agreement can't be approved.  But given the list's reaction,
I'm guessing the board's reasoning must be different.

To repeat, I'm proposing an open source license that has integrated
grant-back license (*not* a copyright assignment) that can be optionally
reassigned to someone else, or removed entirely.  Thus while anything
you get from my source repository would probably list my name as the
default grant back, you are welcome to change that name to yourself when
you redistribute the code.

Regarding specific points brought up:

Matthew writes:
> No, the reason is that it would have no legal validity in many 
> jurisdictions.

I've seen no indication that this a concern to the board.  Indeed, I
thought our OVPL discussion generally decided the license back was
legally enforceable in most jurisdictions.


Brian writes:
> If the contributor agreement is to include a (C) assignment, then the
>  law in the U.S. wouldn't even permit it to be part of a mere license
>  that wasn't a signed writing. If it contains a specific license-back
>  to a specified individual or group then it probably discriminates 
> against everyone else.

First, it's not a copyright assignment.  Second, it's only specific to
an individual isnofar as I set it to my name when I redistribute it.
When you redistribute, you can set it to yourself, or remove it
altogether.  It's as non-discriminatory as can be done with an optional
provision -- the only discrimination is that anyone who disagrees with
the default needs to take action.


Chris writes:
> No. If it requires a license-back that goes beyond the license-grant 
> then it is discriminatory and does not comply with the OSD.

I don't totally follow this.  Given that the license-back is entirely
optional, and that you can put any (or no) name in the blank, I don't
see how the license discriminates.  At *worst* it allows anyone to
redistribute the code in a form that *slightly* favors them by putting
their name in the blank.  But the license itself favors nobody in
particular, and anyone can equally take advantage of this capability by
simply putting their name in the blank (or replacing the name that's 
currently in the blank).  It's just a default; nothing more.


Alex writes:
> No [it's not acceptable], for the above reason [violates right to 
> fork]. And because what people objected to about the OVPL was 
> asymmetry. Opt-out asymmetry is still asymmetry (I agree with that 
> one whole heartedly). And opt-out can itself be a pernicious (see, 
> for instance, spam discussions ad-nauseam).

First, unlike the OVPL (which mandated license back, and thus violated
the right to fork) making it optional preserves the right entirely.

Second, as for asymmetry, I'll grant it's nonzero -- when I give you
code, I can make it easier for you to grant me the license back than to
anyone else.  But the asymmetry is so slight (and so easily overcome --
just change a single line before redistributing) that the OSI would need
to blanket ban all optional provisions.

Third, regarding them being pernicious, I hope you agree it's quite a
stretch between spam (that arrives in your inbox against your will and
demands that you take action to stop being targeted) and an opt-out
provision (that you only deal with if you explicitly choose to
redistribute code that you got from me).


Ian writes:
> I think the big issue is whether anybody can make their own fork of 
> the code without having restrictions beyond those explicitly 
> permitted by the OSD.  Viewed in this way, an opt-out contributor 
> agreement to a specific party is troublesome.

First, they clearly can fork because it's opt-out.  Second, anybody has
the capability to change the "specific party" to themselves or anyone
else, or to nobody else.

Ian also writes:
> I will add that it should be clear that such a license will drive 
> away many potential contributors.

Possibly.  But it seems to work for some of the most successful open
source projects -- even when requiring overt copyright assignment
requiring physical stamp licking.  If it works under those difficult
conditions, it seems like it work much better if the contribution
process were made much easier.


Simon writes:
> My view is that contributor agreements are firmly the domain of 
> project governance and have no place in software licenses.

Ok, that's a fair view, and I certainly wouldn't force licenses to 
combine the two.  But I see nothing in the OSD that prohibits the 
combination.  The license states what rights you have to the code; I'm 
just asking people who get code from me to explicitly decide whether 
they are redistributing within the context of my governance structure 
(ie, but granting me the license back and thus making their code 
eligible for inclusion in my branch), or not.  Basically, I'm asking you 
to specify whether you are forking or not.  You're welcome to do it; it 
doesn't seem too onerous to simply state one way or the other.



So given all this, can you provide a clear argument for why an opt-out 
integrated contributor agreements violates the OSD, or violates some 
unstated "openness" criterion?

I seriously tried to craft that argument on behalf of the board, and it 
was shot down.  I'd love to hear your attempt.  If you truly believe the 
reasoning is so obvious, please state it.

-david