ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
<cr1901_modern>
Sorry I still don't understand.
<cr1901_modern>
>firefox code has to be released under all licenses, not just one
<cr1901_modern>
Okay so timberwolf chose MPL?
<andlabs>
okay so
<andlabs>
firefox is released under Your Choice Of MPL, GPL, LGPL
* cr1901_modern
nods
<andlabs>
all the code that goes back upstream into the main firefox project must legally be available under that same license option — Your Choice Of MPL, GPL, LGPL
<andlabs>
otherwise it wouldn't be legally distributable
<cr1901_modern>
Oh, so timberwolf chose only MPL, meaning their changes can't be put back into Firefox
<cr1901_modern>
b/c their changes are only MPL-licensed
<andlabs>
correct
<andlabs>
but it gets worse
<andlabs>
the MPL allows linking to proprietary code
<andlabs>
all the *new* code that timberwolf wrote is so licensed
<andlabs>
not any of the above, but strictly "aviailable"
<cr1901_modern>
Ahhh, so timberwolf as a whole is source-available, and they're using the fine print of MPL to prevent someone from attempting to plug their changes to Firefox code back into Firefox.
<cr1901_modern>
That's shitty
<cr1901_modern>
Sounds like my particular solution to any emulator I write is to license MPL-only then- to prevent shenanigans like this.
<andlabs>
I don't know
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined ##yamahasynths
andlabs has joined ##yamahasynths
<balrog>
cr1901_modern: what's the thing with MPL and timberwolf here?
<balrog>
please note that with firefox things are more complicated because MPL 1.x is not compatible with GPL/LGPL, unlike MPL 2.0 which is
<balrog>
I think they dropped the triple license when they moved to MPL2
<balrog>
it looks like timberwolf used to be open source?
<cr1901_modern>
balrog: andlabs explains it better than I do. It looks like timberwolf hasn't been updated in a long time, and that might be before the 1.x/2.0 change
<balrog>
cr1901_modern: what kind of use are you trying to prevent?
<balrog>
MPL only will not hep
<balrog>
help*
<balrog>
andlabs: I think perforce uses rcs under the hood lol
<cr1901_modern>
(7:04:32 PM) cr1901_modern: If you're going to be a reference impl of cycle-accurate behavior, my opinion is keep it GPL to (severely) discourage behavior where commercial products make improvements and don't share their changes back
<balrog>
MPL won't help you there
<cr1901_modern>
Okay... why not?
<balrog>
because someone can implement their improvements in separate proprietary files that are linked with your code
<cr1901_modern>
hmmm :/
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined ##yamahasynths
<whitequark>
i mean, if they really want, they can just run the GPL library out of process
<whitequark>
the FSF frowns upon this, but in case of an FM synth there's a very natural interface that isn't just your library's API
<andlabs>
it's the amiga-specific code that's not MPL
<cr1901_modern>
And passing data to and from an FM synth process wouldn't be the bottleneck.
* cr1901_modern
started looking up portable IPC on a lark
<cr1901_modern>
Would be curious to benchmark at some point, so I'll file this away for later
<superctr>
stream vgm data over a socket or a pipe?
<superctr>
get audio samples the other way
<cr1901_modern>
Well yes. Just aesthetically, if you want to do sockets then TCP/IP is the only portable way between Windows and *nix. And Idk enough about difference between *nix and Windows pipes.
<cr1901_modern>
And I've had code denied by others for implemting portable IPC by TCP/IP :P