solomono / kiama

Automatically exported from code.google.com/p/kiama
GNU Lesser General Public License v3.0
0 stars 0 forks source link

ASL 2.0 #69

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago

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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
What is the status of this. If this remains under LGPL the there is a lot of 
inertia to include it in commercial products. So it is best that this is 
licensed under ASL or Scala License. 

Original comment by sirinath...@gmail.com on 13 Apr 2015 at 4:56

GoogleCodeExporter commented 9 years ago
No firm progress as yet, sorry. Our attention is not on Kiama at them moment. I 
plan to get back to it in the next month and get the next release out.

On the license question, on the face of it the LGPL is what we want since we 
don't want people to take the library, extend it, use those enhancements in 
products and then keep those enhancements to themselves. Basically since we are 
an academic group that is largely publicly funded and we are making our work 
available for anyone to use, we would like others to contribute their changes 
to our library back for anyone to use. As far as I can tell the ASL doesn't 
allow us to do this.

I'm aware of the aversion to the LGPL in some parts, but our hope was that it 
would be ok for most people. I'm not sure precisely how the "fat jar" situation 
would work but I know that in other situations it's not necessary to include 
the whole source code in the download, but it's enough to include instructions 
that explain how to obtain that code. If you are basing your code on a released 
Kiama version then it should be sufficient to point to the Kiama repo. If you 
are using a modified version of Kiama then under the LGPL you would have to 
already have that code available somewhere.

Original comment by inkytonik on 20 Apr 2015 at 1:57