dual-licence question

[jeff-h]

Would you consider releasing LESS under GPL v2 (or something compatible with it, such as MIT), as well as the existing Apache 2?

The three big open source CMS's — WordPress, Joomla and Drupal — are all GPL2 only and thus can't incorporate this library easily, instead requiring users to manually come to github or http://lesscss.org and download it, and install it separately, which ultimately reduces adoption.

[lukeapage]

ideally we would recommend people use less.js serverside, not browserside... and this suggestion is to enable more people to use it browser side?

[Soviut]

True, if all you're using is the result of LESS, then license be damned. There are some advantages to using LESS in the browser when it comes to hosted environments, especially the ones that basically force you to edit your CSS directly online via an editor panel.

The GPL really does make things difficult for everyone, doesn't it?

[lukeapage]

I think @cloudhead would have to comment on this...

[jeff-h]

To clarify, no, this request is actually not talking about using it client side in the usual fashion. Sorry for the ambiguity.

In my particular case, I'm writing a Drupal module which needs to create & compile LESS into CSS client-side, after first page load, to power a browser-based theming tool (see http://drupal.org/project/livethemer). After the design is completed client-side, it'll be sent back to the server and compiled once using Leafo's lessphp server-side, and cached on the server from that point on.

I guess another use-case for a GPL2-friendlier license would be packaging a bunch of code together which runs less.js on node.js (all on the server) to help power one of the CMS's I mentioned, but I admit that's probably a less common scenario.

It's true I could have the Drupal module include less.js from a centrally-hosted copy (on my own server) but it would be much nicer to be able to include it in the Drupal module package so everyone has their own copy locally.

[Rarst]

The three big open source CMS's — WordPress, Joomla and Drupal — are all GPL2 only

For the record WordPress is GPLv2 or later, you can do compatible extensions for it under GPLv3 that can include Apache License 2.0.

But I concur that MIT goes much easier with GPL stuff.

[hswong3i]

I am also coming from Drupal and would like to suggest dual license with MIT, or even re-license into MIT as like as that of bootstrap (twbs/bootstrap@cb40a2e).

