Hubbry Logo
Shared Source InitiativeShared Source InitiativeMain
Open search
Shared Source Initiative
Community hub
Shared Source Initiative
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Shared Source Initiative
Shared Source Initiative
Shared Source Initiative
View on Wikipedia
from Wikipedia

The Shared Source Initiative (SSI) is a source-available software licensing scheme launched by Microsoft in May 2001.[1] The program includes a spectrum of technologies and licenses, and most of its source code offerings are available for download after eligibility criteria are met.[2]

Overview

[edit]

Microsoft's Shared Source Initiative allows individuals and organizations to access Microsoft's source code for reference (e.g. when developing complementary systems), for review and auditing from a security perspective (mostly wanted by some large corporations and governments), and for development (academic institutions, OEMs, ODMs, IHVs, IBVs, ISVs, individual developers). For example, higher-level OEMs, such as Dell, HP and Nokia, can get more source code of Microsoft Windows.

As part of the framework, Microsoft released 5 licenses for general use. Two of them, Microsoft Public License and Microsoft Reciprocal License, have been approved by the Open Source Initiative as open source licenses[3][4] and are regarded by the Free Software Foundation as free software licenses.[5] Other shared source licenses are proprietary, and thus allow the copyright holder to retain tighter control over the use of their product.

Microsoft's Shared Source Initiative has been imitated by other companies such as RISC OS Open Ltd.[6]

Microsoft also uses specific licenses for some of their products, such as the Shared Source CLI License[7] and the Microsoft Windows Embedded CE 6.0 Shared Source License.[8]

Free and open-source licenses

[edit]

The following licenses are considered open-source by the Open Source Initiative and free by the Free Software Foundation.

Microsoft Public License (Ms-PL)

[edit]

This is the least restrictive of the Microsoft licenses and allows for distribution of compiled code for either commercial or non-commercial purposes under any license that complies with the Ms-PL. Redistribution of the source code itself is permitted only under the Ms-PL.[9] Initially titled Microsoft Permissive License, it was renamed to Microsoft Public License while being reviewed for approval by the Open Source Initiative (OSI).[10] The license was approved on October 12, 2007, along with the Ms-RL.[11] According to the Free Software Foundation, it is a free software license but not compatible with the GNU GPL.[5] Ms-PL provides a free and flexible licensing for developers using source codes under this license. However, the Ms-PL is a copyleft license because it requires the source code of software it governs to be distributed only under the same license (the Ms-PL).[12]

Microsoft Reciprocal License (Ms-RL)

[edit]

This Microsoft license allows for distribution of derived code so long as the modified source files are included and retain the Ms-RL.[13] The Ms-RL allows those files in the distribution that do not contain code originally licensed under Ms-RL to be licensed according to the copyright holder's choosing. This is similar, but not the same as the CDDL, EPL or LGPL (GPL with a typical "linking exception").[citation needed] Initially known as the Microsoft Community License, it was renamed during the OSI approval process.

On December 9, 2005, the Ms-RL license was submitted to the Open Source Initiative for approval by John Cowan.[14] OSI then contacted Microsoft and asked if they wanted OSI to proceed. Microsoft replied that they did not wish to be reactive and that they needed time to review such a decision.[15]

At the O'Reilly Open Source Convention in July 2007, Bill Hilf, director of Microsoft's work with open source projects, announced that Microsoft had formally submitted Ms-PL and Ms-RL to OSI for approval.[16] It was approved on October 12, 2007, along with the Ms-PL.[11] According to the Free Software Foundation, it is a free software license but not compatible with the GNU GPL.[5]

Restricted licenses

[edit]

The following source-available software licenses have limitations that prevent them from being open-source according to the Open Source Initiative and free to the Free Software Foundation.

Microsoft Limited Public License (Ms-LPL)

[edit]

This is a version of the Microsoft Public License in which rights are only granted to developers of Microsoft Windows-based software.[17] This license is not open source, as defined by the OSI, because the restriction limiting use of the software to Windows violates the stipulation that open-source licenses must be technology-neutral.[18] It is also considered to be non-free by the Free Software Foundation due to this restriction.[5]

Microsoft Limited Reciprocal License (Ms-LRL)

[edit]

This is a version of the Microsoft Reciprocal License in which rights are only granted when developing software for a Microsoft Windows platform.[19] Like the Ms-LPL, this license is not open source because it is not technology-neutral[18] due to its restriction that licensed software must be used on Windows, and is also not considered free by the Free Software Foundation due to this restriction.[5]

Microsoft Reference Source License (Ms-RSL)

[edit]

This is the most restrictive of the Microsoft Shared Source licenses. The source code is made available to view for reference purposes only, mainly to be able to view Microsoft classes source code while debugging.[20] Developers may not distribute or modify the code for commercial or non-commercial purposes.[21] The license has previously been abbreviated Ms-RL, but Ms-RL now refers to the Microsoft Reciprocal License.[13]

Criticism

[edit]

Two specific shared source licenses are interpreted as free software and open source licenses by FSF and OSI. However, former OSI president Michael Tiemann considers the phrase "Shared Source" itself to be a marketing term created by Microsoft. He argues that it is "an insurgent term that distracts and dilutes the Open Source message by using similar-sounding terms and offering similar-sounding promises".[22]

The Shared Source Initiative has also been noted to increase the problem of license proliferation.[23]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Shared Source Initiative

