On Thu, Jul 3, 2014 at 5:43 PM, Robert Kern <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
