From: <rei...@te...> - 2001-05-12 23:19:21
|
On Sat, 12 May 2001, Philip Bock wrote: >=20 > I've been using the latest release of mingw, downloaded from sourceforg= e as > per the "download" page on the site. I've noticed that all c++ executab= les > produced by this version require the libstdc++.dll. Now, I'm not certai= n, > but I beleive that the stable release available from Mumit Khan's ftp > directory does not exhitbit this behavior. Is this someting new? And wh= at are > the licensing reqirements for this DLL? There are several therads in this list concerning the libstdc++.dll in th= e newest release. Please look to the archives: http://www.geocrawler.com/lists/3/SourceForge/6013/0/ Regards, Reinhard --=20 Ing. Reinhard Jessich mailto: rei...@te... A-1190 Vienna, Goergengasse 2/2/1 phone: +43/1/3692600 http://members.telering.at/jessich mobile: +43/664/1735439 |
From: Paul G. <pga...@qw...> - 2001-05-12 23:40:20
|
Hi folks, On 12 May 2001, at 11:51, the Illustrious Philip Bock wrote: > I've been using the latest release of mingw, downloaded from sourceforge > as per the "download" page on the site. I've noticed that all c++ > executables produced by this version require the libstdc++.dll. Yes, sometimes in the last six months we agreed that libstdc++.dll is the preferred method with the msvcrt.dll stuff. Static lib references are being deprecated. > Now, I'm > not certain, but I beleive that the stable release available from Mumit > Khan's ftp directory does not exhitbit this behavior. Is this someting > new? And what are the licensing reqirements for this DLL? Afaik, this latest is lgpl, but I am not sure. Will leave the answering of that question up to others. Peace, Paul G. > Nothing real can be threatened. Nothing unreal exists. |
From: Paul G. <pga...@qw...> - 2001-05-15 21:41:51
|
On 14 May 2001, at 11:51, the Illustrious Earnie Boyd wrote: > Danny Smith wrote: > > > > --- Philip Bock <ph...@es...> wrote: > Okay. I've read through > > the LGPL myself. If I understand correctly, just > > > providing a link isn't enough. I need to provide the source for the > > > DLL. Unfortunately, the closest I seem to be able to get on > > > sourceforge is a diff to gcc-2.95.2-3. I could get the gcc-2.95.2 > > > sources and apply this patch, but I really don't think I'd be able > > > to find the source for that particular dll in among the rest. Is > > > there anyone else who intends to let other people use programs they > > > compiled with mingw? How do other people deal with this? > > > > > > > The easiest option is to build programmes that link against static > > libstdc++.a, etc, rather than dll's. IMHO that should be the > > default. > > > > I agree with Danny. For MinGW we need to default to using static > versions of the LGPL'ed libraries. For my own, very specific and rather lengthy reasons, I have been trying to deprecate using the .dll release of libstdc++.a, to no avail. As it stands I agree with Danny and Earnie. Default should have always been static, imho, with .dll as option for as long as no licensing problems or questions came up. Now that questions have come up re: licensing, it seems only appropriate and "right" to set libstdc++ to be linked statically instead of dynamically. In terms of what Earnie mentioned re: binutils. I have always assumed we need to have the source available for for the SF (Mingw) site. The impression I originally had re: binutils was that because the source was available via Gnu site, you could modify it as you see fit for as long as you included all of the source code and observed the GPL. Paul G. > > -- > Earnie. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users > Systems Software Developer NewDawn Productions http://www.teleport.com/~pgarceau/newdawn/ |
From: Franco B. <fra...@we...> - 2001-05-16 04:34:51
|
Hi all, I don't understand all that fuzz. Why do You all think that with linking statically to libstdc++, you could= =20 avoid licensing-problems ? Also, You do not have to diatribute the source of libstdc++.dll with ever= y=20 program that uses it - it's enough that evereyone can get the source to a= ll=20 the mingw-toolchain (that includes the source to libstdc++). If the sourc= e is=20 available "in well known public places" there is no problem with GPL / LG= PL=20 at all. The licensing problem is that linking to GPL software makes a "derived=20 Project" that MUST be GPL as well, linking to LGPL Software does not FORC= E=20 You to use GPL/LGPL for your Software. Ciao, Franco |
From: Christof P. <chr...@pe...> - 2001-05-16 09:27:16
|
Franco Bez wrote: > Hi all, > > I don't understand all that fuzz. > > Why do You all think that with linking statically to libstdc++, you could > avoid licensing-problems ? IIRC statically linking with a LGPL library imposes really hard obligations on everybody distributing programs linked to it. You have to enable your users to relink your program themselves ! So you have to provide object files, linking scripts etc. So using .dlls should be the way to go. At least this is the common reading of LGPL. [RMS on the other hand does not like to encourage anybody to withhold the source code. So he tries to undermine the common reading IMHO.] So if you link to a .dll the user is free to replace the .dll by a future/customized version. Which is the restriction the LGPL mentions. But I'm no lawyer. And personally I prefer GPL over LGPL unless you want to make your library as public as possible. Christof Quoting the LGPL: 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. |
From: Earnie B. <ear...@ya...> - 2001-05-16 12:36:22
|
Franco Bez wrote: > > Hi all, > > I don't understand all that fuzz. > > Why do You all think that with linking statically to libstdc++, you could > avoid licensing-problems ? > Not trying to avoid any such problems. I'm trying to avoid having to distribute a binary named libstdc++.dll in everyone's distributions and forcing everyone doing so to have to also distribute the source or maintain revisions of the source so that if someone asks for the source I can give him that particular version. MinGW itself was started to avoid having such dependencies. I don't want to add them now. > Also, You do not have to diatribute the source of libstdc++.dll with every > program that uses it You must distribute it with every distribution or promise to do so for up to three years. If you have a net distribution you also distribute the source as well as the binary in order to avoid having to maintain a three year history of sources. > - it's enough that evereyone can get the source to all > the mingw-toolchain (that includes the source to libstdc++). If the source is > available "in well known public places" there is no problem with GPL / LGPL > at all. > You need to reread the GPL. The GPL states that *you* (the distributor of the binary) is responsible for the distribution of the source. *You* cannot rely on someone else's net distribution to cover *your* legal obligation. -- Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: David L. <le...@cs...> - 2001-05-16 12:48:12
|
Christof Petig writes: > Franco Bez wrote: > > > Hi all, > > > > I don't understand all that fuzz. > > > > Why do You all think that with linking statically to libstdc++, you could > > avoid licensing-problems ? > > IIRC statically linking with a LGPL library imposes really hard > obligations on > everybody distributing programs linked to it. You have to enable your > users to > relink your program themselves ! So you have to provide object files, > linking > scripts etc. Some of the source code files in the gcc libstdc++ and other directories contain this helpful clause: // As a special exception, if you link this library with files // compiled with a GNU compiler to produce an executable, this does not cause // the resulting executable to be covered by the GNU General Public License. // This exception does not however invalidate any other reasons why // the executable file might be covered by the GNU General Public License. David |
From: <dan...@ya...> - 2001-05-13 00:46:03
|
--- rei...@te... wrote: > On Sat, 12 May 2001, Philip Bock wrote: > > > > I've been using the latest release of mingw, downloaded from sourceforge as > > per the "download" page on the site. I've noticed that all c++ executables > > produced by this version require the libstdc++.dll. Now, I'm not certain, > > but I beleive that the stable release available from Mumit Khan's ftp > > directory does not exhitbit this behavior. Is this someting new? And what > are > > the licensing reqirements for this DLL? > There are several therads in this list concerning the libstdc++.dll in the > newest release. Please look to the archives: > http://www.geocrawler.com/lists/3/SourceForge/6013/0/ > I wasn't quite satisfied with the answer that came out of that thread. I still believe that if you distribute libstdc++.dll (an executable derived from GPLed source), you are obligated to provide the [modified] source, or at least access to the source, of libstdc++ with the distribution. This includes any modification to the libstdc++ source (eg declspec macros) and the script used to build the dll. Ditto for libgcc.dll. Ditto for libbfd.dll. Copyright is a liability issue. It is the user's responsibility to be fully aware of the meaning of the license and to comply. This, of course, is not a legal opinion. Such an opinion would be more than welcome. Danny _____________________________________________________________________________ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! |
From: Philip B. <ph...@es...> - 2001-05-13 04:19:48
|
So, then, would it be enought to let people know they can get the source for the DLL at www.mingw.org, or should I be more specific? ----- Original Message ----- From: "Danny Smith" <dan...@ya...> To: <min...@li...> Sent: Saturday, May 12, 2001 7:46 PM Subject: Re: [Mingw-users] libstdc++.dll > > --- rei...@te... wrote: > On Sat, 12 May 2001, Philip Bock > wrote: > > > > > > I've been using the latest release of mingw, downloaded from sourceforge as > > > per the "download" page on the site. I've noticed that all c++ executables > > > produced by this version require the libstdc++.dll. Now, I'm not certain, > > > but I beleive that the stable release available from Mumit Khan's ftp > > > directory does not exhitbit this behavior. Is this someting new? And what > > are > > > the licensing reqirements for this DLL? > > There are several therads in this list concerning the libstdc++.dll in the > > newest release. Please look to the archives: > > http://www.geocrawler.com/lists/3/SourceForge/6013/0/ > > > > > I wasn't quite satisfied with the answer that came out of that thread. I still > believe that if you distribute libstdc++.dll (an executable derived from GPLed > source), you are obligated to provide the [modified] source, or at least access > to the source, of libstdc++ with the distribution. This includes any > modification to the libstdc++ source (eg declspec macros) and the script used > to build the dll. > > Ditto for libgcc.dll. Ditto for libbfd.dll. > > Copyright is a liability issue. It is the user's responsibility to be fully > aware of the meaning of the license and to comply. > > This, of course, is not a legal opinion. Such an opinion would be more than > welcome. > > > Danny > > > > ____________________________________________________________________________ _ > http://messenger.yahoo.com.au - Yahoo! Messenger > - Voice chat, mail alerts, stock quotes and favourite news and lots more! > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Philip B. <ph...@es...> - 2001-05-14 05:41:28
|
Okay. I've read through the LGPL myself. If I understand correctly, just providing a link isn't enough. I need to provide the source for the DLL. Unfortunately, the closest I seem to be able to get on sourceforge is a diff to gcc-2.95.2-3. I could get the gcc-2.95.2 sources and apply this patch, but I really don't think I'd be able to find the source for that particular dll in among the rest. Is there anyone else who intends to let other people use programs they compiled with mingw? How do other people deal with this? ----- Original Message ----- From: "Philip Bock" <ph...@es...> To: "Danny Smith" <dan...@ya...>; <min...@li...> Sent: Saturday, May 12, 2001 11:18 PM Subject: Re: [Mingw-users] libstdc++.dll > So, then, would it be enought to let people know they can get the source for > the DLL at www.mingw.org, or should I be more specific? > > ----- Original Message ----- > From: "Danny Smith" <dan...@ya...> > To: <min...@li...> > Sent: Saturday, May 12, 2001 7:46 PM > Subject: Re: [Mingw-users] libstdc++.dll > > > > > > --- rei...@te... wrote: > On Sat, 12 May 2001, Philip Bock > > wrote: > > > > > > > > I've been using the latest release of mingw, downloaded from > sourceforge as > > > > per the "download" page on the site. I've noticed that all c++ > executables > > > > produced by this version require the libstdc++.dll. Now, I'm not > certain, > > > > but I beleive that the stable release available from Mumit Khan's ftp > > > > directory does not exhitbit this behavior. Is this someting new? And > what > > > are > > > > the licensing reqirements for this DLL? > > > There are several therads in this list concerning the libstdc++.dll in > the > > > newest release. Please look to the archives: > > > http://www.geocrawler.com/lists/3/SourceForge/6013/0/ > > > > > > > > > I wasn't quite satisfied with the answer that came out of that thread. I > still > > believe that if you distribute libstdc++.dll (an executable derived from > GPLed > > source), you are obligated to provide the [modified] source, or at least > access > > to the source, of libstdc++ with the distribution. This includes any > > modification to the libstdc++ source (eg declspec macros) and the script > used > > to build the dll. > > > > Ditto for libgcc.dll. Ditto for libbfd.dll. > > > > Copyright is a liability issue. It is the user's responsibility to be > fully > > aware of the meaning of the license and to comply. > > > > This, of course, is not a legal opinion. Such an opinion would be more > than > > welcome. > > > > > > Danny > > > > > > > > > ____________________________________________________________________________ > _ > > http://messenger.yahoo.com.au - Yahoo! Messenger > > - Voice chat, mail alerts, stock quotes and favourite news and lots more! > > > > _______________________________________________ > > MinGW-users mailing list > > Min...@li... > > > > You may change your MinGW Account Options at: > > http://lists.sourceforge.net/lists/listinfo/mingw-users > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users |
From: <dan...@ya...> - 2001-05-14 06:54:57
|
--- Philip Bock <ph...@es...> wrote: > Okay. I've read through the LGPL myself. If I understand correctly, just > providing a link isn't enough. I need to provide the source for the DLL. > Unfortunately, the closest I seem to be able to get on sourceforge is a diff > to gcc-2.95.2-3. I could get the gcc-2.95.2 sources and apply this patch, > but I really don't think I'd be able to find the source for that particular > dll in among the rest. Is there anyone else who intends to let other people > use programs they compiled with mingw? How do other people deal with this? > The easiest option is to build programmes that link against static libstdc++.a, etc, rather than dll's. IMHO that should be the default. Danny _____________________________________________________________________________ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! |
From: Earnie B. <ear...@ya...> - 2001-05-14 15:52:23
|
Danny Smith wrote: > > --- Philip Bock <ph...@es...> wrote: > Okay. I've read through the LGPL > myself. If I understand correctly, just > > providing a link isn't enough. I need to provide the source for the DLL. > > Unfortunately, the closest I seem to be able to get on sourceforge is a diff > > to gcc-2.95.2-3. I could get the gcc-2.95.2 sources and apply this patch, > > but I really don't think I'd be able to find the source for that particular > > dll in among the rest. Is there anyone else who intends to let other people > > use programs they compiled with mingw? How do other people deal with this? > > > > The easiest option is to build programmes that link against static > libstdc++.a, etc, rather than dll's. IMHO that should be the default. > I agree with Danny. For MinGW we need to default to using static versions of the LGPL'ed libraries. -- Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Philip B. <ph...@es...> - 2001-05-14 22:22:05
|
Okay. Thanks, everyone. I guess I'll be linking statically now. ----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: "Danny Smith" <dan...@ya...> Cc: "Philip Bock" <ph...@es...>; <min...@li...> Sent: Monday, May 14, 2001 10:51 AM Subject: Re: [Mingw-users] libstdc++.dll > Danny Smith wrote: > > > > --- Philip Bock <ph...@es...> wrote: > Okay. I've read through the LGPL > > myself. If I understand correctly, just > > > providing a link isn't enough. I need to provide the source for the DLL. > > > Unfortunately, the closest I seem to be able to get on sourceforge is a diff > > > to gcc-2.95.2-3. I could get the gcc-2.95.2 sources and apply this patch, > > > but I really don't think I'd be able to find the source for that particular > > > dll in among the rest. Is there anyone else who intends to let other people > > > use programs they compiled with mingw? How do other people deal with this? > > > > > > > The easiest option is to build programmes that link against static > > libstdc++.a, etc, rather than dll's. IMHO that should be the default. > > > > I agree with Danny. For MinGW we need to default to using static > versions of the LGPL'ed libraries. > > -- > Earnie. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > |
From: Paul S. <pa...@is...> - 2001-05-14 12:55:26
|
Hello Danny, Danny Smith <dan...@ya...> wrote on Sunday, May 13, 2001: DS> --- rei...@te... wrote: > On Sat, 12 May 2001, Philip Bock DS> wrote: >> > >> > I've been using the latest release of mingw, downloaded from sourceforge as >> > per the "download" page on the site. I've noticed that all c++ executables >> > produced by this version require the libstdc++.dll. Now, I'm not certain, >> > but I beleive that the stable release available from Mumit Khan's ftp >> > directory does not exhitbit this behavior. Is this someting new? And what >> are >> > the licensing reqirements for this DLL? >> There are several therads in this list concerning the libstdc++.dll in the >> newest release. Please look to the archives: >> http://www.geocrawler.com/lists/3/SourceForge/6013/0/ >> DS> I wasn't quite satisfied with the answer that came out of that thread. I still DS> believe that if you distribute libstdc++.dll (an executable derived from GPLed DS> source), Well, maybe I'm missing something, but libstdc++ always came with that exception clause concerning linking it into something without strings attached. Secondly, as was several times pointed there, that exception (or LGPL) is pertinent to *library*, and not "static library" or "ar-compatible archive file". It doesn't matter what form library has as long as it is used as library. And I hope you agree that libstdc++.dll cannot be used as "standalone application". DS> you are obligated to provide the [modified] source, or at least access DS> to the source, of libstdc++ with the distribution. This includes any DS> modification to the libstdc++ source (eg declspec macros) and the script used DS> to build the dll. Yep, nice idea. But it's questionable whether conversion of static lib to dll is "modification" in terms of (L)GPL. I compile my C code with GCC - should I provide GCC along the resulting executable. I hope everyone knows that answer is "No". I tend to consider a->dll conversions the same way. Yes, there was some changes to headers of libstdc++, but just couple of lines. Do you remember RMS' commentary about what constitutes "basing on GPLed source". He told that common sense should be used, and cut&paste of 2 lines is not reason for GPL contamination. Well, all writing above is just to argue that distributing libstdc++.dll as it is now is not necessarily violation of libstdc++ license. DS> Ditto for libgcc.dll. Ditto for libbfd.dll. DS> Copyright is a liability issue. It is the user's responsibility to be fully DS> aware of the meaning of the license and to comply. Yes. But the whole idea of (L)GPL is to give users of the software control of that software into their hands. The obvious way to achieve this is to give users all stuff needed to make the software in one place, that's why LGPL doesn't require redistribution of pristine sources, but does require redist of modified - it gets more complex to both find original sources and apply the changes. But (L)GPL doesn't postulate form or presentation of "all stuff". Neither it tries to say it should be "user-friendly" (other reminiscence from commentary is "When you have all source, you no longer depend on specific vendor - you can hire programmer to modify it for your needs"). I see no problems in dumping FSF's, Mumit's, my, someone else's sites, archive of this list, etc., to SourceForge. By doing so we would comply with (L)GPL - that heap would contain everything needed to rebuild binary stuff distributed. But will that be of any use? Does it matter where to dig - there or here? Who will receive bills for that waste? Well, but (L)GPL in fact doesn't even require such a horror - it says that source may be requested, and should be provided. Not even for free - for reasonable fee. And it does not stipulate time that may take. So, binutils (pure GPL) currently distributed from Mingw site at SF without sources. But it was totally disclosed on this list how to get them. I receive personal messages with the same question and I repeate info how to obtain them. So far noone requested me to provide sources from the same place where binaries lie. If I will receive such a request, I will provide them, as time will permit. If someone will want them there *tomorrow*, I'd be glad to do so for compensation, basically cost of bandwidth it will take and minimal hourly rate for time I will spend on it (instead of making my usual job). But I sincerely hope that GPL3 (which should basically allow the Internet as the "same place" for the source) will be ratified sooner than such request will be received. DS> This, of course, is not a legal opinion. Such an opinion would be more than DS> welcome. Again, my opinion, based on many commentaries and observations how that stuff works. The idea is clear, but reality introduces distortions. It's not a problem as long as there's a room and will to improve and comply. Btw, I'm going to split up libstdc++.dll into separate distro. DS> Danny -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Earnie B. <ear...@ya...> - 2001-05-14 15:50:04
|
Paul Sokolovsky wrote: > > Hello Danny, > > Danny Smith <dan...@ya...> wrote on Sunday, May 13, 2001: > > DS> --- rei...@te... wrote: > On Sat, 12 May 2001, Philip Bock > DS> wrote: > >> > > >> > I've been using the latest release of mingw, downloaded from sourceforge as > >> > per the "download" page on the site. I've noticed that all c++ executables > >> > produced by this version require the libstdc++.dll. Now, I'm not certain, > >> > but I beleive that the stable release available from Mumit Khan's ftp > >> > directory does not exhitbit this behavior. Is this someting new? And what > >> are > >> > the licensing reqirements for this DLL? > >> There are several therads in this list concerning the libstdc++.dll in the > >> newest release. Please look to the archives: > >> http://www.geocrawler.com/lists/3/SourceForge/6013/0/ > >> > > DS> I wasn't quite satisfied with the answer that came out of that thread. I still > DS> believe that if you distribute libstdc++.dll (an executable derived from GPLed > DS> source), > > Well, maybe I'm missing something, but libstdc++ always came with > that exception clause concerning linking it into something without > strings attached. Secondly, as was several times pointed there, that > exception (or LGPL) is pertinent to *library*, and not "static > library" or "ar-compatible archive file". It doesn't matter what form > library has as long as it is used as library. And I hope you agree > that libstdc++.dll cannot be used as "standalone application". > If you must distribute the libstdc++.dll then you must distribute the sources to build that dll. Any exception is that might be stated is stated toward your executable and not the library. Distributing the libstdc++.dll is not the same as linking with the import library and like on linux every one would have the shared library on Windows libstdc++.dll isn't a common library so you either have to tell someone where to get it or distribute it and if you distribute it you must provide the source to the library in order to be able to build that library. > DS> you are obligated to provide the [modified] source, or at least access > DS> to the source, of libstdc++ with the distribution. This includes any > DS> modification to the libstdc++ source (eg declspec macros) and the script used > DS> to build the dll. > > Yep, nice idea. But it's questionable whether conversion of static > lib to dll is "modification" in terms of (L)GPL. I compile my C code > with GCC - should I provide GCC along the resulting executable. I hope > everyone knows that answer is "No". I tend to consider a->dll > conversions the same way. > Yes, you must distribute the source of libstdc++.dll if you distribute libstdc++.dll. That is a requirement of the LGPL. You cannot get around it. > Yes, there was some changes to headers of libstdc++, but just > couple of lines. Do you remember RMS' commentary about what > constitutes "basing on GPLed source". He told that common sense should > be used, and cut&paste of 2 lines is not reason for GPL contamination. > > Well, all writing above is just to argue that distributing > libstdc++.dll as it is now is not necessarily violation of libstdc++ > license. > > DS> Ditto for libgcc.dll. Ditto for libbfd.dll. > > DS> Copyright is a liability issue. It is the user's responsibility to be fully > DS> aware of the meaning of the license and to comply. > > Yes. But the whole idea of (L)GPL is to give users of the software > control of that software into their hands. The obvious way to achieve > this is to give users all stuff needed to make the software in one > place, that's why LGPL doesn't require redistribution of pristine > sources, but does require redist of modified - it gets more complex to > both find original sources and apply the changes. But (L)GPL doesn't > postulate form or presentation of "all stuff". Neither it tries to say > it should be "user-friendly" (other reminiscence from commentary is "When > you have all source, you no longer depend on specific vendor - you can > hire programmer to modify it for your needs"). > Again, if you have to distribute the library itself you must distribute the source code for that library. If the library is GPL instead of LGPL then your source is forced to be covered by the GPL as well. > I see no problems in dumping FSF's, Mumit's, my, someone else's > sites, archive of this list, etc., to SourceForge. By doing so we would > comply with (L)GPL - that heap would contain everything needed to > rebuild binary stuff distributed. But will that be of any use? Does it > matter where to dig - there or here? Who will receive bills for that > waste? Well, but (L)GPL in fact doesn't even require such a horror - it > says that source may be requested, and should be provided. Not even > for free - for reasonable fee. And it does not stipulate time that may > take. > If you distribute GPL/LGPL via the net then you must include the source for the GPL/LGPL code via the net. You don't have to offer the distribute the source for three years after the release because you've given the source with the distribution. > So, binutils (pure GPL) currently distributed from Mingw site at > SF without sources. But it was totally disclosed on this list how to > get them. THIS MUST CHANGE. We need to put a distribution of the binutils source on our own site. It is the law. > I receive personal messages with the same question and I > repeate info how to obtain them. So far noone requested me to > provide sources from the same place where binaries lie. If I will > receive such a request, I will provide them, as time will permit. If > someone will want them there *tomorrow*, I'd be glad to do so for > compensation, basically cost of bandwidth it will take and minimal > hourly rate for time I will spend on it (instead of making my usual > job). > Consider the request a mandate. The modified version of binutils that exist on our site must have the source be able to be delivered as well or we will have to remove the distribution from our site. > But I sincerely hope that GPL3 (which should basically allow the Internet > as the "same place" for the source) will be ratified sooner than such > request will be received. > GPL3 isn't here yet and we MUST abide by GPL2. > DS> This, of course, is not a legal opinion. Such an opinion would be more than > DS> welcome. > > Again, my opinion, based on many commentaries and observations how > that stuff works. The idea is clear, but reality introduces > distortions. It's not a problem as long as there's a room and will to > improve and comply. > My opinion is based on very lengthy discussions of the topic with those that have distributed GPL software before and have first hand knowledge of doing so. > Btw, I'm going to split up libstdc++.dll into separate distro. > What does this mean? -- Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Paul S. <pa...@is...> - 2001-05-15 11:21:05
|
Hello Earnie, Earnie Boyd <ear...@ya...> wrote on Monday, May 14, 2001: [] EB> If you must distribute the libstdc++.dll then you must distribute the EB> sources to build that dll. Any exception is that might be stated is EB> stated toward your executable and not the library. Hm, such interpretation is not obvious. Can you give links which explicitly comment on this case? When some application distributed with the bound part in the form of dll, it is not much different than when it is distributed with the bound part of static lib. [] >> So, binutils (pure GPL) currently distributed from Mingw site at >> SF without sources. But it was totally disclosed on this list how to >> get them. EB> THIS MUST CHANGE. We need to put a distribution of the binutils source EB> on our own site. It is the law. Ok, the law is the law. Auto-import feature finally got testing and some problems was found and fixed (otherwise, it's good, people build Qt/KDE with it). Also, binutils reached 2.91 version. So, I plan to update the packages and will take steps to provide sources from site. [] EB> GPL3 isn't here yet and we MUST abide by GPL2. And what remains is to regret that there's no news on that front... >> DS> This, of course, is not a legal opinion. Such an opinion would be more than [] EB> My opinion is based on very lengthy discussions of the topic with those EB> that have distributed GPL software before and have first hand knowledge EB> of doing so. >> Btw, I'm going to split up libstdc++.dll into separate distro. >> EB> What does this mean? I mean, move stuff to support shared libstdc++ to separate package which can be installed optionally. EB> -- EB> Earnie. -- Paul Sokolovsky, IT Specialist http://www.brainbench.com/transcript.jsp?pid=11135 |
From: Earnie B. <ear...@ya...> - 2001-05-15 11:42:11
|
Paul Sokolovsky wrote: > > Hello Earnie, > > Earnie Boyd <ear...@ya...> wrote on Monday, May 14, 2001: > > [] > > EB> If you must distribute the libstdc++.dll then you must distribute the > EB> sources to build that dll. Any exception is that might be stated is > EB> stated toward your executable and not the library. > > Hm, such interpretation is not obvious. Can you give links which > explicitly comment on this case? When some application distributed > with the bound part in the form of dll, it is not much different than > when it is distributed with the bound part of static lib. > I didn't say the application dependent on the library, I said the distribution of the binary form of the library requires distribution of the sources for that library. > >> Btw, I'm going to split up libstdc++.dll into separate distro. > >> > > EB> What does this mean? > > I mean, move stuff to support shared libstdc++ to separate > package which can be installed optionally. > I don't see any good of it. I only see confusion. -- Earnie. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: <jsv...@be...> - 2001-05-15 13:02:13
|
On 14 May 2001, at 11:49, Earnie Boyd wrote: > If you must distribute the libstdc++.dll then you must distribute the > sources to build that dll. Any exception is that might be stated is > stated toward your executable and not the library. Distributing the > libstdc++.dll is not the same as linking with the import library and > like on linux every one would have the shared library on Windows > libstdc++.dll isn't a common library so you either have to tell > someone where to get it or distribute it and if you distribute it you > must provide the source to the library in order to be able to build > that library. > > Yes, you must distribute the source of libstdc++.dll if you distribute > libstdc++.dll. That is a requirement of the LGPL. You cannot get > around it. > > Again, if you have to distribute the library itself you must > distribute the source code for that library. If the library is GPL > instead of LGPL then your source is forced to be covered by the GPL as > well. > > If you distribute GPL/LGPL via the net then you must include the > source for the GPL/LGPL code via the net. You don't have to offer the > distribute the source for three years after the release because you've > given the source with the distribution. I think you are missing a quite important point. You are not required to package the sources with every binary you ship. What you need to do is to provide some facility that enables EVERY user of your binary distribution to obtain a copy of the sources used to build it, if they wish. This is why a link isn't sufficient, because an internet connection is not something EVERY user necessarily has got access to. However, providing a snail-mail address where sources can be requested (In return for whatever fee you choose to charge for this service) should be sufficient. Jon Svendsen |
From: Tony K. <al...@po...> - 2001-05-15 15:29:43
|
Quoth jsv...@be... on Tuesday, 15 May: : : However, providing a snail-mail : address where sources can be requested (In return for whatever fee : you choose to charge for this service) should be sufficient. In this case, it would suffice to provide the FSF mail info. They sell the media. |
From: Jeremy B. <je...@hk...> - 2001-05-15 16:25:33
|
----- Original Message ----- From: "Tony Kimball" <al...@po...> > Quoth jsv...@be... on Tuesday, 15 May: > : > : However, providing a snail-mail > : address where sources can be requested (In return for whatever fee > : you choose to charge for this service) should be sufficient. > > In this case, it would suffice to provide the FSF mail info. > They sell the media. But if there is even one character changed from the FSF source code, then you have a different "derived work", and you need to provide source code that matches the binaries that you are shipping. If all you are doing is getting the FSF source, typing configure and make, then pointing people to FSF would be sufficent. -- Jeremy Bettis -- Software Development Manager Hickman-Kenyon Systems, Inc. je...@hk... |
From: Tony K. <al...@po...> - 2001-05-15 16:40:51
|
Quoth Jeremy Bettis on Tuesday, 15 May: : But if there is even one character changed from the FSF source code, then : you have a different "derived work", and you need to provide source code : that matches the binaries that you are shipping. That "source code" could be a patch file. I take exception to a claim made earlier in this thread, that "it's the Law". Because it's not the law. There is no law that requires you to abide by the GPL. There is a law which allows a party with a certain kind of interest in the issue to use the power of the courts to require you to abide by the GPL, if you are not doing so, and they can convince the court. It is a very different thing. |
From: Jeremy B. <je...@hk...> - 2001-05-15 16:49:23
|
I agree with you completely. I do think that in general, we ought to try to abide by agreements which we are a party to, rather than to wait for a court to order us to do so. ;-) But the implication that "It's the Law" to have a cvs server up for every tiny little project was a bit over the top. -- Jeremy Bettis -- Software Development Manager Hickman-Kenyon Systems, Inc. je...@hk... ----- Original Message ----- From: "Tony Kimball" <al...@po...> To: <je...@hk...> Cc: <min...@li...> Sent: Tuesday, May 15, 2001 11:41 AM Subject: Re: [Mingw-users] libstdc++.dll > Quoth Jeremy Bettis on Tuesday, 15 May: > : But if there is even one character changed from the FSF source code, then > : you have a different "derived work", and you need to provide source code > : that matches the binaries that you are shipping. > > That "source code" could be a patch file. > > I take exception to a claim made earlier in this thread, that "it's > the Law". Because it's not the law. There is no law that requires > you to abide by the GPL. There is a law which allows a party with a > certain kind of interest in the issue to use the power of the courts > to require you to abide by the GPL, if you are not doing so, and they > can convince the court. It is a very different thing. > |
From: Earnie B. <ear...@ya...> - 2001-05-15 20:57:39
|
Semantics with words!! If you take the source of someone else and they control the intellectual property of that source but give you permission to use that intellectual property as long as you abide by the requirements set forth in the agreement then you must abide by that agreement and "It's the Law"!! If some legal entity can force you to abide by that agreement then "It's the Law" since it is that legal entity that makes it the law!! Since the GPL stipulates that you are responsible for providing the source code for the binary then based on the above "It's the Law"!! -- Earnie. Jeremy Bettis wrote: > > I agree with you completely. I do think that in general, we ought to try to > abide by agreements which we are a party to, rather than to wait for a court > to order us to do so. ;-) But the implication that "It's the Law" to have a > cvs server up for every tiny little project was a bit over the top. > -- > Jeremy Bettis -- Software Development Manager > Hickman-Kenyon Systems, Inc. > je...@hk... > ----- Original Message ----- > From: "Tony Kimball" <al...@po...> > To: <je...@hk...> > Cc: <min...@li...> > Sent: Tuesday, May 15, 2001 11:41 AM > Subject: Re: [Mingw-users] libstdc++.dll > > > Quoth Jeremy Bettis on Tuesday, 15 May: > > : But if there is even one character changed from the FSF source code, > then > > : you have a different "derived work", and you need to provide source code > > : that matches the binaries that you are shipping. > > > > That "source code" could be a patch file. > > > > I take exception to a claim made earlier in this thread, that "it's > > the Law". Because it's not the law. There is no law that requires > > you to abide by the GPL. There is a law which allows a party with a > > certain kind of interest in the issue to use the power of the courts > > to require you to abide by the GPL, if you are not doing so, and they > > can convince the court. It is a very different thing. > > > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options at: > http://lists.sourceforge.net/lists/listinfo/mingw-users _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Tony K. <al...@po...> - 2001-05-16 00:27:38
|
Quoth Earnie Boyd on Tuesday, 15 May: : Semantics with words!! Such things can be important sometimes, especially in legal matters. It is fine if we use words differently, as long as we understand each other's meanings well enough to communicate without misinterpretation. I apologize if my terms seemed combative. I think we understand each other's meanings better now. |