
Capistrano: Can't be MIT licensed any more  - jamesbritt
https://github.com/capistrano/capistrano/issues/926?utm_content=bufferfe3ee&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
======
mintplant
The current title ("Capistrano: Can't be MIT licensed any more") is
misleading. leehambley (Capistrano maintainer) refutes this claim in the
thread itself:

> I think I made myself clear. Our lawyers don't see a problem (and don't see
> that the GPL of SSHKit is viral in terms of the usage of Ruby, and
> Rubygems), that in this circumstance the copy-left of the GPL does not cross
> the boundary of Rubygems (Capistrano hints to Rubygems that it would like to
> use SSHKit). And that even using the LGPL with it's provision for "dynamic
> linking" being an exception adds nothing to the discussion for scripting
> languages.

> I won't chance the licence without a proper, peer reviewed audit, if this
> means your lawyers don't think you can use Capistrano, I'm sorry for that,
> but I can't afford the time and energy to re-open this debate. (again…
> again… again… again).

> SSHKit is intentionally restrictively licensed to protect the investment
> that my company made in building it, which is something I also don't have a
> choice about. If you want to rewrite a competitive alternative to SSHKit
> with a compatible API and release it, that would probably be best for the
> community. (At least those backed by pushy IP lawyers)

Funnily enough, this is a case where changing the title _away_ from that of
the original page would improve the accuracy of the submission.

~~~
JoshTriplett
> refutes this claim

I do not think that word means what you think it means.

"disputes" might be more accurate, but that still wouldn't invalidate the
title. This is an entirely legitimate bug report; the maintainer of Capistrano
seems to hold a very unusual view on Open Source licensing, and one at odds
with just about everyone else in the Open Source community.

~~~
tzs
No, refutes is entirely correct. The lawyers for the company that _owns_
SSHKit say there is no licensing issue.

~~~
JoshTriplett
Either the company in question is creating some strange implicit exception to
the GPL, or proprietary/GPL-incompatible products derived from Capistrano are
in violation of the GPL and the company in question simply declines to pursue
those violations.