View on Grokipedia
from Grokipedia
The Shared Source Initiative is a framework developed by Microsoft for distributing source code of its software products under a spectrum of licenses that grant varying degrees of access, from viewing for debugging purposes to limited modification and redistribution, while maintaining proprietary controls and intellectual property protections. Launched in May 2001, the initiative aimed to foster deeper understanding of Microsoft's platforms among partners, governments, and developers, facilitating enhanced security analysis, troubleshooting, and customization without relinquishing full ownership of the code. Key expansions included the 2002 Systems Integrator Source Licensing Program, which extended access to Windows 2000, Windows XP, .NET Server, and Windows CE source code for qualified systems integrators in over 30 countries, requiring criteria such as Gold Certified Partner status and significant Windows deployment volumes. By 2004, the program had grown to encompass one million participants across various licensing tracks, including the Windows Enterprise Source Licensing Program for large organizations and specialized offerings for OEMs and silicon vendors. Notable licenses under the initiative, such as the Microsoft Permissive License and Microsoft Reciprocal License, permitted broader community use in some cases, with two approved by the Open Source Initiative, though most retained restrictions prohibiting unrestricted commercial redistribution. The Shared Source Initiative represented Microsoft's strategic response to demands for code transparency amid competition from fully open-source alternatives, enabling targeted collaborations—such as government access for security auditing—while prioritizing intellectual property preservation over unrestricted openness. It supported practical outcomes like platform-specific optimizations for enterprise and embedded systems but drew scrutiny for its restrictive terms, which limited derivative works compared to permissive open-source models, positioning it as a proprietary-hybrid approach rather than a shift to communal development.

Origins and Historical Context

Inception in 2001

The Shared Source Initiative was formally launched by Microsoft in May 2001 as a framework for providing controlled access to the source code of select Microsoft products and technologies, distinguishing itself from fully open-source models by imposing restrictions on redistribution and modification to safeguard proprietary interests. This program built on prior limited code-sharing practices, including Microsoft's provision of Windows source code to academic institutions starting in 1991, but represented a structured expansion aimed at broader engagement with partners and customers amid growing demands for transparency in software development. The initiative's responded to pressures from enterprise clients, governments, and developers seeking deeper into Microsoft's —particularly Windows—to facilitate customization, , and trust-building, without conceding full open-source freedoms that Microsoft executives, such as Senior Vice President Craig Mundie, publicly critiqued as unsustainable for commercial viability. offerings under the program granted viewing to portions of Windows for qualified entities, with licenses tailored to prevent competitive misuse, thereby targeted while maintaining Microsoft's competitive edge in a market increasingly influenced by open-source alternatives like . By mid-2001, complementary announcements, such as the in , underscored the initiative's in fostering industry on specific technologies, with emphasizing its commitment to standards and through shared implementations. These early steps positioned the Shared Source Initiative as a pragmatic alternative to pure code , prioritizing empirical benefits like enhanced partner development over ideological commitments to unrestricted , as evidenced by its rapid integration into Microsoft's ecosystem strategies.

Evolution Through the 2000s

Following its launch in May 2001, the Shared Source Initiative underwent significant expansions in 2002 and 2003 to broaden access for specific customer groups. In February 2002, Microsoft extended source code availability to systems integrators, enabling them to review and modify portions of Windows code for customized deployments while adhering to nondisclosure and redistribution restrictions. In April 2003, the company introduced the Windows CE Embedded Product program, the first Shared Source offering permitting original equipment manufacturers, silicon vendors, and independent hardware vendors to commercially distribute modified versions of Windows CE source code, provided derivatives remained proprietary and Microsoft royalties were paid on end-user licenses. Concurrently, in January 2003, the Government Security Program was established, granting select national governments access to Office 2003 XML schemas and later source code for security reviews, without modification or redistribution rights. By 2004, the initiative had expanded to encompass over 120 programs, engaging more than 1 million developers worldwide through targeted access for , , and enterprise customization. This growth reflected Microsoft's strategy to foster ecosystem development without fully relinquishing controls, as evidenced by programs like the Most Valuable Professionals Shared Source Licensing, announced in 2003, which provided elite developers with Windows source access under restrictive terms. In October 2005, streamlined its licensing framework, consolidating approximately 10 prior licenses into three principal : the permissive Microsoft Permissive License (Ms-PL), akin to BSD-style terms allowing broad modification and distribution; the License (Ms-CL) for noncommercial use; and the reciprocal Reciprocal License (Ms-RL), requiring derivative works to adopt similar terms. This simplification accompanied the of eight 2005 starter under these licenses, aiming to reduce for developers while maintaining protections against competitive threats. The initiative further evolved in June 2006 with the launch of , a web-based portal for hosting and collaborating on Shared Source and compatible open-source projects targeting platforms, initially featuring over 100 projects and building on engagement with 2 million developers across Shared Source programs. By 2007, sought greater with open-source norms, submitting the Ms-PL and Ms-RL for approval by the , which granted recognition in October, marking a partial alignment with OSI standards despite retained reciprocity and patent clauses that diverged from purely permissive models like the MIT License. These steps positioned Shared Source as a hybrid model, expanding community involvement through the decade while prioritizing Microsoft's control over core proprietary assets.

Core Principles and Strategic Rationale

Balancing Code Sharing with Intellectual Property Protection

