The first "Shared Source" code, Windows CE, has been released, and the license is slightly different from what the initial announcement made it look like. You can find a more detailed comment on the Windows CE Source License here.
On "Shared Source" in general, and it's initial announcement:
In response to Open Source getting stronger and showing off better products, such as the Linux operating system, the Apache web server, and the KDE and GNOME desktops, Microsoft recently announced it will release its products under a new type of licensing, called Shared Source.
Microsoft claims that Shared Source has all the advantages Open Source has, and doesn't have some things they perceive as disadvantages of Open Source.
Looking at the details behind Shared Source, it is quite obvious that it won't live up to this hype.
Open Source, basically, gives everyone the permission to view the full source code (the readable code used to build an application), modify it, and redistribute it in both modified and unmodified form.
"Shared Source", on the other hand, gives only some selected (by Microsoft) large companies the permission to view parts of the source code, under the provision that it is not modified, compiled (turned into an executable file the computer rather than the programmer understands), or redistributed, in modified or unmodified form.
Basically, so-called "Shared Source" is an attempt to get some companies to look at the code without giving them anything in return - they may spot problems, but they may not fix them.
Let's take a look at the advantages Open Source provides - and see how they compare to "Shared Source".
| Open Source | Shared Source | Conclusion |
|---|---|---|
| By giving everyone interested in it access to the source code, Open Source ensures interoperability. If you want to write a new word processor, you can ensure its file format is completely compatible with the existing one by looking at, and possibly copying parts of, its file handling code. | Since only a selected group of customers get access to the source code,
you can't even think about looking at Microsoft Word's file handling code.
Unless you are a very large company, you won't be part of the small selected
group of "Shared Source" licensees. Microsoft won't give you access to the source code of relevant parts of Word 2000 if you tell them "We're about to write a new word processor for Linux. Since we'd like to be as interoperable as possible with your products, please send us the source code for Microsoft Word so we can make sure we can import and export word files." |
Microsoft claims "Shared Source" improves interoperability, and
is playing well with their customers - but effectively, this is not the case.
Reverse engineering for the sake of interoperability is considered fair use even by the DMCA - but even with "Shared Source", Microsoft makes this as hard as possible. Owning a widely used file format and making interoperability as hard as possible for potential competitors is part of Microsoft's attempt to (probably illegaly) expand an almost-monopoly. Open Source does everything it can to ensure interoperability. |
| Open Source gives you the chance to make the software you're using fit your needs exactly. If you like an application, but it doesn't have one feature you need, you can just add the feature yourself (or hire someone to do it), and use this version of the application throughout your company, even if this feature won't be useful to anyone else. | "Shared Source" doesn't give you the permission to modify or reuse the source code. You can't customize "Shared Source" software any more than traditional locked up software. | "Shared Source" doesn't gain the customer anything in terms of customizability. |
| Open Source software helps at fostering a community of users that will help the application advance - by sending in patches that fix problems and expand the functionality of an application and by sending better feedback. | "Shared Source" will not succeed at building up a community
because it doesn't provide an incentive. Most people won't bother to look at
the source code if they know they might be able to fix a problem, but they
can't use the fix because they don't have the right to modify the code. Some
people who would be interested in looking at the code even under those
conditions will be locked out because their company won't be granted a
"Shared Source" license, because they aren't large enough or because
they are working on a competing product.
If someone takes a look at the code and sends in a patch, the only benefit the person who fixed something has is that the problem might (or might not) get fixed in the next version (for which the contributor would have to pay). Without the right to modify the code (or even have access to the entire code), you can't even fix the problems you're encountering for your local setup, and you have no way to make sure the fix gets into the next version. Even if you do come up with a patch that fixes the problem, you can't try it out because you don't have access to the full source code required to build the application. Modern software is so complicated that without recompiling the code and running it in a debugging environment you often can't even find the bug, let alone make a patch for it. |
"Shared Source" will probably improve the quality of bug reports
sent in by a small number of people ("Application xyz crashes because the
construct in xyz.c, line 123 yields an incorrect result" is much more
valuable than "xyz crashed saying there was a fatal exception 0e at
0f38:edfa") over Microsoft's traditional "We won't let anyone see
our source code" licensing model, but it won't get anywhere near the
extent of Open Source. If you want people to look at and fix up your source code, you need to give them an incentive to do so - such as the permission to use the modified source code. Open Source gets this right, "Shared Source" doesn't. |
| "Dead" code can live on. If an original programmer loses interest in his work and moves on to work on something else, someone else can take over his original work and keep it alive. | If the company owning it decides to abandon a product, nobody else can work on it. | "Shared Source" and other closed source development models leave customers alone once the company loses interest in a product. |
| If you don't trust the programmer of Open Source code, you can read the source code, make sure it doesn't contain any security leaks or backdoors (backdoors are, basically, intentional security problems, giving people who know about it control over your machine), rebuild it, and use it. | If you happen to be a "Shared Source" licensee, you can look at
the code Microsoft provides to make sure it doesn't contain any backdoors.
However, even if you are a "Shared Source" licensee, you have no way
of knowing that the source code Microsoft provides is actually the same code
they used to build the product you're using. If they added backdoors, I doubt
they'd be stupid enough to leave them in for a source code release. Since you are not allowed to use their code, you can not (at least not legally) rebuild the clean code they provided by yourself to make sure there aren't any backdoors. Microsoft has been known to implement backdoors before. A recent example of a Microsoft backdoor is the Internet Information Server (IIS) backdoor. |
"Shared Source" makes it harder to implement backdoors. Open Source makes it impossible. If someone tried really hard to hide a backdoor in Open Source software, he could probably succeed for a while, but it would eventually be noticed and fixed by others. |
| Summary: "Shared Source" does not provide all the advantages of Open Source code. It only provides a very small subset of them, and even those are not provided completely. | ||
Furthermore, in their announcement of "Shared Source", Microsoft claimed it eliminates a number of disadvantages of the Open Source Software (OSS) model.
Looking at those perceived disadvantages, however, they turn out to be either untrue, or, in fact, advantages.
Unless stated otherwise, Microsoft's claims below are taken from Craig Mundie (Microsoft)'s speech on shared source, which can be reviewed at http://www.microsoft.com/presspass/exec/craig/05-03sharedsource.asp.
| Microsoft's claim | The Reality |
|---|---|
| The OSS development model leads to a strong possibility of unhealthy "forking" of a code base, resulting in the development of multiple incompatible versions of programs, weakened interoperability, product instability, and hindering businesses' ability to strategically plan for the future. |
While most Open Source licenses permit "forking" of the code base,
it doesn't happen frequently, because maintainers of Open Source Software
usually add patches sent in by their users quickly, or they at least have (and
share) good reasons not to add particular patches.
Even large projects like the linux kernel, glibc (the most basic system library on a Linux (or similar) system), XFree86, KDE or GNOME have not been forked - because nobody had a reason to do it. Some other projects have indeed had forks - mostly because the original maintainers of the software didn't have the time to work on it anymore. If a fork happens, there are usually two outcomes: Either the community agrees that the fork was necessary, and in the long run, the fork becomes the official version - or the community agrees that the fork is not necessary, and it will not get much attention. Still, the person doing the fork can keep on maintaining it, providing a valuable service for other people with similar needs, as rare as those needs may be. Healthy forks have usually happened for projects maintained by people who didn't allow enough outside contribution - for example, with the "egcs" fork of gcc (egcs quickly became gcc 2.95), and the "wu-ftpd-VR" and "BeroFTPD" forks of wu-ftpd - a merged version of both forks eventually became wu-ftpd 2.6.0. Besides, as long as the forks are available under an Open Source License, there will not be any interoperability problems - all the code handling file or transfer formats can simply be merged back. |
| Furthermore, it [Open Source development model] has inherent security risks |
The reasoning behind this claim is that, if anyone can see the source code, anyone can spot security problems and abuse them. This isn't thought through, though. With the code being open, anyone (such as system administrators deploying the code) can proofread it and make sure there are no security problems. If there is indeed a security problem (which happens anywhere - looking at the SecurityFocus statistics shows that neither Open Source nor Closed Source software is completely free from security problems), it can be fixed much faster in Open Source code, simply because the system administrator who finds the problem can fix it himself and publish a patch, rather than having to notify a central authority and wait for them to acknowledge the problem and release an update. Because of this, Open Source Software vendors such as Red Hat are much faster at releasing security updates if problems have been found than Closed Source Software vendors like Microsoft or Sun. "Shared Source" is a much bigger problem here - if you're a licensee, you can spot security leaks, and abuse them to crack systems running the code. But if you're trying to prevent someone from cracking a system by looking at the code (the way many Open Source contributors do), you can't fix it because you are not allowed to modify the code. With Open Source Software, you can be absolutely certain that there are no backdoors (intentional security problems) on your system (by proof-reading the source code or finding someone who does, see above). Also, this server is running completely on Open Source Software. If Open Source Software is all that insecure, why don't you just crack my machine and modify this page? We'll even help you, and tell you what we're running:
This page is still here, and unmodified - maybe Open Source Software is secure after all? Especially where security is a concern, Open Source is the only way to go. Microsoft's own TCP/IP stack is a fork (didn't they claim forking was bad?) of the BSD TCP/IP stack, so if Open Source security can't be trusted, why would people who make this claim use it? The only security risk with Open Source Software is that it's easy for someone to take an Open Source product, add backdoors, and distribute his modified version. You can avoid this risk by installing known good software, such as packages signed with Red Hat's GPG key. By not using Open Source Software, you're not exactly safe from this kind of attack. |
| Some of the most successful OSS technology is licensed under the GNU General Public License or GPL. The GPL mandates that any software that incorporates source code already licensed under the GPL will itself become subject to the GPL. When the resulting software product is distributed, its creator must make the entire source code base freely available to everyone, at no additional charge. This viral aspect of the GPL poses a threat to the intellectual property of any organization making use of it. |
Code released under "Shared Source" terms may not be modified for
local use. The resulting software product must not be distributed at all. If
its creator wants to have any chance of getting his changes integrated in
future versions of Microsoft's products, he has to hand his copyright over
to Microsoft. This aspect of "Shared Source" poses a threat to
the intellectual property of any organization making use of it.
Furthermore, if you ever want to develop proprietary software after reading "Shared Source" code, Microsoft can force you to release your code to them, so they can make sure you aren't copying any of their code, violating their license. Besides, many owners of GPL code will permit proprietary versions for a small fee. For example, Qt is released for free under the terms of the GPL - but you can buy different licensing if you want to develop proprietary software using Qt (Alternate Qt licensing is not more expensive than a Windows NT, MFC and Microsoft Visual C++ license). This is a reasonable demand - everyone using the code should contribute. If not through his own code, then through the funding of people who work on the code. Also, not all Open Source code is licensed under the GPL. Similarily, Microsoft's position that the GPL infringes on intellectual property might lead to some misunderstandings. Some clarifications:
|
| In this sense, open source software based on the GPL mirrors the .com business models that proved the least successful during the past year. They ask software developers to give away for free the very thing they create that is of greatest value in the hope that somehow they'll make money selling something else. In effect, it puts at risk the continued vitality of the independent software sector. | All of the Open Source companies that play well with the community are still around - with various very different business models. Red Hat's business model includes support, training, embedded devices and software sales. Analysts expect Red Hat to become profitable this year. VA Linux gets most of its revenue through hardware sales and advertising on their websites. Trolltech makes money by selling training, support, and different licensing for their software. MandrakeSoft lives from software sales. Loki Games lives from software sales, making only parts of their software available under Open Source licenses (there's no reason why you can't make that mix). Aladdin maintains a non-Open Source version of their most important product (Ghostscript), and Open Sources all previous versions when a new version is released. IBM and Nokia write and support Open Source Software to support their infrastructures. Sleepycat Software license their DB database on GPL-like terms: free for free software, for pay for proprietary software. |
| But as history has shown, while this type of model may have a place, it isn't successful in building a mass market and making powerful, easy-to-use software broadly accessible to consumers. |
There's no real need to comment on this - listing examples of the opposite
should be sufficient: KDE, GNOME, Red Hat Linux, Linux Mandrake, SuSE Linux are all quite successful at this.
The reasons Linux desktops are not as common as Windows® desktops at the moment are primarily the fact that almost every computer you buy (even if you want to run Linux exclusively) comes with Windows® preinstalled (caused mostly by business practices recently ruled illegal). Many people simply stay with the software they get from their hardware vendor because they don't know anything else, or don't see enough of an incentive to risk installing something they aren't familiar with. |
Some relevant links on the topic:
The content of shared-source.com is hereby placed under the GNU Free Documentation License.
Please direct feedback, comments and questions to bero+sharedsource@bero.org. You are not permitted to send unsolicited bulk email (commonly referred to as spam) to this address, or to sell this address to people who do. By extracting the address from this page, you agree to pay a fee of $10,000.00 per UBE message you send and $100,000.00 per instance you sold this address.
Microsoft and Windows are registered trademarks of Microsoft, corp.
