5 ms·

The current title ("Capistrano: Can't be MIT licensed any more") is misleading. leehambley (Capistrano maintainer) refutes this claim in the thread itself: > I

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.

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.