Hello, There has been a lot of talk about possible tainted code in ReactOS and or developers that had access to leaked Microsoft source code. This has caused a lot of speculation about the future of the ReactOS Project. I'm going to try to put those fears to rest and explain what has been going on and where we are going to go from here.
There was one issue that started this discussion and it related to clean-room reverse engineering of certain code in ReactOS. Due to the fact we have developers in many different countries the term reverse engineering can mean many things to many different people. For us in the US when you speak of clean-room reverse engineering it means that one person tears apart the implementation of a device, writes documentation and another reads that documentation and implements. Other countries do not require this invisible great wall of development and allow the same person that disassembles the interface to also write the replacement implementation.
Because of the confusion this has caused and the possible legal issues this could lead to we have decided to do the following.
1) Amend our Intellectual Property Policy Statement to reflect clean-room reverse engineering as meaning the US standard method for reverse engineering and make that the project requirement
2) Audit the entire source tree and rewrite all code found to have been implemented not using the US method for reverse Engineering
3) Require all developers contributing major code to accept the terms of our IP Policy Document via signature.
Now as for the issue of leaked source code, I want to try to put all fears to rest. We don't know what the legal ramifications are for someone downloading and having leaked code, as the party that maintains copyright ownership of that code might still try to claim Trade Secrecy on information contained in the sources in a court of law. It is our point of view that the source code leaks of Windows have been spread to a broad enough audience that it would be impossible to claim the product is still under Trade Secrecy. Because of this we are not banning any developer who might have had access to leaked sources from contributing to ReactOS, however they are being limited as to what area they can contribute. Copyright law still applies to all leaked Windows sources and no one in ReactOS may copy code from a Windows source leak and try to apply it to code in the ReactOS tree.
We know of four developers who have had access to leaked sources prior to working on ReactOS and while they no longer have copies of the source code in question, each of the developers have told us in private which sections of the sources they were exposed to. As such the project has amending the IP document as a fourth step of protection
4) any developer that had access to leaked sources is baned from contributing code to the project for any of the modules that are the same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows source code in version.dll, then they would be unable to contribute code to the ReactOS project for that dll.
It is our hope that a court case will arise and declare Microsoft's Windows code is no longer under Trade Secret protection so these developers who did have access to some of the leaked sources will be free to contribute again to all sections of the project.
One final note, this audit of the code is going to take a long time. It could take years, but it will happen, this project will come out better than it was before. I don't believe anything anyone has done while working on this project was really wrong. Every decision has three possibilities, being moral, ethical and or legal. Sometimes the law in itself is unethical and immoral. If people made mistakes and there was a violation of the law, I question the justice of the law and or anyone that would try to prosecute any of the developers who just want the freedom to learn and create a more free system.
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Steven Edwards wrote:
- any developer that had access to leaked sources is baned from
contributing code to the project for any of the modules that are the same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows source code in version.dll, then they would be unable to contribute code to the ReactOS project for that dll.
I don't think this clause is strong enough. I think that any developer that saw the leaked source code should be banned from contributing to ReactOS. Since there is no record of which parts of the Windows source code that these people saw, if any part of ReactOS they contributed is coincidentally similar to the Windows source then it could be deemed a copyright violation.
If any legal advice the project receives says there is no problem in these four cases then this argument becomes less rigid. However, in the very least, I would still advocate adding a clause to say that, in the future, if anyone was found or admits to have Windows source code in their possession then they should be banned from committing.
You can walk very close to the line, but the damages from a potential Microsoft lawsuit are so great that it would seem sensible to not go anywhere near the line.
Hi,
On 1/26/06, Robert Shearman rob@codeweavers.com wrote:
I don't think this clause is strong enough. I think that any developer that saw the leaked source code should be banned from contributing to ReactOS. Since there is no record of which parts of the Windows source code that these people saw, if any part of ReactOS they contributed is coincidentally similar to the Windows source then it could be deemed a copyright violation.
But using that logic anyone that had ever seen AT&T Unix code would be unable to write GNU and or Linux code. I don't buy that its a copyright violation. Trade Secret maybe but copyright would be like the header situation, as long as they are not directly coping how could it be a derived work?
If any legal advice the project receives says there is no problem in these four cases then this argument becomes less rigid. However, in the very least, I would still advocate adding a clause to say that, in the future, if anyone was found or admits to have Windows source code in their possession then they should be banned from committing.
I agree that anyone that currently HAS the source code for the leak should be banned. Maybe I was not clear enough on that. My issue I have a hard time telling some 15 year old kid who found the Windows source code on a P2P network that he is screwed forever and cannot write free software even if he deletes it. The legal council I spoke with in effect suggested doing the rewrite and banning someone who had seen the code but I do not agree with the idea that someone who makes a mistake should be banned for life.
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Robert Shearman wrote:
Steven Edwards wrote:
- any developer that had access to leaked sources is baned from
contributing code to the project for any of the modules that are the same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows source code in version.dll, then they would be unable to contribute code to the ReactOS project for that dll.
I don't think this clause is strong enough. I think that any developer that saw the leaked source code should be banned from contributing to ReactOS. Since there is no record of which parts of the Windows source code that these people saw, if any part of ReactOS they contributed is coincidentally similar to the Windows source then it could be deemed a copyright violation.
If any legal advice the project receives says there is no problem in these four cases then this argument becomes less rigid. However, in the very least, I would still advocate adding a clause to say that, in the future, if anyone was found or admits to have Windows source code in their possession then they should be banned from committing.
You can walk very close to the line, but the damages from a potential Microsoft lawsuit are so great that it would seem sensible to not go anywhere near the line.
Just fighting a lawsuit might be more than the ReactOS project can handle.
On 1/26/06, Robert Shearman rob@codeweavers.com wrote:
You can walk very close to the line, but the damages from a potential Microsoft lawsuit are so great that it would seem sensible to not go anywhere near the line.
I don't think Microsoft looks at ReactOS as a threat, espeically now that Vista is becoming real. The goal should be to keep moving ReactOS along as fast as reasonably possible.
Remember, staying out of trouble isn't about whether or not you're breaking the law -- it's about not pissing off the wrong people. If Microsoft ever does think of ReactOS as a serious threat, regardless of how prestine the code is, they have the resources to tie it up in the courts for as long as they want. They'll use the same strategy they did in the anti-trust suits: "appeal until we get the verdict we want."
Success for ReactOS will always be a double-edged sword. The important thing is to move forward, and if we ever get on Microsoft's radar to get enough of the collective forces of good behind us -- the EFF, the ACLU, 2600, etc. But, again, I don't think that's likely.
- Craig
Robert Shearman wrote:
Steven Edwards wrote:
- any developer that had access to leaked sources is baned from
contributing code to the project for any of the modules that are the same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows source code in version.dll, then they would be unable to contribute code to the ReactOS project for that dll.
I don't think this clause is strong enough. I think that any developer that saw the leaked source code should be banned from contributing to ReactOS.
We explicitly voted against this (no, I'm lying, we actually explicitly voted against not accepting any contributions which were in the leak, yours goes even further, so the vote would be even more against your idea).
Best regards, Alex Ionescu
We know of four developers who have had access to leaked sources prior to working on ReactOS and while they no longer have copies of the source code in question, each of the developers have told us in private which sections of the sources they were exposed to. As such the project has amending the IP document as a fourth step of protection
- any developer that had access to leaked sources is baned from
contributing code to the project for any of the modules that are the same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows source code in version.dll, then they would be unable to contribute code to the ReactOS project for that dll.
It is our hope that a court case will arise and declare Microsoft's Windows code is no longer under Trade Secret protection so these developers who did have access to some of the leaked sources will be free to contribute again to all sections of the project.
Steven,
I can't sign this point 4) and your hope for some court case. The rule doesn't go far enough. You know the vote about this point was only a vote by majority. To be sure to avoid any legal problems, anyone who had access to the leaked code should not contribute anything to at least that parts, which are covered by the leaked source code. This covers any area of the leaked code - just to be sure. Of course it would be better to abstain from that developer completely.
In my mind it's not important if there has been some court order. I can remember quite clear the time, when the news about the leaked Windows source code came up. The advice at Wine and also here was to _not_ look at those code in any case. Who did it nevertheless should have known what he did. At least in my mind it's only allowed to look at some code if the author (in this case Microsoft) permitted it. Be there a valid juridical trade secret or not... Work derived from such illegitimate looks should be avoided in a free implementation of Windows at any means.
Regards,
Martin
Microsoft licen over windows source code url : http://www.microsoft.com/resources/sharedsource/licensingbasics/sharedsource...
I copy and paste from ms website here
Overview Over the past 5 years, more than 80 technologies have been made available through Microsoft's Shared Source Initiative. Additionally, more than 600 non-Microsoft technologies have been released under a Shared Source license. Like most organizations dealing with the licensing of source code, Microsoft has utilized a range of approaches regarding the rights associated with a given source code release. This has resulted in a variety of source code licenses being used for Microsoft source code releases.
Based on the experience gained through Shared Source, Microsoft has drafted three simplified licenses for future Shared Source releases. These licenses have the following attributes:
. Short and easy to understand - The new licenses are typically shorter than a typewritten page and are easy to read and understand.
. Effective and modern - Although simple, the licenses are designed to be effective and to reflect modern best practices in source code licensing.
. Efficient - By using three simplified licenses, Microsoft will be able to streamline its own internal source code release process, which will allow for more rapid Microsoft source code releases.
. Ecosystem-friendly - Using three simple and well-understood licenses help to simplify source code sharing throughout Microsoft's various software ecosystems, and help to avoid excessive license proliferation.
These new licenses represent a broad spectrum of approaches needed to facilitate an ever-growing, rich set of technologies for release.
The three licenses are:
. Microsoft Permissive License (Ms-PL) - The Ms-PL is the least restrictive of the Microsoft source code licenses. It allows you to view, modify, and redistribute the source code for either commercial or non-commercial purposes. Under the Ms-PL, you may change the source code and share it with others. You may also charge a licensing fee for your modified work if you wish. This license is most commonly used for developer tools, applications, and components.
. Microsoft Community License (Ms-CL) - The Ms-CL is a license that is best used for collaborative development projects. This type of license is commonly referred to as a reciprocal source code license and carries specific requirements if you choose to combine Ms-CL code with your own code. The Ms-CL allows for both non-commercial and commercial modification and redistribution of licensed software and carries a per-file reciprocal term.
. Microsoft Reference License (Ms-RL) - The Ms-RL is a reference-only license that allows licensees to view source code in order to gain a deeper understanding of the inner workings of a Microsoft technology. It does not allow for modification or redistribution. This license is used primarily for technologies such as development libraries.
Source code licensing is an inherently complex topic. There are many possible permutations or interpretations of any given license. It is not our intent to redefine all source code licensing, rather to simplify the approach taken by Microsoft. Existing Shared Source offerings will remain under the terms and conditions of their existing licenses. The new license templates will apply to future Shared Source releases only.
The Shared Source license templates do not apply to the Enterprise Source Licensing Program, Systems Integrator Source Licensing Program, OEM Source Licensing Program, MVP Source Licensing Program, Windows CE Premium Source Licensing Programs, or the Government Security Program.
Microsoft supports the right of a developer to make use of any license and highly recommends that you get appropriate legal advice regarding your choice of source code license.
Top of page Microsoft Permissive License (Ms-PL) The Microsoft Permissive License (Ms-PL) is the least restrictive of the Microsoft source code licenses. It allows you to view, modify, and redistribute the source code for either commercial or non-commercial purposes. Under the Ms-PL, you may change the source code and share it with others. You may also charge a licensing fee for your modified work if you wish.
The copyright and patent grants are both royalty free, meaning that you do not have to pay anything to Microsoft to make use of the source code. There is no obligation for you to publish any changes you make in either binary or source code form. You do need to keep any notices in the code for copyright, patent, trademarks, or for any other forms of attribution.
Microsoft has created a limited version, the Microsoft Limited Permissive License (Ms-LPL), of this license to be used for restricting usage to the Windows platform only. The platform restriction is a measure that Microsoft, as a commercial software provider, may choose for a particular source code release in order to enable positive interaction with Windows-based developers. This version of the license will be employed on a case-by-case basis based upon commercial considerations.
Microsoft can not provide legal advice on the use or implications of this license. We recommend that you get appropriate legal advice before making source licensing decisions.
Top of page Microsoft Community License (Ms-CL) The Microsoft Community License (Ms-CL) is a license that is best used for collaborative development projects. This type of license is commonly referred to as a reciprocal source code license and carries specific requirements if you choose to combine Ms-CL code with your own code. Nearly all current reciprocal licenses are based on the act of distribution to trigger their terms. The Ms-CL seeks to apply the reciprocal terms in a commercially reasonable fashion and to give developers clear guidance as to when the Ms-CL's reciprocal provisions come into play.
Developers often have a range of architectural options at their disposal when crafting a particular product or solution. They frequently have the option to design a larger work as a series of separate files or components that communicate with each other at runtime on the end user's computer, as opposed to one monolithic piece of code that is distributed to the end user as a single file. Although these architectural differences may not be obvious to the end user, they may have significant licensing implications for you as the developer, particularly if you use Ms-CL code in creating the larger work. The Ms-CL (like the Mozilla Public License) works on a "file-by-file" basis. This means that if you use some Ms-CL code in a particular file then the entire file that contains the Ms-CL source code (including any other code in that file, no matter who wrote it), must be redistributed in source code form under the terms of the Ms-CL. On the other hand, for any files in your larger work that contain no Ms-CL code, you are free to license those files under the terms of your choice. This is true regardless of how these "non-Ms-CL" files interact with or communicate with the Ms-CL files at runtime. In other words, if you release code under the Ms-CL and someone includes it in a file in their project (and then distributes their project to others), they must distribute under the Ms-CL anything that is in the specific file that contains your original work. While this file-by-file threshold might at first seem arbitrary, it has the benefit of being an easy to interpret, bright line rule.
Thus, the intent of the reciprocal license is to use licensing as a mechanism to keep certain community-based code "in the community," while allowing companies to commercialize and license (under terms of their choice) their "value add" code that interacts with the community-based code.
The copyright and patent grants are both royalty free, meaning that you do not have to pay anything to Microsoft to make use of the source code. You do need to keep any notices in the code for copyright, patent, trademarks, or for any other forms of attribution.
Microsoft has created a limited version, the Microsoft Limited Community License (Ms-LCL), of this license to be used for restricting usage to the Windows platform only. The platform restriction is a measure that Microsoft, as a commercial software provider, may choose for a particular source code release in order to enable positive interaction with Windows-based developers. This version of the license will be employed on a case-by-case basis based upon commercial considerations.
Microsoft can not provide legal advice on the use or implications of this license. We recommend that you get appropriate legal advice before making source licensing decisions.
Top of page Microsoft Reference License (Ms-RL) The Microsoft Reference License (Ms-RL) is the most restrictive of the Microsoft source code licenses. The license prohibits all use of source code other than the viewing of the code for reference purposes. The intent of this license is to enable Microsoft to release, for review purposes only, more sensitive intellectual property assets.
The most common use of this license will be with developer libraries where modification is not a requirement for making use of the source code. In these cases, the importance of transparency is based on the need for developers to more deeply understand the inner workings of a specific set of technology. In doing so, the developers will be more effective in writing software that makes use of the shared library.
The copyright and patent grants are both royalty free, meaning that you do not have to pay anything to Microsoft to make use of the source code. The license limits the source code release to use on the Windows platform only.
Microsoft can not provide legal advice on the use or implications of this license. We recommend that you get appropriate legal advice before making source licensing decisions.
----- Original Message ----- From: "Martin Fuchs" fuchs.martin@gmail.com To: "ReactOS Development List" ros-dev@reactos.org Sent: den 27 January 2006 11:29 Subject: Re: [ros-dev] Reset, Reboot, Restart,legal issues and the long road to 0.3
We know of four developers who have had access to leaked sources prior to working on ReactOS and while they no longer have copies of the source code in question, each of the developers have told us in private which sections of the sources they were exposed to. As such the project has amending the IP document as a fourth step of protection
- any developer that had access to leaked sources is baned from
contributing code to the project for any of the modules that are the same as leaked sources they examined.
So to clarify that, lets say someone saw some of the leaked Windows source code in version.dll, then they would be unable to contribute code to the ReactOS project for that dll.
It is our hope that a court case will arise and declare Microsoft's Windows code is no longer under Trade Secret protection so these developers who did have access to some of the leaked sources will be free to contribute again to all sections of the project.
Steven,
I can't sign this point 4) and your hope for some court case. The rule
doesn't
go far enough. You know the vote about this point was only a vote by
majority.
To be sure to avoid any legal problems, anyone who had access to the leaked code should not contribute anything to at least that parts, which are covered by the leaked source code. This covers any area of the leaked code - just to be sure. Of course it would be better to abstain from that developer completely.
In my mind it's not important if there has been some court order. I can remember quite clear the time, when the news about the leaked Windows source code came up. The advice at Wine and also here was to _not_ look at those code in any case. Who did it nevertheless should have known what he did. At least in my mind it's only allowed to look at some code if the author (in this case Microsoft) permitted it. Be there a valid juridical trade secret or not... Work derived from such illegitimate looks should be avoided in a free implementation of Windows at any means.
Regards,
Martin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Martin Fuchs wrote: <snip>
Steven,
I can't sign this point 4) and your hope for some court case. The rule doesn't go far enough. You know the vote about this point was only a vote by majority. To be sure to avoid any legal problems, anyone who had access to the leaked code should not contribute anything to at least that parts, which are covered by the leaked source code. This covers any area of the leaked code - just to be sure. Of course it would be better to abstain from that developer completely.
Actually we wanted to propose one more vote to make auditing of all the future contributions by the developers who had a copy of the Windows source code (only for contributions to part covered by the leak, those tools and such wouldn't be covered), but most of the European developers were already sleeping (or preparing to sleep) at that time, so it was cancelled and further discussion was held.
In my mind it's not important if there has been some court order. I can remember quite clear the time, when the news about the leaked Windows source code came up. The advice at Wine and also here was to _not_ look at those code in any case. Who did it nevertheless should have known what he did. At least in my mind it's only allowed to look at some code if the author (in this case Microsoft) permitted it.
Agreed.
Be there a valid juridical trade secret or not... Work derived from such illegitimate looks should be avoided in a free implementation of Windows at any means.
Agreed again, but the point is that at least some of the people (if not all) haven't looked at the source code. Of course implementing something based on that code or knowledge gained from it would be VERY WRONG, at least in my opinion.
Regards, Filip
-
Alex Ionescu -
Craig Talbert -
Filip Navara -
Magnus Olsen -
Martin Fuchs -
Reuben Perelman -
Robert Shearman -
Steven Edwards