Hopefully one of the FMOD guys can solve a debate… there is quite a bit of arguing in some circles (Quake Development, general GPL programming) over whether or not the FMOD license is compatible with the GPL.
>>Yes that’s right, if your product is not intended to make any money, and is not charged for in any way, then you may use FMOD in it for FREE!
That seems pretty straightforward, but the issue is really that FMOD is closed source, and the GPL wants everything non-OS related to be open. A lot of people have taken the middle of the road opinion that if you link to it and use it but don’t REQUIRE it (eg the program runs without the FMOD dll present) and you don’t distribute the FMOD dll with the GPL source/binaries then you are OK. Honestly the whole debate is a pain and hopefully someone ‘official’ and in the know can clear it up. Thank you. – NeVo
Edit: Some possibly helpful links:
Yep If you own the copyright on something it is up to you what you allow people to do with it.
However if you are linking your “GPL with exception” software with other GPL software, to be safe (and more importantly polite) you should ask the owner of the other software for permission.
Disclaimer: I’m a sound guy not a lawyer.
I’m not that much of a GNU’ish person, but I’ve always interpreted it like this:
If FMOD was released under open source GPL, and I wrote say a SoftSynth library changing some parts in FMOD ( tweaking it ) to fit my need. I would then have to make the parts of FMOD that I changed/tweaked open source, but not the additional stuff.
Thus, taking Stdio.h as Brett’s example. If you changed Stdio.h in any way, you would have to include your altered version of stdio.h as open source, but not the rest of the library.
Or is that just my interpretation?
- DEVLiN answered 13 years ago
Optionally, one could create an interface layer for Linux, and release the source for that (since that would be a “derived work”) but not GPL it (so it conforms with the GPL, but doesn’t impose the GPL on subsequent derivations).
I believe that’s the way nVidia’s binary driver is handled (a binary driver + interface layer as source).
It’s kinda silly, but I think a lot of the ambiguity rises from what exactly constitutes a “derived work”
- TheContact answered 13 years ago
Hi Brett, this stuff is about kernel modules, not user-space libraries and applications. Linus also says in that article that as far as he is concerned anything in user space is not derivative of the kernel. AFAIK the oss stuff is not GPL- it is in other unicies like the bsd’s too. And libasound and glibc are released under the LGPL rather than GPL which means you are allowed to dynamically link to to them. However there are some requirements in the LGPL that you don’t seem to be complying with eg crediting that they are being used. I hope you aren’t statically linking libasound.
Perhaps ask the free software foundation- they don’t bite if you are having a good attempt at complying with their licenses.
Also you told me at the ADGC last year that SUSE had asked you to port fmod to alsa0.9, and AFAIK SUSE have been the major funder of alsa development.
- lorien answered 13 years ago
I read this whole thread and still some things aren’t entirely clear to me.
I am working on a DJ’ing program for linux (which is using fmod off course), and it’s starting to get ready so I’m planning to do kind of an “official” release next week (that means, putting everything online on a website and making an announcement to freshmeat.net and openjay.org), so I would like to have all this licencing troubles solved before I do the actual release.
But I think it is gonna be kind of a mess because my program is dynamically linked against:
– mysql (which is available both under the GPL as a commercial, paid licence)
– QT (similar to mysql)
– fftw (similar to mysql)
– libfs++ (A very tiny GPL library where I don’t use a much of functionality from, it should be easy to get rid of that one)
– id3lib (LGPL, so no problem here)
Technically, I am not linking against fmod because I load it dynamically using fmoddyn.h and link with -ldl. But off course, without the fmod libraries present, the audio player component won’t initialise so the program would be quite useless (unless you use it just to organise your mp3 collection, since it has kind of a functionality to do that also).
Furthermore, the only place in my source code where fmod interacts directly with a GPL library is in a DSP callback where I make some calls to fftw (which I use for beat detection). The QT audio player interface doesn’t make direct calls to fmod, instead of that it communicates with an AudioDeck class which is a kind of an interface class to fmod. (So I have an AudioDeckWidget which makes calles to AudioDeck, and AudioDeck handles the fmod things)
So what should I do now? Is it safe to release it as it is now or should I ask permission to the authors of all the GPL things I’m using?
It’s driving me crazy, it seems easier to buy commercial licences of all the things I’m using and make only a commercial, closed source release of my program than to release it for free (and open source).
I mailed to the MySQL, FFTW and QT people to ask if I can use their libraries together with fmod, and I ‘ve got already one reply from FFTW and their answer is, unfortunately, “no”.
If most authors of GPL software do the same (I assume they do), this puts a serious limitation on the use of fmod in linux and other open source projects
So basically, I have following three options now:
drop fmod and search for another audio framework.
This option would be hard because I don’t know of a good (L)GPL replacement for fmod which is as fast (I tried some other linux DJ’ing programs but they all had more latency, stuttered playback, or bad sound quality), but maybe it could be worth investigating…
replace the three GPL libraries (QT, FFTW, MySQL) by others which are LGPL (GTK+, Kiss FFT, PostgreSQL)
I don’t like this, too, because it will envolve a complete rewrite of the GUI and the database interface (replacing FFTW isn’t that hard). Furthermore, I have found very good GPL’ed beat detection algorithms which I was planning to use.
find a workaround for using fmod legally in combination with GPL libraries. (by, for instance, make the interface to fmod available as kind of plugin, which doesn’t make use of GPL libs)
I don’t know how I should accomplish this technically, but I’m gonna think about it. It would at least require me to separate the QT interface and fmod calls completely, which prohibits me to write some QT dialog for configuring sound drivers and sound cards.
I don’t know which way I’ll be going. The best thing that can happen is that the linux version of fmod will be released under GPL. I know that there is very little chance that Brett will do this, but please let me bring up some arguments for doing so anyway:
– Is there so much “rocket science” involved in fmod that it is really important to keep your code secret? There are much other open source sound libraries available (the FFTW guy pointed me out to some, like PortAudio), so it would be only useful to keep the source code closed when it is really innovative compared to other libs. If the other libs are as good as fmod (I don’t know this because I didn’t test them yet), there is no point for me (and other linux developers) for using fmod.
– The fact that the linux version is closed source and Brett doesn’t seem to test the linux version thoroughly so it takes longer for linux problems to get fixed. No offence, but this is what I’ve seen during the period I have been working with fmod. For instance, I reported the broken alsa interface half a year ago (http://126.96.36.199/forum/viewtopic.php … light=alsa), and it was fixed in fmod a week ago. When the linux version had been GPL’ed, other linux developers could have fixed the problem in days.
– By releasing your code under GPL, it can’t be used in commercial projects either so people wanting fmod in their commercial project would have to buy an fmod licence anyway. MySQL, FFTW and QT are both available under GPL and a commercial licence, so it seems that such a licencing strategy isn’t that harmful. Maybe you’re afraid that others steal your code and use it illegally in their commercially projects, but I don’t think many companies would be taking that risk. Even microsoft doesn’t seem to do it, they only use some BSD code.
– Maybe you could just release fmod 3.7X under GPL when fmod Ex is released and keep the fmod Ex source code closed? 😉
Maybe this has been discussed earlier, but maybe it’s worth to think about it again.
Well I’m not someone “official”, but I’ve been using the GPL and Linux for years, so:
Sorry, but all this is wrong. The reason why msvcrt etc can be linked with a GPL prog is because it is fine to link against a library provided as a standard component of the OS. Which fmod certainly is not. Just because it is OK with Brett and Firelight doesn’t mean it is OK with the free software owner, and you could find yourself in big trouble with the GNU people. There are ways around it though:
1)If you are writing a GPL prog that uses fmod you must include a notice stating that as an exception to the GPL you permit dynamic linking with fmod
2)If you are modyfying a GPL prog to use fmod you can ask the primary author for permission to link with fmod.
3)Ask Brett very nicely for a GPLed version of fmod
If there is any confusion about the GPL/LGPL it is always better to ask 1)the programs owner, ’cause what they say goes :), and 2)someone at gnu.org.
Please login first to submit.