Ogre Forums

I have a question to a legal topic: I would just like to know if someone has some knowledge, experience or just random thoughts on the legal status of file formats. I did some first google searches, but that did not bring up helping hits...

• Situation: I am currently writing a conversion tool for some file formats used in music production / composing / sampling. Right now, it is primarily targeted for personal use, but I consider as well (far away in the future) to release it to public or even charge a little bit of money for it once it reaches a stage where I could justify that. There is already at least one such tool on the market, yet rather expensive (~80€), packed with functions I don't need, hence the self-development.
• The question is now: Are you generally allowed to decode and (commercially) use foreign file formats? How is "proprietary" defined in this context (imagine that this plays a role here)? Could the company that created the format as for license fees or similar things (as they perhaps already do with for the mentioned one existing tool)?
• What are we actually talking about: The main format leading to these thoughts is the *.NKI format from the company "Native Instruments". It is basically a zlib compressed XML file with some extra bytes. So, I fail to see here some sort of intellectual property that could protect it. The other one is *.SF2 (Soundfont), which should not be a problem since the company that invented it even offers a free code example on how to load an read them (dating back to 1995!) and there are quite some tools to use and alter them out there.

So, do I need to get a written permission from Native Instruments (mainly from the hard legal point of view, since I probably would try that either way, once I plan on releasing the tool). But, if I already knew right now, that this ain't gonna happen at all, I can leave out all the parts to increase usability and make it more self-explanatory.

Looking forward to your thoughts!

Cheers - spacegaier

PS: Yes I know that we are not a community specialising in legal issues, but as it is quite related to IT some of you might know something or have some thoughts.

I am NOT a lawyer...

I assume both are sample libraries for instruments to be used in sequencing software etc. As long as you don't convert the samples themselves and ship the converted versions, I can't see how they would care too much. That should be their primary concern. They had to have given specs for decoding these formats to the big players at some point (the Reaktor's, Ableton's, Logic's, etc. of the world).

Interesting that you directly bring in the corresponding sample libraries. I thought that this question with the file formats was independent of the audio samples. Imagine that I recorded an instrument myself (so have several .WAV files from the recording session), would I then be allowed to create a .*NKI file for them and therefore decode and use this file format?

For non-musicians: A *.NKI file stores information about the used samples (*.WAV) so where the are located and for which note they should be used and if the are looped and so on...

To keep that topic clean: Let's differenciate between file format usage in general versus this special case where samples are involved and we are talking about music / sampling library formats.

Not a lawyer, either, but I don't think a file format in itself is protected, only particular data stored in that format is copyrighted. There are, however, patent issues to deal with (see mp3 and most video formats). If you need a specific (protected) algorithm to transform your data before storing it, that might be an issue.

Well, in my case here (the *.NKI format) the storing is just taking the XML and compressing it via zlib and putting some bytes in front of it. Not really something that I would entitle as specific protectable storing algorithm, would you?

Of course the data/content stored or associated with that file (e.g. the *.WAV audio samples this *.NKI file points to) can be protected by copyright. No question about that. But that is then down to the user using my tool to decide whether he or she is allowed to actually convert files. At least that's how I see it...

And I would agree with you. But I wouldn't know for sure
Only thing I do know is that I have seen enough programs able to import/export foreign formats (OpenOffice could import/export MS Word .doc even before Microsoft made their new format an ISO standard), but have never heard of a suit against such usage. I could of course just have missed those.

From my opinion, you can have a problem only in case of patent.
If there is a patent, then the algorithm must be made public.
If the algorithm is not public, then there is no patent.

As a consequence, if the xml is just 'encrypted' with a few byte, there is almost no way it is patented.

If someone reverse engineer correctly a closed product, well, bad luck for the producers, they should have patented it. (And yes, software patents are often stupids).

madmarx wrote:If there is a patent, then the algorithm must be made public.
If the algorithm is not public, then there is no patent.

As a consequence, if the xml is just 'encrypted' with a few byte, there is almost no way it is patented.

That's how I see it as well: This is far too common (just compressing a XML file) than being worth a patent. Just to be sure I should perhaps have a look at the online patent archives...

So bottom line is: If they don't have a patent, I am free to use (= decode) the format (commercially)? Or is that a too fast conclusion?

one to watch out for is container formats like avi/mkv where it could be using somthing patented or not depending on the app that produces the file

Okay, then it would purely depend on the application, because as the .AVI format belongs to the family of RIFF that as far as I can tell are all open. The SF2 format I am targeting with the converter also belongs to that family. So as long as there is no patent on the actual structure of a file and I am not using any protected algorithms, there shoulnd't be a problem, right?