[gst-devel] Ideas for clean room policy

[David Schleef]

On Tue, Feb 12, 2008 at 06:25:06PM -0600, Brian Cameron wrote:
> 
> In relation to the recent addition of swfdec to the GNOME platform
> the GNOME Foundation has been discussing whether it would be good
> for the Foundation to have a clean-room policy for reverse
> engineering of specs like SFW.
> 
> I was wondering if there might be anyone in the GStreamer community
> who might be able to help the GNOME Foundation with putting together
> such a policy?  Is anybody aware of a good cleanroom policy that the
> GNOME Foundation could borrow?

I don't know of many projects that use reverse engineering of software
as opposed to black box testing and/or simple hex dumping and analysis
(i.e., reverse engineering of a *protocol*).  I think some of the Linux
driver projects, and perhaps nouveau, might use actual reverse engineering
of software.

Reverse engineering of *protocols* by (for example) analysis of a file
or packet sniffing is completely legal, so doesn't need a policy.

Swfdec was written using available specifications and (more so now)
black box comparison to the Adobe player.  Some of the DVD code in
GStreamer was helped along by hex dumping and analysis of lots of
DVDs, i.e., reverse engineering a protocol.  But neither of these
are reverse engineering of software, which is where the trouble is.

A simple policy would be:

 1. Don't read privileged code.

 2. Don't hexdump, disassemble, or decompile proprietary binaries.

I think this is the policy that most people follow intuitively anyway.
Of course, this policy cuts out a lot of clearly legal reverse engineering
activity.  But IMO it's not activity that is common or necessary.



dave...