Bug#381263: gyachi 1.1-61-1
Sorry about the poor formatting. ymail just plain sucks in the reply dept.
I'll tag my replys with "**"
--- On Thu, 4/2/09, Eddy Petrișor <eddy.petrisor@gmail.com> wrote:
From: Eddy Petrișor <eddy.petrisor@gmail.com>
Subject: Re: Bug#381263: gyachi 1.1-61-1
To: "Greg Hosler" <mr_gyachi@yahoo.com>
Date: Thursday, April 2, 2009, 5:58 PM
2009/4/2 Greg Hosler <mr_gyachi@yahoo.com>:
>
> Got your file list. Thanks. It's really not as bad as it looks, and I can
> fix most fairly easily and fairly quickly.
Great. You'd probably want to foward this info t the Debian BTS (just
CC the mail to 381263@bugs.debian.org).
I am not cutting anything from this reply to make this easy for you.
> All the gyvoice files are from an earlier version of wine. not
> sure why the copyright was yanked. actually I have some guesses.
> the code necessary for gyachi was a small subset of wine, and the
> files were just hacked, removing anything not explicitly necessary.
> In the process of the hacking, that's almost certainly where the
> copyright (and a lot of other extraneous stuff) got dropped. Adding
> back in the respective copyrights is probably doable.
Or is possible that wine didn't had those at that time. Can't you use
some library instead of that embedded copy of the loader?
** Wine almost certainly had copyrights at the time. :)
BTW, is gyachi usable without any windows dll files? I see that there are no dll files in the source, but a wine interface, why is it needed?
** GyachI needed a way to load and callback a dll. Wine
** does a WHOLE LOT more than that. In fact, last year
** i looked at replacing the gyvoice directory with winelib
** calls. The problem is that wine *is* an emulator, DESIGNED
** for running window exe's (as well as for loading dlls).
** GyachE only needed the DLL loading capability, and so the
** necessary wine suport was *GREATLY* hacked to eliminate as much
** of wine as possible. What's left is stubs of the original
** (except the dll loading portions).
** This, by the way, is what other codec players have ALL done (as
** pointed out to me by people on the wine-devel list. Projects
** like mplayer, avifile, etc, all hacked wine to get the dlls
** loaded. One would think that someone would have made this a
** separate library, with use that it has seen...
**
** :)
** Re: the dll files.
** the DLL are only for voice chat, and in fact, there is a
** configure option for disabling voice chat altogether (which
** in fact eliminates the gyvoice PE code from ever being compiled.
** I added that configure option when GyachI was added to Fedora.
** it became necessary in order to compile on X64 (and PPC). Anything
** where wine won't run.
** there are 2 codec files. They are available if you hunt around on the
** internet. The true speech codec dll files. They are a side project
** of the gyachi project, and you can find them at sf. They USED to
** be part of the code base. Obviously that was a problem. I received
** a LOT of vocal flak from one particular individual (but a lot of
** support from others) when I conditionalized, and removed the codes
** from the codebase.
** if gyvoice happens to be enabled, and the codecs aren't found, then
** you will see a popup stating which of the 2 coded files (or both)
** cannot be found. gyvoice is then disabled. So no harm is done
** by leaving it enabled
> the client/gyachi_icon_defs.h file i actually added (with other files
> along the way. I just forgot to update it with proper copyright before
> commiting it. That can and will be done.
Cool.
> The md5.* files DO have copyright, and I don't see these files being in
> conflict w/ gpl.
Indeed, it is some sort of BSD-like lincese.
> The crc32 - worse case I have a public domain version that I can replace
> this with if I can't locate a gpl'd version (or I'll borrow the gpl
> version from coreutils).
Either one of those two (public domain or GPL will do).
> the sha.* files. I'm tempted to just make those 2 files a library, which
> gyachi links against. Seems like that would solve that particular issue....
Unfortunately linking GPL code against a MPL-ed code is not a compatible
mix of licenses. Simply put, you can't mix MPLed and GPLed code together,
neither by static nor dynamic linking. You must replace this sha
implemenation with another one that is GPL-ed, LGPLed, BSD or public
domain licensed
I am sure there are many sha implementaions with have such a license.
** I actually spent a bit of time looking last night. It wasn't as
** straight forward to find as one would think. The actual reference
** work is out there, and this actual code. some perl code, and a lot
** of wiki stuff, and papers.
** I'm also aware that coreutils has implementations of crc32 and sha160
** so worse case, I'll borrow that code...
> The autogen.sh script. I'll add the necessary copyright / attributions.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
** All the best,
**
** -Greg Hosler
** principle GyachE developer
Reply to: