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

[Pieter Hintjens]

On Thu, Jul 3, 2014 at 5:43 PM, Robert Kern <robert.kern at gmail.com> wrote:

We're stepping into legal whatif's here, however it's a good thread,
let's continue... I'll continue to defend my argument, even though I
do tentatively agree with you.

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

Let's agree to not use terms like "IP" when we mean copyright, as the
same term is used for patents, and that is confusing in this context.

This is probably the most likely case, person A submitting a patch
they wrote, yet don't own the copyrights to.

I see two plausible scenarios. One, the error is found rapidly, and
the patch is removed without harm. Indeed, as you say, there's no
obligation to license derived works at all.

Case two, the error is found much later, perhaps during a hostile
attack on the project. In that case, the project goes to court and
claims bad faith and/or negligence on the part of the real copyright
holders.

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

True. However, it's far easier to change the attached license

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

Even in the "stupid employee" scenario, it is arguable that a
share-alike license will be more convincing to a judge than a BSD
license. That is, the copyright owner can claim that they forked the
BSD project, added proprietary code, and published that in good faith
under, say, a commercial license. Perhaps they added their own LICENSE
text. Then there's a pull request, and then there is a merge, which
actually copies the code. Now the master branch has unlicensed code in
it. The maintainer wasn't doing his job. Ergo, no negligence from the
copyright holder.

Whereas if it's a share-alike license, that argument isn't tenable.
The employee is an agent of the firm, and they are liable for his/her
actions, authorized or not. There is no way to publish the derived
work _except_ under the same share-alike license. Whether that act of
publishing went through internal approval or not isn't the project's
concern.

There is another commonish case, which is a freelancer making changes
for a client, where the client owns the code. In this case, when it's
a BSD/MIT license, it can be extremely hard to convince the client to
allow patches to be sent back. Whereas when it's a share-alike
license, that discussion (and I've had many) is generally trivial.

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

I assume then that the book is out of date, or out of touch. We tried
CLAs in the early days of ZeroMQ. Not a single person signed one. They
are toxic to the entire concept of gradual involvement without upfront
agreement. A modern text on Producing Open Source should be explaining
how to get rid of CLAs, not provide examples of them.

/me rests his case. :)

-Pieter