Layer licensing and charm licensing

[Tom Barber]

Licensing is always an interesting question.

For example, when we started writing Saiku it was GPL, after some pressure
from other people who said "think of the adoption" we switched from GPL to
ASL2.0, then we decided to try and monetise it, which, now because it was
ASL based transpires to be a right PITA because people are like "well its
permissively licensed, why would I bother?".

>From a personal perspective if I were starting an open source project from
scratch, with a thought of possibly trying to get help from companies who
use it in terms of monetisation, I would probably not use the ASL license
for GUI based stuff, because that is the layer everyone sees and then you
find you app embedded all over the place with just the logo changed and
you're like "urm right, so you charge a premium for that?", but if I were
starting a library or backend block of helper code for something, I'd
absolutely still use the ASL license, because its easy and allows people to
pick up your code without worrying. So if you're talking about layers and
interfaces, and all my home made charms, they will be ASL licensed, they
don't benefit me from being anything else, and as a small company getting
people to adhere to GPL based license restrictions without just dumping
money on a laywer is a waste of time anyway(clearly Canonical don't suffer
from that affliction).

In a perfect world, companies who use open source projects would help the
communities who write that software either in terms of man power,
sponsorship or something else, but this world is far from perfect and the
big corps are worse than most at participating in the open source ethos,
which is a shame because personally I'd like to see everything ASL or LGPL
and that be the end of it!

--------------

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart
<http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
goal, but you can always help by sponsoring the project
<http://www.meteorite.bi/products/saiku/sponsorship>)

On 5 May 2016 at 16:38, Merlijn Sebrechts <merlijn.sebrechts at gmail.com>
wrote:

> 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
>>
>>
>
> --
> 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/bffcbc96/attachment.html>