Use of Jujucharms to launch non-opensource code
Mark Shuttleworth
mark at ubuntu.com
Tue Feb 9 11:35:13 UTC 2016
On 08/02/16 04:01, Ramesh Nethi wrote:
> If one use Jujucharms in commercial projects where non-open source code is
> deployed using jujucharms, is this bound by AGPL ? I understand that
> modifying jujucharms code itself would call for open sourcing it.
>
> Are there any known commercial uses of jujucjarms ?
TL;DR - Please share any changes to juju-core (client, controller,
agent) and existing charm layers, the rest you can keep as proprietary
as you like.
Our general posture would be:
* it should be easy and non-controversial to charm proprietary software
- we will add capabilities in Juju to support things like EULA's
- the license of Juju and the license of the charm are independent of
the license of the software installed and operated by the charm
* changes to Juju core itself should be contributed to Juju
- and if you are running a modified Juju server you should publish
the modification source
- but it's fine to create your own proprietary management system that
wraps or drives Juju
* changes to shared charm layers should be contributed back to the layer
The general approach should probably be to have an open source charm for
your proprietary software, and to add features that you need in Juju
core to the public version of Juju core. But there's nothing to stop
those charms from driving proprietary applications, and we'll make it
easy to manage the associated issues like EULAs and distribution of
those bits. If you want to have a proprietary charm that's probably OK
too, but you'd miss out on a lot of the cool shared layer stuff.
If there is a lot of interest in using a permissive license like BSD or
Apache for charm layers, then I'm open to discussing that. This would
allow for purely proprietary charms too, that still benefit from layers,
but it might remove some of the motivation for people contributing to
the layers.
Mark
More information about the Juju
mailing list