With the release of Microsoft’s Windows 8 operating system approaching (October 26th) I thought I would take a look at the current version of the agreement that developers must sign to get their applications into the Windows Store. There has been some controversy over the Windows Store, with some games company representatives pouring scorn on the potential benefits that the Microsoft-managed distribution channel is said to provide. Clearly Microsoft have seen what Apple has succeeded in doing with their iOS App Store and subsequent Mac App Store (essentially gaining increased control over their developer ecosystems) and decided that they would like some of the same, please.
When the developer agreement was published in December last year Microsoft got some positive coverage from the IT press for what seemed to be a deliberate attempt to include open source software in the range of code that could be distributed via the Windows Store. In fact, as many noted at the time, although Microsoft’s definition of what ‘FOSS’ is includes GPL licensed software (‘”FOSS” means any software licensed under an Open Source Initiative Approved License…’) in practice the fact that the Windows Store agreement imposed restrictions not present in the GPL would make use of third party material under that licence in the Windows Store impossible.
The agreement makes it clear that Microsoft is not an intermediary in the grant of rights from the developer to the end user, but that they do have certain requirements for what that grant of rights should look like. In fact they provide a default agreement between developer and customer which will automatically used if the developer fails to write their own (Exhibit A at the end of the agreement, referred to as the Standard Application License Terms). If the developer does want to write their own, Microsoft has some opinions on what it should look like. These requirements are given in section g:
So for a developer wanting to include third party code, they must determine if the open source licence they have to the code they want to include is compatible with these requirements. (a) and (b) seem relatively unproblematic. (c) could be a problem, depending on how explicitly Microsoft require such a disclaimer to be. If Microsoft need to be explicitly named that could be an issue, as they tend not to be in open source licences . Then we read that, as well as those requirements, our open source licence must also not conflict with any part of the default agreement with the exception of section 3, which it is entitled to overrule. So, at the risk of belabouring the point, we now need to check all the responsibilities we inherit as a result of our inbound FOSS licence against those present in the Microsoft Standard Application License Terms (excluding section 3) to see if this combination of responsibilities results in any conflicts. If it does, we can’t use the FOSS in question. We have to assume, I think, that section 7 of the Standard Application License Terms has to be excluded too, as its requirement that the Standard Application License Terms be the entire agreement between the developer and the customer is necessarily conflicting with any additional/alternative agreements, FOSS or not.
So what’s a developer to do (if they want to use someone else’s FOSS in their project)? Well, in practice, the developer agreement lets us know what we have to do in order to submit our code. After that Microsoft will determine whether our variant customer agreement (including the FOSS terms of the code we reused) meets with their approval or not. Once the Windows Store has been operating for a while we will be able to see practical examples of software containing third party FOSS which have been approved, and start making a de facto list of FOSS licences that Microsoft feel are not in conflict with their model. Of course, it is still possible that the third party FOSS authors themselves might object that distribution via the Windows Store is not in accordance with their understanding of the licence they chose, but that is another issue. What would have been a genuinely useful gesture on Microsoft’s part, however, one that would have made their seeming openness towards FOSS much more useful to the community, would be a pre-delivered list of OSI approved licences that meet the rather difficult-to-assess criteria that we see in the current version of the developer’s agreement. Without it, the developers that Microsoft is so keen to woo to their platform will have to waste valuable coding time doing something that Microsoft’s legal department would be much better placed to accomplish.