The Shared Source Initiative (SSI), launched by in , sought to expand access to proprietary source code beyond traditional non-disclosure agreements while imposing restrictions to safeguard derived from substantial investments. Unlike fully models, which mandate unrestricted modification and redistribution to promote communal , SSI licenses permitted targeted uses such as , , and limited customization for partners and customers, but prohibited broad sublicensing or competitive exploitation that could undermine 's commercial viability. This approach reflected 's recognition that unrestricted risked commoditizing core technologies, potentially eroding the —estimated at billions annually in R&D —necessary to sustain proprietary software advancement. Central to this balance was of selective transparency, ecosystem participants like hardware manufacturers and integrators to enhance and product customization without granting them ownership or derivative rights that might benefit direct competitors. For instance, under SSI terms, licensees could often view and modify code for internal purposes or specific deployments, but were barred from redistributing altered versions publicly or incorporating them into rival products, thereby preserving Microsoft's control over key algorithms and architectures. Microsoft executives, including Craig Mundie, articulated this as a pragmatic alternative to open source, arguing that while code sharing fosters collaboration and trust, absolute openness would disincentivize private in high-cost innovation by exposing trade secrets to free replication. This rationale was substantiated by Microsoft's business model, which relied on licensing fees and product sales rather than community-driven contributions, contrasting with open source ecosystems where IP protection is often waived in favor of viral adoption. Critics from communities contended that SSI's restrictions constituted a form of "faux openness," prioritizing IP enclosure over genuine reciprocity, yet empirical outcomes demonstrated its in controlled scenarios: by , expansions allowed systems integrators access to Windows components for tailored solutions without compromising Microsoft's market position. This calibrated aligned with causal incentives in software , where partial disclosure accelerates partner-driven value —such as optimized device drivers—while reciprocal or limited licenses deterred opportunistic forking that could fragment Microsoft's platform dominance. Ultimately, SSI exemplified a hybrid , leveraging code as a strategic asset to build alliances and interoperability standards, such as those for smart cards and embedded systems, without relinquishing the proprietary barriers that funded ongoing development.

Contrast with Pure Open Source Models

The Shared Source Initiative (SSI), launched by Microsoft in May 2001, diverges from pure open source models by providing tiered access to source code under licenses that prioritize intellectual property safeguards over unrestricted freedoms, as defined by the Open Source Initiative's (OSI) Open Source Definition. Pure open source licenses, such as the MIT License or GNU General Public License, mandate freedoms including free redistribution in binary or source form, allowance for derived works without discrimination against fields of endeavor, and no technology-specific restrictions, enabling broad community modification and forking. In contrast, many SSI licenses impose eligibility requirements, prohibit redistribution of modifications, or confine use to non-commercial or reference purposes, as seen in the Microsoft Reference Source License (Ms-RSL), which limits code to internal reference only and excludes modifications or distribution to maintain Microsoft's control over core technologies. This controlled approach reflects Microsoft's rationale of fostering and developer trust—such as independent software vendors to debug or port applications—without exposing proprietary assets to competitive replication, a inherent in pure where forks could undermine commercial viability. While two SSI licenses, the (Ms-PL) and Reciprocal (Ms-RL), received OSI approval in for aligning with criteria by permitting modification and redistribution under reciprocal terms, the initiative's broader restrictive licenses, like the Shared Source Community License, discriminate against certain users or uses, violating OSI principles such as non-discrimination. Former OSI president Michael Tiemann highlighted that three of Microsoft's five primary shared source licenses at the time failed open source standards to such provisions, positioning SSI as a proprietary-hybrid model rather than a commitment to communal openness.

License Categories

Permissive Licenses Aligned with Open Source Standards

The Shared Source Initiative includes licenses designed to align with the Open Source Definition approved by the Open Source Initiative (OSI), enabling broad freedoms for software use, modification, and redistribution while facilitating Microsoft's participation in open source communities. These licenses, introduced as part of the initiative's evolution, were submitted to the OSI for approval in 2007 and certified as conforming to open source standards on October 12 of that year. Unlike more restrictive Shared Source licenses, these permissive variants do not impose field-of-use limitations or require special agreements, allowing general public access to applicable codebases such as components of the .NET Framework. The Microsoft Public License (Ms-PL) exemplifies a fully permissive approach, granting recipients the right to use, copy, modify, merge, publish, distribute, sublicense, and sell the software in source or binary form without mandating the disclosure of derivative works' source code. It permits incorporation into proprietary products, provided that copyright notices, patent rights, and the full license text are retained in all copies or substantial portions. Approved by the OSI on October 3, 2007, the Ms-PL supports commercial exploitation and is OSI-listed as compatible with a wide range of other open source licenses, excluding strong copyleft ones like the GPL due to its non-reciprocal nature. Complementing the Ms-PL, the Microsoft Reciprocal License (Ms-RL) maintains similar baseline permissions but adds a reciprocity clause: distributions of modifications to the licensed code or larger works containing it require making the modified source available under Ms-RL terms, promoting community access to enhancements without enforcing project-wide copyleft. This file-level reciprocity mirrors licenses like the Mozilla Public License, balancing openness with protection against proprietary lock-in of improvements. Also OSI-approved in October 2007, the Ms-RL was crafted to encourage collaborative development on Microsoft-shared components while allowing proprietary extensions outside the original codebase. By adopting these OSI-aligned licenses, the Shared Source Initiative enabled to release over files from the in under Ms-PL and Ms-RL terms, fostering developer feedback and interoperability without fully relinquishing intellectual property control inherent to the broader initiative. These licenses have been applied to libraries and tools, demonstrating their utility in hybrid ecosystems where open contributions enhance proprietary platforms.

