[ros-dev] Bye bye

[Kai Moonbourn]

Might I remind you that, not withstanding someone hiring legal help to do
this, the "opportunity" for someone such as a judge to determine legality of
ROS's code would probably only occur only after ROS was in some pretty nasty
legal trouble, which I think we'd all like to avoid.

What any individual dev "thinks" is honestly quite irrelevant. What matters
is what a (potentially hostile) judge will think when presented with two
near-identical pieces of code.

On 1/19/06, Brian <briandabrain at gmail.com> wrote:
>
> Beautiful. I am happy. Alex, from what i have seen, i agree with the
> "black sheep" statement. I haven't seen a better msg on the list since this.
> Now that makes me feel that my work is done.
> I will continue to watch the project, but i feel to useless not working on
> it, and realy am not comfortable with the code (I am a *n*x clone kernel
> programer myself ). I plan to write an OS of my own soon ( "AHGG, Not
> another enama!!!" ) and may look for help. I will keep a link on my site up
> to reactos.org, but for now, until a day i am needed again...
>
>
> brian
> friend of reactos
> my site: <psudobuddha's site> <http://www.metawire.org/%7Epsudobuddha>
>
> On 1/19/06, Alex Ionescu <ionucu at videotron.ca> wrote:
> >
> > Hi,
> >
> > I'm going to answer generically, not point-by-point, since I don't have
> > much time, but I hope I can cover everything:
> >
> > 1) Those magic sizes were calculated in my head and I didn't have time
> > to make them into constants as I did many of them.
> > 0x29C is the pre-defined value of NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH.
> > 0x48 is the differerence in the KTRAP_FRAME between the registers that
> > we will skip. I could've done (KTRAP_FRAME_XXX - KTRAP_FRAME_YYY).
> >
> > 2) This is not a matter of driver compatibility. The fast system call
> > stub is a mostly hardware-defined entrypoint, handled by low-level
> > software logic. In implementing it, there are only 3 available sources
> > of information: Whatever minimal info the Intel manual gives, the Linux
> > sources, the Windows kernel binary. It is almost simply impossible to
> > "guess" how the stub should work. Filip tried to make it work more then
> > a year ago, and even he gave up (the AMD version), beacuse it is simply
> > too hard and confusing unless you have some available code to look at.
> > As such, my first and foremost source was the Linux source code. It
> > helped me understand how to setup the LSTAR MSR register, as well as the
> > other register values. Then, through several mailing list posts, I was
> > able to understand some bugs in the way ReactOS had its segments set up,
> >
> > which caused problems in the code. Then, to understand the way Windows
> > chose between INT2E and SYSENTER, I found a document online written by a
> > person called Elicz, which described the stub and what it should do,
> > much in the same way people argued "clean-room reverse engineering" is
> > done. With this information, I was able to write more then 85% of the
> > stub. My next, and final remaining possible step, was to use IDA to look
> >
> > at the Windows code. I used it as a learning tool, not as a copying
> > tool. It is hard to argue that what I did was "Reverse-engineering",
> > which, to my knowledge, implies taking something apart to re-create it,
> > since this usually implies converting the assembly code to functional C
> > code or otherwise. But I don't view as looking at assembly in order to
> > understand a low-level hardware interface as "reverse engineering". And
> > yes, as described above, it -was- my last choice. Additionally, the
> > parts which were supposedly "copied" are NOT part of the functional part
> > of the code. They are debug helpers, offering nothing else but
> > assertions in case of problems.
> >
> > 3) I find the idea of removing code that "Violates policy" ludicrous. No
> > one has the right to dermine if some piece of code violates policy or
> > not, especially if the author writing it denies it. Only a judge or
> > lawyer should be able to make that decision. Additionally, in this
> > specific case, what could be done? The code is in SVN and even if
> > rewritten it will 1) look the same, excpt "edx" would become "esi" and
> > vice-versa 2) a judge would still argue that "hey, you had the previous
> > code in SVN for over a year, you've all been tainted and could've just
> > as easily looked at it". Furthermore, such attitude might start
> > devolving into a dangerous witchhunt. Don't like someone's code? Report
> > them and have it removed! This communist-era and fascist-era behaviour
> > deeply scares me and reminds me of a country and regime which I fled. I
> > do not want to see it happen, because it would slowly kill and rip apart
> > this project.
> >
> > These monthly Alex-bashings are starting to tire me very much and maybe
> > it's time I took an offensive position instead of a defensive one. I do
> > not want to start naming names, but many of our developers have already
> > violated our policy in different ways. If you actively start enforcing
> > it, then it will be my duty as an active developer to enforce it as
> > well, meaning that hiding any information I have concerning other
> > developers' violations would be considered as complicity, so I would be
> > legally bound to report them. In other words, this would mean that the
> > project would lose half of its developers.
> >
> > I am sick of being treated as the black sheep and the "example". This
> > stops here. I have always been put in the spotlight for almost any
> > action I took, and I've always taken steps to repair it. But these
> > public trials of guilt have passed a limit. Either start questionning
> > everyone and treating every developer the same, or stop using me as a
> > tool.
> >
> > Best regards,
> > Alex Ionescu
> >
> > Steven Edwards wrote:
> >
> > >On 1/19/06, WaxDragon <waxdragon at gmail.com> wrote:
> > >
> > >
> > >>You are not a judge with years of experience in law. Whether or not
> > >>you have any kernel internal knowledge is also irrelevant to this
> > >>thought experiment.
> > >>
> > >>
> > >
> > >No but I am someone trying to be objective that has spent a good part
> > >of the past few years reviewing case history for reverse engineering
> > >cases. Its more than we are going tot get from some judges.
> > >
> > >
> > >
> > >>>Why did you have to do this? Is it not possible to write a driver
> > that
> > >>>abuses fastcall to make a mostly working implementation without
> > having
> > >>>to 1. look at and 2. copy the existing object code of Windows?
> > >>>
> > >>>
> > >>Alex clearly stated that there is only one way to perform that stack
> > >>check, let's quote him properly:
> > >>
> > >>"Note however, that there is only one way to check the stack: cmp ebp,
> >
> > >>esp. Unless you want to consider cmp esp, ebp as an alternate method."
> > >>
> > >>As Casper said, it is legal to use that information, but not legal to
> > >>*copy/paste* it into ReactOS.  Alex clearly comprehends what that bit
> > >>of assembly does.
> > >>
> > >>
> > >
> > >Once again he may have stated this but he also states he disassembled
> > >Windows. The issue is the methods used to gather the information.
> > >Reverse engineering is legal if there is no other method to gather the
> > >information which is why I clearly asked "Was there no other way to
> > >get this information" or let me put it another way....
> > >
> > >Alex: did you even bother doing some sort of clean room examination of
> > >Windows behavior based on third party drivers or some sort of testing
> > >or was IDA your first step? Checked Microsoft driver assertions and
> > >debug symbols don't count.
> > >
> > >
> > >
> > >>>OK so someone else sneaked something in that violates the rules and
> > it
> > >>>was not caught. Lets just check your argument for a moment and say
> > you
> > >>>could be wrong about your development methods. Being ..."clearly
> > >>>commented, organized and structured..." does not amount to a hill of
> > >>>beans if I am violating the law and or project rules. I can make bank
> > >>>robbing plans that are "...clearly commented, organized and
> > >>>structured..." I don't think that will gain me much ground in court.
> > >>>
> > >>>
> > >>This analogy is invalid.  The legality of this issue stems directly
> > >>from whether or not he wrote the code.  Robbing a bank is _always_
> > >>illegal, writing code is only illegal if you copy/paste it from a
> > >>legitimate author, or implement a patented method.
> > >>
> > >>
> > >
> > >No its perfectly a valid question. In law there is this concept called
> > >Mens Rea which means intent. Was his intent to create a independent
> > >unique work he himself created and he just needed the information for
> > >compatibly reasons or did he intend to just make it work without
> > >caring of the consequences to everyone else. Hence the question above.
> > >Was IDA the first step or the last?
> > >
> > >
> > >
> > >>Alex's structured and commented code demonstrates comprehension.  In
> > >>this case, where the code's function is clear, and constrained by
> > >>implementation details, the code will be similar by anyone who
> > >>implements it.  Alex's comments and code structure shows that he
> > >>understands what is going on in the assembly, and most likely shows
> > >>that he wrote the code, as opposed to just copy/pasting existing code.
> > >>
> > >>
> > >
> > >Just because he understands the code now is irrelevant. Its the method
> > >of which that understanding came. Because our work is going to be
> > >similar to windows the arguments about a derived work hangs upon the
> > >notion that we are independently creating our own implementation
> > >rather than looking at the original. We can read documentation about
> > >the original all day long, we can examine applications and drivers
> > >that use the original all day long but when we start to crack open the
> > >book of the original implementation we run the legal risk of being
> > >declared a derived work.
> > >
> > >
> > >
> > >>It only looks suspicious since you are not a kernel developer.  Again,
> > >>not something a judge would concern himself with.  Now the
> > >>prosecutor.....
> > >>
> > >>
> > >>
> > >>>    /* Skip the other registers */
> > >>>    sub esp, 0x48
> > >>>
> > >>>
> > >>>
> > >
> > ><snip>
> > >
> > >
> > >
> > >>>ie.  why 0x29C, why 0x48?
> > >>>
> > >>>
> > >>Since he is making room on the stack for another frame, this is a
> > >>predefined size.
> > >>
> > >>
> > >
> > >Hmm ok. So another size won't work? Where is it predefined? I ask not
> > >to accuse but to try to understand to be fair to all parties involved.
> > >But according to Hartmut this is a clear case of copy and paste. This
> > >is why we cannot allow this to continue. If dirty-room reverse
> > >engineering was the last resort then it would be a original
> > >implementation
> > >
> > >
> > >
> > >>further.   Now, I do agree he could have used the safer "clean-room"
> > >>method, but I'm not convinced that it would have yielded a
> > >>significantly different implementation, and we might still be in the
> > >>same position.
> > >>
> > >>
> > >
> > >You admit that his implementation was not based on "clean-room". My
> > >question once again was why did it have to be dirty room? If there is
> > >no other option for making a compatible implementation then this
> > >discussion holds no water but if by your own words he could have used
> > >a safer method then there is a problem.
> > >
> > >So we are back to the first question. What development methods were
> > >used. IDA first or last?
> > >
> > >--
> > >Steven Edwards - ReactOS and Wine developer
> > >
> > >"There is one thing stronger than all the armies in the world, and
> > >that is an idea whose time has come." - Victor Hugo
> > >
> > >_______________________________________________
> > >Ros-dev mailing list
> > >Ros-dev at reactos.org
> > >http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > >
> > >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev at reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20060119/fc9ab45f/attachment-0001.html