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 <[email protected]> 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 <[email protected]>: > >> 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
