mailing list archives
Re: The Trillian GPL violation allegations are confirmed false.
From: Tobias Weisserth <tobias () weisserth de>
Date: Mon, 01 Mar 2004 21:38:22 +0100
Am Mo, den 01.03.2004 schrieb Valdis.Kletnieks () vt edu um 19:20:
On Sun, 29 Feb 2004 01:54:51 +0100, Tobias Weisserth <tobias () weisserth de> said:
(Note - although my name got dragged into this, I'm not at all privy to what
the actual Trillian code looks like... I just contributed a Gaim "off by one" fix that
happened to be in the code section in question).
Question: If Cerulean Studios let GAIM use parts of their codebase, how
can the GAIM people license this under the GPL?
Because I'm told they shared *algorithms*, not actual code. And copyright
and GPL don't enter into it.
There is rather strong evidence the code is too similar to be based on
the same abstract algorithm only. I gladly forward you to the issues
Stefan Esser has already investigated.
"What you need to do is loop across the packet while doing this..."
You might still have patent or trade-secret issues, but there's no copyright
issue at that point.
If indeed no code has been shared. But this I believe. See below.
There are enough clients that can connect to the Yahoo network and which
haven't been vulnerable to the GAIM exploits (which were buffer
overflows mainly if I remember correctly).
If the shared algorithm had a bug (such as "oh, and don't forget to do this")
then of course both implementations will be broken.
Abstract algorithms do not have real-world exploitable buffer overflows.
Real-world implementations of abstract algorithms do have buffer
overflows. I just can't believe the "coincident" explanation of two
similar implementations when there are virtually a dozen other ways to
do it and even do it better.
Bugs can creep through even the best Chinese-wall development - if the original
has a bug, the team doing the reverse engineering will probably have the bug in
the specs that get handed across the wall, and as a result the code written
will be bug-compatible.
See above. Please give an example of an abstract algorithm (maybe in
pseudo-code) that contains a real-world exploitable buffer overflow.
This is only possible if this abstract algorithm already has been
described in a real language, say C# and that makes it more than just an
abstract algorithm, it makes it C# source code.
At a previous gig, a co-worker of mine wrote an emulator for a Tektronix 4027
graphics terminal to run on a Zenith Z-100. Working only from published specs
and "what does a real 4027 scribble on the screen" he found his program
produced different results for certain color-fill operations with some complex
self-intersecting polygons - which he tracked down to a bug in the 4027
firmware, and then reproduced in his software to be bug-compatible. All without
access to any proprietary Tektronix information....
I fail to see how this incident relates to the GAIM/Trillian
To be absolutely clear about my intentions and why I'm that interested
in the matter: I don't care who gave code to whom. But I want it
properly documented, at least in the GPL GAIM sources that are available
to the terms of the GPL to other developers. Suppose someone uses the
GAIM code in another GPL project and years later someone from Cerrulean
Studios turns into some Darl McBride and starts crying out loud. How is
this forked GPL project to defend against future claims if they can't
rely on a clear documentation in the GAIM sources where their code came
from? Maybe right now nobody from Trillian is claiming GAIM somehow
released code under the GPL without permission from Trillian but suppose
years later someone from Trillian does?
This is a risk issue. In the interest of the usability of the GAIM code
under the GPL it has to be documented clearly and without a doubt where
which code came from under which terms.
The "coincident" creation of the code is not really believable. When
there's supposedly no problem involved here then why do I have the
impression that people are not honest about the sources?
Full-Disclosure - We believe in it.