Re: [ros-kernel] Proposed ReactOS headers and code sharing policy

[Eric Kohl]

"Vizzini" <vizzini(a)plasmic.com> wrote:
> Executive Summary
> -----------------
>  - Use MinGW for all public interface headers, i.e. everything that
> MinGW supports
>  - Use non-OS-specific Wine libraries unmodified
>  - Use portions of OS-specific Wine libraries (e.g. user32)
>  - Keep it all straight with CVS vendor branches
>
> Details
> -------
> For headers, we will use MinGW as our external interface in all cases
> that MinGW supports, including kernel-mode code (i.e. the DDK).  We will
> submit patches to MinGW when we find problems with the public
> interfaces.  There is the added benefit of having a compatibility check
> against our public interface.

One important detail was missing from the discussion. Kernel-mode and native
code (ntdll, smss, etc.) does _not_ know about Win32 types, like BYTE, WORD,
DWORD, INT, UINT or the LP* types. Unfortunately, the use of these types
does not cause any trouble because of the braindead mix of SDK and DDK
headers. Actually, we need three different sets of headers: Kernel-mode
headers which include all definitions used in ntoskrnl and drivers,
native-mode headers which include only the Nt/Zw/Rtl functions used in ntdll
and other native components and finally Win32 headers which include the
remaining stuff.
> We will continue to maintain our own internal headers for anything that
> doesn't belong in the public headers.  We will begin to port our
> kernel-mode code to use the MinGW DDK headers, maintaining our internal
> headers for non-public things.

Component-internal headers should be moved into the component directory
(<component_path>/<header_name>.h) or into a component-specific include
directory (<component_path>/include/<header_name>.h). They should always be
added to a .c file by using '#include "..."'. Non-public headers which are
shared by components (the csrss-subsystem communication protocol for
example) should be treated as public headers, they become part of the SDK,
DDK or native headers but are not shared between projects.
> The first class of libraries is more difficult.  Some chunks of code
> will be used unmodified, ideally on a file-by-file basis.  Other chunks
> of code will have to be ReactOS-specific, and we will maintain those in
> our local tree.  If Wine ever chooses to merge our changes, that's fine
> too, but it certainly won't be required.

If code is ported from Wine to ReactOS, we have to make sure it will be
adjusted to the ReactOS/MS style. I do not like to see any
Wine-isms/Unix-isms in ntdll/ntoskrnl or a driver because this will become a
portability issue sooner or later.


Another issues are licenses and copyrights. IMO, public headers and import
libraries should not be licensed or copyrighted at all. They should be in
the public domain, so anybody can use them the way they want.

Wine code is published under the LGPL, which is important because of
Winelib. ReactOS on the other hand should use a clean mix of licenses: GFDL
for the documentation, public domain for public headers and import libraries
and GPL for the internal code. We should establish a GPL/LGPL dual-license
agreement so that shared code automatically changes its license when it is
moved from ReactOS to Wine or vice versa.


Regards,
Eric Kohl

[Mingw-users] Re: [ros-kernel] Proposed ReactOS headers and code sharing policy

[Earnie Boyd]

Eric Kohl wrote:
> Another issues are licenses and copyrights. IMO, public headers and import
> libraries should not be licensed or copyrighted at all. They should be in
> the public domain, so anybody can use them the way they want.

This is the only option that makes the most sense.  Headers and import 
libraries should remain in the public domain.  MinGW will have to 
examine the w32api to possibly determine a license change.  It is 
currently written as

<license file="windows.h">
/*
         windows.h - main header file for the Win32 API

         Written by Anders Norlander <anorland(a)hem2.passagen.se>

         This file is part of a free library for the Win32 API.

         This library is distributed in the hope that it will be useful,
         but WITHOUT ANY WARRANTY; without even the implied warranty of
         MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

*/
</license>

The email address for Anders isn't a valid email address any longer. 
I've modified the license once to remove a requirement to notify Anders 
of the use of the w32api, since that wasn't possible anyway.
> Wine code is published under the LGPL, which is important because of
> Winelib. ReactOS on the other hand should use a clean mix of licenses: GFDL
> for the documentation, public domain for public headers and import libraries
> and GPL for the internal code. We should establish a GPL/LGPL dual-license
> agreement so that shared code automatically changes its license when it is
> moved from ReactOS to Wine or vice versa.

This makes sense, perhaps a clause similar to the one Cygwin uses?

<snippit file="CYGWIN_LICENSE">
In accordance with section 10 of the GPL, Cygnus permits programs whose
sources are distributed under a license that complies with the Open
Source definition to be linked with libcygwin.a without libcygwin.a
itself causing the resulting program to be covered by the GNU GPL.

This means that you can port an Open Source(tm) application to cygwin,
and distribute that executable as if it didn't include a copy of
libcygwin.a linked into it.  Note that this does not apply to the cygwin
DLL itself.  If you distribute a (possibly modified) version of the DLL
you must adhere to the terms of the GPL, i.e., you must provide sources
for the cygwin DLL.

See http://www.opensource.org/osd.html for the precise Open Source
Definition referenced above.
</snippit>

Earnie
-- 
http://www.mingw.org
Powered by SourceForge <http://sourceforge.net/projects/mingw>