On 7/19/2010 8:35 AM, Earnie wrote:
> Well, IANAL either. However, this smells like reverse engineering. But
> looking to http://en.wikipedia.org/wiki/Reverse_engineering we have many
> examples of other projects using such techniques to discover
> undocumented Windows details. And reading the "Legality" segment of
> that document I can support the use of such a program for such findings.
> However, let's have Keith's opinion on the matter.
As bad as the recent legal climate in the US is with respect to computer
software, the EU and the UK appear to be worse.
It appears that reverse engineering for interoperability is allowed
everywhere, but not for replacement. However...while our w32api may
substitute for the Windows SDK, its actual purpose is to allow
interoperability of code generated by MinGW (that is, gcc) with the
Further, as Earnie notes, "interfaces" themselves are not protected
under copyright. A specific realization of those interfaces, as a
collection (such as the entire Windows SDK, or w32api itself), might be
-- but the actual interfaces themselves are not.
So, I think black box reverse-engineering is OK (studying only the
inputs and outputs of specific programs). White-box reverse-engineering
(*) is PROBABLY ok -- for interop purposes only -- given the
non-copyrightability of interfaces. cut-n-paste is definitely out.
FYI, in recent private conversations with the mingw64 people, they've
made the claim that all of their "w32api" interfaces were developed,
independently of Anders Norlander's (or our) w32api code, AND
independently of the Windows SDK, completely by reverse engineering. The
implication is that they used a white-box approach. I'm awaiting more
IANAL, etc etc.
(*) One team studies the actual code -- disassembles existing binaries,
or studies the Windows SDK itself, and creates documentation describing
the discoveries (**). A separate team uses that documentation to
generate the new implementation.
(**) Note that in some jurisdictions, this documentation may not be
published; only used internally. That makes white-box reverse
engineering difficult for open source collaboration in those
jurisdictions; it appears the documentation must be held in private and
used only by the organization that developed it. But how exactly do you
limit publication when the organization's members are "anybody with an
sf.org account that volunteers to help"?