Open Source and Contributor Agreements

[David Ryan]

I'm a bit late to this argument, thanks to a week away from email.  
First, well done David for attempting to clarify these issues further.  
The responses show that this continues to be a fuzzy area where there is 
no clear consensus.

Most of the argument seem to have run there course, however, I'd like to 
add a point..

There seems to be a lot of people talking about the "right to fork".  It 
should be made clear that the OVPL *did* allow projects to fork.  There 
was nothing stopping this in the license.  It wasn't because the OVPL 
did not allow forks that it was considered not OSI compatible.  It was 
because of the asymmetry of the license, and that the initial developer 
had a privileged position.  The initial developer could always 
re-integrate code from the fork into their version of software.  Some 
developers might consider this discriminates because they may not want 
their fork merged back into the initial developer version. This right to 
stop merging from happening is also why the OVPL was not compatible.

The interesting thing is that a true community license like the GPL 
where nobody has a clear advantage (ie copyright ownership), forks and 
merging can be done without issue (assuming all code is genuine GPL 
code).  In these situations, all the problems of initial developers and 
forks are not an issue. 

I'm really curious to discover if the GPL's intention was to allow both 
scenarios, or if the incumbent initial developer is considered 
acceptable and encouraged?

Just another 2c worth,
David.


David Barrett wrote:

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


-- 
--
David Ryan. aka Oobles.
http://www.livemedia.com.au/Blog