license question?

[Peter]

OKOK , i understand now, the key point is "modified" and "unmodified".

If i include a GPL product in my commerical product without modify it,
then i still can distribute my product commerically and closed-source.
And this what you guys called "dynamic link"

If i include a GPL productt in my commerical product and modify it,
then my whole product need to be GPL too. And this what you guys
called "static link"

RIGHT?

thanks
from Peter

 

[Byron A Jeff]

-->
-> > HI
-> > I have read GNU GPL , Common public licence and gnu lesser license.
-> > As my understanding, i can including those softwares which is(
-> > GNU GPL , Common public licence and gnu lesser license) into my
-> > commerical product. And i am free to distribute it and modify it.
-> >
-> > Am i correct?
->
-> Partially.
->
-> You can include a LGPL library in your commercial prduct, and still
-> distribute
-> it closed-source, as long as you keep the library itself open. You can not
-> include any full GPL product in an application that is not itself full GPL

or GPL compatible license.

-
-But be VERY CERTAIN that your usage of the LGPL library
-is only via dynamic calls. Static linking will contaminate
-your product and make it also LGPL.

Not true #1. Don't spread FUD.

-
-GNU licenses (all variants) are extremely viral; attempting
-to convert your hard work into effectively public domain.

Not true #2. Don't spread FUD.

-
-I would suggest looking at other license models that
-are less socialistic in nature.

Not necessarily. Simply understand the licenses and their implications.

First off the GPL and LGPL are designed to look out for their free developers
and end users. Which frankly means they are not looking out for the
commercial developer. But in no way shape form or fashion does any of these
liceses contaminate or convert any of your code. The rules are simple: your
code is your code and the L/GPL code is the L/GPL code.

What invariably tries to happen is that a commercial developer attempts to
convert L/GPL code into proprietary code, then gets upset when they are told
or read that they cannot do that.

In fact the in its own way the GPL is the ultimate in capitalistic nature,
as it defines what belongs to it, and gives you rules on how to use what
belongs to it.

Now back to your FUD.

#1: Static linking doesn't contaminate your code or make it LGPL. But it
does require that if you statically link to an LGPL library, that you
provide a way for the user to update the LGPL library. Notice it says
nothing about your code. Why? Because it's yours. Dynamic linking makes
this requirement easy as the end user can simply load the new dynamic
library. But static linking doesn't comtaminate anything. You can in fact
offer the end user a compiled object to link in, never showing the end user
your code. But relinking is a requirement for you as a developer to use
the library.

#2: The GPL converts nothing. Even if you write code into GPL code, it's
still your code. However the GPL doesn't give you the right to distribute
it unless you make your code GPL too. If you don't like the terms, then don't
use GPL code.

It's just FUD to state that someone imposing use rules on their code is
converting or contaminating your code. It isn't a fair assertion.

BAJ

 

[Todd Knarr]

In Todd Knarr's explanation, any company can include GPL product in
their commerical product. But why you say we can't? I think we just
need to keep those GPL products still be GPL is ok, not our product.
Right?

