Layer licensing and charm licensing

Merlijn Sebrechts merlijn.sebrechts at gmail.com
Thu May 5 15:38:32 UTC 2016


Hi All


Interesting discussion. We've also been discussing this internally.

LGPL would be fine for our use-case. LGPL has the added benefit that the
weak copyleft 'forces' us to open-source patches. Having a choice means
having to go through a painstakingly slow process to internally approve the
open-sourcing of code. This can be a big hamper to efficient
collaboration...

For the moment, we don't reject projects because they have some form of
copyleft. I doubt this will become a problem in the future.



PS: Regardless of the decision, I think it would be best if there was an
official Canonical statement about this licensing business. I haven't found
a great source explaining the details of copyleft myself. What exactly a
combined work is doesn't seem to be very clear. I get a lot of questions
about this, such as "can a GPL'd charm install proprietary software". It
would be great to have a [c\C]anonical source to point them to..

2016-05-05 16:47 GMT+02:00 Mark Shuttleworth <mark at ubuntu.com>:

> Hi folks
>
> The move to layers, which is fantastic from a charming productivity point
> of view, will also raise the question of licensing in a cross-charm way.
> Originally, we envisaged each charm being licensed by the charmer
> independently, but layers introduce cross-cutting licensing questions, and
> in particular, questions about copyleft.
>
> It certainly is not our intent that contributions from Canonical (which we
> generally prefer to make under copyleft licenses) should force a charm
> author to pick a copyleft license for their own contributions to their own
> charm.
>
> There are two options for common code that would be obvious solutions - a
> limited copyleft (LGPL) and a permissive (Apache2 or BSD). Both options
> enable people to bring shared public layers into their charms but still
> pick their own licenses for their own layers and additional bits. The LGPL
> option would require people modifying shared layers to allow others to use
> their modifications ("if you edit this file, we can merge your edits") but
> any new pieces created by them (typically specific to their charms) could
> be restricted for their own use.
>
> The OSM project, which is using charms for telco application modelling,
> has a preference for Apache2, which is arguably also a preference for many
> other industrial-scale initiatives.
>
> We could also dual-license these components (Apache2 + LGPL, or even
> Apache2 + GPL).
>
> Am writing to gather feedback from the charmer community as to your
> preferences in this regard.
>
> Mark
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160505/0172c776/attachment.html>


More information about the Juju mailing list