Non-capistrano, non-GPL app deployment tools?

62 views
Skip to first unread message

Will Bryant

unread,
Feb 7, 2014, 4:59:08 AM2/7/14
to wellr...@googlegroups.com
What are people using for deploying their apps these days?

The current maintainer of Capistrano has based v3 on a GPLed library (SSHkit) and his lawyers and ours have a difference of opinion as to whether this makes Capistrano GPL too (https://github.com/capistrano/capistrano/issues/926). I find the advice he has received from his company's lawyers surprising as to me it implies the see the GPL as the same as the LGPL, which it certainly is not. Would be interested to hear if anyone else has had their lawyers look at this...

So anyway, we wouldn't want to take that risk, so what other options are there we should be considering these days?

Vlad the Deployer had some good stuff when it came out but looking at the current readme and recent commits I get the impression it has fallen out of date a bit.

There is Mina which I just heard of today, but I haven't tried it.

Any others we should be looking at?

Nahum Wild

unread,
Feb 7, 2014, 5:44:10 AM2/7/14
to WellRailed
I've heard of Chef and/or Puppet being used.

Anyone know what do the continuous integration tools use?


--nahum



--
You received this message because you are subscribed to the Google Groups "WellRailed" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wellrailed+...@googlegroups.com.
To post to this group, send email to wellr...@googlegroups.com.
Visit this group at http://groups.google.com/group/wellrailed.
For more options, visit https://groups.google.com/groups/opt_out.

Jeremy Olliver

unread,
Feb 7, 2014, 5:53:04 AM2/7/14
to wellr...@googlegroups.com
I believe most chef or puppet deployment usage is in a continuous deployment manner (deploying latest passing builds from a CI server).

We're still using chef to setup a server, but Capistrano v2 (with our own extension gem easy-deployment) to deploy.

Something else worth looking at is recap, which is Capistrano (2?) under the hood, but rewrites tasks for speed - no releases dir, directly runs the app from the git clone, and only bundle or asset if the relevant files have changed. Obviously it comes with some fairly heavy choices/conventions to support this. Codeclimate have a blog post on the topic I think.

Cheers,
Jeremy


--
Jeremy Olliver


Nahum Wild

unread,
Feb 7, 2014, 6:06:10 AM2/7/14
to WellRailed

Ugh, I ment deployment and not integration.

I've just been assuming that those tools were used in that process...

--nahum

Grant McLean

unread,
Feb 7, 2014, 1:52:22 PM2/7/14
to wellr...@googlegroups.com
On Fri, 2014-02-07 at 22:59 +1300, Will Bryant wrote:
> What are people using for deploying their apps these days?
>
> The current maintainer of Capistrano has based v3 on a GPLed library
> (SSHkit) and his lawyers and ours have a difference of opinion as to
> whether this makes Capistrano GPL too
> (https://github.com/capistrano/capistrano/issues/926).

I'm obviously missing something here. What would the problem be even
*if* Capistrano was GPL? Is your product a modified version of
Capistrano? If not, the fact that your deployment tool happened to be
licensed under the GPL would have no bearing on the software you used it
to deploy.

Regards
Grant

Steve H

unread,
Feb 7, 2014, 3:08:43 PM2/7/14
to wellr...@googlegroups.com
If you're concerned, simply don't bundle capistrano with your application; use it independently. Your capistrano deploy scripts don't even need to be in the same repository, let alone the Gemfile.

To add to what Grant said: rsync is GPL; if you used rsync to deploy your application, it doesn't mean your application now must be licensed under the GPL.

Also, unless I'm missing something, leehambley is also the author of sshkit, and came right out and said you specifically are fine to use it. So what are you concerned about? Him reneging and suing?

Will Bryant

unread,
Feb 7, 2014, 5:13:35 PM2/7/14
to wellr...@googlegroups.com
I totally agree that a lot of people would be fine with using a GPL deployment tool, but we need to be pretty careful about IP in our company, and it is not at all cool that the true license is not stated up front so people can make a decision about it.  

I do feel that since Jamis Buck and co did so much great work on an MIT project, it doesn't feel right to effectively GPL the new version of it, or at least a very major part of it, without public discussion.  GPL is really not very friendly to the Ruby community, which has been deliberately very liberal with its licenses so we don't have to deal with this crap.

With regards to the maintainers, I don't have any beef with leehambley who I'm sure has done a lot of good work there.  But it is his company lawyers who have imposed the license and I have zero trust in them, especially since a) they don't appear to understand the GPL as I read it and b) they have declared:

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

Our lawyers can't just ignore that.

In addition, I'll have to check with legal, but my understanding was that the GPL can be enforced by anyone - not just the copyright owners.  So to a certain extent it doesn't matter what leehambley's lawyers' interpretation is, it's what the world's is, and the rest of the world interprets GPL in the traditional way.

Rsync is a bit easier because it's a separate program and the interface between it and callers is very minimal, so basically not enough to create a combined work unless your whole product is somehow based around rsync and closely integrated with it.  Now in fact we've been advised that there is no clear rule as to what makes something a combined work, but using a library directly and basing your tools around it certainly does make it a combined work - that is indeed the point of the GPL (as opposed to the LGPL) for libraries.

Does that affect deployment if your deployment is integrated somehow with your application?  No probably not, but I'm not likely to be able to convince our general counsel that we should be the ones to find out :).


Will Bryant

unread,
Feb 7, 2014, 10:37:55 PM2/7/14
to wellr...@googlegroups.com
Cool, I like a lot of those recap ideas.  The releases/* directories do seem a bit redundant with git now.

Sampath Munasinghe

unread,
Feb 8, 2014, 12:56:52 AM2/8/14
to wellr...@googlegroups.com
I'm using Mina. its pretty cool. check that out for deployments. 

Tim Uckun

unread,
Feb 8, 2014, 4:48:27 AM2/8/14
to wellrailed
The GPL only applies when you do two things. 

1. Modify the source code
2. Distribute the source code.

Since you are not modifying capistrano and are not distributing the modified version of capistrano you should be OK.

It sounds like your lawyers are confused.  Maybe you can create a separate repository for your capistrano files. Better yet run your capistrano scripts from a pristine laptop bought just for that purpose and nothing else.  That way you can convince your lawyers you are save.

Will Bryant

unread,
Feb 8, 2014, 6:08:42 AM2/8/14
to wellr...@googlegroups.com
We are modifying it if & when we build tools on top of it, and we are distributing it if we sell our system to other companies.

Like I say, this may not concern everyone, since most people merely use it as you suggest, but it certainly concerns us.

One of the great things about Ruby is that almost everything written for it is MIT or similar.  Not having to worry about where the code goes is a privilege we don't want to lose :).  Especially not when the current version of a tool is MIT!

Will Bryant

unread,
Feb 8, 2014, 6:16:48 AM2/8/14
to wellr...@googlegroups.com
Thanks, I'll give it a try.  Any tricky areas I should watch out for?

Shane Mingins

unread,
Feb 18, 2014, 8:10:51 PM2/18/14
to WellRailed
I've just started looking at Ansible today https://github.com/ansible/ansible which one of our devs has been using and liking.  I'm more looking at it as a replacement for chef but you can also use it to deploy your application as well.  I did come across http://mxey.net/deploying-rails-with-ansible/, but have yet to read it as I am still going through the ansible basics.




On Fri, Feb 7, 2014 at 10:59 PM, Will Bryant <will....@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "WellRailed" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wellrailed+...@googlegroups.com.
To post to this group, send email to wellr...@googlegroups.com.
Visit this group at http://groups.google.com/group/wellrailed.
For more options, visit https://groups.google.com/groups/opt_out.



--
Shane Mingins

Tim Uckun

unread,
Feb 18, 2014, 10:52:37 PM2/18/14
to wellrailed
When you say you are modifying it do you mean you are modifying the capistrano code or just writing config files?

Once again there is no requirement for your deployment files to be mixed in with your application. They can be in completely different repositories.  


Will Bryant

unread,
Feb 18, 2014, 10:53:31 PM2/18/14
to wellr...@googlegroups.com
Extending the cap code.  I guess not something a lot of its users do.

Tim Uckun

unread,
Feb 18, 2014, 11:31:43 PM2/18/14
to wellrailed
No I don't think many people do that.

In that case it's probably best to separate out your deployment from your code.

Will Bryant

unread,
Feb 19, 2014, 9:04:37 PM2/19/14
to wellr...@googlegroups.com
On 19/02/2014, at 17:31 , Tim Uckun <timu...@gmail.com> wrote:
Yup, but v3 was rewritten around https://github.com/capistrano/sshkit, which is GPL.

Rafael Formiga Santos

unread,
Feb 20, 2014, 3:36:48 PM2/20/14
to wellr...@googlegroups.com
I seems the same question was asked multiple times in the same thread but I still couldn't find a clear answer.
I will ask in another way to make this clear for once and for all:


1 - Will your product use capistrano to be deployed?
or
2 - Your customer will operate indirectly the capistrano changed copy via a web site of yours or similar where your product is accessible?
or
3 - Your customer will operate directly a copy of your product with the changed copy of capistrano included?

and if your answer is the  #1, or #2, I believe you already have your question is already answered in the previous emails.

now, if your answer is #3, as mostly of lawyer predictions, is very unclear what will happens. Capistrano team thinks their Capistrano still MIT Licensed, but who knows what kind of extensions you have and who knows what will be the future issues to be brought to the judge. Maybe is just better migrate to anything. Capistrano basic functionality, at least, is not that hard to be rewritten. And with Capistrano v3, everything is just Rake.

Or maybe, just clone capistrano, that is MIT, rewrite the parts requiring sshkit, and you would have a capistrano with no sshkit dependencies.




Grant McLean

unread,
Feb 18, 2014, 8:30:46 PM2/18/14
to wellr...@googlegroups.com
On Wed, 2014-02-19 at 14:10 +1300, Shane Mingins wrote:
> I've just started looking at Ansible today
> https://github.com/ansible/ansible which one of our devs has been
> using and liking. I'm more looking at it as a replacement for chef
> but you can also use it to deploy your application as well. I did
> come across http://mxey.net/deploying-rails-with-ansible/, but have
> yet to read it as I am still going through the ansible basics.

It looks like Ansible is GPL too.

Although of course since Ansible does so little, any modifications you'd
need to make to use it for deployments would likely be to your own
scripts and not to Ansible itself.

Regards
Grant


Will Bryant

unread,
Feb 21, 2014, 4:48:28 PM2/21/14
to wellr...@googlegroups.com
We currently do 1 and arguably 2, and we will do 3 in the future.

So yeah, I agree, probably best to move on when cap v2 is not enough or stops working.

It would be nice to have it integrated into the server management stuff if one of them was a good fit for deployment - thanks for everyone's suggestions, currently looking at Ansible, Salt (via ssh), Chef-solo, Puppet, Fabric.

Will Bryant

unread,
Feb 21, 2014, 4:54:08 PM2/21/14
to wellr...@googlegroups.com

On 19/02/2014, at 14:30 , Grant McLean <gr...@mclean.net.nz> wrote:

> It looks like Ansible is GPL too.
>
> Although of course since Ansible does so little, any modifications you'd
> need to make to use it for deployments would likely be to your own
> scripts and not to Ansible itself.

True. However I probably confused the issue by talking just about cap modifications. We don't mind releasing our code that we add to the deployment tools - we release most of our tools as open source anyway.

But if we build a solution around a GPL product and then combine that with the core apps to sell to customers, there is no clear boundary in the GPL that ensures that the GPL only applies to the deployment stuff and not the whole solution ie. our core IP.

It's not necessarily going to be interpreted in that way, but there's no case law clearly limiting its scope and so we would be taking the risk of having to defend it in court. Wouldn't want to go there - we'd be nervous any time we moved a bit of code between the management stuff and the core apps.

Tim Uckun

unread,
Feb 23, 2014, 5:58:50 PM2/23/14
to wellrailed
Once again you can just create a new project for your deployment and GPL that.  This will contain your modified copy of capistrano and the deployment descriptor files. You code can be completely separate from your deployment.

This way you code can be under any license you want.


Reply all
Reply to author
Forward
0 new messages