[ros-kernel] Copyright/IP issues and ReactOS

[Vizzini]

On Thu, 2004-02-26 at 05:38, Jonathan Wilson wrote:
> 1.How can you take a Microsoft definition (from a .H file, from MSDN, from 
> wherever) and include it into ReactOS wihout the (C) MS problems of my 
> patches? Given that our definitions need to match those from MS, we need to 
> come up with an answer on this one.

It's easy:  You look at it, you understand what it has to do (in a
similar way that a compiler would), and you independently design and
code something that works exactly the same way.  You may use the same
types and formal parameter names (in order to foster compatibility with
Microsoft code), and you must use exactly the same number of arguments,
same "base" types (i.e. bit width, signedness, etc), and they must be in
the same order.  Please abide by Eric's suggestion from yesterday, and
do not copy the general layout of Microsoft prototypes.  I think Eric's
way is fine, or you can use the one I've been using lately:

NTSTATUS NTAPI FunctionName(ULONG Arg1,
                            ULONG Arg2)
/*
 * FUNCTION: A function to function on things
 * ARGUMENTS:
 *     Arg1: The number of words in War And Peace (English)
 *     Arg2: The number of those words you actually read in school
 * RETURNS:
 *     STATUS_SUCCESS when it feels like it
 *     STATUS_FAILURE when it is sad
 * NOTES:
 *     - Only call when you are wearing a blue hat at the time
 */
{
}

> 2.With the recent source leak, the definitions to even more items that are 
> not documented in MSDN/PFSDK/other public sources are available.

In case we haven't said it enough:  do NOT look at the source.  If you
do, our current policy is that you will be banned for life from
committing.

> But even discounting the source leak, there are things like the IFS kit and 
>   such that contain definitions that arent officially public.

You have an interesting definition of public.  Anyone on this list can
pay MS the $1k and accept the EULA and get the kit.  I must admit that I
have not read the NDA, however, but I don't think it covers the
informational content of the header files (I am under the impression
that it is mostly for non-disclosure of the samples).

> Assuming we had an answer to point 1 above, following the same steps here 
> as for public definitions would remove the (C) MS problems but are there 
> any other issues with using definitions that arent officially public but 
> have become public anyway? (IANAL but from what I have read, once something 
> is public, Trade Secret protection doesnt apply anymore but I could be wrong)

IANAL either, but I think you're right about the trade secret question. 
Exactly the same process from (1) above would apply here.  Read,
understand, and re-code from scratch.

> and 3.Another issue is if someone was to look at the leaked code and from 
> there figure out what an undocumnented function does or what happens in an 
> undocumented corner case or when wierd arguments are passed to a function 
> or whatever (for example, all that work I did on windows, classes, window 
> procedures etc, most of that counts as "undocumented behaviour"). Assuming 
> that the info that was learned was not a Derived Work of MS code (it is 
> possible to document what a piece of code does without that document being 
> a derived work of the code), are there any other issues that would come up 
> from using said documentation in ReactOS development?

This is a legal rat's nest, and at the moment, our policy is that you
must not look at the leaked Windows source code for any reason.  I plan
on reviewing these policies in a couple of months, but meanwhile, the
source is off-limits, period.

> No, I havent seen the leaked source code but given that its out there, 
> someone who has will try and provide this kind of info to ReactOS and we 
> need to have clear policies in place to make sure that we know how to deal 
> with it (especially if, as is almost certain, its not specificly labeled as 
> comming from the MS source code, so saying "anything that mentions the code 
> is no-go" wont work)

ATM, I'm inclined to be very conservative.  If I have reason to believe
that the coder looked at the leaked code, I'll recommend it for removal
from CVS, or if it's a patch, I won't commit it.  If I believe that any
code is copied and pasted from anywhere at all that isn't public domain,
the same will apply, unless we have explicit license to use it (like
Wine).

If I don't have reason to doubt the origin of technical information,
I'll be happy to take it.  We can always use good information.

Is this clear enough?

 -Vizzini