4 ms·

Capistrano: Can't be MIT licensed any more

17 points by jamesbritt 13y ago

mintplant 13y ago
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 13y ago
  > 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.
  - mintplant 13y ago
    On the contrary. "refute" is defined as: > refute - v, prove (a statement or theory) to be wrong or false; disprove. I contend that this section does disprove the theory that Capistrano cannot continue to be licensed under the MIT License: > 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. Of course, this is all semantics.
  - argonaut 13y ago
    You forgot to claim that you know more about digital IP than Capistrano's digital IP lawyer. Oh wait...
  - tzs 13y ago
    No, refutes is entirely correct. The lawyers for the company that owns SSHKit say there is no licensing issue.
    - JoshTriplett 13y ago
      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 13y ago
        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 13y ago
        > 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.
trengrj 13y ago
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.
nilved 13y ago
> 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 13y ago
  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 13y ago
    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.
billyjobob 13y ago
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#Linking_and_derived_works https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin... 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."

17 points by jamesbritt 13y ago

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 13y ago
> 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.
- mintplant 13y ago
  On the contrary. "refute" is defined as: > refute - v, prove (a statement or theory) to be wrong or false; disprove. I contend that this section does disprove the theory that Capistrano cannot continue to be licensed under the MIT License: > 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. Of course, this is all semantics.
- argonaut 13y ago
  You forgot to claim that you know more about digital IP than Capistrano's digital IP lawyer. Oh wait...
- tzs 13y ago
  No, refutes is entirely correct. The lawyers for the company that owns SSHKit say there is no licensing issue.
  - JoshTriplett 13y ago
    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 13y ago
      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 13y ago
        > 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.

trengrj 13y ago

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.

nilved 13y ago

> 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 13y ago
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 13y ago
  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.

billyjobob 13y ago

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#Linking_and_derived_works https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin... 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."