[zeromq-dev] [ANN] zmq.rs - native stack of ØMQ in Rust

[Robert Kern]

On 2014-07-03 12:57, Pieter Hintjens wrote:
> Our process bans patches delivered any way except via the GitHub
> fork/merge process. That can only happen from public forks, thus any
> patch is published (and optionally licensed) before the author can
> start making a pull request.
>
> We simply don't accept patches provided any other way. So the question
> is, what's the license on a derived work published on GitHub? IANAL
> and TINLA however it seems clear that with a share-alike license, the
> derived work is by definition published under the same license,

This is not correct. The act of publishing a derivative work does not 
automatically license the derivative work in any particular way even when the 
original license is share-alike. You don't have *permission* to publish it any 
other way, certainly, but that doesn't stop one from doing it in error. They can 
still fix their error by removing the derivative work. They do not have to 
license it to you under any given license. Violating the upstream license just 
means that you lose the ability to distribute the derivative work.

Consider the case of a developer employed by a company. As is typical, the 
company owns the copyright to whatever code he writes in the course of his job. 
Suppose he forks 0MQ to submit a patch needed for work, but he doesn't get the 
appropriate permissions from his superiors to do so. The contents of his PR are 
still owned by the company, and no one else has a license to use it until they 
decide so (of course, no one outside knows this because the developer goofed). 
The fact that the forked project is licensed under a share-alike license doesn't 
force the company to retroactively license their IP under that license. If you 
merged that PR, they can still force you to remove it.

> whereas with a "permissive" license, you can't make that assumption.
> It may be, and it may not be.
>
> Which puts the onus of verification on the person clicking "Merge",
> which brings us back to "maintainers as experts", which we have
> learned is not good for community growth.

I think that you can reasonably take the act of publishing a forked repo without 
changing its attached license indicates agreement to apply that license to the 
modifications in the repo. Similarly, the act of submitting a PR to a project 
that declares that it will only accept PRs under the project's license is 
sufficient in my book.

If you don't think that this is sufficient for the MIT/BSD license, then it is 
also insufficient for share-alike licenses. The share-alike nature of the 
license does not provide any more protection. If someone comes along claiming 
that they own code that was committed by someone else or if they say that they 
contributed it in error and didn't intend to contribute it under the project's 
license, you have exactly the same problem.

Karl Fogel's book _Producing Open Source Software_ covers this issue:

   http://producingoss.com/en/contributor-agreements.html

Note that there is no discussion of share-alike licenses providing extra protection.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco