ASL 2.0

[GoogleCodeExporter]

Is it possible to more to ASL 2.0 with a view to bee more commercial friendly?

Original issue reported on code.google.com by sirinath...@gmail.com on 27 Jan 2015 at 12:49

[GoogleCodeExporter]

You can borrow parts of he project which can be customised to other projects 
which have other licenses. E.g. You can use some parts from Kiama in Scala.Meta 
(I am not part of the team.) or projects which use Scala.Meta.

When you customise you have to license the whole work under LGPL. So it is best 
to have ASL 2.0 or perhaps Scala License so this can be reused for a wider 
purpose. Also mix with into projects which are not LGPL.

Original comment by sirinath...@gmail.com on 28 Jan 2015 at 2:16

[GoogleCodeExporter]

I'm not sure we want to encourage "parts from Kiama" to be incorporated into 
other projects or "mixing" of bits of Kiama into non-LGPL projects. Of course, 
we aim to encourage use of Kiama from other projects, but that should be doable 
with LGPL since Kiama is just a library.

Original comment by inkytonik on 28 Jan 2015 at 2:48

[GoogleCodeExporter]

LGPL does not allow for customisation and use unless the whole work is under 
LGPL.

Original comment by sirinath...@gmail.com on 28 Jan 2015 at 2:51

[GoogleCodeExporter]

If you customise and modify Kiama then those modifications come under the LGPL. 
This is intended since we want work derived from Kiama's code to continue to be 
open in the same way.

Use of an LGPL library does not require the other code in the application  to 
also be under the LGPL. For example, see 
https://www.gnu.org/licenses/lgpl-java.html.

Original comment by inkytonik on 28 Jan 2015 at 8:46

[GoogleCodeExporter]

I would like to use Kiama's rewriting to add simple CAS capabilities to Breeze.
Breeze is used in Spark which is Apache 2 licensed and Apache doesn't get along 
well with any GPL: http://www.apache.org/legal/resolved.html
Maybe the Mozilla Public License (which is Apache compatible) might be an 
option?
http://programmers.stackexchange.com/questions/221365/mozilla-public-license-mpl
-2-0-vs-lesser-gnu-general-public-license-lgpl-3-0

Original comment by Martin.Mauch@gmail.com on 29 Jan 2015 at 5:22

[GoogleCodeExporter]

My only comment here is that LGPL is very often worrying for commercial 
companies, because, under LGPL, it may be argued that all the code that uses a 
library is now "tainted" and must itself be released under LGPL. I'm no expert 
in the matter, but have had lawyers & experts encouraging me - multiple times - 
to move away from any LGPL libraries, as a way to prevent/remove this concern. 
The definition of library is vague, and that is a problem. Kiama is "just a 
library", but the same reasoning applies: it may be argued that it is core to 
the code and therefore the whole "client" must itself be LGPL; the company may 
even be willing to do that, but the whole thing cascades quickly to other 
libraries that get tainted, and it all becomes, well, a legal mess.
So, yes, a more commercial-friendly API would help spread the use of Kiama.

Original comment by msbra...@gmail.com on 30 Jan 2015 at 12:41

[GoogleCodeExporter]

To add to my prev comment: yes, LGPL advocates argue that 'tainting' is not an 
issue, but other experts argue otherwise. Therefore, some companies play it 
safe by skipping LGPL.

Original comment by msbra...@gmail.com on 30 Jan 2015 at 12:44

[GoogleCodeExporter]

Original comment by inkytonik on 17 Feb 2015 at 10:40

• Added labels: Component-General

[GoogleCodeExporter]

Even if Kiama is "just" a library, and although the LGPL is more user-friendly 
than the GPL, it still has significant implications on the application using 
Kiama.

After reading the licenses and getting help from the FSF's license help desk, I 
am (more or less) sure that developers who want to offer a fat jar binary of 
their application - say ORS - which uses (but doesn't modify) Kiama have to
  1. include a copy of the LGPL in the download --- Fair enough
  2. include Kiama (and that is it covered by the LGPL) in any kind of copyright message that the application might show at any point of its execution --- Fair enough
  3. include the sources for Kiama in the download --- Not that great, but if need be

However, the situation becomes less appealing if a third party wants to release 
a fat jar binary of an application - say THRS - that uses ORS as a library. 
Even if ORS is covered under some permissive BSD-style license, they still need 
to be aware that ORS uses Kiama, and then they have to comply with the 
requirements of the LGPL as well, e.g. they need to modify their copyright 
message as well.

It is the transitive implications of the LGPL that I don't find appealing, and 
which is why I would also prefer it if Kiama wasn't released under LGPL.

In any case, thanks for the great work!

Original comment by mun12345...@googlemail.com on 13 Mar 2015 at 2:24