Microsoft Public License (Ms-PL)

The is a permissive license introduced by within its Shared Source Initiative to enable broad reuse of select codebases while preserving core intellectual property protections. It grants recipients rights to use, modify, reproduce, and redistribute the software in source or object form, including incorporation into proprietary products, without imposing copyleft requirements on derivatives. Licensees must retain all original copyright, , trademark, and attribution notices in any distributed portions, and the license includes an explicit grant of rights from Microsoft to end users and redistributors, conditioned on compliance. Approved by the Open Source Initiative (OSI) on October 17, 2007, following its initial proposal as the Microsoft Permissive License, the Ms-PL met the OSI's Open Source Definition criteria, marking Microsoft's first license to receive such certification. This approval facilitated its application to projects like Reactive Extensions (Rx) for .NET and certain ASP.NET components, promoting developer contributions and ecosystem growth around Microsoft technologies. Unlike reciprocal Shared Source licenses, the Ms-PL's non-restrictive terms align closely with established permissive models such as the MIT License, differing primarily in the patent grant's scope, which applies only to Microsoft's contributions and excludes liability for third-party claims. In practice, the Ms-PL supports Microsoft's strategic goal of fostering and without mandating source disclosure for modifications, as evidenced by its use in over 100 GitHub repositories tied to Microsoft by 2020. It prohibits sublicensing under incompatible terms but allows with other licenses if the Ms-PL governs the original files, ensuring Microsoft's notices propagate. Empirical indicates compatibility challenges with strong licenses like the GPL, due to the grant's non-transferability to downstream users in certain scenarios, though it remains suitable for dual-licensing in commercial contexts.

Microsoft Reciprocal License (Ms-RL)

The Microsoft Reciprocal License (Ms-RL) is a file-level copyleft license introduced by Microsoft in 2007 as part of its Shared Source Initiative, granting users rights to reproduce, modify, and redistribute covered software while requiring reciprocal sharing of source code for any modified files containing original licensed material. Approved by the Open Source Initiative on October 10, 2007, following submission on October 3, it extends permissive elements similar to the Microsoft Public License (Ms-PL) but imposes conditions to ensure derivatives of licensed files remain accessible under the same terms, balancing code sharing with protections against proprietary enclosure of modifications. Under Section 2, the license provides a non-exclusive, royalty-free copyright grant to create derivative works and distribute them, alongside a patent grant covering making, using, offering, selling, importing, and having sold contributions or combinations thereof. Redistribution in source or binary form, per Section 3A, mandates inclusion of the full source code for any file incorporating the original software, licensed identically under Ms-RL, with all copyright, patent, and attribution notices preserved. This reciprocity applies specifically to modified files rather than the entire project, allowing integration into larger works provided the licensed portions' sources are disclosed, which distinguishes it from stronger copyleft licenses like the GPL that propagate requirements project-wide. Patent grants terminate if a licensee asserts claims against contributors regarding patents on the software, per Section 3C. The Ms-RL disclaims warranties, offering the software "as is" without implied assurances of merchantability or fitness, though local laws may limit such exclusions (Section 3F). It permits commercial use and modification without fees, but prohibits sublicensing under alternative terms and grants no trademark rights. In practice, this has enabled release of components like certain Visual Studio extensions and tools, such as CMake Tools for Visual Studio in 2016, fostering developer contributions while enforcing source availability for enhancements to Microsoft-provided code. Compared to pure open source models, the Ms-RL prioritizes controlled reciprocity to protect intellectual property in derivatives, aligning with Shared Source goals of encouraging ecosystem participation without full relinquishment of control.

Restrictive Licenses for Controlled Access

The restrictive licenses within the Shared Source Initiative impose targeted limitations on source code usage to enable selective sharing while preserving Microsoft's control over proprietary technologies and ecosystem development. Introduced in the mid-2000s as part of license rationalization efforts, these licenses deviate from open source norms by incorporating platform dependencies, reciprocity clauses confined to specific contexts, or reference-only access, thereby preventing broad redistribution that could undermine commercial products. This approach facilitated code disclosure to Windows developers and partners for interoperability and debugging without granting freedoms equivalent to OSI-approved licenses. The (Ms-LPL), version 1.1, extends the permissive Ms-PL framework but restricts granted —non-exclusive, and licenses—to the development of software for Windows platforms exclusively. No are conveyed, and usage beyond Windows-compatible applications is prohibited, ensuring shared code bolsters rather than competes with Microsoft's core operating . This applied to sample code and components intended for ecosystem enhancement, as evidenced in developer resources since approximately 2005. The Microsoft Limited Reciprocal License (Ms-LRL) mirrors the copyleft structure of the Ms-RL but narrows its scope to software development based on the Microsoft Windows platform, mandating source code disclosure for derivative works only within that bounded domain. This reciprocity applies selectively, allowing internal modifications for Windows-targeted products while curtailing broader application or distribution, a design choice aligned with Shared Source goals of controlled collaboration announced in 2005. Most constraining is the Source (Ms-RSL), which authorizes non-transferable, non-exclusive of code solely for reference in developing applications using products, explicitly barring redistribution, modification for distribution, or any commercial exploitation outside personal or company-internal reference. Employed for high-value components like libraries starting in , it supported developer comprehension and —such as stepping through source in —without risking IP leakage, as the license terminates upon any prohibited use.