There's a difference between an external program and a library. The
external program can be run outside the context of the program using it,
just as you would from the command line. There's a clear line between
your program and the external program, they don't even share memory
space and they communicate only indirectly through the I/O interfaces of
the OS. A library, on the other hand, is linked with your program and
actually becomes part of your program in memory when your program runs
(and in some cases may be phyically part of your actual executable on
disk even when it's not in memory). This is a bit more intimate a
connection, and the question then becomes where the library's authors
drew the line that says "Outside of this point we don't consider our
work to have been copied into yours.". The GPL and the LGPL draw it
at different points.

 

[Todd Knarr]

In my java program, i called some function from another jar
file(GPL). And i will include that GPL jar file into my jar file. It
is a static link or dynamic link?

In Java, it would probably be considered a static link. Your jar
file physically contains GPL'd code, it either has to be distributed
under the terms of the GPL or you are violating the copyright on
the GPL'd code by distributing copies without a valid license.

Fortunately, with Java you don't need to even worry about this. Java
can load classes without having them physically within the application's
jar file. Just distribute the GPL'd jar alongside your code but
not physically included within your jar files, install the GPL'd jar
files into a directory in the CLASSPATH and Java should happily find
and load them when you use them. Since they're physically seperate
from your program you can distribute your code under any terms you
want without interfering with distributing the GPL'd code under the
terms of the GPL. IIRC Java doesn't do header files the way C does
#include'd headers, so there's not the issue of header code being
physically included in your classes that makes the GPL-vs-LGPL
distinction important for C programmers and others.

 

[Todd Knarr]

If i include a GPL product in my commerical product without modify it,
then i still can distribute my product commerically and closed-source.
And this what you guys called "dynamic link"

No. Modification has nothing to do with it, it's the distribution of
code licensed to you under the GPL in a manner that violates the terms
of your license. Whether or not you've changed the GPL'd code, the
fact that your product contains copies of it and isn't itself under
the GPL is sufficient for copyright infringement (you've voided
your license under the GPL by violating it's terms, and you don't
have any other license from the author to copy and distribute their
code).

 

[Malcolm Dew-Jones]

Peter ([email protected]) wrote:
: OKOK , i understand now, the key point is "modified" and "unmodified".

Sorry, no. It has nothing to do with whether you modify something or not.
The issue is how "tightly" the gpl code is incorporated into your product.

: If i include a GPL product in my commerical product without modify it,
: then i still can distribute my product commerically and closed-source.
: And this what you guys called "dynamic link"

no. A dynamic link is a technical term. If you don't know what it is
then I can't image explaining it properly here, but in involves how the
code is compiled and linked.

: If i include a GPL productt in my commerical product and modify it,
: then my whole product need to be GPL too. And this what you guys
: called "static link"

Sorry, but no. A static link is a technical term. If you don't know what
it is then I can't image explaining it properly here, but in involves how
the code is compiled and linked.

In non-technical terms, the key point is whether a user could delete the
gpl product from their computer and replace it with something else and
your product still runs. If this is possible then your product is
probably "safe" from the gpl.

As an aside, if you want to include a gpl product with your product
without your product becoming gpl, then I think you may _also_ be required
to provide the gpl product as a separate install (in _addition_ to any
other requirement). I could be wrong on this, this requirement may be for
some other common product such as cygwin, but you need to check.

 

[Thomas Weidenfeller]

OKOK , i understand now, the key point is "modified" and "unmodified".

No. May I suggest you ask a lawyer to explain the licenses to you? And
pay attention to the difference between the GPL and the LGPL. They are
not the same license. And, hire a programmer who knows the meaning of
phrases like "dynamic linking".

F'up set.

/Thomas

 

[Morten Alver]

Thanks for your reply first

If my java program including a jar file, and calling the functions
that in the jar file. It is a dynamic link or static link?

The library can reside in an external jar, so in principle you don't
even have to distribute the library along with the application. I'm no
expert, but it seems to me that there would be no requirements on the
license of your application in this situation. Allowing this is the
reason for choosing the LGPL instead of the GPL.

 

[Chris Uppal]

Not necessarily. Simply understand the licenses and their implications.

That's one problem. The licence is long and complicated. I cannot feel
confident that I understand the terms in either the same sense that the creator
of the software intended (and that's important to me), or in the same way that
a court would interpret it. Under the circumstances I tend to avoid even LGPL
because, even if /I/ am satisfied that some use is OK, I cannot be sure that
the users of my libraries will see it the same way.

The confusion in this thread, and in others like it I've seen, makes it clear
that many intelligent people simply do not understand the LGPL. Under the
circumstances I am suspicious of (a) my own understanding, (b) the
understanding of any other programmer or non-legal expert.

Dynamic linking makes
this requirement easy as the end user can simply load the new dynamic
library. But static linking doesn't comtaminate anything. You can in fact
offer the end user a compiled object to link in, never showing the end
user your code. But relinking is a requirement for you as a developer to
use the library.

You see ? I hadn't read that into the license. Unless and until it is
rephrased in a way that makes it plain /in a technology independent way/ what
constitutes linking, then I shall continue to treat it with suspicion. It's
worth mentioning that quite a few libraries I've been looking at recently have
come with a license that is the LGPL plus some explicit riders to make it clear
that (say) static linking is allowed.

And it's important that the wording is technology independent. I mostly work
in Smalltalk and Java these days, and while there are certainly some cases
where a use of some code is clearly dynamic linking under the terms of the
LGPL, there are other cases that are less clear. This particularly applies to
software that is not written in a DLL-ish language (such as C -- and neither
Smalltalk or Java are DLL-ish), but also can apply to 'C'. E.g. I was looking
at one library, LGPLed, that is coded only to support static linking. So I can
write a DLL that uses that library, and then call that from Smalltalk, that's
not a problem technically, but I simply don't know to what extent the DLL is
now covered by the LGPL. I don't greatly mind if it is (my stuff is free, as
in beer, anyway) but I don't the hassle of, say, finding that I have to
distribute the source to the original library (not least because I don't like
becoming a secondary source of potentially out-of-date information).

-- chris

 

[P.T. Breuer]

You see ? I hadn't read that into the license. Unless and until it is
rephrased in a way that makes it plain /in a technology independent way/ what
constitutes linking, then I shall continue to treat it with suspicion. It's

Why? Linking is one of the oldest and best defined concepts in computer
science. It's the pass in which symbolic references in the code are
replaced by addresses.

"Dynamic" vs "static" tells you when this pass is done. At run time or
compile time, respectively. Or shades between and beyond.

worth mentioning that quite a few libraries I've been looking at recently have
come with a license that is the LGPL plus some explicit riders to make it clear
that (say) static linking is allowed.

I've never read the LGPL, but my understanding is that it explicitly
allows receivers to use the code as a library (that is, link it in,
however they like) withot contaminating their product. That's its
intention, no? As far as I recall the reasons for creating the LGPL, it
was to ENABLE authors to distribute libraries under free-software terms
without running afoul of the legal problem that linking is legally seen
as making a combined work, a dervative, which would contaminate the
product under the GPL. The LGPL is like the GPL but it explicitly
disavows the legal theory that linking produces a combined work. Thus
it enables authors to distribute free-software libraries.

Hmm .. reading the LGPL now, it looks like my understanding is correct.
The LGPL promises to allow the secondary users of the product to fix the
LGPL libraries contained in them, which is the idea behind free
software - that the users should be empowered. I'll have to read on to
see the legal mechanism they created.


Peter

 

[Chris Uppal]

Why? Linking is one of the oldest and best defined concepts in computer
science. It's the pass in which symbolic references in the code are
replaced by addresses.

Because that notion of "linking" is /not/ how most interesting or useful
languages work these days. Ok, I'm overstating that a bit (there is still
/some/ use for C/C++ ;-) but I want to make the point clear.