I would like to reference the complete discussion of bootstrap in here (twbs/bootstrap#2054) as your reference.

[cloudhead]

If this is still a major issue, dual-licensing with MIT is ok with me.

[hswong3i]

At least from a Drupal contributor point of view, Apache license must be a issue when we hope to contribute code to drupal.org GPL-only GIT repository (which we had already try to encourage ppl switch to GPLv3 for more than 2 years but not success).

In case we can dual-licensing with Apache + MIT, the problem will be solved automatically.

P.S. as your reference that the corresponding Drupal module for integrating less.js already completed (https://drupal.org/project/twbs_less); BTW, I can't submit less.js URL to drupal.org packaging whitelist (https://drupal.org/packaging-whitelist?title=less) since it is now under Apache license ;-(

P.P.S. Drupal.org Library Packaging Whitelist request for including less.js is now submitted, too.

[lukeapage]

Would we need to get a CLA signed by all contributors? or is it something we can just declare?

[Rarst]

Without prior agreement every contributor needs to agree to license change or their contributions need to be reverted and re-done. That's what took Bootstrap so long to deal with.

[jonschlinkert]

every contributor needs to agree

All that is required is a simple "yes". So you have mine at least, yes.

[hswong3i]

From twbs/bootstrap#2054 (comment)

FYI .. the doctrine project used this tool here to handle the migration from LGPL to MIT:
https://github.com/beberlei/license-manager

[hswong3i]

I give some try to installation https://github.com/beberlei/license-manager on my local testbed and able to create a license switch project for less.js as below screenshot.

If this tool looks good enough I will able to give a hand for install it under a public accessible domain name.

Any idea?

[lukeapage]

well we don't want to move to MIT, we want to dual-license right?
What back-end does this tool go against? whats the easiest option - is it possible to get it running using gh pages only and presumably some free online database?

[cvrebert]

Sass is MIT-licensed, so that's always an option for the CMSes. Although honestly, they're being way too paranoid+draconian.

[ghost]

Is there any progress ? It would be a pity if lessjs would loose the "race" against sass only because of licence restrictions.

[ghost]

It would be nice to get even a single line of feedback. Are there any thoughts about changing the licence ?

[seven-phases-max]

@Nueckman

It's all above I guess. As I see it, this is not going to happen until someone to sit and manage all those things required to get the change permission from every less.js codebase contributor. I assume none of the (very small) Less team does actually find this pretty much abstract "race condition" thing (5 posts for 2.5 years?) to be important enough to take this quite tedious task. But obviously if anyone else finds this to be important enough to put his time for, he's welcome and helped.

[SomMeri]

@Nueckman I do not mind adding another open source license to less or changing it to another standard open source one.

@seven-phases-max Is it really necessary to hunt down every single small commit author for license addition?

[seven-phases-max]

@SomMeri I'm not an expert at all, but according to above comments, twbs/bootstrap#2054 and similar issues found elsewhere - yes, it looks like so.
(This is weird of course, counting that the codebase was reworked and reorganized sort of several times by now... so that, I believe, roughly speaking, 99% of the current code is actually written solely by @lukeapage from scratch :), but such estimations are not what these kind of things can be based upon :(

P.S. Obviously you don't need to if you can manually go through each contribution and decide (after all a commit might even only remove some code :), but that looks to go even more tedious than simply contacting all of them ((semi?)-automatically).

[ionas]

LGPL 2 / LGPL3 would be good. IMHO it is an excellent choice for community driven libraries.

I do understand Stallman that he prefers the non L GPLs (see http://www.gnu.org/philosophy/why-not-lgpl.html ) but then you can't easily open source most commercial projects.

On the other hand, LGPL as the ONLY license would oblige to give back on the LESS project itself. Perfect choice between how things should be (GPL) and how real world scenarios demands are (don't share, aka MIT).

Thus instead of MIT/Apache2 AND GPL it would be much easier to just go with LGPL2 or LGPL3.

[ionas]

@lukeapage Well as the main project's drivers/contributer(s) it is up to you to decide what should happen. I can't see why one would not want LGPL instead of MIT for LESS because there is little to gain if you keep your own LESS hacks secret from the main LESS project (is there?). So IMHO that would have been the best choice from the start.

That being said, I have no idea how the legal implications for a CHANGE would be. My guess is: keep the old versions on MIT and only change the license on new versions.

The only thing though is the possibility of a legal impact. But I can't see any impact (though I am not a lawyer): You can easily use LGPL in MIT based closed source commercial projects. The only audience that will have an impact when switching to LGPL would be a tiny one that:

1. Used LESS in the past
2. Hacked that LESS usage to their needs by modifying less compilers/pre-processors
3. Wants to update LESS to a newer version that has LGPL WITHOUT dropping their hacks
   Then AND ONLY then they would legally need to share that code (but honestly no one would do anything if they didn't cause most likely no one is interested and their LESS hackery isn't a secret business key stone anyway).

Edit: And no, it is not about the compiled results. I am not sure if in legal terms but you are probably choosing a license for those code-generation results yourself. LESS.js is another thing but it is mostly a development tool right now. I have to say so that I could imagine shipping LESS.js along GPLed CMS/CRM/ERP whenever you have to do good content management and want a live preview of styled content. LESS.js could be utilized to do this live thing "live" and once the user saves the LESS css-preprocessor is run to generate the css. In this special case I can see license issues too.

So the work that @hswong3i has done is probably required in any case. Either to do the switch OR to allow for a 2nd license.

[matthew-dean]

I would suspect that we only need to contact contributors if we're still using that code. Once Luke rewrote things for plugins, probably a lot, if not most, if not all, of those pieces were replaced.

This is an open source project with no corporate interests. Is there a real concern by changing the license? If so, you could just run a "blame" on the whole project, could you not? And see if any line from a contributor other than Luke?

[matthew-dean]

My guess is: keep the old versions on MIT and only change the license on new versions.

Or that. Less 1.x could have had one license, and 2.x can have a different license. They're re-architected enough that they're unique projects.

[ionas]

Version numbers are cheap. Switching licenses is a good enough reason to go with SemVer major +1 version I think. So Less 3.0 could utilize LGPL2/3 (or BSD/MIT) only.

[lukeapage]

I can have a go at setting up https://github.com/beberlei/license-manager
but first I'd like the core team to decide what we want. I need to read up on the license types.

[jonschlinkert]

edited: I read this from my cell initially. I agree with virtually everything @ionas points about LGPL. I'm good with whatever the consensus is

[ionas]

@jonschlinkert What has twitter to do with LESS in terms of an argument? Why is MIT superior to LGPL for a library/language/compiler like LESS?

What do you gain by dual licensing instead of sticking just with LGPL (or MIT)? More hassle?

[jonschlinkert]

What has twitter to do with LESS in terms of an argument?

What do commercial projects have to do with LESS?

You can easily use LGPL in MIT based closed source commercial projects.

[ionas]

@jonschlinkert Nevermind, I don't think we have an argument anyway. Sorry and NVM.

Just imagine a company creating some pre-processor application and extending modifying LESS for that purpose and not giving back the changes to LESS compilers. That's sad and LGPL stops that, MIT does not. It is fine if people create proprietary management tools for LESS but the LESS compiler itself should not suffer from "free but worse VS proprietary and better" because of free-as-bike-riding-beer-drinking MIT issues.

For me it is: LGPL3/LGPL2 > MIT > MIT + LGPL2/3 > MIT + Apache

[seven-phases-max]

Just imagine a company creating some pre-processor application and extending modifying LESS for that purpose and not giving back the changes to LESS compilers.

Too imaginary and too hypothetical bonus against real corks (while for sure LGPL is perfectly fine for JavaScript libraries, it's also extremely confusing for an average "scripting people" because of its quite-c/cpp-coupled terms and concepts: "linking", "header files", "object code" etc. For example, how many hours one will need to put into findings/research to make sure that by including less.js into his own minified/uglyfied/concatenated page scripts he does not actually violate anything?).

[dantman]

Why are we diving off on this tangent (talking about the merits of LGPL)?

Debating copyleft vs. permissive now is pointless. Less.js is Apache licensed and every release up to this point will remain available under an Apache no matter what new license is picked. Apache is a permisive license. And Less.js (along with the rest of the Node.js community, which I've noticed is primarily permissively licensed) has been doing quite fine so far with the permissive license.

The only reason this bug was opened at all. Was because the Apache license gives some trouble to the GPLv2(+) based projects. Not because there was an overwhelming sentiment that Less.js should switch to a copyleft license.

The only thing worth deciding, besides how to make the switch, is whether we Apache/LGPL2+ dual-license to fix the issue or drop down to MIT to fix it.

Note that the Apache license includes patent protection which MIT doesn't. It's not exact, but you can consider Apache 2.0 to roughly equal MIT + Patent protection. So the question is basically do we ditch the patent protection (switch to MIT). Or try to keep it (dual-license with LGPL2+ to add GPL compatibility).

[seven-phases-max]

@dantman

Indeed.

[ionas]

Why?

1. Because single licensing is easier than dual licensing maybe? (is it not?)
2. Because when choosing a single license MIT and LGPL are both good candidates? (are they not?)
3. Because not being compatible with GPL2 would have not been an issue if LGPL2/LGPL3 (or MIT) had been chosen up front?

So I wonder why you want to stop the discussion @dantman as it is imho related and relevant.

Side note 1: http://en.swpat.org/wiki/Patent_clauses_in_software_licences#LGPL_2.1 - I did not dig into LGPL3 but GPL3 did copy Apache 2's patent clauses it seems.
Side note 2: it is not about the current source code and its license but future versions.

[matthew-dean]

Just imagine a company creating some pre-processor application and extending modifying LESS for that purpose and not giving back the changes to LESS compilers.

Errr I've done that. The changes I made were not applicable to Less core. We want to adapt a license to prevent that? Why? What's the benefit to Less in being restrictive about its use?

[ionas]

@matthew-dean well and the spirit of (L)GPL is to let the community of developers that created the foundation you used to work upon decide if those changes you did, are relevant to them, too. They worked for you, you are working for them. They can then learn and re-use. Improve and innovate, as you did. The MIT model clearly failed as you can see with Apple's Darwin.

The benefit is very clear: If you are utilizing a (L)GPL'ed community effort you are obliged to share/give back. (L)GPL is basically a free-rider stop in the FOSS world.

Well, its not up to me anyway, I'd still rather prefer one MIT license over a dual licensing model, it is just that I don't see why it should not be LGPL and the reason you stated above is actually a pro LGPL argument.

[matthew-dean]

Well as both a community manager and a user of Less, I'd prefer if people didn't submit changes that they knew to be irrelevant and ask me to decide about it, because that's more work for me. Sure, I'd love if people submit pull requests for things they feel are of a benefit, but I don't want to be one of the people that has to decide which it is, each and every time, for every change. I don't know much about licensing, but if that's what LGPL means, great then, consider me anti-LGPL. People are volunteering their time here. Adopting a license which necessitates using more of their time is not a fair exchange. I'm happy to contribute and help maintain Less because it's been tremendously useful to a lot of people. I don't really care if people use it to build a doomsday machine.

As @seven-phases-max, all of these scenarios are hypothetical. As far as we know, no one yet has built a doomsday machine. So, rather than try to make something restrictive and have people ask permission for everything, it seems more of a community benefit to license as permissively as possible, without allowing someone else to release to the public something else called "Less.js" that uses our logo and assets and does the same thing.

[htstudios]

The whole sharing 'pollution' argument is void. Your changes just have to be LGPLed FOSS and distributed somehow.

[htstudios]

And if you want to protect a brand that has imho little to do with the compiler's source license. See how diffivult that is to pull of @ Firefox/Debian.

[matthew-dean]

The whole sharing 'pollution' argument is void. Your changes just have to be LGPLed FOSS and distributed somehow.

Ok, I'm still against that.

[matthew-dean]

@lukeapage @jonschlinkert @seven-phases-max You're all for dual-licensing with MIT?

[htstudios]

Yes, cause you profit from free riding which LESS is probably creating a lot (for me too by just utilizing it).

MIT vs GPL is always a matter of economical interests. Tjose doing the heavy lifting in recent LESS versions should decide if they rather have obligation to share of invisible free riders.

I am done. I do really hope it gets to be One license only (MIT or LGPL).

[matthew-dean]

Yes, cause you profit from free riding which LESS is probably creating a lot (for me too by just utilizing it).

lol. I have? I should check my bank accounts.

To be clear, this was more of an issue in Less 1.x, where there was no API to speak of, and many of Less's core functions were not exposed in the library. My change was to modify the browser version for an Adobe AIR environment, which had direct file access instead of HTTP requests. Yes, that code is available in a (free) open source project on Github, but I've no idea what license it would conform to as to how consumable it is.

What I found more a benefit was to give input on design of an API with the ability to create file managers separate than just "Node" and "browser" JS environments, which isn't really "licensable". But that to me was the item of greater value - contributing in a design discussion for something that would benefit a greater number of people, rather than just slap code that only served my needs somewhere. So, I'm not sure how different licensing would have made any difference in that scenario, except a more restrictive licensing raising more questions as to the requirements & obligations of software authors.

I think the more relevant point is in other projects (such as the top of the issue) where there is a direct conflict between licensing they've chosen and the Less license that prevents inclusion into other projects. So right now the problem reads as already one of too much obligation. Therefore, more obligation doesn't logically follow as the answer.

[ionas]

As for the first point. GPL doesn't mean you have to prepare things on a dish. Nor does it mean you have to open up PRs. It just means that you are legally bound to share. If someone takes away LESS and builds a commercial compiled obstructated closed source app, adds some killer features and it becomes a new great pre-processor everyone has to pay for, then that's a real free rider issue. If someone simply hacks the compiler to do some other things, no one will complain "even if you don't share back". If you want to, you will have to distribute sources or links to those sources. You don't have to advertise or distribute nice sources, just sources.

Issues arise when you are obliged to share sources and how to share them actually. But I'd rather have those small issues than free rider over-takings (think again OS X).

As for your 2nd point: I do agree.
It is not crystal clear even though I'd love LGPL over MIT if one or the other is a better choice. If LGPL creates practical issues that go beyond free-riders not wanting to share back (after all, that is the key difference between free as in freedom and free as in beer), then its an issue and MIT is probably the better option.

[matthew-dean]

@ionas Okay, that makes more sense. If I understand you correctly, someone would not have to open source their whole app, they would just need to re-share modifications to Less in some non-specific form? That seems fair. I'm just hoping we wouldn't get into a situation where it also means some other restriction we haven't thought of because we're not lawyers, and then we have to spend time discussing new licensing / getting permission again.

So yes, I obviously agree someone shouldn't screw over the Less community, and I want us to be pragmatic about letting people do what they want outside of that, so that they're not afraid to use Less over other solutions. I think striking that balance is important.

[Synchro]

@matthew-dean

If I understand you correctly, someone would not have to open source their whole app, they would just need to re-share modifications to Less

That is essentially the difference between GPL and LGPL.

[matthew-dean]

That is essentially the difference between GPL and LGPL.

Got it. :-)

[splitbrain]

Any progress being made here? Any way the community could help?

[matthew-dean]

@splitbrain Is there anything that needs to happen?

[splitbrain]

@matthew-dean well... this ticket is still open. I think others here (and in linked tickets) have made clear that the Apache License is problematic when working with other Open Source licenses.

What needs to happen are the following things I believe:

• decide if you want to do a license change
• if yes, decide on a license (LGPL or BSD/MIT)
• once done create a way to ask contributors to agree (eg. using the mentioned license manager tool)
• contact contributors and ask them to agree (explaining the reasons)
• once enough contributors agreed, change the license

[ghost]

I support the LGPL.

[kryptine]

Some thoughts:

1. Firstly, the primary reason for license change is that Apache License 2.0 is not compatible with GPLv2. Therefore any other license not compatible with GPLv2 must not be used unless accompanied by another, GPLv2-compatible, license:

   1. GNU Lesser General Public License version 3 or later
   2. Eclipse Public License version 1.0

   For a detailed list, see https://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses

2. One of the commentator, @ionas, suggested using the LGPL (version 2 only or version 2 and later, not version 3 or later or version 3 only) instead of the MIT license. His/her arguments certainly have merits: He/she wants people modifying the LESS software to also share and license their modifications as free software. However, I would like to present my case for MIT:

   1. The LGPL requires supplying a copy of the license with every copy of the software program (really, see https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#WhyMustIInclude and this applies to the LGPL as well). On this issue, a commentator mentioned a use case in which the LESS scripts are sent to the client's browser for local rendering. Since the LGPL is significantly larger than the MIT license (26 kB instead of 1 kB), distributing the license along with the script is a huge waste of bandwidth. For larger, infrequently downloaded software packages this is not an important problem, but for web pages (where minifiers are often used) the problem is much more significant. (Also, the LGPL counts minified JS as binary.) The original copyright holder can just add a "This program is free software..." notice, but subsequent redistributors must include the full license.
   2. I don't think that the LGPL (or other weak-copyleft licenses, such as the Mozilla Public License) will give "the free/open-source software community" much benefit in this case. With the LGPL, if proprietary developers decide to modify LESS and distribute it they will have to license their changes as LGPL too, yes. But they don't have to use LESS. They have alternatives. For example Sass is licensed under MIT and is also a CSS preprocessor, they can use that. You will have to convince them to switch to LGPL. And everyone else who distributes permissively-licensed software too. The history of copyleft vs. permissive is long; there have been many debates about "which license is better?" But I am going to give my opinion here: Free-riders aren't necessary a problem — if they choose to do things by themselves (write their own code from scratch or choose an alternative) we are not going to gain anything either. We don't expect hurricane victims to "recompensate" us for the donations we gave them. LESS is not a free software project created to promote free software, it is an open source project created to scratch itches. I would like to see the greatest freedom granted to the greatest number of people possible (a derivative fork does not reduce your freedom pertaining to the original software)
   3. If you go for LGPL now and later want to switch to MIT, you will have to find and ask the contributors two times: first for LGPL, second for MIT. However, if you go for MIT now and later want to switch to LGPL, you only need to ask for permissions once. The reasons are obvious: MIT being much more permissive than LGPL, switching from MIT to LGPL is to reduce the existing rights. Switching in the opposite direction is adding more rights, and therefore will require asking for permissions again. Since license compatibility is the principal reason for this, it is much more important than the perennial debate about the merits and shortcomings of copyleft vs. permissive, and we want to get this done first. We can always change our mind if we go for MIT now. (Instead of LGPL and MIT, the same applies to more permissive and less permissive licenses)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.