Licensing question: Using Kiama as a benchmark

[Andreas Sewe]

Hi all,

I am PhD student at Technische Universit�t Darmstadt and working on JVM
performance characterization. My current research question is this:
Scala == JVM (mod JVM)? In other words, do Scala programs behave
similarly to Java programs from the JVM's (low-level) viewpoint. (This
work in progress has been presented at PPPJ 2010's poster session:
<http://www.stg.tu-darmstadt.de/media/st/publications/scala_java_mod_jvm.pdf>
and <http://ceur-ws.org/Vol-692/paper7.pdf>)

Now Kiama (or rather some of the examples Kiama ships with) make for
very interesting benchmarks. But bundling them together with a (very
thin) benchmark harness I wrote and the Apache License'ed DaCapo
benchmark suite <http://www.dacapobench.org/> popular among JVM
researchers raises some interesting licensing questions. Unfortunately,
the LGPL is not what you would call an easy read. :-(

So I have to turn to this mailing list: Is it OK to reflectively call,
from within Apache License'ed code, the main method of, say,
org.kiama.example.obr.Main? This is really little more than an "exec",
albeit in the same JVM instance; the situation is quite close to the one
described in the following statement from the GPL FAQ: "If the program
dynamically links plug-ins, but the communication between them is
limited to invoking the �main� function of the plug-in with some options
and waiting for it to return, that is a borderline case."

Also, is it OK to bundle the Kiama JAR with my benchmark harness, be it
with or without the entire DaCapo benchmark suite. (Either way would
work for me.)

Best wishes,

Andreas

[Eelco Visser]

I would think that you can call an LGPL library or program from a
program with any license.

-- Eelco

On Mon, Jan 17, 2011 at 6:10 PM, Andreas Sewe
<se...@st.informatik.tu-darmstadt.de> wrote:
> Hi all,
>

> I am PhD student at Technische Universität Darmstadt and working on JVM

> performance characterization. My current research question is this: Scala ==
> JVM (mod JVM)? In other words, do Scala programs behave similarly to Java
> programs from the JVM's (low-level) viewpoint. (This work in progress has
> been presented at PPPJ 2010's poster session:
> <http://www.stg.tu-darmstadt.de/media/st/publications/scala_java_mod_jvm.pdf>
> and <http://ceur-ws.org/Vol-692/paper7.pdf>)
>
> Now Kiama (or rather some of the examples Kiama ships with) make for very
> interesting benchmarks. But bundling them together with a (very thin)
> benchmark harness I wrote and the Apache License'ed DaCapo benchmark suite
> <http://www.dacapobench.org/> popular among JVM researchers raises some
> interesting licensing questions. Unfortunately, the LGPL is not what you
> would call an easy read. :-(
>
> So I have to turn to this mailing list: Is it OK to reflectively call, from
> within Apache License'ed code, the main method of, say,
> org.kiama.example.obr.Main? This is really little more than an "exec",
> albeit in the same JVM instance; the situation is quite close to the one
> described in the following statement from the GPL FAQ: "If the program
> dynamically links plug-ins, but the communication between them is limited to

> invoking the ‘main’ function of the plug-in with some options and waiting

> for it to return, that is a borderline case."
>
> Also, is it OK to bundle the Kiama JAR with my benchmark harness, be it with
> or without the entire DaCapo benchmark suite. (Either way would work for
> me.)
>
> Best wishes,
>
> Andreas
>

> --
> You received this message because you are subscribed to the Google Groups
> "kiama" group.
> To post to this group, send email to ki...@googlegroups.com.
> To unsubscribe from this group, send email to
> kiama+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/kiama?hl=en.
>
>

--

Associate Professor at Delft University of Technology

Group:          Software Language Design and Engineering
Email:          e.vi...@tudelft.nl
Homepage:   http://eelcovisser.org
Publications: http://researchr.org/profile/eelcovisser
News:           http://twitter.com/eelcovisser

[Tony Sloane]

Hi Andreas,

I agree with Eelco. There should not be a problem. See this page for the official FSF position on the LGPL when used with Java:

http://www.gnu.org/licenses/lgpl-java.html

Regarding distribution of the JAR, I guess you could do that as long as you comply with the LGPL conditions for redistribution.

However, I would recommend that you consider using sbt to build your benchmark harness. Then you can automatically download Kiama (and presumably the DaCapo libraries) when the harness is built, rather than having to distribute all of the libraries with your code. This strategy would also avoid any concerns about redistribution.

Kiama is posted to the www.scala-tools.org repository. See the beginning of http://code.google.com/p/kiama/wiki/Installation for details on how to refer to Kiama in an sbt project.

cheers,
Tony

[Andreas Sewe]

Ho Tony,

> I agree with Eelco. There should not be a problem. See this page for the official FSF position on the LGPL when used with Java:
>
> http://www.gnu.org/licenses/lgpl-java.html

Just what I thought and hoped for. I just wanted to say "Hi!" and let
you know what I use Kiama for.

> Regarding distribution of the JAR, I guess you could do that as long as you comply with the LGPL conditions for redistribution.

The packaging of the DaCapo benchmark suite, which I build on,
unfortunately mandates that all dependencies and input data are part of
a single standalone JAR, so at least for prepackaged benchmarks I have
to redistribute Kiama; thus, I have to comply with the LGPL's conditions.

> However, I would recommend that you consider using sbt to build your benchmark harness. Then you can automatically download Kiama (and presumably the DaCapo libraries) when the harness is built, rather than having to distribute all of the libraries with your code. This strategy would also avoid any concerns about redistribution.

Yes, but it would require any user of the benchmark suite to build it
from scratch. While tools like Maven or sbt can make this easy, it's
still slightly inconvenient for users than simply downloading a single
standalone JAR for the entire benchmark suite. Also, it would raise
(minor) concerns over reproducibility of measurements if every
researcher uses their own build of the suite. It's simply hard to get
100% reproducible builds, so I'd rather offer an "official" release for
download.

> Kiama is posted to the www.scala-tools.org repository. See the beginning of http://code.google.com/p/kiama/wiki/Installation for details on how to refer to Kiama in an sbt project.

Yes, Maven repositories like scala-tools.org are great, in particular as
they increase the dependencies' stability and long-term availability. As
mentioned above, this is a property quite important for a benchmark
suite meant for research.

FWIW, I am already building my benchmark with Maven itself (sbt is
certainly nice; I just happen to be more familiar with Maven), so
automatic downloading comes for free. :-) Still, for most users a
prepackaged benchmark is probably the better solution.

That being said, keep up the good work with Kiama.

Best wishes,

Andreas

[Tony Sloane]

Hi Andreas,

On 18/01/2011, at 7:24 PM, Andreas Sewe wrote:

> Ho Tony,
>
>> I agree with Eelco. There should not be a problem. See this page for the official FSF position on the LGPL when used with Java:
>> http://www.gnu.org/licenses/lgpl-java.html
>
> Just what I thought and hoped for. I just wanted to say "Hi!" and let you know what I use Kiama for.

Thanks and please keep the list up to date on your future work. Benchmarking Scala vs Java is an interesting project.

>> Regarding distribution of the JAR, I guess you could do that as long as you comply with the LGPL conditions for redistribution.
>
> The packaging of the DaCapo benchmark suite, which I build on, unfortunately mandates that all dependencies and input data are part of a single standalone JAR, so at least for prepackaged benchmarks I have to redistribute Kiama; thus, I have to comply with the LGPL's conditions.

Ok, no problem.

>> However, I would recommend that you consider using sbt to build your benchmark harness. Then you can automatically download Kiama (and presumably the DaCapo libraries) when the harness is built, rather than having to distribute all of the libraries with your code. This strategy would also avoid any concerns about redistribution.
>
> Yes, but it would require any user of the benchmark suite to build it from scratch. While tools like Maven or sbt can make this easy, it's still slightly inconvenient for users than simply downloading a single standalone JAR for the entire benchmark suite. Also, it would raise (minor) concerns over reproducibility of measurements if every researcher uses their own build of the suite. It's simply hard to get 100% reproducible builds, so I'd rather offer an "official" release for download.

Yep, makes sense.

>> Kiama is posted to the www.scala-tools.org repository. See the beginning of http://code.google.com/p/kiama/wiki/Installation for details on how to refer to Kiama in an sbt project.
>
> Yes, Maven repositories like scala-tools.org are great, in particular as they increase the dependencies' stability and long-term availability. As mentioned above, this is a property quite important for a benchmark suite meant for research.
>
> FWIW, I am already building my benchmark with Maven itself (sbt is certainly nice; I just happen to be more familiar with Maven), so automatic downloading comes for free. :-) Still, for most users a prepackaged benchmark is probably the better solution.
>
> That being said, keep up the good work with Kiama.

