Jump to content
Excelsior Forums
Sign in to follow this  

(Legal) Using Jet with libraries

Recommended Posts

Has anybody compiled a list of licences that Jet can be used with? I'm currently working on an application which I intend to sell, my understanding is that generally I can use LGPL and Apache licensed libraries in something I?m going to sell (assuming I don?t make any changes to the library). But what are the restrictions on compiling them (with Jet) and packaging them for install. Does this count as altering them or in the case of the LGPL) making a derivative work?

? Graham

Share this post

Link to post
Share on other sites

I am not a lawyer, but I have considered this quite a bit. The argument I would pose is that I am charging for the added value (i.e. all of this code separately does not accomplish what I created)...I am not charging for the code, I am charging for my labor.

The GPL is more about 'giving back to the community' any code you have modified or improved that you 'took' from the community; but how do you do that with an executable? The GPL has nothing regarding an executable as far as I know. This is still a 'sticky' issue.

However, the GPL (in my opinion) cannot stop me from 'gleening' information, so it has its weeknesses. In fact, what is there (besides a patent) to stop someone from merely looking at how my application works (not even looking at the code) and discerning what they want?


Share this post

Link to post
Share on other sites

DISCLAIMER: I am not a lawyer, so this is all my opinion.

My reading of the Apache License v2.0 is that as long as you meet the criteria of section 4, you are fine redistributing a AOT compiled version of this library.

My reading of the LGPL v2.1 is that you can distribute a compiled version of a Java library, but only under very specific circumstances. The clause to look at for distributing an AOT compiled version is clause 6. (There are other conditions you need to meet in the other clauses, but this is the only clause I found that can be read to restrict/permit AOT compilation). The full clause is below, with relevant parts italics and comments in bold.

  6. As an exception to the Sections above, you may also combine or

link a "work that uses the Library" with the Library to produce a

work containing portions of the Library, and distribute that work

under terms of your choice, provided that the terms permit

modification of the work for the customer's own use and reverse

engineering for debugging such modifications.

This is the first implication that the customer must be able to modify the library.

You must give prominent notice with each copy of the work that the

Library is used in it and that the Library and its use are covered by

this License.  You must supply a copy of this License.  If the work

during execution displays copyright notices, you must include the

copyright notice for the Library among them, as well as a reference

directing the user to the copy of this License.  Also, you must do one

of these things:

    a) Accompany the work with the complete corresponding

    machine-readable source code for the Library including whatever

    changes were used in the work (which must be distributed under

    Sections 1 and 2 above); and, if the work is an executable linked

    with the Library, with the complete machine-readable "work that

    uses the Library", as object code and/or source code, so that the

    user can modify the Library and then relink to produce a modified

    executable containing the modified Library. (It is understood

    that the user who changes the contents of definitions files in the

    Library will not necessarily be able to recompile the application

    to use the modified definitions.)

Since a traditional JAR is always dynamically linked, it's fine if you distribute it as a JAR using mixed-mode compilation (where the JAR is compiled at runtime). However, if you statically link the JAR file, then you must also distribute the object code for your application so a user can create a modified version of the library and relink it. Since the object code can easily be 4-5x the size of the original executable, this makes it impractical for distribution unless you have an extremely small application.

    B)Use a suitable shared library mechanism for linking with the

    Library.  A suitable mechanism is one that (1) uses at run time a

    copy of the library already present on the user's computer system,

    rather than copying library functions into the executable, and (2)

    will operate properly with a modified version of the library, if

    the user installs one, as long as the modified version is

    interface-compatible with the version that the work was made with.

My reading of this is that if you compile the library into a DLL and that DLL can be replaced by a newer version without recompiling the original application, that you can distribution an AOT compiled version of the library as a DLL.

    c) Accompany the work with a written offer, valid for at

    least three years, to give the same user the materials

    specified in Subsection 6a, above, for a charge no more

    than the cost of performing this distribution.

This is where I get fuzzy. Presumably as long as you promise the user to deliver the object code, then you can get away with precompiling without necessarily distributing the object code. However, if you are using Excelsior JET to make it harder to reverse engineer your code, it may be that distributing the object code makes it easier to do the reverse engineering. That would be a different question for this forum.

    d) If distribution of the work is made by offering access to copy

    from a designated place, offer equivalent access to copy the above

    specified materials from the same place.