I've never read the LGPL,

Yet you sound confident that your understanding of it is correct in law ?

but my understanding is that it explicitly
allows receivers to use the code as a library (that is, link it in,
however they like) withot contaminating their product.

Fair enough. I'll have to try read it for the Nth time, to see what I've
missed. /That/ is the main problem. It's a legal document, but it is not
clear (to me) what it means.

Under the circumstances there is no way whatsoever that I'll put any of my
stuff out under the LPGP (and the GPL would be completely inappropriate). And
I'm suspicious of any other LGPLed software.

In practise I've been treating as: if the software is in a DLL then it clearly
OK to use it, if not then you have to take a very fine reading of the LGPL to
permit it (assuming you don't want to LGPL your own stuff). That may be a bad
approximation, I'll go back and review it in the light of this thread. But my
current understanding is that there is no way at all that I can use, say,
LPGP-ed Smalltalk libraries. And that's why I won't even consider LGPL-ing my
own stuff since, even if the above approximation is wrong, I don't want to risk
any user being put off my stuff by the same [mis]reading of the license.

That's its intention, no?

How should I know ? And /who's/ intent ? The GNU people ? The author/owner
of the particular code that has been issued under LGPL ? And anyway, I don't
think /intent/ counts for all that much in a legal agreement (though it does
/also/ matter to me -- I wouldn't want to "cheat" an author even if was OK in
the letter of the law).

As far as I recall the reasons for creating the LGPL, it
was to ENABLE authors to distribute libraries under free-software terms
without running afoul of the legal problem [..]

That's my understanding too. But the range of ways in which bits of software
can be hooked together (such that I'd expect/hope the author didn't want them
to be considered to be "combined" for these purposes) is larger than that
provided by what a techie would call "linking".

-- chris

 

[P.T. Breuer]

Because that notion of "linking" is /not/ how most interesting or useful
languages work these days. Ok, I'm overstating that a bit (there is still

I don't know of any other use for the term. What can you be thinking
of? (yes, I am a language designer and author). The alterative is to
run an interpreter at some level, instead of linking the machine code
or some other level of code.

Yet you sound confident that your understanding of it is correct in law ?

I am as confident as a person can be who has never bothered to read the
LGPL because of his confidence in all the lawyering that went into it,
and his confidence in the aims of its creators.

Fair enough. I'll have to try read it for the Nth time, to see what I've

I was able to scan it in about 5 mins after I wrote my message, and it
did not seem at all difficult or strange to me.

missed. /That/ is the main problem. It's a legal document, but it is not
clear (to me) what it means.

It says explicitly what it means! I don't see your problem. I read what
it meant to mean in the intro blurb - don't make me quote it!

Under the circumstances there is no way whatsoever that I'll put any of my
stuff out under the LPGP (and the GPL would be completely inappropriate). And
I'm suspicious of any other LGPLed software.

The LGPL is quite explicit about what it does. It binds the receiver of
the library to allow the receiver of a linked work from him access to
the library code and the capability to relink it, but does not
contaminate the whole product with the same licence. I quote:

6. As an exception to the Sections above, you may also compile 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.

In other words, "do what you like except prohibiting people from
reverse engineering and debugging and improving to taste". In other
words still, "free software".

In practise I've been treating as: if the software is in a DLL then it clearly
OK to use it, if not then you have to take a very fine reading of the LGPL to

What? Why a DLL? The LGPL refers to "libraries", not "dynamically
linked libraries". That qualification is all your own invention and I
do not know where you got it from. If you want to see explicitly:

... linking a "work that uses the Library" with the Library creates an
executable that is a derivative of the Library (because it contains
portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 [which I quoted above] states terms for distribution of
such executables.

It's quite irrelevant if it's a DLL or something liked in statically or
something TO BE linked in statically. It's still linked in, and that
has a precise and unambiguous meaning.

permit it (assuming you don't want to LGPL your own stuff).

I don't get you. The LGPL specifically says that it allows you to
distribute a linked in work "under terms of your choice" (provided that
they are not onerous in that they prohibit reverse engineering or some
like thing).

That's its whole intent - to allow "linking in" to be regarded as
"using", and thus let you escape the legal trap of having created a
derived work. The LGPL specifically gives you permission to distribute
the derived work under your own terms, provided those terms do not
impinge on peoples rights to "free software" vis a vis the library
under LGPL. Under section 6, the licence goes on to specify what you
must do in order to maintain peoples rights to the library. It's very
explicit. I don't see your problem with the understanding of it:


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 ... [and provide
the OBJECT code of yours that is linked with the library
so that people can relink it with a different library if they
like]

[or] b) Accompany the work with a written offer, valid for at least
three years, to give the same user the materials specified in
[a)] ...

[or] c) ... offer ... access to copy the above specified materials ...

