Archbold, David W. schrieb am 22 Feb 2000:
'Course you don’t want to rely on someone telling you that you screwed up,
but it is nice to know that people ask questions first then shoot (well,
most of the time
You obviously don’t know slashdot 
This is the best way to do it, but it doesn’t have to be on that CD-ROM.
You can provide it to them in another form, but it has to come from you.
Not someone elses webpage.
if space is tight on the CD,why not put SDL’s source on a floppy ??
Alain
— hayward at slothmud.org wrote:
From Section 6 of the LGPL (last two paragraphs of section 6).
stuff snipped***
Just be careful and read the licenses closely yourself. As Sam said,
don’t trust what we all say on this list, you have to understand it
yourself. Even if we sound like we know what we’re talking about…
–
Brian Hayward
Your touching on the difference between dynamicaly linked and
staticly linked libraries. My interpretation of it (and I had to
re-read the lgpl again to make sure)
http://www.gnu.org/copyleft/lgpl.html
Case 1:
MyProg.c -> MyProg.exe (stuff I wrote)
MyLibrary.c -> MyLibrary.dll (more stuff I wrote)
SomeoneElses.c -> SomeoneElses.dll (under lgpl)
-MyProg.exe uses both MyLibrary.dll and SomeoneElses.dll (you could
say they are linked)
Case 2:
MyProg.c + MyLibrary.c + SomeoneElses.c -> MyProg.exe
MyProg.exe contains MyLibrary.dll & SomeoneElses.dll
-Myprog.exe uses both Mylibrary.dll and SomeoneElses.dll (also
linked)
The difference being, in case (1) the lgpl is applied to
SomeoneElses.dll/c only. In case (2) the lgpl infects MyProg.exe and
MyLibrary.dll thus making them under the lgpl as well. Care has to be
taken when describing ‘linked-in’ (internal linking) vs
‘linked-against’ (external linking)
Even though I’m not a legal lawyer myself I can reassure you that
(case 1) is perfectly valid and correct. I even at one time wrote up a
little article on why (case 1) cannot legaly make (MyProg.exe) lgpl by
that exact application.=====
Jason Platt.
“In theory: theory and practice are the same.
In practice: they arn’t.”
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
Archbold, David W. schrieb am 22 Feb 2000:
'Course you don’t want to rely on someone telling you that you screwed up,
but it is nice to know that people ask questions first then shoot (well,
most of the timeYou obviously don’t know slashdot
Well, thats a different story. Typically the people who write the code
and own the copyright are more patient and try to correct the problem
rather than shooting first.
I won’t comment on the non-patient, quick to jump on your case masses of
linux enthusiasts. It’s sad… very sad. They harm more than they help
in many cases.–
Brian
Your touching on the difference between dynamicaly linked and
staticly linked libraries. My interpretation of it (and I had to
re-read the lgpl again to make sure)
http://www.gnu.org/copyleft/lgpl.html
Yup. You’re right here… sorry if I wasn’t clear enough in my letter.–
Brian
Archbold, David W. schrieb am 22 Feb 2000:
'Course you don’t want to rely on someone telling you that you screwed
up,but it is nice to know that people ask questions first then shoot
(well,most of the time
You obviously don’t know slashdot
Oh yes I do (actually, I’m moderating over there as I type this), and I was
waiting for someone to say that
My belief is that the majority of the noisemakers on slashdot are a minority
in the community as a whole. At least I hope that’s the case! I still
think that the majority of the community would be polite enough to say “You
realize that you are in violation of the (L)GPL. You can get around that by
doing blah, blah”.
cheers,
Dave “PenguinDude” ArchboldOn Tuesday, February 22, 2000 4:42 PM, Andreas Umbach [SMTP:marvin at dataway.ch] wrote:
— hayward at slothmud.org wrote:
Your touching on the difference between dynamicaly linked and
staticly linked libraries. My interpretation of it (and I had to
re-read the lgpl again to make sure)
http://www.gnu.org/copyleft/lgpl.htmlYup. You’re right here… sorry if I wasn’t clear enough in my
letter.Brian
No worries, I’ve over the last while gained quite a bit of experince
on figuring out the gpl and lgpl along with forking licences it gets
really complicated quickly. Also being that there are vague terms used
in computer science which can have different meanings based on what
they apply to doesn’t help much either.=====
Jason Platt.
“In theory: theory and practice are the same.
In practice: they arn’t.”
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
Sam Lantinga wrote:
From Section 6 of the LGPL (last two paragraphs of section 6).
If you have a proprietary library that allows distribution of it as a
runtime but not as a development library, you cannot link an LGPL library
and the proprietary library with your program to create an executable.For example, commercial versions of Motif provide you with a development
library and say you can distribute static or dynamic executables, but you
cannot distribute the library itself.You cannot link an application with a LGPL library as well as this
commercial library and distribute it, because you aren’t allowed to give
them everything they need to recreate the executable.I don’t know about the legal ramifications of this, but one way I would
look at to get around this would be to link all of your code and proprietary
libraries into a single giant object file and distribute that.Like I said, I’m not sure the legal ramifications of this.
| Rafael R. Sevilla @Rafael_R_Sevilla |
| Instrumentation, Robotics, and Control Laboratory |
| College of Engineering, University of the Philippines, Diliman |
|---|
I like to help interpret licenses, so here we go.
hayward at slothmud.org wrote in message …
From Section 6 of the LGPL (last two paragraphs of section 6).
I just read through that.
If you have a proprietary library that allows distribution of it as a
runtime but not as a development library, you cannot link an LGPL library
and the proprietary library with your program to create an executable.
You can, but if you do you must provide it to the end user for linking (as
binary or source).
The section says that this might conflict with a proprietary licensed
library if it doesn’t allow free redistribution.
If the library in question is allowed to be redistributed, then we have no
problem.
For example, commercial versions of Motif provide you with a development
library and say you can distribute static or dynamic executables, but you
cannot distribute the library itself.
Right.
You cannot link an application with a LGPL library as well as this
commercial library and distribute it, because you aren’t allowed to give
them everything they need to recreate the executable.
If the license doesn’t allow the library to be redistributed, yes.
The GPL was created to protect free software (as in freedom, not free beer).
The LGPL was created to rectify this obvious mistake. Then RMS had another
change of heart and decided to change the name from “Library” to “Lesser” in
order to disuade its use.
In any case, it’s not meant to harm commercial companys as Sam pointed out.
Instead, it is designed to be anti-proprietary, the side effect of hurting
commercial
interest was, of course, just a fluke. 
The LGPL says you must provide them with all libraries needed to create
the executable again. They did make an exception for libc, gcc, or
anything commonly shipped with the OS that the application is distributed
to run on.
Right, which allows porting.
Boy… I must say, that LGPL has some good points in it, but overall it’s
sortof a mess. It’s really easy even if you read it a couple times to
miss something and be in violation of it when you don’t intend to do so.
It’s already happened to companies before too.
Which is why you have a lawyer read it.
Just be careful and read the licenses closely yourself. As Sam said,
don’t trust what we all say on this list, you have to understand it
yourself. Even if we sound like we know what we’re talking about…
…I’m a little teacup short and stout, here is my handle, here is my
spout…
Sincerely,
Nelson Rush
I like to analyze licenses, so here we go.
hayward at slothmud.org wrote in message …
From Section 6 of the LGPL (last two paragraphs of section 6).
Okay, I read it.
If you have a proprietary library that allows distribution of it as a
runtime but not as a development library, you cannot link an LGPL library
and the proprietary library with your program to create an executable.
You can distribute it as long as the license allows free redistribution.
Proprietary licenses sometimes allow redistribution, but only of the binary.
For example, commercial versions of Motif provide you with a development
library and say you can distribute static or dynamic executables, but you
cannot distribute the library itself.
Yup.
You cannot link an application with a LGPL library as well as this
commercial library and distribute it, because you aren’t allowed to give
them everything they need to recreate the executable.
GPL isn’t anti-commercial, it’s anti-proprietary. The LGPL was created
because RMS came to his senses and said, “Hey, now see here, this ‘share the
code’ idea is silly.” And later, he renamed it “Lesser”, out of guilt.
The LGPL says you must provide them with all libraries needed to create
the executable again. They did make an exception for libc, gcc, or
anything commonly shipped with the OS that the application is distributed
to run on.
Right, that helps porting.
Boy… I must say, that LGPL has some good points in it, but overall it’s
sortof a mess. It’s really easy even if you read it a couple times to
miss something and be in violation of it when you don’t intend to do so.
It’s already happened to companies before too.
Which is why you have a lawyer read it to you.
Just be careful and read the licenses closely yourself. As Sam said,
don’t trust what we all say on this list, you have to understand it
yourself. Even if we sound like we know what we’re talking about…
…I’m a little tea pot short and stout, here is my handle, here is my
spout…
Sincerely,
Nelson Rush
I like to analyze licenses, so here we go.
hayward at slothmud.org wrote in message …
From Section 6 of the LGPL (last two paragraphs of section 6).
Okay, I read it.
If you have a proprietary library that allows distribution of it as a
runtime but not as a development library, you cannot link an LGPL library
and the proprietary library with your program to create an executable.
You can distribute it as long as the license allows free redistribution.
Proprietary licenses sometimes allow redistribution, but only of the binary.
For example, commercial versions of Motif provide you with a development
library and say you can distribute static or dynamic executables, but you
cannot distribute the library itself.
Yup.
You cannot link an application with a LGPL library as well as this
commercial library and distribute it, because you aren’t allowed to give
them everything they need to recreate the executable.
GPL isn’t anti-commercial, it’s anti-proprietary. The LGPL was created
because RMS came to his senses and said, “Hey, now see here, this ‘share the
code’ idea is silly.” And later, he renamed it “Lesser”, out of guilt.
The LGPL says you must provide them with all libraries needed to create
the executable again. They did make an exception for libc, gcc, or
anything commonly shipped with the OS that the application is distributed
to run on.
Right, that helps porting.
Boy… I must say, that LGPL has some good points in it, but overall it’s
sortof a mess. It’s really easy even if you read it a couple times to
miss something and be in violation of it when you don’t intend to do so.
It’s already happened to companies before too.
Which is why you have a lawyer read it to you.
Just be careful and read the licenses closely yourself. As Sam said,
don’t trust what we all say on this list, you have to understand it
yourself. Even if we sound like we know what we’re talking about…
…I’m a little tea pot short and stout, here is my handle, here is my
spout…
Sincerely,
Nelson Rush
Sorry for the double post, I thought the message was >/dev/null
