views:

83

answers:

2

I have some software that utilizes a C++ template library that is licensed MS-LPL.

MS-LPL specifies:(F) Platform Limitation- The licenses granted in sections 2(A) & 2(B) extend only to the software or derivative works that you create that run on a Microsoft Windows operating system product. Which is my problem as I am moving this code to Linux.

I am wanting to provide a drop in replacement for this particular MS-LPL licensed library, but keep the applications utilizing this library source code compatible.

Are there any restrictions with my library providing identical symbols,macros,types,etc. as to provide this source code compatibility so long as the implementation is re-written?

Someone please educate me =).

+2  A: 

I AM NOT A LAWYER, but this is a common enough question I'm comfortable answering. Don't take my word for it, though. APIs are not subject to copyright laws in the US. Only the actual code that uses them and the actual code that implements them is covered by copyright. You can write your own implementations of any interface you want [EDIT: modulo patents, of course]. This is most likely why Wine hasn't been sued to hell and back by Microsoft.

Cogwheel - Matthew Orlando
I'm not a Wine expert but isn't that a binary interface? API in this is a little confusing to me because a template library is normally deployed in source form not as a DLL for example. Say the MS-LPL library has #define WHATEVER 1; I will need the identical line in my code as to provide they are source code compatible. So I guess the question really is what constitutes as the 'implementation'. Is the implementation just the imperative code itself? The line is very fuzzy to me and I haven't had much experience in this area of legality
Matt Davison
" I will need the identical line in my code as to provide they are source code compatible" <-- That's actually exactly what I was referring to. The courts deemed this as trivial as it seems it should be. :)
Cogwheel - Matthew Orlando
+2  A: 

There could be a potential problem if MS could claim that your product is derived from the library, since you obviously had to look at the code to create the interface. One approach to get around this is called the clean room approach. You have one person/team look at the library and write down the spec for the library, in as much detail as needed to reimplement it, but without any copyrighed code. A second team then takes this spec and reimplements it. Then, as long as it is done correctly, there is no possibility of the new library having been derived (in the copyright sense) from the first.

KeithB