[or] d) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.

So - in summary, you must make available the object code that you
linked with the library in order to create your derived work, provide
access to the source code of the library, and then you can distribute
the whole under whatever terms you like, provided that you don't
violate the forgoing and don't prohibit people from the act of reverse
engineering or debugging.

Seems completely straightforward to me.

How should I know ?

Because it says so, and it's clear about it.

And /who's/ intent ?

The creators.

T> he GNU people ?

Yes.

The author/owner
of the particular code that has been issued under LGPL ?

Of course.

And anyway, I don't
think /intent/ counts for all that much in a legal agreement (though it does

It's a contract, so intent IS what counts.

As far as I recall the reasons for creating the LGPL, it
was to ENABLE authors to distribute libraries under free-software terms
without running afoul of the legal problem [..]

That's my understanding too. But the range of ways in which bits of software
can be hooked together (such that I'd expect/hope the author didn't want them
to be considered to be "combined" for these purposes) is larger than that
provided by what a techie would call "linking".

You either link or you interpret, or you arrange for a proxy to do it
for you, and talk to the proxy through a communication mechanism. There
is no other possibility. And the LGPL only gives you an out for
linking, since linking is the only thing apart from authoring that
creates a combiend work under law. Anything else is just "using" your
thing. You don't become derived from a teacup when you use a teacup, do
you?


Peter

 

[xarax]

/snip bullshit/

I've read the LGPL. You should read it again. Static
linking makes your code a derivative of the library.

What I wrote is true. It is not FUD. So STFU.

 

[Jose Maria Lopez Hernandez]

HI
I have read GNU GPL , Common public licence and gnu lesser license.
As my understanding, i can including those softwares which is(
GNU GPL , Common public licence and gnu lesser license) into my
commerical product. And i am free to distribute it and modify it.

Am i correct?

thanks for your help
from Peter ([email protected])

If you use GPL code or link with GPL libraries you CAN'T distribute
your software as a commercial product. You are obligated to distribute
it under the GPL. You can link your commercial product with LGPL
libraries. And I don't know the Common Public License so I can give
you any advice.


--

Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
(e-mail address removed)
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
-- Jack Kerouac, "On the Road"

 

[Floyd L. Davidson]

It's a contract, so intent IS what counts.

One small correction to Peter's excellent commentary: the GPL
(and the LGPL too) constitutes a *license*, not a contract.

The difference is that two parties agree to a contract, and the
intent of each counts; but only one party offers a license while
the other either agrees or is not licensed, hence only the
intent of the licensee is what counts.

 

[P.T. Breuer]

/snip bullshit/

I've read the LGPL. You should read it again. Static
linking makes your code a derivative of the library.

This is correct. So does any linking. Those are legal facts. What the
LGPL does is allow you to distribute such a derived work (and I quote)
"under terms of your choice" [provided only that you allow reverse
engineering and debugging and relinking and access to the source code
of the Library, to summarize your obligations].

What I wrote is true. It is not FUD. So STFU.

What did you write? It sounds a lot like it might have been FUD or SaN.

Peter

 

[Chris Smith]

But be VERY CERTAIN that your usage of the LGPL library
is only via dynamic calls. Static linking will contaminate
your product and make it also LGPL.

GNU licenses (all variants) are extremely viral; attempting
to convert your hard work into effectively public domain.

I can only speak to the traditional interpretation since I am not a
lawyer. Courts may always interpret things differently. However, the
way these licenses were initially supposed to work is a bit different
from what you say. Specifically, your comments about the LGPL actually
apply to the GPL, and the LGPL is more permissive.

The problem with linking in the GPL is that parts of the library are
actually included into the resulting binary by the compiler or linker.
In traditional C environments, the concern is mainly about stuff defined
in header files and about function names from the library, as well as
the code itself in case of static linking. In Java (since this was
posted to comp.lang.java.programmer) the concern could be raised with
regard to identifier names being taken from the library, and also the
inclusion of constant values from public compile-time constant fields of
library classes. Because it's unclear whether this causes the
application to become a derived work, the LGPL was introduced
specifically to disclaim any responsibility on your part of complying
with GPL terms for application code merely because of linking and header
files.

Arguably, even a GPL library allows certain forms of dynamic linking
from a non-GPL work. These days, though the intent of the author is
pretty clear when that author chooses to use the GPL for a library, and
it's at best exploitation to disrespect those wishes, and at worst a
violation of the license. It's interesting to note that about ten years
ago, that wasn't the case, and the general consensus among free software
developers was still that linking did not cause an application to become
a derived work; the LGPL was introduced only to make people more
comfortable using a library. That has changed not because of a change
in the text of the license, but because the surrounding politics are
different... now we have MySQL, Eric Raymond, and a surrounding crowd of
people who want to believe that the GPL allows them certain openings for
profit, and their wishes have changed the consensus opinion. It's up to
courts and lawyers whether the old or new view is correct.

Some unfortunate gray areas still arise, though, even when you try to
respect an author's wishes. One example: I've discussed, with MySQL and
an attorney, what would happen if an application -- written using the
generic JDBC API -- were to end up deployed with MySQL's GPLed JDBC
drivers. MySQL chose to leave me with the impression that they would
sue anyone writing JDBC code if their profits looked short some quarter
(almost reminds me of DirectTV); but the attorney was fairly certain
that a product can't become a derivative work because of the way it's
used by an end-user. Again, it's up to you to make an interpretation
with the help of an attorney.

I would suggest looking at other license models that
are less socialistic in nature.

Not necessarily. Play it safe, certainly, and don't push the license to
the extremes, but an LGPL library specifically allows the use that's
wanted here. It's probably pretty safe to use it that way. After all,
it takes an upset author to sue over use of code.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[John Thompson]

["Followup-To:" header set to comp.os.linux.misc.]

That may not be your intent, but it is the intent of [L]GPL.

No, the intent is that if you have benefited from (L)GPL code, you are
expected to share your derivative code with the community, who in turn are
expected to share their modifications as well. It is not "public domain"
because your code remains your code, and anyone who uses it in violation
of the license terms is Asking for Trouble.

If you choose wrong, then your work, that you never
intended to give away to the public, is given away
to the public.

So choose carefully. Don't blame the (L)GPL if *YOU* didn't do your
homework.

 

[Tor Iver Wilhelmsen]

If you use GPL code or link with GPL libraries you CAN'T distribute
your software as a commercial product.

If you mean "charge money for it", then yes, you can. However, you
need to supply source, and cannot prevent the person receiving it
giving it away after you sell that one copy.

 

[Malcolm Dew-Jones]

Tor Iver Wilhelmsen ([email protected]) wrote:

: > If you use GPL code or link with GPL libraries you CAN'T distribute
: > your software as a commercial product.

: If you mean "charge money for it", then yes, you can. However, you
: need to supply source, and cannot prevent the person receiving it
: giving it away after you sell that one copy.

This is true, and (as I understand it) is in fact why many small
developers provide "commercial" code as GPL.

A developer sells the code they develop to the customer, but with a gpl
license.

The customer can be pursuaded to like this because it protects them in the
sense that they know have everything they will ever need, no matter what
happens to the developer.

The developer is also protected, though this might not be quite so
obvious.

First, The customer will not be able to prevent the developer from using
the code the they just developed.

Second, if the customer does not sell the code then they will not be
competing with the developer anyway, so the gpl makes no difference.
This is most likely since the customer has little to gain from trying to
sell the code.

But even if the customer does sell the code then the developer is at least
the authority on the product and will be free to sell related development
services to the [original] customer's customers, and the developer will
likely gain access to any improvements the [original] customer made.

You may wish to clarify what it means to "distribute" the code if you go
this route. The customer will be happiest if your license specifies the
types of use and copying that would be considered "internal" to their
business. So, for example, you would allow the customer to provide copies
to maintenance programmers who work for the customer, and to deploy the
software on the customer's servers, and etc, without those being
considered "distributions" of the code.

If the original code included existing gpl code then of course you might
not be able to "clarify" what it means to dstribute the code, but if you
write the code from scratch then you certainly can.