GPL clarifications for Java application
Michael Weiss-Malik
determine a definite answer to my situation. I'm still not 100% sure
of the correct answers to my questions below.
The situation is this: I work for a research project at a large public
university and we're producing a java application. We'd like to use a
GPL'd package or two. Due to restrictions from higher-ups, it is
completely impossible to release our application's source code under
the GPL. We do not need to make any changes at all to any GPL java
libraries, we're only interested in dynamically linking to them. We
ARE able to include any and all proper copyright notices, and make
source available for anything other than our application proper.
I am fully aware that GPL and LGPL are two different licenses.
#1) Is it okay for our program to automatically detect and take
advantage of the existence of specific GPL'd libraries in the user's
classpath? Assume our program will function just fine without those
libraries, but certain functionality might be disabled.
My sense is that #1 is not permissible, and I don't understand
why/how. If I distribute a program that doesn't contain GPL'd
property, but is only aware of the EXISTENCE of GPL'd property with
specific interfaces, where is my violation? An interface is
essentially a communications protocol. Now perhaps protocols are
patentable (dunno), but they certainly aren't copyrightable. If #1 is
not permissible, how is it any different than a GPL XYZ client
designed to talk to a non-GPL XYZ server, or vice-versa? Note that the
client and server might even be on the same machines.
I don't believe Microsoft SHOULD have a right to prevent me from
distributing an application that calls some internal functions in one
of Excel's DLL files, period. Why is it a "Good Thing" if GPL authors
are allowed to restrict me in this way?
#2) Does the LGPL allow you to include an entire (unaltered) LGPL'd
library inside a jar file for a closed-source application? Note that a
user can easily unzip the jar file, alter the library, and "relink" it
with the application.
#3) Is it okay to distribute GPL'd programs and proprietary programs
in a single zip file of "my favorite applications"? Is it okay to do
this AND have a single installer program to install all applications
at once?
#4) If #3 is okay, doesn't that make it legal to distribute our
application alongside a GPL'd library in a JAR file? What if the only
interface between our application and the "library" is actually
command-line based through pipes?
#5) Am I allowed to include unmodified GPL'd class files in my non-GPL
jar file? The GPL FAQ makes me think this is specifically
disallowed... however a jar file is just an archive format, it's not
really an executable, it's a document type (a zip file).
If someone distributes a program that, given a zip file, runs every
executable program in the zip file, does that instantly turn every zip
file into an executable in the eyes of the GPL? If not, then why does
the existence of the java JVM turn a jar file into an executable
binary format, in the eyes of the GPL?
Certainly distribution in a "plain old zip file" of a GPL program is
more like distribution on a floppy than distribution in a derivative
work. Why is a JAR file a derivative work?
I appreciate any help anyone can offer. Our programming staff is very
much interested in preserving the rights of free software authors,
otherwise I wouldn't bother asking these questions.
-Michael Weiss-Malik
Mars Space Flight Facility, Arizona State University
http://themis.asu.edu/
http://tes.asu.edu
Jean-Marc Lienher
> #1) Is it okay for our program to automatically detect and take
> advantage of the existence of specific GPL'd libraries in the user's
> classpath? Assume our program will function just fine without those
> libraries, but certain functionality might be disabled.
This is a FAQ. Here is the FSF's answer :
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
http://www.gnu.org/licenses/gpl-faq.html#TOCGPLAndPlugins
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
>
> My sense is that #1 is not permissible, and I don't understand
> why/how. If I distribute a program that doesn't contain GPL'd
> property, but is only aware of the EXISTENCE of GPL'd property with
> specific interfaces, where is my violation? An interface is
> essentially a communications protocol. Now perhaps protocols are
> patentable (dunno), but they certainly aren't copyrightable. If #1 is
> not permissible, how is it any different than a GPL XYZ client
> designed to talk to a non-GPL XYZ server, or vice-versa? Note that the
> client and server might even be on the same machines.
>
> I don't believe Microsoft SHOULD have a right to prevent me from
> distributing an application that calls some internal functions in one
> of Excel's DLL files, period. Why is it a "Good Thing" if GPL authors
> are allowed to restrict me in this way?
Don't ask this kind of question to RMS, or he will drop
the conversation.
I had discussion on this subjet on 4 newsgroups and I had a
private discussion with RMS.
Now I wrote my own opinion here :
http://www.oksid.ch/license/faq.html
In short I think that dynamic linking is legal.
But this in no way a legal advice. I'm not a lawyer.
Bijan Soleymani
This is not exactly the same thing.
The FSF doesn't object to proprietary software communicating with free
software. If a proprietary program runs a GPL program on a file then
that shouldn't be a problem (proprietary front-end). These are
different components.
Protocols are no problem. No one complains if some GPL browser accesses
a site off of Microsoft's IIS server, or vice versa.
When you link a library (even dynamically) it in a sense becomes part
of your program. It is not an external part, data structures can be
accessed directly, etc.
Basically linking is not communicating far enough. It's a little too
close for comfort. Basically the idea is that you should take the GPL
library make a stand-alone program and have your program call that. If
that is impossible, then your program probably is a derivative work
of that library as it is in some sense depends on it.
> I don't believe Microsoft SHOULD have a right to prevent me from
> distributing an application that calls some internal functions in one
> of Excel's DLL files, period. Why is it a "Good Thing" if GPL authors
> are allowed to restrict me in this way?
It may not be a good thing for you or it may not be a good thing in
general. But the thinking behind this seems to be that this will make
Free Software better. For example many free programs have excellent
completion features of readline (bash), while something like
(cmd.exe) has lousy completion.
This evens the score with proprietary software makers. You see
Microsoft doesn't need to stop free software from linking with
proprietary libraries, free software by definition can't really do
that. How is it free if you can't modify large parts of the program
(of course there are exceptions for system libraries).
Just my personal opinion,
Bijan Soleymani
Jean-Marc Lienher
> When you link a library (even dynamically) it in a sense becomes part
> of your program. It is not an external part, data structures can be
> accessed directly, etc.
>
> Basically linking is not communicating far enough. It's a little too
> close for comfort. Basically the idea is that you should take the GPL
> library make a stand-alone program and have your program call that. If
> that is impossible, then your program probably is a derivative work
> of that library as it is in some sense depends on it.
I hope that you are wrong.
If you are right then the GNU/Linux world has a big problem.
It makes nearly all Linux programs to violate the LGPL.
Because the glibc is released under the LGPL...
And the LGPL says that if you make a derivative work:
----------------------------------------------
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:
----------------------------------------------
I've only seen a few (if any) programs with a notice stating
that they use the glibc...
Barry Margolin
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>Bijan Soleymani a écrit :
>> When you link a library (even dynamically) it in a sense becomes part
>> of your program. It is not an external part, data structures can be
>> accessed directly, etc.
>>
>> Basically linking is not communicating far enough. It's a little too
>> close for comfort. Basically the idea is that you should take the GPL
>> library make a stand-alone program and have your program call that. If
>> that is impossible, then your program probably is a derivative work
>> of that library as it is in some sense depends on it.
>
>I hope that you are wrong.
>If you are right then the GNU/Linux world has a big problem.
>
>It makes nearly all Linux programs to violate the LGPL.
>Because the glibc is released under the LGPL...
If there are multiple libraries implementing the same API, and a program is
not statically linked to any particular one of them, then it will work with
any of them. In that case, it's not considered to be a derivative of any
specific one, because the programmer has no way of knowing which one will
be used when it's linked at run-time.
In the case of glibc, it implements the same API as other Unix libc's. So
a program that uses it will also work with the other ones, so it's not a
derivative of glibc. An exception would be if glibc has some unique
features and the program makes use of them.
--
Barry Margolin, barry.m...@level3.com
Genuity Managed Services, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Bijan Soleymani
Glibc is not GPL!
It has exception allowing linking proprietary programs with it.
This is for tactical reasons.
If it was GPL, many distributions would use a proprietary alternative
so it is under a more liberal license.
Bijan
Bijan Soleymani
Glibc has many such features. However glibc license allows proprietary
linking for tactical reasons (if it didn't some distributions might
use a proprietary alternative).
Bijan
Jean-Marc Lienher
> Glibc is not GPL!
> It has exception allowing linking proprietary programs with it.
Can you show me where is this exception ?
here ?:
----------------------------------------------
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
----------------------------------------------
A program always contains itself. And a program is a derivative of
the library.
It means that it is not a "work that uses the Library".
Jean-Marc Lienher
> If there are multiple libraries implementing the same API, and a program is
> not statically linked to any particular one of them, then it will work with
> any of them. In that case, it's not considered to be a derivative of any
> specific one, because the programmer has no way of knowing which one will
> be used when it's linked at run-time.
>
> In the case of glibc, it implements the same API as other Unix libc's. So
> a program that uses it will also work with the other ones, so it's not a
> derivative of glibc. An exception would be if glibc has some unique
> features and the program makes use of them.
Do you know another C library for Linux ?
I don't. So I think that there is no choice, under Linux you
must use glibc...
Bijan Soleymani
> Bijan Soleymani a écrit :
> > Glibc is not GPL!
> > It has exception allowing linking proprietary programs with it.
>
> Can you show me where is this exception ?
glibc is licensed under LGPL (lesser GPL), this allows linking
proprietary programs.
Bijan
Jean-Marc Lienher
You misunderstood me. Where is the exception in the LGPL ?
( I think that I have quoted it in my previous message.)
Bijan Soleymani
> Bijan Soleymani a écrit :
> >
> > Jean-Marc Lienher <ok...@bluewin.ch> writes:
> >
> > > Bijan Soleymani a écrit :
> > > > Glibc is not GPL!
> > > > It has exception allowing linking proprietary programs with it.
> > >
> > > Can you show me where is this exception ?
> > glibc is licensed under LGPL (lesser GPL), this allows linking
> > proprietary programs.
>
> You misunderstood me. Where is the exception in the LGPL ?
> ( I think that I have quoted it in my previous message.)
Sorry I misunderstood.
Section 5 says that before linking the work is not considered a
derived work (yet!). But as soon as linking occurs it is considered a
derived work.
Section 6 indicates that in this case the distributor has certain
options:
1)Distribute source code for librar and either source or object code
for the program.
2)Use a shared library mechanism.
3)Give a written offer to provide items in 1
etc.
Oh the user must be allowed to study and reverse engineer the
software.
Basically the goal is that the user not lose the ability to modify the
free library.
Bijan
Jean-Marc Lienher
> Section 5 says that before linking the work is not considered a
> derived work (yet!). But as soon as linking occurs it is considered a
> derived work.
The problem is the definition of the unlinked program.
It is defined as a program that contains no _derivative_ of the library.
A program is a derivative and it contains itself.
The author of LGPL should have used the word "portion", but he use
the legal term "derivative"...
It means that the program is not a "work that uses the Library".
And it means that it must be distributed with a prominent notice,
supply a copy of LGPL and if it displays a copyright notice then
it must display the library one too.
Sam Holden
To name just three:
diet libc : http://fefe.de/dietlibc/
newlib : http://sources.redhat.com/newlib/
uclibc : http://www.uclibc.org/
--
Sam Holden
Jean-Marc Lienher
> Do you know another C library for Linux ?
> I don't. So I think that there is no choice, under Linux you
> must use glibc...
> To name just three:
>
Thank I only know uclib I've not mentionned it because I know
that it is not glibc compatible.
> diet libc : http://fefe.de/dietlibc/
Q: Why aren't you compatible to glibc? I thought the interface was a
standard?
A: Yes, the interface is, but a lot of details are missing. For
example, the diet libc uses a different "struct stat" layout than
glibc. We use the one from the kernel, glibc uses an own one and
links in translation code. This is part of the reason why glibc is
so big and ugly. If we support all of this, we end up as bloated as
glibc.
> newlib : http://sources.redhat.com/newlib/
I've not found any doc about its glibc compatibility.
Is it runtime glibc compatible ?
> uclibc : http://www.uclibc.org/
Porting applications from glibc to uClibc typically involves just
recompiling the source code.
Barry Margolin
Many applications that run on Linux will also run on most other flavors of
Unix, using whatever libc is provided with that system. So unless your
program is designed so it only runs on Linux, it doesn't seem like an
issue.
Jean-Marc Lienher
>
> In article <3E608DA1...@bluewin.ch>,
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> >Barry Margolin a écrit :
> >> If there are multiple libraries implementing the same API, and a program is
> >> not statically linked to any particular one of them, then it will work with
> >> any of them. In that case, it's not considered to be a derivative of any
> >> specific one, because the programmer has no way of knowing which one will
> >> be used when it's linked at run-time.
> >>
> >> In the case of glibc, it implements the same API as other Unix libc's. So
> >> a program that uses it will also work with the other ones, so it's not a
> >> derivative of glibc. An exception would be if glibc has some unique
> >> features and the program makes use of them.
> >
> >Do you know another C library for Linux ?
> >I don't. So I think that there is no choice, under Linux you
> >must use glibc...
>
> Many applications that run on Linux will also run on most other flavors of
> Unix, using whatever libc is provided with that system. So unless your
> program is designed so it only runs on Linux, it doesn't seem like an
> issue.
Yes a Linux program can run on *BSD, Solaris and even Windows.
But the program must be statically linked or you must install
the Linux libraries. Because these emulators emulate only system
calls, but not the libc functions.
And I think that's when you compile a program for Linux, you
know that the end user will use glibc. (Execpt if you are creating
a program for embeded system which uses a smaller libc).
At least Debian, RedHat and SuSE know that the programs that
they distribute will use the glibc.
So if a dynamically compiled program is a derivative work then
they violate the LGPL.
But don't worry, a dynamically compiled program is not a
derivative work.
Barry Margolin
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>Yes a Linux program can run on *BSD, Solaris and even Windows.
>But the program must be statically linked or you must install
>the Linux libraries. Because these emulators emulate only system
>calls, but not the libc functions.
Functions like printf(3) and select(3) should be in any POSIX-compliant
libc.
They only need glibc if they're using functions that are only available in
that library. If they stick to the usual Unix stuff, they should be
portable to all flavors of Unix.
Jean-Marc Lienher
>
> In article <3E63F369...@bluewin.ch>,
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> >Yes a Linux program can run on *BSD, Solaris and even Windows.
> >But the program must be statically linked or you must install
> >the Linux libraries. Because these emulators emulate only system
> >calls, but not the libc functions.
>
> Functions like printf(3) and select(3) should be in any POSIX-compliant
> libc.
Of course. But that's not what I'm talking about.
>
> They only need glibc if they're using functions that are only available in
> that library. If they stick to the usual Unix stuff, they should be
> portable to all flavors of Unix.
I'm not talking about portability of source code I'm talking
about running a dynamically compiled program with a different libc.
The orignial point was that a program is not a derivative work
because the end-user doesn't know which library will be used.
I took glibc as an example but there is other well known unique LGPL
libraries.
Barry Margolin
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>Barry Margolin a écrit :
>>
>> In article <3E63F369...@bluewin.ch>,
>> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>> >Yes a Linux program can run on *BSD, Solaris and even Windows.
>> >But the program must be statically linked or you must install
>> >the Linux libraries. Because these emulators emulate only system
>> >calls, but not the libc functions.
>>
>> Functions like printf(3) and select(3) should be in any POSIX-compliant
>> libc.
>
>Of course. But that's not what I'm talking about.
Then I don't know what you're talking about. Most of the functions in
glibc are the ones that implement the standard C and POSIX/Unix APIs, like
those functions, and they should be available in every POSIX-compliant or
Unix-like OS.
>> They only need glibc if they're using functions that are only available in
>> that library. If they stick to the usual Unix stuff, they should be
>> portable to all flavors of Unix.
>
>I'm not talking about portability of source code I'm talking
>about running a dynamically compiled program with a different libc.
>
>The orignial point was that a program is not a derivative work
>because the end-user doesn't know which library will be used.
>I took glibc as an example but there is other well known unique LGPL
>libraries.
But glibc is not like many other LGPL libraries, because it implements a
standard API and can easily be replaced by other libraries that implement
the same API. The point you raised is only a concern when the application
*must* be linked with a particular library to work.
Jean-Marc Lienher
>
> In article <3E647EF3...@bluewin.ch>,
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> >Barry Margolin a écrit :
> >>
> >> In article <3E63F369...@bluewin.ch>,
> >> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> >> >Yes a Linux program can run on *BSD, Solaris and even Windows.
> >> >But the program must be statically linked or you must install
> >> >the Linux libraries. Because these emulators emulate only system
> >> >calls, but not the libc functions.
> >>
> >> Functions like printf(3) and select(3) should be in any POSIX-compliant
> >> libc.
> >
> >Of course. But that's not what I'm talking about.
>
> Then I don't know what you're talking about. Most of the functions in
> glibc are the ones that implement the standard C and POSIX/Unix APIs, like
> those functions, and they should be available in every POSIX-compliant or
> Unix-like OS.
I'm not talking about portability, but "runnablity".
Do you mean that I can run a Linux POSIX program under Solaris
without emulator ?
I don't know I've never tried.
>
> >> They only need glibc if they're using functions that are only available in
> >> that library. If they stick to the usual Unix stuff, they should be
> >> portable to all flavors of Unix.
> >
> >I'm not talking about portability of source code I'm talking
> >about running a dynamically compiled program with a different libc.
> >
> >The orignial point was that a program is not a derivative work
> >because the end-user doesn't know which library will be used.
> >I took glibc as an example but there is other well known unique LGPL
> >libraries.
>
> But glibc is not like many other LGPL libraries, because it implements a
> standard API and can easily be replaced by other libraries that implement
> the same API.
Where can I find such a non-LGPL library for Linux ?
Somebody has already sent 3 links to libc Libraries, but
according to the doc that I've found they are not 100%
compatible with glibc.
> The point you raised is only a concern when the application
> *must* be linked with a particular library to work.
I agree with you. A dynamically compiled program must never be
linked with a particular library to work. The end-user can always
have his own compatible library. A dynamically compiled program
is not a derivative work.
Jean-Marc Lienher
> > Then I don't know what you're talking about. Most of the functions in
> > glibc are the ones that implement the standard C and POSIX/Unix APIs, like
> > those functions, and they should be available in every POSIX-compliant or
> > Unix-like OS.
>
> I'm not talking about portability, but "runnablity".
>
> Do you mean that I can run a Linux POSIX program under Solaris
> without emulator ?
> I don't know I've never tried.
I don't have Solaris but I have an old SuSE from 1999.
I've extracted the ls program (which I hope is POSIX) and
I've tryed to run it under my Debian 3.0.
It doesn't work...
So I have some doubts that it will work with Solaris...
-------------------------------------------------------------------
nt:~/bin# file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically l
inked (uses shared libs), stripped
nt:~/bin# ls -l /bin/ls
-rwxr-xr-x 1 root root 43784 Mar 18 2002 /bin/ls
nt:~/bin# ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x4001b000)
libc.so.6 => /lib/libc.so.6 (0x4002c000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4014a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
nt:~/bin# file ls
ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked
(uses shared libs), stripped
nt:~/bin# ls -l ls
-rwxr-xr-x 1 root root 35644 Mar 4 23:03 ls
nt:~/bin# ldd ls
/usr/bin/ldd: ./ls: No such file or directory
nt:~/bin#
----------------------------------------------------------------
Barry Margolin
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>I'm not talking about portability, but "runnablity".
>
>Do you mean that I can run a Linux POSIX program under Solaris
>without emulator ?
>I don't know I've never tried.
You can't do it, but it has nothing to do with the libraries. It's because
they use different executable file formats.