Open GoogleCodeExporter opened 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
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
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
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
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
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
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
Original comment by inkytonik
on 17 Feb 2015 at 10:40
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
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
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
Original issue reported on code.google.com by
sirinath...@gmail.com
on 27 Jan 2015 at 12:49