So basically, you can avoid the written offer if you allow someone to download the object code from wherever you distribute the original code. For a commercial program that you might distribute electronically through distributors, this is a pain in the neck.

    e) Verify that the user has already received a copy of these

    materials or that you have already sent this user a copy.

For an executable, the required form of the "work that uses the

Library" must include any data and utility programs needed for

reproducing the executable from it.  However, as a special exception,

the materials to be distributed need not include anything that is

normally distributed (in either source or binary form) with the major

components (compiler, kernel, and so on) of the operating system on

which the executable runs, unless that component itself accompanies

the executable.

This is the kicker. From this clause it seems that you need to include a copy of Excelsior JET ("utility program needed for reproducing the executable") with the object code distributions. This is almost certainly against the Excelsior JET license.

Note that this is a really sloppy clause anyway, since it implies anyone distributing a Java program under LGPL must distribute the entire Java SDK used to compile the program (since the SDK is not always included in all operating systems by default).

  It may happen that this requirement contradicts the license

restrictions of other proprietary libraries that do not normally

accompany the operating system.  Such a contradiction means you cannot

use both them and the Library together in an executable that you


Possible technical ways around the limitation described above:

- If Excelsior JET could be modified to first look for a JAR file in a specific directory and if that JAR file exists JIT compile it, otherwise use an AOT compiled version of the JAR, then you could meet the requirement that a user needs to be able to replace the existing library with a newer one and still have the program execute.

- If Excelsior JET had a subset of the compiler that could compile a JAR to a DLL that could be distributed, then you could comply with the last clause more easily.

Overall, in my opinion, the LGPL is an awfully written license, especially for use by any Java program. It is much to technology-specific and geared too much toward specific methods of C/C++ development.

One final alternative is if the library you are using has a single or only a couple authors, writing the authors and getting them to redistribute the code under a new license. The open source iText library recently switched from LGPL to the Mozilla Public License specifically because of problems with the LGPL.

For a more official opinion, you can e-mail the staff at the Free Software Foundation (http://www.fsf.org/) and get their opinion on using AOT compiled Java libraries that are licensed under LGPL. Since they have the final say, if you get an official opinion from them, you should feel pretty safe to do what you need to. If you go this route, I would be interested to hear the result.

Share this post

Link to post
Share on other sites


Any more info on this, as I am potentially in a similar position if I go ahead and use some lgpl jars?

The clearest explanation of java.lgpl issue I have found is http://www.gnu.org/licenses/lgpl-java.html

So I can produce an executable with Jet that still dynamically links the jars at run time, from say a lib directory?

Jet will allow me to do this? ["Mixed Compilation Model" I think?]

[ and then I just have to include source of the lgpl jars as well as copyright notices]

I think the reverse engineering clause that is standard in most licenses you would not have due to the lgpl reversere engineering provision, but in reality people will do it anyway so having a combo of obfuscation and jet I guess will make it a little tricky for them. http://www.javalobby.org/forums/thread.jspa?threadID=15903 has some interesting conversation on the reverse engineering issues.

or am I reading it wrong?

By Object code do you mean my app .class files before they go through Jet?


Share this post

Link to post
Share on other sites

When in doubt over a legal issue, consult a lawyer or at least read a book written by a lawyer. Reciprocity and the GPL is a chapter of one such book called "Open Source Licensing", and it has a section on LGPL on page 121. It is not very enlightening or encouraging, though:

      .  .  .
   These sections of the LGPL are an impenetrable maze of
   technological babble. They should not be in a general-purpose
   software license. The LGPL even concedes that ?the threshold
   for this to be true is not precisely defined by law.? (LGPL section
   5.) A licensee under these provisions won?t have a clue
   how extensive his or her good faith efforts must be when creating
   a derivative work in accordance with the LGPL.
   .  .  .

Food for thought:

  • LGPL is not limited to Java, right? Suppose I get an LGPL library written in C or C++, compile it with MSVC, and link statically to my C++ app. This is not much different to compiling an LGPL jar with Excelsior JET. I think this has been discussed many times in C/C++ forums and newsgroups - do a search.
  • How is all that licensing supposed to work if you use GCJ? Perhaps there is an answer in its mailing lists...

P.S. I have just checked the GCJ FAQ- the GCJ runtime library, [tt]libgcj[/tt], is not LGPL, but GPL with 'libgcc exception'.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this