From: Joe S. <jo...@ra...> - 2008-05-14 20:11:39
|
Hi everyone, I'm using GDI+ for several projects and would really like to switch to using MinGW and gcc rather than using the MSVC compiler. I've searched the list archives for GDI+ information, but have only found either vague references or implementations that aren't usable due to copyright issues. Does anyone have gcc compatible headers for GDI+ that can be used legally in commercial software projects? If no one has such a thing, I would be interested in creating said header files for possible inclusion in MinGW. I just need to know what the acceptable sources for information are for creating the headers. I understand that looking at the headers from the Windows Platform SDK isn't an acceptable resource, but would the public, online MSDN reference at http://msdn.microsoft.com/en-us/library/ms533798(VS.85).aspx be acceptable? Thanks for any information, Joe |
From: Joe S. <jo...@ra...> - 2008-05-14 20:11:45
|
Hi everyone, I'm using GDI+ for several projects and would really like to switch to using MinGW and gcc rather than using the MSVC compiler. I've searched the list archives for GDI+ information, but have only found either vague references or implementations that aren't usable due to copyright issues. Does anyone have gcc compatible headers for GDI+ that can be used legally in commercial software projects? If no one has such a thing, I would be interested in creating said header files for possible inclusion in MinGW. I just need to know what the acceptable sources for information are for creating the headers. I understand that looking at the headers from the Windows Platform SDK isn't an acceptable resource, but would the public, online MSDN reference at http://msdn.microsoft.com/en-us/library/ms533798(VS.85).aspx be acceptable? Thanks for any information, Joe |
From: Brandon S. <br...@oq...> - 2008-05-14 20:16:11
|
On May 14, 2008, at 1:13 PM, Joe Stenger wrote: > Hi everyone, > > I'm using GDI+ for several projects and would really like to switch > to using > MinGW and gcc rather than using the MSVC compiler. I've searched the > list > archives for GDI+ information, but have only found either vague > references > or implementations that aren't usable due to copyright issues. Does > anyone > have gcc compatible headers for GDI+ that can be used legally in > commercial > software projects? > You can use the MS GDI+ headers with GCC all you want provided you make a few modifications. If you've obtained the headers, you've most likely agreed to their EULA in the PSDK which doesn't dictate what you can/can't compile it with. There are no legal issues with this, only with redistribution of the headers themselves. > If no one has such a thing, I would be interested in creating said > header > files for possible inclusion in MinGW. I just need to know what the > acceptable sources for information are for creating the headers. I > understand that looking at the headers from the Windows Platform SDK > isn't > an acceptable resource, but would the public, online MSDN reference at > http://msdn.microsoft.com/en-us/library/ms533798(VS.85).aspx be > acceptable? > online MSDN is an acceptable resource, albeit probably incomplete for this. Brandon Sneed |
From: Earnie B. <ea...@us...> - 2008-05-15 13:38:23
|
Quoting Brandon Sneed <br...@oq...>: > You can use the MS GDI+ headers with GCC all you want provided you > make a few modifications. If you've obtained the headers, you've most > likely agreed to their EULA in the PSDK which doesn't dictate what you > can/can't compile it with. There are no legal issues with this, only > with redistribution of the headers themselves. > Which then prevents you from distributing a GPL licensed source as the two can't be used together. You can privately use such a combination all you want but you cannot distribute a GPL source that has used a MS EULA library. Earnie |
From: Doug S. <dsc...@ro...> - 2008-05-15 17:42:28
|
Earnie Boyd wrote: > Quoting Brandon Sneed <br...@oq...>: > > >> You can use the MS GDI+ headers with GCC all you want provided you >> make a few modifications. If you've obtained the headers, you've most >> likely agreed to their EULA in the PSDK which doesn't dictate what you >> can/can't compile it with. There are no legal issues with this, only >> with redistribution of the headers themselves. >> >> > > Which then prevents you from distributing a GPL licensed source as the > two can't be used together. You can privately use such a combination > all you want but you cannot distribute a GPL source that has used a MS > EULA library. > > Earnie > > Is that a restriction in the MS EULA? I don't see the GPL restricting that? But then IANAL. Doug. |
From: Keith M. <kei...@us...> - 2008-05-15 20:33:49
|
On Thursday 15 May 2008 18:42, Doug Schaefer wrote: > > Which then prevents you from distributing a GPL licensed source as > > the two can't be used together. You can privately use such a > > combination all you want but you cannot distribute a GPL source > > that has used a MS EULA library. > > Is that a restriction in the MS EULA? I don't see the GPL restricting > that? But then IANAL. The GPL requires you to distribute full source, to allow an end user to rebuild your application from scratch. If part of that source resides in headers which you do not have the right to redistribute, how can you possibly comply with the GPL, without infringing the EULA of those headers? Regards, Keith. |
From: Doug S. <dsc...@ro...> - 2008-05-15 21:56:07
|
Keith Marshall wrote: > On Thursday 15 May 2008 18:42, Doug Schaefer wrote: > >>> Which then prevents you from distributing a GPL licensed source as >>> the two can't be used together. You can privately use such a >>> combination all you want but you cannot distribute a GPL source >>> that has used a MS EULA library. >>> >> Is that a restriction in the MS EULA? I don't see the GPL restricting >> that? But then IANAL. >> > > The GPL requires you to distribute full source, to allow an end user to > rebuild your application from scratch. If part of that source resides > in headers which you do not have the right to redistribute, how can you > possibly comply with the GPL, without infringing the EULA of those > headers? > > Regards, > Keith. > > Actually with that argument, GPL would be restrict you from building against any proprietary C run-time including Solaris, AIX, etc. So I'm not sure this is actually restricted. But then I could be missing something. At either rate, GPL apps do not redistribute all the headers they use, of course. Getting back to GDI+, I thought one of the issues we had was linking against MSVC built C++. Is there a workaround for this? Doug |
From: Dave K. <dav...@ar...> - 2008-05-15 22:36:49
|
Doug Schaefer wrote on 15 May 2008 22:56: > Actually with that argument, GPL would be restrict you from building > against any proprietary C run-time including Solaris, AIX, etc. So I'm > not sure this is actually restricted. But then I could be missing > something. At either rate, GPL apps do not redistribute all the headers > they use, of course. GPLv2 has an explicit exception for standard libs and headers shipped with the system. http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLIncompatibleLib s " However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." I don't know if that covers something that comes as a separate package like the PSDK; the GPLv2 was rather unix-centric, and didn't conceive that someone would ever ship an OS without a compiler, libraries and headers! I suspect the answer might be that since the compiler is not shipped with the OS, it is not a "component", but if you wanted a better answer, you'd probably want to raise it on gnu.misc. (Or even search the archives, it may have been discussed before). But anyway, that's how come it works for AIX and Solaris and co. Hmm, thinking back on it, I'm not sure if the compiler and libs and headers package always shipped as a standard part of Solaris, so there might be some leeway for optional extras. Only an opinion from the FSF itself can have any authority in this matter, however. cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Tor L. <tm...@ik...> - 2008-05-16 07:54:45
|
> Only an opinion from the FSF itself can > have any authority in this matter, however. Or more properly, an opinion of the copyright owner to the code in question. If one or several persons own the copyright to some code that requires, say, GDI headers to compile, and they still decide to distribute that code under the GPL or LGPL, I don't see what the FSF's or some third party's interpretation of these licenses have to do with it. --tml |
From: Tuomo L. <dj...@ik...> - 2008-05-16 09:42:41
|
Tor Lillqvist wrote: >> Only an opinion from the FSF itself can >> have any authority in this matter, however. > > Or more properly, an opinion of the copyright owner to the code in > question. If one or several persons own the copyright to some code > that requires, say, GDI headers to compile, and they still decide to > distribute that code under the GPL or LGPL, I don't see what the FSF's > or some third party's interpretation of these licenses have to do with > it. IANAL, but even the copyright owner's interpretation of the license is irrelevant. You are suppose to say what you mean without any room for misinterpretation in a license. If there is room for interpretation, funny legal things may ensue. Of course, the copyright owner may re-license or choose to ignore breaches of license (which in some cases could also be seen as implicit re-licensing, I think), but that is another matter. -- Tuomo ... Don't do what I SAY, do what I mean! |
From: Earnie B. <ea...@us...> - 2008-05-16 12:17:22
|
Quoting Tor Lillqvist <tm...@ik...>: >> Only an opinion from the FSF itself can >> have any authority in this matter, however. > > Or more properly, an opinion of the copyright owner to the code in > question. If one or several persons own the copyright to some code > that requires, say, GDI headers to compile, and they still decide to > distribute that code under the GPL or LGPL, I don't see what the FSF's > or some third party's interpretation of these licenses have to do with > it. > The licenses of the original code cannot be changed unless the copyright owner(s) agree. MS EULA and GPL contradict each other and therefore cannot coexist. If you distribute binaries of GPL code then you must distribute the source for that GPL code and the GPL states that you must be able to compile the source which would mean you would have to distribute the GDI headers which you are not permitted to do which is a direct contradiction to the GPL which requires you to distribute the source. This is why MinGW exists. Note LGPL gives no exception to distributed source; it only gives exception to the use of the compiled source. Earnie |
From: Dave K. <dav...@ar...> - 2008-05-16 12:34:28
|
Earnie Boyd wrote on 16 May 2008 13:17: > Quoting Tor Lillqvist <tm...@ik...>: > >>> Only an opinion from the FSF itself can >>> have any authority in this matter, however. >> >> Or more properly, an opinion of the copyright owner to the code in >> question. If one or several persons own the copyright to some code >> that requires, say, GDI headers to compile, and they still decide to >> distribute that code under the GPL or LGPL, I don't see what the FSF's >> or some third party's interpretation of these licenses have to do with >> it. >> > > The licenses of the original code cannot be changed unless the > copyright owner(s) agree. MS EULA and GPL contradict each other and > therefore cannot coexist. If you distribute binaries of GPL code then > you must distribute the source for that GPL code and the GPL states > that you must be able to compile the source which would mean you would > have to distribute the GDI headers which you are not permitted to do > which is a direct contradiction to the GPL which requires you to > distribute the source. *headdesk* Is it groundhog day _again_? Because I'm sure this is where we came in, and then the next comment was me saying "but maybe the MS PSDK headers are counted under the standard-system-components exclusion, but you'd need to ask the FSF", and then Tor says "well actually it's up to the copyright holder in the case of the particular GPL code in question, who is not always the FSF so I don't see what they have to do wtih it", and then you say "The GPL says that if you distribute binaries of GPL code then you must dstribute the GDI headers and you can't do that", and then I say "But maybe the PSDK headers are covered by the standard-system-components exclusion", and then Tor says ... and then you say ... and then it all just goes round and round. Pardon me while I duck out of this thread for however many more times it wants to go round in circles... cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Earnie B. <ea...@us...> - 2008-05-16 12:28:06
|
Quoting Doug Schaefer <dsc...@ro...>: > Getting back to GDI+, I thought one of the issues we had was linking > against MSVC built C++. Is there a workaround for this? > Use C wrappers. Earnie |
From: Earnie B. <ea...@us...> - 2008-05-18 03:11:06
|
Quoting Charles Wilson <cwi...@us...>: > Doug Schaefer wrote: >> Keith Marshall wrote: >>> The GPL requires you to distribute full source, to allow an end user to >>> rebuild your application from scratch. If part of that source resides >>> in headers which you do not have the right to redistribute, how can you >>> possibly comply with the GPL, without infringing the EULA of those >>> headers? >> >> Actually with that argument, GPL would be restrict you from building >> against any proprietary C run-time including Solaris, AIX, etc. So I'm >> not sure this is actually restricted. But then I could be missing >> something. At either rate, GPL apps do not redistribute all the headers >> they use, of course. > > The question is, do the GDI+ libraries meet the requirements of the > "system library" exception in the GPL. If it does, then I don't think > it matters what EULA applies to the headers, as far as the GPL is > concerned. (Sure, *we* can't redistribute the GDI+ headers, but neither > are the gcc folks allowed to redistribute the /usr/include/sys/ headers > for HP/UX) > > But IANAL. > > BTW, it looks like the GPLv3 relaxed the definition of "System Library" > compared to GPLv2. According to the GPL FAQ: > > http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL > ====================== > I'm writing a Windows application with Microsoft Visual C++ (or Visual > Basic) and I will be releasing it under the GPL. Is dynamically linking > my program with the Visual C++ (or Visual Basic) run-time library > permitted under the GPL? > > The GPL permits this because that run-time library normally > accompanies the compiler or interpreter you are using. The run-time > libraries here are “System Libraries” as GPLv3 defines them, and as such > they are not considered part of the Corresponding Source. GPLv2 has a > similar [ed: similar, but not identical] exception in section 3. > ====================== > > I wonder if this impacts some of the recent discussions we've had > concerning linking against the msvcrtXX.dll runtimes? Sure, you can't > redistribute the dll itself, *yourself*, without a VisStudio license -- > but you could, if I'm reading the faq above correctly, compile GPL apps > against the msvcrtXX.dll, and instruct users to go get the redistXX > package from MS themselves -- all without violating either the GPL or > MS's eula. > And it may come down to whether or not you're using the compilers as supplied by MS or perhaps at least licensed for use by other compilers. So if you're willing to use Visual C++ you can create GPL code for windows. It doesn't sound quite right. Maybe we should as the FSF lawyers. Earnie |
From: Peter F. <pet...@gm...> - 2008-05-18 10:25:22
|
Earnie Boyd schrieb: > Quoting Charles Wilson <cwi...@us...>: > >> Doug Schaefer wrote: >>> Keith Marshall wrote: >>>> The GPL requires you to distribute full source, to allow an end user to >>>> rebuild your application from scratch. If part of that source resides >>>> in headers which you do not have the right to redistribute, how can you >>>> possibly comply with the GPL, without infringing the EULA of those >>>> headers? >>> Actually with that argument, GPL would be restrict you from building >>> against any proprietary C run-time including Solaris, AIX, etc. So I'm >>> not sure this is actually restricted. But then I could be missing >>> something. At either rate, GPL apps do not redistribute all the headers >>> they use, of course. >> The question is, do the GDI+ libraries meet the requirements of the >> "system library" exception in the GPL. If it does, then I don't think >> it matters what EULA applies to the headers, as far as the GPL is >> concerned. (Sure, *we* can't redistribute the GDI+ headers, but neither >> are the gcc folks allowed to redistribute the /usr/include/sys/ headers >> for HP/UX) >> >> But IANAL. >> >> BTW, it looks like the GPLv3 relaxed the definition of "System Library" >> compared to GPLv2. According to the GPL FAQ: >> >> http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL >> ====================== >> I'm writing a Windows application with Microsoft Visual C++ (or Visual >> Basic) and I will be releasing it under the GPL. Is dynamically linking >> my program with the Visual C++ (or Visual Basic) run-time library >> permitted under the GPL? >> >> The GPL permits this because that run-time library normally >> accompanies the compiler or interpreter you are using. The run-time >> libraries here are “System Libraries” as GPLv3 defines them, and as such >> they are not considered part of the Corresponding Source. GPLv2 has a >> similar [ed: similar, but not identical] exception in section 3. >> ====================== >> >> I wonder if this impacts some of the recent discussions we've had >> concerning linking against the msvcrtXX.dll runtimes? Sure, you can't >> redistribute the dll itself, *yourself*, without a VisStudio license -- >> but you could, if I'm reading the faq above correctly, compile GPL apps >> against the msvcrtXX.dll, and instruct users to go get the redistXX >> package from MS themselves -- all without violating either the GPL or >> MS's eula. >> > > And it may come down to whether or not you're using the compilers as > supplied by MS or perhaps at least licensed for use by other compilers. > So if you're willing to use Visual C++ you can create GPL code for > windows. It doesn't sound quite right. Maybe we should as the FSF > lawyers. > > Earnie gdiplus.dll has a C API (see GdiPlusFlat.h), that is wrapped by classes. It works perfectly well with GCC. I wrote some GDI+ gadgets with GCC a while ago. All the wrapper-class code is in Microsoft's header files. gdiplus.dll is part of Windows XP, so I think there is no licensing issue. Peter |
From: Peter F. <pet...@gm...> - 2008-05-18 10:27:16
|
Peter Frentrup schrieb: > gdiplus.dll has a C API (see GdiPlusFlat.h), that is wrapped by > classes. It works perfectly well with GCC. I wrote some GDI+ gadgets > with GCC a while ago. > All the wrapper-class code is in Microsoft's header files. > > gdiplus.dll is part of Windows XP, so I think there is no licensing > issue. > > Peter > ups I didn't read Tor's answer. who wrote the same |
From: Dave K. <dav...@ar...> - 2008-05-15 21:13:54
|
Keith Marshall wrote on 15 May 2008 21:36: > On Thursday 15 May 2008 18:42, Doug Schaefer wrote: >>> Which then prevents you from distributing a GPL licensed source as >>> the two can't be used together. You can privately use such a >>> combination all you want but you cannot distribute a GPL source >>> that has used a MS EULA library. >> >> Is that a restriction in the MS EULA? I don't see the GPL restricting >> that? But then IANAL. > > The GPL requires you to distribute full source, to allow an end user to > rebuild your application from scratch. If part of that source resides > in headers which you do not have the right to redistribute, how can you > possibly comply with the GPL, without infringing the EULA of those > headers? Ship pre-processed .i files? ;-) cheers, DaveK -- Can't think of a witty .sigline today.... |
From: Earnie B. <ea...@us...> - 2008-05-15 21:53:53
|
Quoting Dave Korn <dav...@ar...>: > Keith Marshall wrote on 15 May 2008 21:36: > >> On Thursday 15 May 2008 18:42, Doug Schaefer wrote: >>>> Which then prevents you from distributing a GPL licensed source as >>>> the two can't be used together. You can privately use such a >>>> combination all you want but you cannot distribute a GPL source >>>> that has used a MS EULA library. >>> >>> Is that a restriction in the MS EULA? I don't see the GPL restricting >>> that? But then IANAL. >> >> The GPL requires you to distribute full source, to allow an end user to >> rebuild your application from scratch. If part of that source resides >> in headers which you do not have the right to redistribute, how can you >> possibly comply with the GPL, without infringing the EULA of those >> headers? > > Ship pre-processed .i files? ;-) > I'm glad you put the smiley on. You about had me going. Earnie |
From: Charles W. <cwi...@us...> - 2008-05-15 22:46:16
|
Doug Schaefer wrote: > Keith Marshall wrote: >> The GPL requires you to distribute full source, to allow an end user to >> rebuild your application from scratch. If part of that source resides >> in headers which you do not have the right to redistribute, how can you >> possibly comply with the GPL, without infringing the EULA of those >> headers? > > Actually with that argument, GPL would be restrict you from building > against any proprietary C run-time including Solaris, AIX, etc. So I'm > not sure this is actually restricted. But then I could be missing > something. At either rate, GPL apps do not redistribute all the headers > they use, of course. The question is, do the GDI+ libraries meet the requirements of the "system library" exception in the GPL. If it does, then I don't think it matters what EULA applies to the headers, as far as the GPL is concerned. (Sure, *we* can't redistribute the GDI+ headers, but neither are the gcc folks allowed to redistribute the /usr/include/sys/ headers for HP/UX) But IANAL. BTW, it looks like the GPLv3 relaxed the definition of "System Library" compared to GPLv2. According to the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL ====================== I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic) and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ (or Visual Basic) run-time library permitted under the GPL? The GPL permits this because that run-time library normally accompanies the compiler or interpreter you are using. The run-time libraries here are “System Libraries” as GPLv3 defines them, and as such they are not considered part of the Corresponding Source. GPLv2 has a similar [ed: similar, but not identical] exception in section 3. ====================== I wonder if this impacts some of the recent discussions we've had concerning linking against the msvcrtXX.dll runtimes? Sure, you can't redistribute the dll itself, *yourself*, without a VisStudio license -- but you could, if I'm reading the faq above correctly, compile GPL apps against the msvcrtXX.dll, and instruct users to go get the redistXX package from MS themselves -- all without violating either the GPL or MS's eula. -- Chuck |
From: Aaron W. L. <aar...@aa...> - 2008-05-17 06:13:42
|
Earnie Boyd wrote: > Quoting Doug Schaefer <dsc...@ro...>: > >> Getting back to GDI+, I thought one of the issues we had was linking >> against MSVC built C++. Is there a workaround for this? > > Use C wrappers. This is the actual difficulty here: the ABI incompatibility. One way or another, you're going to have to map the GCC C++ ABI to the MSVC C++ ABI, in whatever subset of C++ is used by GDI+. This is the main work to be done, and it is probably nontrivial. I am not familiar with GDI+, but the above mapping may not actually be possible in any reasonable sense. This would be the case if GDI+ depended on class layout beyond a minimal extent. For instance, if the compiler needs to construct objects to pass to GDI+ by reference, and GDI+ needs to modify these objects asynchronously, the mapping may be practically impossible to accomplish. However, if GDI+ uses a comfortably small subset of C++, the mapping may be readily possible; only the application of money and/or volunteer time will be required. There is always talk of adding support for the MSVC ABI to GCC. The main thing keeping this from happening is the amount of work and expertise that would be required. |
From: Tor L. <tm...@ik...> - 2008-05-17 09:16:46
|
> However, if GDI+ uses a comfortably small subset of C++, the mapping may > be readily possible; only the application of money and/or volunteer time > will be required. Actually, GDI+ (the actual DLL) provides a plain C API. All the C++ stuff is implemented by the GDI+ headers only. If you are no C++ fan, it works fine to use just the C API. --tml |