BSD license for table lookup oscillator adapted from pd

[ndonald2]

So, looking at the BSD license in the pd source (from which our table lookup oscillator implementation is adapted), I think we may have a conflict with our "do anything you want" license.

https://github.com/libpd/libpd/blob/master/LICENSE.txt

Since we're using a portion of source code adapted from pd, parts 1 and 2 would stipulate that anyone who adapts Tonic for their own usage or uses it in a publicly-distributed binary must reproduce the license in the written materials and source code.

I can re-write the table lookups to not use the pd-derived algorithm, but it's by far the fastest implementation I have ever come across. My profiling early on indicated that it was approximately 2x faster than the vDSP library, let alone a more typical C++ implementation like the one in STK.

Performance vs licensing... not really sure what we want to do here.

[ndonald2]

Then again since it's such a small bit of code I have no idea what the exact legal implications are.

Know anyone who knows anything about software licensing law?

[morganpackard]

Maybe we could just get in touch with the PD people and ask them what their intention is?

[ndonald2]

That's a good idea. I know someone who recently emailed Miller Puckette and got a reply, but I don't know that he's actively maintaining it anymore.

[Dewb]

If you want to write up a general description of how the table lookup oscillator works, and what techniques it uses to get the awesome performance, then someone else who has never looked at the Pd code could reimplement the algorithm based on your notes, and then there wouldn't be a licensing issue anymore.

[ndonald2]

Awesome, thanks for the input, Dewb.

So would that description just live in a file that's mentioned in the header of the oscillator?

[Dewb]

Well, it would live on for a time in an issue or a spec document somewhere, then someone who hasn't seen the Pd code could reimplement it and then the description would no longer be necessary. This "clean room" reimplementation runs much less risk of accidental copyright violation versus having someone who had looked at the code try and rewrite it (aka "dirty room" reverse engineering.)

See e.g. http://my.safaribooksonline.com/book/software-engineering-and-development/9788131731857/reverse-engineering/ch09lev1sec4

[ndonald2]

Ah I see what you're saying. That would definitely work, but it's hard to gauge how much time/work would go into both writing a description and getting someone else to successfully reimplement the algorithm.

The funny thing is, there is supposedly a paper floating around somewhere that describes the algorithm - the pd source mentions a research paper before the implementation ("R. Hoeldrich, ICMC 1995 Banff") - but I could not find it for the life of me. Apparently I'm not the only one, according to an archived thread from the pd mailing list I found while digging into it. There are Hoeldrich papers in the 1995 ICMC proceedings, but none of them contain anything related to the table lookup algorithm.

If I could find that paper, that might be enough documentation to make a "clean room" argument against anything that might possibly ever come up.

[Dewb]

Oh yeah, a paper would be excellent.

[ndonald2]

I found a mention on a mailing list archive:

http://lalists.stanford.edu/lad/2000/Sep/0188.html

It seems to be a fairly well-known technique, and our implementation is decently different from pd's so I'm not too concerned. I may do a technical write-up anyway in case someone wants to do the clean room implementation, just because I find it so damned interesting.

[tavi-vi]

I happen to be working on the same problem. I think perhaps the author may have been misattributed, or perhaps something was lost to time. In the same 1995 ICMC proceedings that pd references, Optimizing Software Synthesis Performance by Nicholas Thompson and Roger B. Dannenberg (archive) was published, and it talks about this technique and references Real-Time Software Synthesis on Superscalar Architectures by Roger B. Dannenberg and Clifford W. Mercer from 1992 which was expanded on and published again in 1997 with the same title, and the 1997 version gives a full description of the algorithm. Notably, it differs slightly from the was pd does it.

There may be earlier references, but someone else will have to find them as this is enough for my needs, and hopefully yours as well.