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.
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
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
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
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
-
Aleksey Bragin -
Daniel Hazelton -
Daniel Verkamp -
Mike Swanson