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.