Open Sourcing MSVC’s STL

Stephan T. Lavavej - MSFT

Today at CppCon 2019, we (the MSVC team) announced that we’re releasing our implementation of the C++ Standard Library (also known as the STL) as open source. is our new repository, containing all of our product source code, a new CMake build system, and a README with more information. As it explains, we’re still working on migrating to GitHub. While you can clone and build the code right now, there are several things we need to do (like adding our test suites) before we can begin reviewing pull requests.


Q: Why are you doing this?

A: There are several reasons. Working on the STL in GitHub will allow our customers to follow our development as it happens, try out our latest changes, and help improve our pull requests by reviewing them. As C++ Standardization accelerates, with more large features being voted in every year, we believe that accepting major features as open source contributions will be important. (For example, C++20’s chrono and format libraries are potential candidates.) We also want to contribute back to the C++ community by making it possible to take our implementations of major features. (For example, C++17’s charconv.)

Q: What license are you using, and does this directly affect Visual Studio’s customers?

A: MSVC’s STL is distributed under the Apache License v2.0 with LLVM Exceptions, which was recently created by the Clang/LLVM/libc++ project. We chose this permissive open source license because having the same license as libc++ will make it easier to share code between our libraries. To be clear, MSVC’s STL isn’t merging with libc++; they’re still distinct libraries that support different platforms with different data structure representations. However, if libc++’s maintainers are interested in taking feature implementations from MSVC’s STL (e.g. floating-point charconv), or in collaborating on the development of new features in both libraries simultaneously, we’ll be able to help without having to worry about licensing.

As a customer of MSVC’s STL, you might be wondering whether this new license creates new obligations for you. Microsoft’s position is that the text of the Apache License v2.0 with LLVM Exceptions (specifically, the wording of the LLVM Exceptions) clearly states that when you compile your own source code using MSVC’s STL to produce object code or similar output (e.g. static libraries, dynamic libraries, and executables), you aren’t required to provide attribution when shipping your compiled products to your end users. This is another reason we’ve chosen this license: to avoid disrupting our customers’ businesses.

(Additional note, in the interest of completeness: MSVC’s STL contains source code derived from Boost.Math and Ryu, used under the terms of the Boost Software License v1.0. This is another permissive open source license that also contains an explicit exception for object code. Our derived source code is distributed under the Apache License v2.0 with LLVM Exceptions.)

Q: Are you going to open source anything else in the MSVC toolset?

A: We have no such plans. We chose the STL because it’s different from other MSVC libraries and the compiler. Specifically, the STL is fast-evolving and designed by the C++ Standardization Committee, unlike other MSVC libraries. (Being designed by Committee is an advantage for open sourcing! It means that we don’t need to spend any time and energy on feature design review. Implementation strategy and tactics are far more constrained, and therefore easier to review.) The STL is also relatively easy to contribute to, and somewhat loosely coupled, unlike the compiler (where, as a general rule, everything interacts with everything else).

(One exception: there are support libraries for the STL that we may open source in the future, but we have nothing to announce at this time.)

Q: Is there some catch?

A: A fairly small one: we’re going to spend some time overhauling our build system, test infrastructure, and issue tracking, which will delay some work on C++20 library features. (We just finished implementing all C++17 library features, so this shouldn’t be too problematic.) This will allow us to work on the STL more efficiently and ultimately reach C++20 completeness faster.


The MSVC team would like to thank Dinkumware and P.J. Plauger for making this possible.