Maybe you will find the answer in the GPL FAQ.
Maybe you will find the answer in the GPL FAQ.
Thank you for that fine link. Unfortunately I'm not allowed to let my tool link to closed-source APIs if I want to release my software under GPL...
I am not sure, but I think you may be ok. I mean there are plenty of GPL'ed applications written in Win32 API, or MFC, which are very much closed source. With these, you indeed have to link against the respective libraries, which are again closed. Maybe I am not understanding the situation. And also i am no lawyer.
Bojan
The march of progress:
C:
printf("%10.2f", x);
C++:
cout << setw(10) << setprecision(2) << showpoint << x;
Java:
java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance();
formatter.setMinimumFractionDigits(2);
formatter.setMaximumFractionDigits(2);
String s = formatter.format(x);
for (int i = s.length(); i < 10; i++) System.out.print(' ');
System.out.print(s);
I would consider the Media SDK to be an OS component. But regardless, it's still okay to do, because you cannot copyright an API. If all you do is link (runtime or dynamic) to an API, you are not creating a derivative work.
AFAIK you can't link to a non-gpl compatible library from a gpl application. You need to find some GPL/LGPL alternative. Alternatively you make make an external library which links to that closed source library and make using it from your application an option -- meaning that your app has to be able to run without it (for example by using some GPL'd alternative).
Another option could be to dynamically load the closed source library using QLibrary and resolve its symbols manually. I don't know what does GPL consider such a situation -- you're not linking with the violating lib, but you still depend on it (unless you make it an option as stated before).
Thanks for the infos. Well, probably it's okay to link to the closed-source libs in my case because every modern Windows ships with some sort of Windows Media Player, so the libs kind of ARE a de facto OS component.
I also have to ship some MS-implemented standard C++ libs because I strictly call Unicode versions of stdlib functions. MS says to ship them along with an application because they are not System-known yet. Technically it's the same problem again. GPL software using essential, but closed-source stdlib functions.
well you should not distribute the media sdl with your program if you license it under the gpl...
then again you could choose a different gpl-compatabile license for your program but i dont know if you want that...
Originally Posted by Bertolt Brecht
There are not Open Source as their sources are not available, so that already makes them GPL-incompatible, no matter if they are shipped with the system or not. Windows Media Player component is not a part of the system. And even if it was, it doesn't change anything, it's still GPL incompatible.Originally Posted by Wan-Hi
As for the media player itself, you could use it in a GPL'd app as an activeX component, provided that you make it possible to use some other component in its place.
Yes it does! Otherwise you couldn't use win32 or any other standard Windows library. The GPL makes an explicit exception for system components. Specifically, the exception clause covers anything "distributed with" the system components. In other words, if it's on the Windows or Visual Studio CDs, you're probably covered.Originally Posted by wysota
Bookmarks