From: Danny S. <dan...@cl...> - 2006-05-20 03:35:43
|
> To Greg's point, I don't know of an easy way to create a > script so as to generate these files dynamically at > installation time. However, as the registry exists on every > windows installation and is obviously there for anyone to > view, is this really an issue? It's not like I'm reverse > engineering a binary lib file produced and distributed by > Microsoft in an EULA type scenario. How can MS copyright the information in an object that gets modified by users on a very regular basis? > > Chris > |
From: Danny S. <dan...@cl...> - 2006-05-21 10:05:55
|
> -----Original Message----- > From: min...@li...=20 > [mailto:min...@li...] On Behalf Of=20 > Keith Marshall > Sent: Sunday, May 21, 2006 2:27 AM > To: min...@li... > Subject: Re: [MinGW-dvlpr] Fwd: [Mingw-users] Re: w32api=20 > uuid.lib generation for pocket pc >=20 >=20 > On Friday 19 May 2006 11:54 am, Earnie wrote: > > I'm thinking we need to pull the libuuid.a library from our=20 > > distribution! =A0We are distributing MS's original object=20 > library! =A0What=20 > > are our distribution rights for uuid.lib? >=20 > Just to add my two pennyworth to the discussion. I've been=20 > following the=20 > thread, and am replying to the top entry, because I want to bring=20 > together points from various branches. >=20 > AIUI, there is concern that we may be reverse engineering an=20 > MS library,=20 > only to rebuild and redistribute a replacement.=20 Please reread the comment in uuid.c=20 "This file was generated by extracting the names of all GUIDs from uuid.lib. The names were in turn processed by a script..." This comment has been here since at least the 1.1 winsup CVS version (Feb 2000). I I have an earlier version of this file (part of Mumit Khan's 1999 release of gcc-2.95 based mingw, on an old PC, the point being that these definitions have been distributed by mingw for 7 years or so. Any attempt to rebuild the file from values published on the web will most likely be "tainted" by the same uuid.c source file we are trying to replace.=20 =20 The original author of this file extracted the *names* , not the actual 128-bit ID.=20 How is that different from extracting the names of exports from system dll's to build import libs? Danny |
From: Luke D. <cod...@ho...> - 2006-05-21 14:23:58
|
>From: Danny Smith <dan...@cl...> >Reply-To: min...@li... >To: min...@li... >Subject: RE: [MinGW-dvlpr] Fwd: [Mingw-users] Re: w32api uuid.lib >generation for pocket pc >Date: Sun, 21 May 2006 22:05:48 +1200 > >The original author of this file extracted the *names* , not the actual >128-bit ID. >How is that different from extracting the names of exports from system >dll's to build import libs? > > >Danny Yes, I agree that this is fine. Luke |
From: Chris S. <ir0...@gm...> - 2006-05-21 17:28:11
|
> >The original author of this file extracted the *names* , not the actual > >128-bit ID. > >How is that different from extracting the names of exports from system > >dll's to build import libs? > > Yes, I agree that this is fine. In terms of determining the names, they should all be found on the MSDN, so I don't think the names have ever been the issue. The question is how were the 128-bit IDs determined? As it was pointed out, all the IIDs seem to be defined in the 'Interface' key. Unfortunately the majority of the CLSIDs and all the CATIDs don't seem to be defined in the registry, or at least they do not share the same name. I'm open to suggestions on where to look them up. The IIDs are good start, but unfortunately without the accompanying CLSIDs all the COM functions (for which I link in libuuid) will not work. Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2006-05-23 01:01:21
|
Hey All, > The question is how were the 128-bit IDs determined? As it was > pointed out, all the IIDs seem to be defined in the 'Interface' key. > Unfortunately the majority of the CLSIDs and all the CATIDs don't seem > to be defined in the registry, or at least they do not share the same > name. I'm open to suggestions on where to look them up. > > The IIDs are good start, but unfortunately without the accompanying > CLSIDs all the COM functions (for which I link in libuuid) will not > work. Does anybody have any ideas on how to proceed or are we at an impasse? Do we pull libuuid.a? Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2006-05-23 01:56:56
|
> Does anybody have any ideas on how to proceed or are we at an impasse? > Do we pull libuuid.a? One more thought, what about providing a script/batch file that could be run against the uuid.lib provided by the Microsoft platform SDK? We would not actually provide a libuuid.a, but rather the script itself, it would then be up to the developer to use the script on uuid.lib should they need it. This should take care of the legal side of things since the developer would have agreed to the EULA in the PSDK to obtain uuid.lib. My only concern with going this route is that should someone include any of the headers that have an EXTERN_C reference to libuuid.a without generating it first, it will cause link time error. Comments? Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Chris S. <ir0...@gm...> - 2006-05-23 02:16:36
|
> One more thought, what about providing a script/batch file that could > be run against the uuid.lib provided by the Microsoft platform SDK? > We would not actually provide a libuuid.a, but rather the script > itself, it would then be up to the developer to use the script on > uuid.lib should they need it. This should take care of the legal side > of things since the developer would have agreed to the EULA in the > PSDK to obtain uuid.lib. > > My only concern with going this route is that should someone include > any of the headers that have an EXTERN_C reference to libuuid.a > without generating it first, it will cause link time error. Just thought of a way around the link time error. We could add a guard around the EXTERN_C definitions, like 'HAVE_UUID' that way when someone wants those defines they would have to specify '-DHAVE_UUID' and we just have to make the assumption that if they specify the define then they must have generated libuuid.a. May not be ideal, but at least it is a solution. Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Earnie B. <ea...@us...> - 2006-05-23 11:38:18
|
Quoting Chris Sutcliffe <ir0...@gm...>: >> Does anybody have any ideas on how to proceed or are we at an impasse? >> Do we pull libuuid.a? > > One more thought, what about providing a script/batch file that could > be run against the uuid.lib provided by the Microsoft platform SDK? > We would not actually provide a libuuid.a, but rather the script > itself, it would then be up to the developer to use the script on > uuid.lib should they need it. This should take care of the legal side > of things since the developer would have agreed to the EULA in the > PSDK to obtain uuid.lib. > > My only concern with going this route is that should someone include > any of the headers that have an EXTERN_C reference to libuuid.a > without generating it first, it will cause link time error. > > Comments? > It misses the point of having distributable source set, IMO. However, as Danny points out the SDK C libraries are usable by recent GCC and binutils so it would be a matter of instructing the user to download the SDK for the files. Not something I treasure doing. Earnie Boyd http://shop.siebunlimited.com |
From: Greg C. <chi...@co...> - 2006-05-23 12:36:13
|
On 2006-5-23 11:38 UTC, Earnie Boyd wrote: > Quoting Chris Sutcliffe <ir0...@gm...>: [...] >> One more thought, what about providing a script/batch file that could >> be run against the uuid.lib provided by the Microsoft platform SDK? >> We would not actually provide a libuuid.a, but rather the script >> itself, it would then be up to the developer to use the script on >> uuid.lib should they need it. This should take care of the legal side >> of things since the developer would have agreed to the EULA in the >> PSDK to obtain uuid.lib. [...] > > It misses the point of having distributable source set, IMO. However, > as Danny points out the SDK C libraries are usable by recent GCC and > binutils so it would be a matter of instructing the user to download the > SDK for the files. Not something I treasure doing. Would that preclude using MinGW to develop GPL apps? I tried following the links at the bottom of this page http://en.wikipedia.org/wiki/Platform_SDK (presumably updated as ms moves its web pages around) but couldn't see an easy way to view the license. However, this seems troubling: http://www.linuxtoday.com/news_story.php3?ltsn=2001-06-20-018-20-NW-MS-SW 'Microsoft SDK license disallows the use of "viral software"' |
From: Michael G. <mg...@te...> - 2006-05-23 13:02:45
|
> > It misses the point of having distributable source set, IMO. However, > > as Danny points out the SDK C libraries are usable by recent GCC and > > binutils so it would be a matter of instructing the user to download the > > SDK for the files. Not something I treasure doing. >=20 > Would that preclude using MinGW to develop GPL apps? =46rom reading the below mentioned article: No. > I tried following the links at the bottom of this page > http://en.wikipedia.org/wiki/Platform_SDK > (presumably updated as ms moves its web pages around) > but couldn't see an easy way to view the license. >=20 > However, this seems troubling: > http://www.linuxtoday.com/news_story.php3?ltsn=3D2001-06-20-018-20-NW-M= S-SW > 'Microsoft SDK license disallows the use of "viral software"' _If_ I understand that correctly and also _if_ the article correctly cites the M$ licence than all that's forbidden is distribution of stuff that's part of the SDK, including possibly required DLLs. As long as the GPL'd app does not include any part of the SDK itself then IMO there is no problem with the licence. This is not so much different from the situation so far. After all we won't distribute any part of SDK today. The only difference comes for parties having purchased e.g. Visual Studio but using mingw for building the final executables/DLLs and distributing some parts like MSVCRT71.DLL together with their app. I'm not sure that would have been allowed in the past but it seems to be disallowed by this particular licence. =46WIW I do think the article in linuxtoday is wrong w/r to this statement: "This includes not being allowed to use open source/Free Software development tools in conjunction with the SDK, according to this EULA." I'm basing this on the following part of the cited licence: (ii) not using Potentially Viral Software (e.g. tools) to develop Recipient software which includes the Software, in whole or in part. The key part IMO is "which includes the Software". As long we don't include parts of the SDK we are safe (i.e. unless we link statically all is fine). Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Chris S. <ir0...@gm...> - 2006-05-23 13:26:15
|
> I tried following the links at the bottom of this page > http://en.wikipedia.org/wiki/Platform_SDK > (presumably updated as ms moves its web pages around) > but couldn't see an easy way to view the license. > > However, this seems troubling: > http://www.linuxtoday.com/news_story.php3?ltsn=3D2001-06-20-018-20-NW-M= S-SW > 'Microsoft SDK license disallows the use of "viral software"' The standard IANAL applies here... I've downloaded the platform SDK, and license seems to deal with distribution only. I've temporarily uploaded it here: http://emergedesktop.org/PSDK/License.htm As for the link to the license from the linux today story, it seems that it's no longer there, so I can't comment (not that I have the legal background to anyway). I would hope not though, given the number of GPL projects that I'm aware of that require the PSDK to be compiled on the Windows OS. Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Aaron W. L. <aar...@aa...> - 2006-05-23 19:52:54
|
Greg Chicares wrote: > However, this seems troubling: > http://www.linuxtoday.com/news_story.php3?ltsn=2001-06-20-018-20-NW-MS-SW > 'Microsoft SDK license disallows the use of "viral software"' This is obsolete. For a brief while, some of the MS SDKs (I don't remember which offhand.) were licensed under a completely stupid and over-reaching license that banned even using MS property along side GPL or BSD software, listing popular open source licenses by name. This appears to be what this article is referring to. The present license seems tame enough, and doesn't seem to these problems. However, I am not a lawyer, and this is not legal advice. |
From: Keith M. <kei...@us...> - 2006-05-21 18:56:22
|
On Sunday 21 May 2006 3:23 pm, Luke Dunstan wrote: > From: Danny Smith <dan...@cl...> > > > >The original author of this file extracted the *names* , not the > > actual 128-bit ID. > >How is that different from extracting the names of exports from system > >dll's to build import libs? > > > > > >Danny > > Yes, I agree that this is fine. Sorry guys, but I *don't* agree. The difference is that the system DLLs are *operating system* components; we may legitimately assume that every user of the OS holds a valid licence to deploy those DLLs. That legitimises, at least as I understand UK law, reverse engineering to achieve interoperability with those OS components. (And do please note that, while *I* am bound by UK law, it may be different for you), OTOH, uuid.lib is *not* an OS component; it is a component of a SDK, which independent developers may license individually. By the same criterion, those developers who *have* licensed the use of uuid.lib may reverse engineer the interface, if required, to allow them to link their own code against the library. They may then, if the SDK licence permits it, (as would normally be the case), distribute their own application in binary form. What they *cannot* do, (unless also permitted by the SDK licence), is redistribute the library itself; nor can they legitimately use the information they have obtained by reverse engineering of the original library, even if such reverse engineering is restricted to extracting only entity names, to create a replacement for the original library, which they then distribute; that simply cannot be construed as `reverse engineering for the purpose of achieving interoperability', and therefore does not satisfy the criterion for legitimate reverse engineering, IMO. Of course, if the necessary information can be extracted from the registry, the SDK licensing issue does not apply. The registry is the ultimate definition of the OS environment, in which *every* application must operate, and each and every application is therefore entitled to glean whatever information it requires, by whatever means are appropriate, from that resource. BTW, do we know how the original author established the 128-bit ID values, if only the names were reverse engineered? Regards, Keith. |
From: Michael G. <mg...@te...> - 2006-05-23 13:44:31
|
> Would that preclude using MinGW to develop GPL apps? >=20 > I tried following the links at the bottom of this page > http://en.wikipedia.org/wiki/Platform_SDK > (presumably updated as ms moves its web pages around) > but couldn't see an easy way to view the license. >=20 > However, this seems troubling: > http://www.linuxtoday.com/news_story.php3?ltsn=3D2001-06-20-018-20-NW-M= S-SW > 'Microsoft SDK license disallows the use of "viral software"' I've done some more thinking on it: I strongly doubt M$ is able to forbid using free tools _using_ any of their SDKs. _If_ they could do that they could also forbid the use of *any* non-M$ tool (not just free ones) and that in turn would violate the laws on free competition (or however it is called). The only thing they can prohibit is that by means of using free (or other) tools they do lose rights on their proprietary stuff and/or are e.g. obliged to publish their stuff under e.g. the GPL. IMO this is nothing new. New is only M$ explicitly discouraging the use of free tools. What I don't know is wether using uuid.lib from the PSDK would in fact imply statically linking to that lib, i.e. physically copy code from that lib into the resulting app. Not sure wether that would violate the "old" PSDK licence and/or the "new" version as cited in the linuxtoday article. I guess I'll have to think about that a bit more. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Chris S. <ir0...@gm...> - 2006-05-23 16:52:20
|
> What I don't know is wether using uuid.lib from the PSDK would in fact > imply statically linking to that lib, i.e. physically copy code from > that lib into the resulting app. Not sure wether that would violate the > "old" PSDK licence and/or the "new" version as cited in the linuxtoday > article. As I mentioned in my previous post, the license with the PSDK seems concern with distribution. We are not actually distributing any M$ libs, only linking against them (granted uuid is not a specific dll). Out of interest I modified the makefile of one of my apps to link against the PSDK libs and as Danny mentioned, it works like a charm. To that end, should we made w32api a collection of headers only with the libs being supplied by the PSDK? To Earnie's point, it does add the wrinkle of developers wanting to use the w32api needing to download the PSDK (which is no small download). Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Luke D. <cod...@ho...> - 2006-05-24 15:43:02
|
>From: "Chris Sutcliffe" <ir0...@gm...> >Reply-To: min...@li... >To: min...@li... >Subject: Re: [MinGW-dvlpr] Fwd: [Mingw-users] Re: w32api uuid.lib >generation for pocket pc >Date: Tue, 23 May 2006 12:52:14 -0400 > >>What I don't know is wether using uuid.lib from the PSDK would in fact >>imply statically linking to that lib, i.e. physically copy code from >>that lib into the resulting app. Not sure wether that would violate the >>"old" PSDK licence and/or the "new" version as cited in the linuxtoday >>article. > >As I mentioned in my previous post, the license with the PSDK seems >concern with distribution. We are not actually distributing any M$ >libs, only linking against them (granted uuid is not a specific dll). > >Out of interest I modified the makefile of one of my apps to link >against the PSDK libs and as Danny mentioned, it works like a charm. >To that end, should we made w32api a collection of headers only with >the libs being supplied by the PSDK? To Earnie's point, it does add >the wrinkle of developers wanting to use the w32api needing to >download the PSDK (which is no small download). > >Chris I think supporting the PSDK would be nice, but requiring it would be bad. For someone using a mingw-targeted cross-compiler from another OS, getting the PSDK would be difficult or impossible (although I can't see anything in the license prohibiting it). Luke |
From: Brandon S. <br...@oq...> - 2006-05-24 17:35:42
|
> > I think supporting the PSDK would be nice, but requiring it would > be bad. For someone using a mingw-targeted cross-compiler from > another OS, getting the PSDK would be difficult or impossible > (although I can't see anything in the license prohibiting it). > I myself do *all* of my development work on mac os x via a cross- compiler. In order to perform even the smallest bit of testing requires either a windows machine, or a VM. I use both depending on what i'm doing, but since that's the case, installing the PSDK in my VM is quite handy, both from a headers/libs standpoint, but the help is included too. It was very easy to install on the VM (and my windows machine) and then copy the include/lib dirs to my mac. The main reason i opted to install the PSDK in the first place is that testing of mingw and the PSDK i mentioned previous message. Being forced to install it to get the uuid.lib is a big turnoff. I realize there's not a whole lot of options, but it seems this project itself is a bit short of contributions outside of the core group, and that requirement would further alienate us. I would conjecture that the reason our usage seems lower (compared to most other win32 compilers) is because of incompatibilities with the PSDK and/or lack of an all-encompassing win32 api of our own. GCC is appealing to me because of its flexiblity compared to the MS tools and the fact that its open. I'm not necessarily in need of the GPL itself, and for me if the PSDK worked well with mingw out of the box, it would be a no-brainer. I know i can't speak for everyone out there, but it seems like the vast majority of people who would use mingw on a project would opt for that as well. B |
From: Greg C. <chi...@co...> - 2006-05-24 23:04:34
|
On 2006-5-24 17:35 UTC, Brandon Sneed wrote: >> [On 2006-5-24 15:42 UTC, Luke Dunstan wrote:] >> I think supporting the PSDK would be nice, but requiring it would be >> bad. > > [...] I know i can't speak for everyone out there, but it > seems like the vast majority of people who would use mingw on a project > would opt for that as well. Speaking for myself and my six coworkers only, supporting the PSDK would be irrelevant to us, but requiring it would be inconvenient to say the least, and conceivably perilous. Our GPL project already depends on a handful of free libraries. Building it on msw (which all current end users require) depends on the cygwin or mingw/MSYS toolkit. We keep a copy of every dependency on a CD, to create an "instant developer environment" when we hire a new employee or get a new computer. Yet even the less-malignant version of the ms EULA, which Chris Sutcliffe posted a link to here the other day, forbids that in its "Transfer" clause. If all of us just have to download our own copies whenever we work on a new computer, that's pretty inconvenient. If we add a dependency on software that's not free, and indeed has a license inimical to free software, then FSF might not be willing to continue hosting us at savannah.nongnu.org . That would be really inconvenient. It appears from recent discussions here that ms has changed the license in the past. Maybe one day they'd make it illegal for us to build our program with any gcc version that requires the PSDK. That would prevent sales of about US$1,000,000,000 per year and imperil the jobs of two hundred people. Speaking for those people too, I can't afford to take that risk. Maybe you're right, and the vast majority of people don't care, but then I'd point out that the vast majority can eat peanuts without anaphylaxis. |
From: Chris S. <ir0...@gm...> - 2006-05-24 23:44:18
|
> Speaking for myself and my six coworkers only, supporting the PSDK > would be irrelevant to us, but requiring it would be inconvenient > to say the least, and conceivably perilous. This seems to be where we are stuck. Supporting the PSDK seems to be considered by all a Good Thing (TM), but requiring it is not. As it was pointed out, the HKEY_CLASSES_ROOT\Interface key can be used to determine the IID values for the names contained in the headers, but does not contain the CLSID or CATID values. Tracking down these CLSID and CATID values is problematic at best (I have yet to find a source). Without these CLSIDs and CATIDs, the IIDs are basically useless. So I guess it's a matter of where do we go from here? Do we use the url with the 'uuid_objs.d' file (given that we don't know the source of the values contained in that file either)? Using WINE is an issue given the license and the fact that it's not clear how they determined the 128-bit IDs. Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Michael G. <mg...@te...> - 2006-05-25 05:59:42
|
> As it was pointed out, the HKEY_CLASSES_ROOT\Interface key can be used > to determine the IID values for the names contained in the headers, > but does not contain the CLSID or CATID values. Tracking down these > CLSID and CATID values is problematic at best (I have yet to find a > source). Without these CLSIDs and CATIDs, the IIDs are basically > useless. Drop me note once you've found that -- that's where I'm stuck with my previously anonunced perl script... :-( > So I guess it's a matter of where do we go from here? Do we use the > url with the 'uuid_objs.d' file (given that we don't know the source > of the values contained in that file either)? Using WINE is an issue > given the license and the fact that it's not clear how they determined > the 128-bit IDs. I don't think using the 'uuid_objs.d' file is possible unless we know the source of the information. Someone (no longer recall who) had suggested to put the info obtained by reverse engineering uuid.lib into a headerfile. IIRC the consensus was that that's probably safe as we only provide info required to achieve interoperability. I still don't think that generating our own version of uuid.lib by the same means can legally be prohibited for the very same reason: otherwise interoperatability can't be achieved. But I'm not in the position to actually challenge any such position in court should that be required. So my proposal is to create the aforementioned headerfile. Best, Michael PS: After reading the rest of this thread: I don't think dropping w32api would be a good idea. Since almost all of the cons have already been voiced I won't reiterate them. =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Brandon S. <br...@oq...> - 2006-05-25 00:21:15
|
On May 24, 2006, at 4:04 PM, Greg Chicares wrote: > Speaking for myself and my six coworkers only, supporting the PSDK > would be irrelevant to us, but requiring it would be inconvenient > to say the least, and conceivably perilous. > > Our GPL project already depends on a handful of free libraries. > Building it on msw (which all current end users require) depends > on the cygwin or mingw/MSYS toolkit. We keep a copy of every > dependency on a CD, to create an "instant developer environment" > when we hire a new employee or get a new computer. > I wasn't advocating dropping w32api support for the other. However, if you have to depend on the psdk to build libuuid.a you're still in the same boat if you ever need that lib. > > If we add a dependency on software that's not free, and indeed > has a license inimical to free software, then FSF might not be > willing to continue hosting us at savannah.nongnu.org . That > would be really inconvenient. i think that would apply to the current proposal which depends on a psdk lib as well. > > It appears from recent discussions here that ms has changed > the license in the past. Maybe one day they'd make it illegal > for us to build our program with any gcc version that requires > the PSDK. That would prevent sales of about US$1,000,000,000 > per year and imperil the jobs of two hundred people. Speaking > for those people too, I can't afford to take that risk. > and maybe someone will get the GPL license invalidated. if you work solely based off of unknowns you won't get anywhere. sure MS changing the license is more likely to happen, but the likelihood of it being done in the way which you describe is just as far fetched. > Maybe you're right, and the vast majority of people don't care, > but then I'd point out that the vast majority can eat peanuts > without anaphylaxis. > I see your point, however i wasn't proposing to drop w32api, but instead to put some focus on getting mingw to work with the psdk better than it currently does. Certainly one size doesn't fit all, evident because we're all using mingw rather than msvc, however options are good and having a PSDK option is good for mingw i believe. B |
From: Danny S. <dan...@cl...> - 2006-05-23 02:41:58
|
> Does anybody have any ideas on how to proceed or are we at an > impasse? http://svn.dsource.org/projects/bindings/trunk/uuid_obj.d Danny |
From: Earnie B. <ea...@us...> - 2006-05-23 11:32:21
|
Quoting Danny Smith <dan...@cl...>: > > >> Does anybody have any ideas on how to proceed or are we at an >> impasse? > > http://svn.dsource.org/projects/bindings/trunk/uuid_obj.d > This looks good and the license is correct. Earnie Boyd http://shop.siebunlimited.com |
From: Chris S. <ir0...@gm...> - 2006-05-23 13:08:31
|
> >> Does anybody have any ideas on how to proceed or are we at an > >> impasse? > > > > http://svn.dsource.org/projects/bindings/trunk/uuid_obj.d > > This looks good and the license is correct. Are we safe to use this as a replacement then? I'd be willing to convert this to uuid_obj.c. I assume we should just reference the url in note at the top of the file? Chris --=20 Chris Sutcliffe http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Michael G. <mg...@te...> - 2006-05-23 13:13:58
|
> > http://svn.dsource.org/projects/bindings/trunk/uuid_obj.d > > >=20 > This looks good and the license is correct. Do we know the source of the information in uuid_obj.d ? I mean do we know it has not been derived by reverse engineering M$'s uuid.lib Just asking, best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |