3D Sound System

[zammbi]

Thanks for looking at this!
Have you tried jobrbis? http://www.jcraft.com/jorbis/
That might help you.

[paulscode]

I will only use jorbis as a last resort, since I want to avoid anything with the term "GPL" attached.  Granted, this library only falls under the "Lesser" GPL, but I am still very leery about using anything with GPL on it, as the legal restrictions are extremely complicated, controlling, and very difficult to understand.

[zammbi]

Oh ok, I see everyone using that one. I do remember there was another one around but can't remember what its called.

Maybe the creator of Jogg could help about the problem?

[zammbi]

I searched around, I found 2 others that were also GPL.
But I also found this one: http://jflac.sourceforge.net/index.html
It has no real licence. Hope that helps.
Also has last updated in 2008.

[paulscode]

Yeh, I've done some more searching as well, and it looks like there isn't going to be anything without the LGPL license (unless I wanted to remove support for .ogg and switch to .flac).  If I can't solve this j-ogg problem, then I'll probably just have to read that LGPL document carefully to figure out what all the legal jargon in there means, and what my obligations are if I decide to use it in my library.  I am definitely no lawyer - documents like these sound like a foreign language to me.

The main thing I want to make absolutely sure of is that anyone using SoundSystem is NOT required to distribute the source-code to their projects, or that their projects must be "free and open".  If anyone has some experience using LGPL licensed stuff, any tips would be greatly appreciated.

[zammbi]

Oh I had thought jflac has supported ogg, because a the site pointing to it said it did. But can't see this on there site so I guess not.
You could always write your own ogg lib 

[paulscode]

You could always write your own ogg lib 

Hehe.  Have you seen the source code for j-ogg?   

[fireside]

The only thing I know about GPL is that if you mix your code with it, then it becomes also gpl.  If you keep the library separate, then your own work doesn't have to be GPL.  If you distribute it, I'm not sure if you are required to place a link to the source or not.  Anyone that uses Java is using GPL code, because Java uses a GPL license, although slightly modified.

[paulscode]

Thanks.  I have posted on several forums a list of questions about LGPL, specific to using JOrbis in my project here.  I am also looking carefully at the text of the license to see what are the legal concerns if I do decide to use it in my project.  So far, I do know that the following will be required:

1) To keep the LGPL license off of my library, the JOrbis source can not be compiled into it.  The difference between GPL and LGPL seems to be that I am allowed to interface with an LGPL licensed library without restricting my project to the license.  The SoundSystem library alone will only be able to load .wav and .mid files, but to support .ogg files, you would have to link to an external JOrbis jar.

2) The user must be able to swap out the JOrbis library for newer versions.

3) Applications using the SoundSystem library which link to JOrbis will not themselves be under the LGPL license.  However bundeling the JOrbis jar with them is, of course, considered a form of "redistributing" the JOrbis library, and must therefore follow the guidelines of redestributing a LGPL software (The JOrbis source will need to be distributed along with the jar, as well the LGPL license and anything else required by the LGPL license).

The things I am unclear on are:

1) For applets which use SoundSystem and link to the JOrbis jar online, is that considered "redistribution" of the JOrbis library, and if so what is required by the applet's owner to be legally compliant with the LGPL?

2) What, besides the JOrbis source and LGPL document, must be included with a project like SoundSystem or a product that uses SoundSystem?  How specifically do those required things need be incorperated into the product (and are there differences between compiled form vs source code, or applet vs. application)?

3) What am I required to tell people who want to use SoundSystem, and specifically how am I required to tell them?

[fireside]

I know with open source games I have played there is usually a choice of a binary distribution.  This dist does not include the source, so I don't think it's required.  The site, however, provides a source code download, or a link to the source code.  It might be simpler to go with an lgpl with your library and then mix the code into one jar, depending how you feel about it, since the restrictions are going to be approx the same so why not just have one jar?  Just a suggestion, of course.  One place where you might want to ask is at the Linux Game Tome.  From what I've used, I think people that use your library would need no more than a link to your site with the source for the sound library.
  http://www.happypenguin.org/