Microsoft Limited Public License (Ms-LPL)

The Microsoft Limited Public License (Ms-LPL), introduced in October 2005 as part of Microsoft's Shared Source Initiative, is a restrictive source-available license designed to grant limited access to source code for developers building software compatible with Microsoft platforms, such as Windows. It permits viewing, internal modification, and binary redistribution of the licensed code but imposes strict conditions on source code redistribution: modifications can only be shared externally if they are incorporated into products that run exclusively on Microsoft operating systems or are used in developing Microsoft-branded software. This platform-specific limitation ensures that proprietary enhancements do not extend beyond Microsoft's ecosystem, protecting intellectual property while enabling targeted collaboration. Key terms include a requirement for any distributed binaries to include a copyright notice and state that they were modified from the original Ms-LPL-licensed software, alongside prohibitions on sublicensing or using the code to create derivative works for non-Microsoft platforms. Unlike the permissive Ms-PL, the Ms-LPL's reciprocity-like restrictions on source sharing align it with controlled-access models, reflecting Microsoft's strategy to encourage ecosystem-specific innovation without risking broad commoditization of its codebase. The license has been applied to components like ATL Server, a C++ web services framework released in January 2007, where developers could customize server-side functionality for Windows applications but not redistribute source alterations freely.

Microsoft Limited Reciprocal License (Ms-LRL)

The Microsoft Limited Reciprocal License (Ms-LRL) restricts the rights granted under the Microsoft Reciprocal License (Ms-RL) to scenarios involving the development of software specifically for Microsoft Windows platforms. This platform-specific limitation ensures that licensees can access, modify, and redistribute the source code only when creating Windows-compatible applications or components, prohibiting its use in software targeting alternative operating systems such as Linux. Like the Ms-RL, the Ms-LRL incorporates reciprocal obligations: if a licensee distributes binary forms incorporating the licensed code or derivative works, they must make the source code of those modifications available under the same license terms. However, the Ms-LRL's Windows-only restriction renders it incompatible with open source definitions, as it discriminates against non-Microsoft platforms and was not approved by the (OSI), unlike the unrestricted Ms-RL approved in 2007. Introduced within Microsoft's Shared Source Initiative, which began in May 2001, the Ms-LRL served to enable with developers and partners on Windows ecosystem enhancements while protecting core from broader or competitive . Its terms align with the initiative's restrictive category, prioritizing controlled access over permissive , and it classified as non-copyfree to clauses requiring source disclosure for under specific conditions. No major software releases under the Ms-LRL have been prominently documented, reflecting its niche application for proprietary Windows-focused development.

Microsoft Reference Source License (Ms-RSL)

The Microsoft Reference Source License (Ms-RSL) constitutes the most restrictive category among Microsoft's Shared Source licenses, designed to provide developers with access to source code solely for non-distributive reference purposes. Introduced as part of the Shared Source Initiative in May 2001, it grants a non-transferable, non-exclusive, worldwide, royalty-free copyright license limited to reproducing the software for "reference use," defined as internal examination within a company to debug proprietary programs or for educational study of implementation details. Under Ms-RSL terms, licensees may view and analyze the code but are expressly forbidden from modifying, distributing, sublicensing, or incorporating it into derivative works, ensuring Microsoft's retention of full intellectual property control while enabling targeted transparency. The license acceptance occurs upon use of the software, with no rights extended beyond the specified reference scope, distinguishing it sharply from permissive models by prioritizing proprietary safeguards over collaborative freedoms. In practice, Ms-RSL facilitated release of .NET Framework base class library reference source code, notably for versions up to .NET Framework 4.5, announced on August 15, 2012, to aid developers in understanding runtime behaviors, enhancing debugging, and improving interoperability without enabling competitive replication. This application underscored its strategic role in fostering ecosystem trust among enterprise users while averting the risks of full open-source exposure, as evidenced by its exclusion from approval due to absent redistribution rights.

Practical Applications

Software Components Released Under Shared Source

The Shared Source Initiative enabled Microsoft to release source code for select software components, typically under restrictive licenses that permitted viewing, modification for non-commercial purposes, or interoperability work while prohibiting broad redistribution or derivative commercial products. These releases targeted developers, academics, governments, and partners, fostering ecosystem development without full open-source freedoms. Key components emphasized .NET-related technologies and embedded systems, with access often requiring agreements to limit usage. A foundational release was the (SSCLI), codenamed , version 1.0, made available on , 2002. This provided a functional implementation of the ECMA CLI standard and C# language specification, spanning over 9,000 files across and platforms, including core runtime, class libraries, and compilers for educational and research analysis. The accompanying allowed debugging and porting for learning but barred commercial deployment or unmodified redistribution. SSCLI version 2.0 followed on March 11, 2006, under the Microsoft Reference License (Ms-RL), incorporating updates aligned with .NET Framework 2.0 features such as improved JIT compilation and metadata handling, while maintaining restrictions on commercial use and requiring source modifications to be shared back for certain derivatives. This version supported broader reference purposes, aiding interoperability efforts like those in Mono project analysis, though Microsoft emphasized its non-production intent. In July 2004, Microsoft expanded Shared Source access to include components from Windows CE .NET (kernel and drivers), ASP.NET (web framework elements), Visual Studio .NET (tooling subsets), and Passport Manager (authentication modules), primarily for qualifying governments and enterprises to review security and compatibility. These releases, totaling millions of lines of code, were governed by licenses like the Microsoft Limited Public License (Ms-LPL), enabling internal modifications but restricting external sharing. Additional embedded-focused components, such as select modules in Microsoft Windows Embedded CE 6.0 (released in 2006), were distributed under Shared Source terms to OEM partners for customization in devices like industrial controllers, with licenses enforcing non-disclosure for proprietary extensions. Overall, these components demonstrated Shared Source's role in controlled transparency, contributing to over 650 projects by 2007, though empirical adoption metrics remained internal to Microsoft.