Here's the statement from the folks who wrote the GPL, on this exact point:
[https://www.gnu.org/licenses/gpl-
faq.html#GPLWrapper](https://www.gnu.org/licenses/gpl-faq.html#GPLWrapper)

~~~
tzs
The statement you quote is not on point, since there is no "module B" here.
What they are trying to describe in that is the situation where someone takes
a GPL piece of code, and writes a wrapper module (module B) that adds some
kind of interface that their proprietary module (module C) knows how to
interface with, and then they distribute this whole mess.

As far as I can see, Capistrano has not wrapped SSHKit or modified it. It just
invokes SSHKit through its public interfaces. In particular, Capistrano does
not seem to be a derivative work of SSHKit. If it and SSHKit are distributed
together, this would be what the GPL calls mere aggregation.

Conceptually, it is no different than distributing bash along with a bash
script that is not under GPL.

~~~
JoshTriplett
> The statement you quote is not on point, since there is no "module B" here.
> What they are trying to describe in that is the situation where someone
> takes a GPL piece of code, and writes a wrapper module (module B) that adds
> some kind of interface that their proprietary module (module C) knows how to
> interface with, and then they distribute this whole mess.

Other than flipping C and A around, what you describe exactly matches the
situation from the GPL FAQ.

Apart from that, I'm not going to argue GPL, derived works, and linking here;
suffice it to say that the interpretation of the GPL authors is that code
calling into GPLed code (directly or indirectly) is a derived work and subject
to the GPL, and thus may not be proprietary. That's the interpretation and
intention of the FSF in writing the license, and it's the standard
interpretation in the broader FOSS community.

~~~
tzs
In all the cases I'm aware of where courts have considered code calling into
other code, they have found that this does not make the caller a derivative
work of the callee.

Here's a good quick and dirty test. If I write code that interfaces to your
code, and I do this without looking at anything of yours other than things
that are not copyrighted (such as your publicly documented interfaces), then
my code cannot be a derivative work of your code. If I want to distribute my
code (in source or binary), and I'm not distributing your code with it, then I
don't have any reason to care what license your code is using.

Now, if I've going to take my code, and your code, and compile and link them
together and distribute the result, then (1) I've actually copied your code
into something I'm distributing, and (2) I'm distributing your code. In this
case, your license is very relevant. This is the kind of situation the FSF was
mostly thinking of when they wrote most of that FAQ. I think they were caught
off guard by the explosive rise of the so-called scripting languages, which do
away with the whole linking things together into a package to distribute
thing.

This is very good for free software. If calling into code (directly or
indirectly) made the caller a derivative work of the callee, then it would be
a copyright violation to make and distribute apps for jailbroken iPhones.
These apps call into Apple's system software, and so would be derivative works
and require Apple's permission to distribute, and Apple has not given that
permission. It would be similar for desktop operating systems--application
writers would need permission from the OS copyright owner to make applications
that run on that OS.

Capistrano is distributed in source form (and as far as I can see that is the
only form in which it is distributed). Looking at the source, I don't see them
including anything copyrighted from SSHKit. I'm not a Ruby guy, so maybe I
missed some tricky Ruby thing that would make it non-obvious. Any Ruby users
want to take a look?

~~~
belorn
> In all the cases

Please cite references rather than hand waving.

Here is some other dirty tests: If I write a website that links to someone
else images, I can still be held liable under copyright law. It is not good
enough defense to claim that the images themselves are not sent by my web
server.

Dirty tests are often not enough in discussion around law.

~~~
tptacek
For what it's worth, 'tzs is a law school grad.

~~~
tzs
An almost grad. Never got around to finishing a paper for a seminar, which was
needed to satisfy a writing requirement.

------
nilved
> the GPL is recognised to be a dinosaur that has little bearing in modern
> software infrastructures

If I needed any more reason not to use Capistrano, this is it. But I need to
wonder why people still use such outdated and poorly implemented instruments
as Capistrano in 2014. I speak for myself only, but we have about 200 websites
that use Capistrano at my work, each with its own 50-line Capfile, that is
subtly broken depending on which Capistrano version you use. Every 2.x release
is broken in a different way such that we have an index of which exact version
of Capistrano (down to the patch level) works because the rest don't. 3.x is
backwards incompatible and infeasible to upgrade at this scale.

git-based deployment takes five seconds to set up and leverages the existing
infrastructure instead of creating a feeble reinvention of the wheel, so maybe
we should forget this licensing issue and use other deployment strategies
because they're plain better.

~~~
jamesbritt
_git-based deployment takes five seconds to set up and leverages the existing
infrastructure instead of creating a feeble reinvention of the wheel_

Isn't Capistrano basically git-based deployment, wrapped in some DSL-ish
commands?

~~~
nilved
Sort of. Capistrano can clone a git repo for your application code, but by
git-based deployment I mean via post-receive hooks a la Heroku. For example, a
short script that runs `bundle install`, `rake assets:precompile` and restarts
your web server. Ultimately, you get a solution like Heroku where you deploy
by `git push`ing to the server.

Trivial to set up, easier to modify, easier to integrate with your git
repository, easier to debug, and isn't _completely broken_. Capistrano
compared is all downsides.

------
trengrj
Will Bryant is unhelpful here with his aggressive tone and how he "threatens"
to post on the mailing list warning people about the project.

The question regarding when a project becomes a derivative in the GPL sense
seems quite complicated and is definitely something that should be decided by
lawyers rather than flamewars online.

------
billyjobob
It seems a strange situation. Both packages have the same author. He chose MIT
license for one and GPL for the other. He claims his lawyers told him this was
OK, but in fact legal opinion is divided on this:
[https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...](https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works)

Of course, from his point of the view this really doesn't matter: he is the
copyright holder of both packages and he can hardly violate his own copyright.
The problem is for other people who might want to distribute modified copies
of Capistrano under MIT but who can actually only do so under GPL.

If he really does want the whole package to distributed as MIT with no
ambiguity then the solution is simple: change the license of SSHKit to LGPL.
If the company won't agree to that, then change it to GPL plus written
exception that we won't sue you for linking to Capistrano.

However, he could be deliberately sneaky. Tell people "our lawyers think this
is OK, but check with your own lawyers". Then if any competitor does fork
Capistrano and the fork becomes too successful he could say "whoops our
lawyers have changed their mind, you've violated the GPL and we are now suing
you."

