CRT source code issue

[Aleksey Bragin]

	Hi,
Recently Betov made some accusations regarding possible usage of MS's  
copyrighted code in ReactOS's CRT library (example lib/sdk/libcntpr/ 
math/i386/sqrt_asm.s, alldiv_asm.s, and other files).

Here is my official statement in regarding to this false accusation:
This source code originally was imported into ReactOS from SanOS  
project, where it was said as having GPL license (all original  
copyrights are kept). After a lot of complains from Betov (aimed at  
getting attention to his own project, not at improving ReactOS),  
developers thought it worths looking into the issue deeper.

I performed some investigation, and found that SDL project  
(www.libsdl.org) has the same code in trunk and in v1.2 branch  
(http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/stdlib/ 
SDL_stdlib.c?view=markup).
Everyone can compare asm source code with respective functions found  
in MSVC's CRT source code. It matches up to label names, however  
numbers have been converted from dec to hex representation. The code  
in SDL project is marked as "GPL" and author is stated as "Sam  
Lantinga".

It may look like a serious problem, but in reality, the source code  
of these functions is released by Microsoft in SSCLI 2.0, with a  
license which allows GPLing of the source code, with one restriction:  
"You may not use or distribute this Software and any derivative works  
in any form for commercial purposes.".
SSCLI 2.0 can be freely downloaded by everyone, license is also  
certainly available to read.

I'm going to communicate with SDL about this issue, but since ReactOS  
is not used commercially, it's not a problem for ReactOS now. We are  
ready to collaborate with SDL on removing this issue, if it's  
considered a real problem.


With the best regards,
Aleksey Bragin.

[Daniel Verkamp]

Aleksey Bragin wrote:
>   It may look like a serious problem, but in reality,
> the source code  
>  of these functions is released by Microsoft in SSCLI 2.0, with a  
>  license which allows GPLing of the source code, with one restriction:  
>  "You may not use or distribute this Software and any derivative works  
>  in any form for commercial purposes.".
>  SSCLI 2.0 can be freely downloaded by everyone, license is also  
>  certainly available to read. 
IANAL, but as far as I can tell, such a license is not compatible with
the GPL since it imposes "further restrictions on the recipients'
exercise of the rights granted" (GPL version 2, section 6).

-- Daniel Verkamp

[Daniel Hazelton]

On Friday 03 August 2007 18:51:55 Daniel Verkamp wrote:
>   Aleksey Bragin wrote:
> >   It may look like a serious problem, but in
> > reality, the source code
> >  of these functions is released by Microsoft in SSCLI 2.0, with a
> >  license which allows GPLing of the source code, with one restriction:
> >  "You may not use or distribute this Software and any derivative works
> >  in any form for commercial purposes.".
> >  SSCLI 2.0 can be freely downloaded by everyone, license is also
> >  certainly available to read. 
>  IANAL, but as far as I can tell, such a license is not compatible with
>  the GPL since it imposes "further restrictions on the recipients'
>  exercise of the rights granted" (GPL version 2, section 6).
>
>  -- Daniel Verkamp 
Pardon me (a lurker just following the project) from butting in, but from what 
I can tell this is a non-issue. The "further restriction" doesn't exist - 
unless you hold full copyright to the software (ie: you are the one who has 
released it under the GPL) then there is no way you can distribute it for 
commercial purposes. (You can make money to cover distribution costs and/or 
make money from support but not off the software itself.)

So, non-issue. The additional restriction isn't even needed.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.

[Mike Swanson]

On Friday 03 August 2007 16:28:21 Daniel Hazelton wrote:
>   unless you hold full copyright to the software (ie:
> you are the one who has
>  released it under the GPL) then there is no way you can distribute it for
>  commercial purposes. (You can make money to cover distribution costs and/or
>  make money from support but not off the software itself.) 
Who gave you that idea? http://www.gnu.org/philosophy/selling.html

[Daniel Hazelton]

On Saturday 04 August 2007 04:32:32 Mike Swanson wrote:
>   On Friday 03 August 2007 16:28:21 Daniel Hazelton
> wrote:
> >   unless you hold full copyright to the software
> > (ie: you are the one who
> >  has released it under the GPL) then there is no way you can distribute it
> >  for commercial purposes. (You can make money to cover distribution costs
> >  and/or make money from support but not off the software itself.) 
>  Who gave you that idea? http://www.gnu.org/philosophy/selling.html 
Then something changed somewhere along the line. (Probably at the GPLv2->GPLv3 
transition, but...) The last time I had looked into making *any* money off of 
GPL covered software you weren't allowed to do much more than charge a fee to 
cover distribution costs. (And it was the GPLv2 that led me to that 
understanding. (Though looking at the GPLv2 again I can't quite figure out 
why I had this belief.)

Anyway... 

Which of their three Licenses is the SSCLI2.0 released under? The "Permissive 
License" (which seems the most likely) does not have the stated 
anti-commercial restriction. The "Community License" also lacks that 
restriction. In fact, the only license that MS is using for their "Share 
Source Initiative" that doesn't explicitly permit commercial-sale is 
the "Reference License" - and that one only lets you have access to the 
source for *reference* purposes. (Oh, nevermind. I just downloaded SSCLI2.0 
and it has a completely standalone license, separate from the three listed)

Okay, I can't see where the license shipped with the SSCLI2.0 source allows 
for conversion of any part to the GPL. Time to check the code as well - looks 
to me like this might all be a red-herring. And yes, it appears to be exactly 
that. The SSCLI2.0 code shows that, for "common floating point functions", 
there is a bare-bones wrapper around a call into the standard C runtime.

Example:
(clr/src/classlibnative/float/comfloat.cpp)
FCIMPL1_V(double, COMDouble::Sqrt, double d)
    WRAPPER_CONTRACT;
    STATIC_CONTRACT_SO_TOLERANT;

    return (double) sqrt(d);
FCIMPLEND

AAMOF, thats the only occurrence of sqrt() being defined - anywhere in the 
source. So it looks like the whole thing - even the existence of the same (or 
similar) assembler appearing somewhere - is just a red herring.

DRH

-- 
Dialup is like pissing through a pipette. Slow and excruciatingly painful.