Adoption by Partners and Developers

The Shared Source Initiative saw significant uptake among partners and developers following its expansions in the early 2000s. By March 2004, Microsoft's Shared Source community had expanded to approximately 1 million members, reflecting broad developer interest in accessing source code for Windows operating systems and related components under restrictive licenses. This growth was driven by programs allowing limited modification and redistribution, particularly appealing to enterprise and embedded systems developers seeking to customize Microsoft technologies without full open-source freedoms. Partners, including hardware manufacturers and systems integrators, adopted Shared Source licenses for practical integration needs. In February 2002, Microsoft extended source access to systems integrators, enabling them to tailor Windows code for specific deployments. Hardware partners gained rights to view and modify Windows CE .NET source code, facilitating the creation and commercialization of customized embedded products. A April 2003 program further permitted commercial distribution of modified Windows CE source derivatives, boosting adoption in device manufacturing. By 2005, over 20 Microsoft products were available for source inspection, supporting partner ecosystems in areas like mobile and server customization. Developers leveraged Shared Source for educational, debugging, and extension purposes, with notable examples including the Shared Source Common Language Infrastructure (SSCLI, codenamed Rotor). Released in 2002 under a restrictive license, Rotor provided source for a CLI implementation runnable on Windows, FreeBSD, and Mac OS X, comprising over 9,000 files and 1,300 public classes for studying .NET internals. The Windows Installer XML (WiX) toolset, licensed under the Microsoft Reciprocal License (Ms-RL), enabled developers to build MSI packages and was integrated into numerous .NET deployment workflows. Similarly, Microsoft Enterprise Library, distributed under the Microsoft Public License (Ms-PL), offered reusable blocks for logging, data access, and caching, adopted by .NET developers for enterprise applications since its initial releases. These components demonstrated developer reliance on Shared Source for productivity tools, though usage was constrained by reciprocity requirements limiting derivative works. By the mid-2000s, around 1 million individuals held access to Windows source code variants, underscoring empirical developer engagement despite ideological critiques from open-source advocates.

Evaluations and Outcomes

Demonstrated Benefits and Empirical Successes

The Shared Source Initiative enabled hardware partners to access and modify the source code of Windows CE .NET, facilitating the development and commercialization of customized embedded devices tailored to specific hardware requirements. This capability allowed licensees to create and sell products incorporating those modifications, thereby accelerating in mobile and embedded systems markets. By April 2003, Microsoft expanded the Windows CE Shared Source Licensing Program into the Commercial End-User Program (CEP), building on prior successes that included over 160,000 lines of shared Windows CE code utilized by developers for enhancements and integrations. This expansion permitted broader commercial distribution of modified code, demonstrating practical utility in enabling device manufacturers to optimize performance for niche applications without full open-source redistribution. The initiative's overall reach grew significantly, with reporting that the Shared Source expanded to 1 million developers by , providing access to portions of Windows and other technologies that supported interoperability, educational purposes, and customization while preserving controls. This scale of access contributed to developer familiarity with ecosystems, as evidenced by subsequent program expansions to systems integrators and governments for and compliance.

Criticisms from Ideological Opponents and Rebuttals

Open source advocates, including figures associated with the (OSI), have criticized the Shared Source Initiative for failing to meet established criteria for licensing, such as unrestricted to modify, redistribute, and commercially exploit derivatives. Licenses like the , while permitting modifications, impose requirements that derived works retain restrictive terms, limiting broader community-driven development and deviating from OSI's ten-point . Critics argue that Microsoft's refusal to submit most Shared Source licenses for OSI approval—despite occasional submissions, such as two in —renders the initiative a masquerading as collaborative , potentially misleading developers about the extent of freedoms granted. Free software proponents, aligned with the (FSF), view Shared Source as ideologically incompatible with software principles, emphasizing that most licenses under the initiative do not satisfy the FSF's four essential freedoms, including the right to run, study, distribute, and modify software without encumbrances. For instance, restrictive access models, such as those limiting viewing to approved entities (e.g., only about 2,300 companies eligible by 2002, with 150 actively participating), prevent the "many eyes" scrutiny purportedly needed for robust software and evolution, a hallmark of fully libre models like the GPL. Partial disclosures, such as sharing only 90% of Windows source while withholding competitive or cryptographic components, further fuel accusations of selective transparency designed to harvest developer feedback without reciprocal openness. Microsoft rebutted these critiques by positioning Shared Source not as open source, but as an intermediate approach on a spectrum between full proprietary control and unrestricted openness, tailored to protect intellectual property while enabling targeted collaborations like interoperability testing and bug fixes. Company representatives, such as licensing director Jason Matusow, argued in 2002 that widespread demand for source access was overstated, with empirical disinterest from most manufacturers and evidence of effective grassroots engagement—e.g., 128,000 downloads of Windows CE code—demonstrating practical value without needing full freedoms. They countered security claims by noting vulnerabilities in open source projects, such as the Kerberos flaw, and highlighted Shared Source's role in accelerating partner-driven improvements, as seen in government approvals for 60 nations by the early 2000s, which facilitated customized deployments without risking core IP erosion.