[paulscode]

That makes sense, however I really don't want to include the Jorbis sources in SoundSystem, because I don't want to restrict users to LGPL if they are not using the .ogg format in their projects.

What I am thinking of doing instead is to create an "IDecoder" interface in SoundSystem, and then have any number of independant derivatives which the user may add.

By default, SoundSystem would use a J-Ogg derivitive of IDecoder, for everyone who wants to avoid the LGPL headache and would rather run their .ogg files through a converter to make them work.

Then, I would make a LGPL-licensed JOrbis derivitive of IDecoder available as an add-on.  A user would load an extra jar and use something like this in their code:

Code Select Expand

SoundSystemConfig.addDecoder( "ogg", myJorbisDecoder );

That way, users will only have to deal with the LGPL license if they want to.  This would also make it easy to add support for additional audio formats in the future.  For example I might want to add in the GPL-licensed Gervil MIDI software synthesizer so MIDI could be used like any other format, or I may someday want to implement a .flac decoder:

Code Select Expand

SoundSystemConfig.addDecoder( "mid", myGervilDecoder );
SoundSystemConfig.addDecoder( "flac", myFlacDecoder );

To keep down the size of SoundSystemSmall, it would not have a default .ogg decoder built in, allowing the user to choose which one (if any) they prefer to use.

[fireside]

That sounds pretty good.  Personally, I think I might prefer to run my ogg files through a converter if it wasn't too much trouble and skip having to worry about adding a source code link.  This is one of those times where it really doesn't make sense because it's questionable how it would work with java applets that only stay in memory for a little while. 

[paulscode]

I've been talking with a number of developers who are familiar with the LGLP license, and I have learned a couple of useful things which I thought I would share for anyone who is interested.

The whole point of LGPL is that the user should be able to upgrade the lgpl code/library with different versions. For example, if I were to use JOrbis v0.9 and a user finds that it doesn't work on their system then they should be able to go and fetch JOrbis v1.0 which does work on their system, and use it to play their game with this newer version. It doesn't matter how the user is allowed to be able to do that, as long as it's possible.  It is not necessary to dynamically link (although that is often how it is done) - simply releasing the source code for the parts that incorperate JOrbis is sufficient, so the user can rebuild them with a newer version.  As long as this basic requirement is met, then it is not necessary to license a project that uses LGPL libraries with the LGPL license.

What is interesting is when you are talking about applets.  The basic requirement still stands - that the user must be able to swap out different versions of the LGPL parts.  Again, it doesn't matter how the user is allowed to do this, as long as it is possible.  For example, you are covered if you provide a link to the source code for whatever parts incorporate the LGPL licensed library (since the user can potentially recompile the source with a different version of the library, create a local html file, and modify the <archive> parameters for the applet to link with the new version).  The LGPL license document must also be provided, and if any modifications were made to the original library, those must be clearly outlined and the original source code provided as well.  The easiest way would be to bundle all this stuff together in a zip file and provide a link to it somewhere obvious on the website where the applet resides.

One more interesting thing is that you are allowed to modify the source of an LGPL library, so long as you release the modifications back to the community, which could be as simple as posting an archive of the source code for the modified version.  The modified source is, of course, still bound by the LGPL.

[zammbi]

Still confused on what's happening...
Will I be seeing ogg support anytime soon ? 

[paulscode]

Will I be seeing ogg support anytime soon ? 

Depends on a couple of things.  Firstly, to prove that the problem is with the J-Ogg library and not with my code (I will know when I get JOrbis up and running).  Secondly, whether or not JOrbis is any better/more compatible than j-ogg, or if I will need to try another library.  Lastly, how long it takes me to implement the new IDecoder infrastructure.  This is a fairly significant change, so I don't expect to have it finished and debugged for at least a few weeks.