Thanks. We'll try :-)

cheers,
Tony

[alexander...@googlemail.com]

Hi all,

This post was helpful - I had a very similar query about Kiama. My name is Alex Summers (actually, I've met Eelco before - hi again), and I work as a researcher at ETH Zurich on building various verification tools. For some time, we used Kiama in various projects, and found it extremely elegant and convenient, particularly when prototyping new tools - thank you for making it available!

In a recent project (Viper) we are building further tools that are designed to be of use to other researchers in the area, and we came to a different conclusion when we attempted to analyse the licencing requirements for .jar files (with respect to the last question in the original post). As I understand it from the licence, packaging the library into a .jar would be considered a "Combined Work":

A "Combined Work" is a work produced by combining or linking an
Application with the Library.  The particular version of the Library
with which the Combined Work was made is also called the "Linked
Version".

For a Combined Work, the requirements of the LGPL are unfortunately quite problematic for us (the five requirements under point 4 of the LGPL). Amongst other things, I believe we would need to include both the actual licence and the GPL (even though this does not cover any part of the software, as far as I understand it?), both within the .jar file and to be referenced at runtime by any software displaying a copyright notice. As far as I can tell, this would apply equally to clients of our software, e.g. other academic users who are building verification tools on top of ours (there are a few groups at other universities trying this out, typically also using Java/Scala, for which .jar files seem the convenient means of distribution, as discussed in this thread).

I read the linked page above ( https://www.gnu.org/licenses/lgpl-java.html ) and it indeed seems clear that we are OK to use our own licence (for which we chose the Mozilla Public Licence), but it seems that the restrictions of point 4 of the LGPL would all still apply to a .jar including Kiama (such as those that our sbt builds produce). Do you think that our above understanding of the Kiama licence with respect to .jar files is incorrect? Unfortunately, our project is now looking into library alternatives to Kiama, since we would like to be able to allow (particularly) other researchers to build upon our tools without these restrictions, and it's important to us to be able to distribute versions of our tools that work "out of the box" when new users are interested.

In any case, thank you for producing a great library - it has certainly helped us in our tool development so far!

Best wishes,

Alex Summers

[Tony Sloane]

Hi Alex,

Thanks for your positive feedback about Kiama. I’m glad that it’s been of use to your group. Hopefully it can continue to be useful.

Regarding the LGPL etc, I’m sorry to hear that you think that it will get in the way of you using Kiama in the future. As far as I am aware, there should be no serious problem. Including the license information in the jar shouldn’t be too much of a burden, I think. Otherwise, section 5 of the LGPL makes it clear that you can bundle some of your things with an LGPL library as long as you also distribute the uncombined version of your things. So you might have to distribute two jars but that doesn’t seem to be a big price to pay, certainly compared to the effort of replacing Kiama with something else.

Please let me know if I’m missing something here, because we do want to balance our desire to keep Kiama modifications open and the needs of Kiama users.

regards,
Tony

> --
> You received this message because you are subscribed to the Google Groups "kiama" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+un...@googlegroups.com.

> To post to this group, send email to ki...@googlegroups.com.

> Visit this group at https://groups.google.com/group/kiama.
> For more options, visit https://groups.google.com/d/optout.

[Miguel Branco]

Hi,

Just to add that the same applies to us. Unfortunately, we've been repeatedly told by lawyers that, despite FSF statements, much of the LGPL hasn't been truly "exercised" and that the actual legal implications depend on court precedence. Their summary is: if Microsoft/Google/IBM don't use it, then don't touch it. That's why we're asked regularly to remove our dependency away from Kiama because it can "taint" our own software, and forces a license on it that the university may otherwise disapprove off, as it limits (effectively impairs) future commercial application. Of course it's entirely up to you to decide, but pragmatically, (L)GPL seems to work mostly on an environment where all subsequent uses are also (L)GPL. We are using MIT License for similar reasons to the ones described by Andreas. These are sensitive issues, I understand, and we all tend to have strong opinions; unfortunately, the lawyers we've been in touch with have a different approach, which says that until some license has been truly exercised (I'm told by a long list of court cases), its meaning can't truly be defined. In the case of LGPL, this is particularly true as even its authors have different interpretations to its meaning.

cheers!

> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+unsubscribe@googlegroups.com.

> To post to this group, send email to ki...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kiama.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kiama" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kiama+unsubscribe@googlegroups.com.

[Tony Sloane]

Hi everyone,

It seems that the LGPL issue is a deal breaker for some people, so we will consider moving to a different license, since we would much rather people use our software than be forced to move away.

Can I suggest that we discuss the options on this issue:

https://bitbucket.org/inkytonik/kiama/issues/69/asl-20

to keep the discussion off the mailing list, since it won’t be of interest to everyone.

In particular, I am interested in the pros and cons of the different alternatives, since as far as I can tell there are Apache licenses, MIT ones and presumably more options. If you have a view about the possible future license for Kiama, can you please post on that issue?

thanks,
Tony

> > To unsubscribe from this group and stop receiving emails from it, send an email to kiama+un...@googlegroups.com.

> > To post to this group, send email to ki...@googlegroups.com.
> > Visit this group at https://groups.google.com/group/kiama.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "kiama" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+un...@googlegroups.com.

> To post to this group, send email to ki...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kiama.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "kiama" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+un...@googlegroups.com.

[Alexander Summers]

Hi Tony and all,

Thanks a lot for the speedy replies - I'm sorry that I dropped out of the loop for a bit. Having the option of another license would be great! I will ask around within our project too, since we spent some time looking at various open-source licences at some point, and can probably reconstruct some of our thinking from back then (although I seem to recall that the differences between many of the options were quite minor from our perspective).

Anyway, thanks very much for considering this!

Best wishes, Alex

> > To unsubscribe from this group and stop receiving emails from it, send an email to kiama+unsubscribe@googlegroups.com.

> > To post to this group, send email to ki...@googlegroups.com.
> > Visit this group at https://groups.google.com/group/kiama.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "kiama" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+unsubscribe@googlegroups.com.

> To post to this group, send email to ki...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kiama.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "kiama" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to kiama+unsubscribe@googlegroups.com.

> To post to this group, send email to ki...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kiama.
> For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "kiama" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kiama/vE-gHz7GY2U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kiama+unsubscribe@googlegroups.com.