Long-Term Influence

Transition to Broader Open Source Engagement

In the mid-2000s, Microsoft began aligning select Shared Source licenses with (OSI) standards to facilitate wider developer participation beyond restricted access models. The (Ms-PL), originally the Microsoft Permissive License, was approved by the OSI in 2007, enabling unrestricted modification and redistribution of covered code while requiring attribution. Similarly, the (Ms-RL) received OSI approval in 2007, imposing reciprocity only on derivative works that link with original components. These approvals marked an early pivot from purely proprietary sharing to permissive principles, allowing components like the .NET Framework subsets to attract external contributions without full source disclosure of Windows internals. By the early , empirical feedback from Shared Source adopters—such as in embedded systems and academic —highlighted the benefits of community-driven , prompting to experiment with fully releases. In 2014, under CEO , open-sourced the Core runtime and libraries under the , hosted on , which garnered over and thousands of pull requests within the first year, demonstrating accelerated through global . This shift extended Shared Source's diagnostic into production-grade ecosystems, with Core achieving cross-platform compatibility on and macOS by June 2016. The transition culminated in Microsoft's formal commitment to governance. In September 2017, the company joined the OSI as a Premium sponsor, signaling a strategic embrace of norms after years of selective engagements to Shared Source's . This was followed by the June 2018 acquisition of for $7.5 billion, integrating over 28 million repositories into Microsoft's developer tools and fostering hybrid models where proprietary extensions coexist with communal codebases. Such moves empirically validated Shared Source's proof-of-concept for code sharing, evolving it into a broader ecosystem where Microsoft contributed to projects like Linux kernel improvements via the Linux Integration Services, amassing over 20% of Azure's workload on foundations by 2020.

Enduring Role in Microsoft's Ecosystem

The Shared Source Initiative's controlled access model endures within Microsoft's ecosystem primarily through the Government Security Program (GSP), launched in January 2003 as a direct extension of the SSI to address governmental demands for code transparency without compromising intellectual property rights. Under the GSP, qualifying national governments gain read-only access to select source code for key products, including Windows operating systems and Office applications, via a secure web portal known as Code Center Premium (CCP). This arrangement, which prohibits modification, redistribution, or external sharing of the code, supports independent security audits and vulnerability assessments while restricting usage to internal government review. As of February 2024, the program continues to operate with online access provisions, emphasizing enhanced security protocols for code inspection to build assurance in Microsoft's platforms amid evolving cyber threats. Beyond governmental use, remnants of Shared Source principles influence partner and enterprise engagements, where limited code visibility aids interoperability for independent software vendors (ISVs) and systems integrators in specialized scenarios, such as customizing embedded systems or verifying compatibility with proprietary Microsoft components. Although Microsoft has largely transitioned newer projects to OSI-approved permissive licenses like MIT and Apache 2.0, certain legacy codebases—particularly in .NET-related libraries originally released under the Microsoft Public License (Ms-PL)—remain available under Shared Source terms, enabling ongoing reference and derivative works in commercial ecosystems without mandating reciprocal openness. This selective persistence allows Microsoft to sustain ecosystem loyalty among enterprises requiring tailored access, distinct from full open-source redistribution, thereby preserving competitive advantages in closed-source core technologies. The SSI's framework has thus embedded a hybrid code-sharing paradigm into 's operations, informing ongoing initiatives like secure development pipelines where partial transparency fosters trust without eroding value. Over governments participated in early GSP expansions by , demonstrating empirical for such mechanisms, which continue to underpin bilateral agreements on product . This enduring underscores a pragmatic evolution from SSI's origins, prioritizing verifiable and partner enablement over ideological commitments to unrestricted openness.

