Mike Kienenberger schrieb:
Looking at someone else's code and then writing your own version is a no-no.
However, there's a legal way to deal with it. Clean-room reverse engineering.
Here's an example of how it was done with wireless driver support for
linux -- good overview of the proper process.
http://bcm-specs.sipsolutions.net/ReverseEngineeringProcess
Werner can write specs of how it should work (which it sounds like he
has already done). Just be careful not to say how to implement the
behavior.
Ok this will become long because the entire area is not as easy as it
first looks:
First of all I did not post anything regarding all this for two days
because I kind of was frustrated to push down valid work down the
gutters, but anyway I decided to sleep things over to calm my temper
which is always the best to get a clean head before going into the
discussion again. So I can post again now:
Ok if we need to go with clean room the following stuff is feasable.
So what can we do in a real clean room environment:
Run your code against the RI binaries, and check the protocol details
yes
Patch the original code to run your code against the RI which I did with
the tag handler, no unless you never ever touch the patched part again -
although definitely valid with the Apache license.
Looking at the code to find out about unspecified implementation details
which otherwise might corrupt the compatibility also a no go, although I
personally think it still is valid regarding the Apache license, and
legal pretty much confirmed me that with their answers, but we are not
talking about the Apache license here.
Reading the Specs, yes, reading the javadocs of the spec, probably the
same although they might be under the same license as core code (gotta
check that), now that becomes even fishier, because about 30%-40% of the
spec are within the javadocs. So there is no way you can even remotely
deal with the implementation without having read the javadocs.
So unavoidable to read those.
Those are the only things I can think of on how to deal with clean room
stuff.
Also what we need is someone who checks the commits against RI code so
that no code is slipped in which might stem from the other project
that must be a person who himself cannot commit himself but can look at
both codebases, sort of a constantly ongoing auditing. So that means
this person cannot ever again touch the core codebase and is delegated
to auditing only
and probably cannot even talk about details of the other implementation.
(So we purely can only rely on the spec and send in some holes we found
instead of fixing them as good as possible by asking someone)
Have in mind this is all corporate criteria not Apache criteria , Apache
criteria is that we cannot mix the codebases due to incompatible
opensource licenses, and Harmony has applied the tighter rules because
they went against a closed source implementation (with attainable
sources) and the project was under legal fire from day zero. Which was
absolutely correct at that time.
Curtiss please correct me if I was wrong in this regard, but thats how I
understand the policy of the corporate entity you work for with all the
background I know from the last 20 years of computing history.
Werner
