charm license requirements with multi-licensed payloads

Hi folks, Our big data charms (apache licensed) deploy Hadoop (apache licensed). Hadoop supports various compression codecs, with one of the more popular being lzo. lzo is GPLv2 licensed and therefore not distributed with Hadoop. As a charm author, what is my licensing obligation if I want my

Re: charm license requirements with multi-licensed payloads

Hey Kevin, When you write a charm and include a copyright file, what you are licensing are the lines of code that you write in the charm, not the software itself. You may choose any license you want. If you want to specify the license each piece of software uses, you can do so in the README

Re: charm license requirements with multi-licensed payloads

Thanks, José! I was curious about this too. A follow-up on this question: I have a Charm repo that includes Charms from different sources with patches. Some of these Charms are licensed differently, some require copyleft and some don't. Now, I do it

Re: charm license requirements with multi-licensed payloads

That is right. When you do a patch and include it inside a charm, what you are doing is a contribution to the pre-existing code, hence inheriting the license from another charm. If it doesn't have a license and it's been released, I would assume a public domain license until a license is

Re: requirements for

I, too, am looking for an example command line to put both juju and landscape on the MAAS server, in containers would be nice, but not necessary. On Tue, 2015-03-31 at 19:19 -0500, Ali wrote: On Fri, 2015-03-27 at 08:22 -0400, Rafael Gonzalez wrote: Hi Stephen, MAAS would be your first

Re: requirements for

On Fri, 2015-03-27 at 08:22 -0400, Rafael Gonzalez wrote: Hi Stephen, MAAS would be your first node, if configured robustly enough, it can also run Ubuntu Infrastructure services such as Juju and LandScape. The MAAS server should be on bare metal and separate from any of your OpenStack

Re: requirements for

, Rafael O. Gonzalez Canonical, Solutions Architect rgo...@canonical.com On Thu, Mar 26, 2015 at 10:08 PM, Stephen step...@artifex360.com wrote: Hi, What is the hardware requirements for the maas-region-controller? If OpenStack

Re: requirements for

Architect rgo...@canonical.com On Thu, Mar 26, 2015 at 10:08 PM, Stephen step...@artifex360.com wrote: Hi, What is the hardware requirements for the maas-region-controller? If OpenStack is installed, which machine should it be? block, object, controller, etc? Sometimes I cannot explain my

Re: requirements for

...@artifex360.com wrote: Hi, What is the hardware requirements for the maas-region-controller? If OpenStack is installed, which machine should it be? block, object, controller, etc? Sometimes I cannot explain my problems well. Cheers, Stephen -- Juju mailing list Juju@lists.ubuntu.com

Re: requirements for

On 03/27/2015 10:08 AM, Matt Rae wrote: Also noting that running MAAS in a vm has worked fine in my experience. Are there any pitfalls with using a vm? Nope - that should work just fine as long as you're using a bridged interface for the network you want to manage. I typically run MAAS in an

requirements for

Hi, What is the hardware requirements for the maas-region-controller? If OpenStack is installed, which machine should it be? block, object, controller, etc? Sometimes I cannot explain my problems well. Cheers, Stephen -- Juju mailing list Juju@lists.ubuntu.com Modify settings

Re: Juju Docs - SSH key requirements

On Fri, Jan 31, 2014 at 1:03 PM, Nate Finch nate.fi...@canonical.com wrote: +1000 on version-specific doc pages. Most other similar projects do this already. Given that our stable releases are getting spaced out somewhat more than they had been, it doesn't seem too burdensome. On Fri, Jan

Re: Juju Docs - SSH key requirements

Back to the original discussion. We should document some new information/requirements around SSH keys, particularly when it comes to bootstrapping. Bootstrap now requires you to be able to ssh to the bootstrapped machine. The machine's ~/.ssh/authorized_keys file is initialised depending on how

Re: Juju Docs - SSH key requirements

I absolutely agree that we should drop steps that are not necessary from the documentation (so long as we *do* still describe authorized-keys-[path] for those with more sophisticated requirements). But we can't do this while 1.16 is the latest stable version, lest we confuse all those users

Re: Juju Docs - SSH key requirements

On Fri, Jan 31, 2014 at 5:34 PM, William Reade william.re...@canonical.comwrote: I absolutely agree that we should drop steps that are not necessary from the documentation (so long as we *do* still describe authorized-keys-[path] for those with more sophisticated requirements). But we can't do