References

  1. https://news.microsoft.com/source/2002/02/21/microsoft-announces-major-expansion-of-shared-source-initiativeproviding-source-code-to-systems-integrators/
  2. https://news.microsoft.com/source/2004/03/15/microsoft-announces-shared-source-community-grows-to-1-million/
  3. https://www.networkworld.com/article/856596/software-microsoft-consolidates-shared-source-licenses.html
  4. https://www.itprotoday.com/microsoft-windows/what-you-need-to-know-about-the-microsoft-shared-source-initiative
  5. https://www.crn.com/news/security/23904969/microsoft-expands-access-to-shared-source-program
  6. https://www.govtech.com/products/Microsoft-Expands-its-Shared-Source-Initiative.html
  7. https://news.microsoft.com/source/2004/11/08/microsoft-announces-solutions-sharing-network/
  8. https://www.technewsworld.com/story/microsoft-proprietary-code-and-the-shared-source-initiative-33537.html
  9. https://www.cnet.com/tech/computing/microsofts-long-history-of-open-source-acrimony/
  10. https://www.eweek.com/news/microsoft-expands-access-to-windows-source-code/
  11. https://www.computerworld.com/article/1421876/update-microsoft-to-expand-shared-source-initatives.html
  12. https://news.microsoft.com/source/2001/06/19/microsoft-announces-shared-development-process-for-cooperation-on-key-technology-initiatives/
  13. https://news.microsoft.com/source/2001/06/27/microsoft-expands-commitment-to-open-standards-and-interoperability/
  14. https://news.microsoft.com/source/2003/04/09/microsoft-announces-first-windows-ce-shared-source-program-to-allow-commercial-distribution-of-modified-source-code/
  15. https://www.e-channelnews.com/microsoft-announces-government-shared-source-license-for-office/
  16. https://news.microsoft.com/source/2003/10/22/microsoft-announces-most-valuable-professionals-shared-source-licensing-program/
  17. https://www.eweek.com/news/microsoft-slashes-shared-source-licenses/
  18. https://news.microsoft.com/source/2006/06/27/microsoft-launches-codeplex-a-new-collaborative-development-portal/
  19. https://www.zdnet.com/article/microsoft-gets-the-open-source-licensing-nod-from-the-osi/
  20. https://news.microsoft.com/speeches/speech-transcript-craig-mundie-the-new-york-university-stern-school-of-business/
  21. https://news.microsoft.com/source/2001/05/15/microsoft-to-license-windows-for-smart-cards-source-code-to-card-manufacturers-and-technology-providers/
  22. https://www.bileta.org.uk/wp-content/uploads/How-open-is-open-Microsofts-Shared-Source-Initiative-as-an-Alternative-to-Open-Source-Software.pdf
  23. https://fossa.com/blog/open-source-licenses-101-microsoft-public-license-ms-pl/
  24. https://arstechnica.com/information-technology/2007/08/evaluating-microsofts-shared-source-licenses/
  25. https://timheuer.com/blog/osi-approves-microsoft-open-source-licenses/
  26. https://opensource.org/license/ms-pl-html
  27. https://opensource.org/license/ms-rl-html
  28. https://www.itnews.com.au/news/osi-approves-microsofts-open-source-licenses-94736
  29. https://nzoss.nz/content/osi-approves-microsoft-license-submissions
  30. https://www.mend.io/blog/top-10-microsoft-public-license-ms-pl-questions-answered/
  31. https://spdx.org/licenses/MS-RL.html
  32. https://visualstudiogallery.msdn.microsoft.com/6d1586a9-1c98-4ac7-b54f-7615d5f9fbc7
  33. https://www.theregister.com/2005/10/19/microsoft_sharedsource/
  34. https://linux.slashdot.org/story/08/05/12/1325203/microsoft-shared-source-attempts-to-hijack-foss
  35. https://spdx.org/licenses/MS-LPL.html
  36. https://visualstudio.microsoft.com/license-terms/dn458602/
  37. https://microsoft.fandom.com/wiki/Shared_source
  38. https://openhub.net/licenses/MS-RSL
  39. https://www.codemag.com/Article/2009041/When-Open-Source-Came-to-Microsoft
  40. https://developers.slashdot.org/story/05/10/19/1530216/microsoft-reduces-shared-source-licenses
  41. https://devblogs.microsoft.com/cppblog/atl-server-visual-c-shared-source-software/
  42. https://lists.fossology.org/g/fossology-commits/message/619
  43. https://copyfree.org/standard/rejected
  44. https://wiki.geant.org/pages/viewpage.action?pageId=579141681
  45. https://www.quora.com/Why-is-MS-RSL-Microsoft-reference-source-license-not-considered-an-open-source-license
  46. https://opensource.stackexchange.com/questions/7665/what-is-the-meaning-of-the-term-company-in-ms-rsl
  47. https://devblogs.microsoft.com/dotnet/announcing-the-release-of-net-framework-4-5-rtm-product-and-source-code/
  48. https://meta.stackoverflow.com/questions/328240/is-pasting-code-from-the-reference-source-from-microsoft-legal
  49. https://learn.microsoft.com/en-us/archive/msdn-magazine/authors/jason_whittington
  50. https://github.com/SSCLI/sscli20_20060311
  51. https://www.informationweek.com/software-services/microsoft-depends-on-shared-source-dips-toe-in-open-source-waters
  52. https://docs.firegiant.com/wix/
  53. https://www.microsoft.com/en-us/download/details.aspx?id=38789
  54. https://www.zdnet.com/article/open-source-shared-source-or-secret-sauce-5000125363/
  55. https://redmondmag.com/articles/2007/03/01/cracking-open-the-door-to-open-source.aspx
  56. https://www.itpro.com/126176/microsofts-quest-for-shared-source-approval
  57. https://www.fsf.org/news/osi-fsf-joint-position-cptn
  58. https://github.com/sirredbeard/microsoft-opensource
  59. https://opensource.microsoft.com/blog/2017/09/26/microsoft-joins-open-source-initiative/
  60. https://news.microsoft.com/source/2003/01/14/microsoft-announces-government-security-program/
  61. https://www.microsoft.com/en-us/securityengineering/gsp
  62. https://learn.microsoft.com/en-us/security/engineering/programoverview
  63. https://learn.microsoft.com/en-us/security/engineering/onlinesources
  64. https://news.microsoft.com/source/2004/09/19/microsoft-announces-government-shared-source-license-for-office/
Add your contribution
Related Hubs
User Avatar
No comments yet.