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

[Robert Kern]

On 2014-07-03 19:58, Pieter Hintjens wrote:
> 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.

Agreed.

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

I think that you can get the same effect just by having a public, documented 
policy of only accepting BSD-licensed contributions. Perhaps with language like 
"By submitting a PR to this project, you certify that all code therein is 
licensed under a BSD license. We do not accept submissions of code under other 
licenses." Then submitting that PR with non-BSD-licensed code is negligence (I 
use the term *loosely*, IANAL, etc.) on the part of the copyright holder (or 
their agent). The nice thing about the C4.1 process is that it does limit the 
vector of contributions in this way, so it's much easier to tailor that language 
and have a paper trail of activity. It's the paper trail that's important. 
Whether you have the share-alike license be the "trigger" or a simple policy 
statement won't make much difference, I don't think (IANAL!).

Neither one is a CLA, and neither will give you that same level of protection. 
Even with a CLA, if a company can prove that they didn't authorize the 
contributor to give the code, you are going to be removing the code. You might 
(IANAL!) be able to shift the blame to the contributor, you might be able to 
avoid monetary damages because of the company's negligent supervision, you might 
be able to delay removal with any of these approaches, but nothing lets you keep 
the code under your desired license if the legitimate copyright owner doesn't 
wish it.

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

Certainly, but that's an orthogonal issue that can cut both ways. I deal with 
clients that forbid using (L)GPLed libraries even for nominally "internal" 
projects because they are legally organized into many different subsidiaries, so 
distributing modified GPLed software across those legal subsidiary boundaries 
triggers the external distribution clauses (and they usually just shy away from 
any share-alike licenses out of FUD based on this experience). So that cuts out 
their potential contributions (and mine, if I can't use it to work for them!).

Some open source communities just prefer to work with BSD-like licenses (like 
the Lua community, to refer to a recent thread), so it's easier to get 
contributors from those communities if you stick to their style of license. For 
projects like language bindings (e.g. the Lua implementation of 0MQ, the Rust 
implementation, etc.), fitting into that community can make or break the project.

Deciding the project's license on those grounds involves considerations other 
than safety. If a reasonable amount safety can be obtained through other means 
short of CLAs, that lets you decide the license based on those other 
considerations. I'm not pushing for either side here, just saying that once 
safety is dealt with by other mechanisms, you can make the licensing decision 
based on the full set of contextual factors rather than having your hand forced 
by just the one.

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

I would say that it covers a broad spectrum of open source development and the 
different solutions that different projects take. For some projects at certain 
stages of maturity, CLAs seem to work fairly well. Python currently requires a 
CLA. I doubt it would have worked well for them fifteen years ago, but as a 
mature and popular project now (with some unfortunate copyright entanglements 
that led to the CLA process), it seems to at least do little harm. The maturity 
of the codebase and strict backwards compatibility requirements are a bigger 
source of drag on new involvement than signing a CLA.

I cite this section not to encourage the use of a CLA, just to note that there 
is no discussion of share-alike licenses automatically providing CLA-like 
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