MOOCs | News

edX Revisits Completely Open Source License

• By Stephen Noonoo
• 09/17/14

After famously releasing its source code under a broad open source license, MIT and Harvard’s edX MOOC platform is backtracking a bit—reclassifying part of its code to a less restrictive license that will let programmers use some edX code with closed source platforms and tools.

Previously, Open edX’s source code had been designated under an Affero GPL license, which stated that developers were free to remix the code—frequently used to create MOOC platforms and individual features—so long as their finished products were open as well.

However, in a blog post Ned Batchelder, edX Software Architect, wrote that the single license didn’t “fit all purposes.” Given that a key objective of edX is to establish itself as a sort of industry standard platform, it is relicensing XBlock (an API used to create interactive components in MOOC courses that functions as sort of the underlying architecture of the platform) under an Apache 2.0 license, which allows users to choose whether to share their creations or keep them private.

The switch, Batchelder said, was necessary because some platforms that wished to use XBlock code, or otherwise connect with XBlock components, had licenses that were incompatible with AGPL. Basically, those platforms were less open with their source code.

“Of course the ideal is that all XBlocks will be open source,” wrote Batchelder, while acknowledging that not every component that interacts with XBlock would share the same dedication to openness.

The issue was raised outright in one recent example at the Universitat Politècnica de València in Spain. There, programmers built an XBlock to view files from the math and engineering program Mathematica right in Open edX courses. But Mathematica software is not open source. The new Apache license allowed them to mix components without stepping on any toes.

“We believe that this mixed licensing strategy is the best way to achieve all of our goals: create an ecosystem of shared work and open systems, and also get the broadest possible adoption of our APIs and tools,” Batchelder wrote.