Re: [fluid-dev] Another application using FluidSynth announced

[Matt Giuca]

> You are assuming too much here. We don't know under which license Rouet 
> Production is going to release his product in October.

Hmm, I possibly side-tracked this thread a bit. In my post, I was
speaking generally about coming up with a consistent policy for this
sort of behaviour, not specifically about Rouet. I hadn't looked into
the details of Slide Control.

I can't find any licensing information about Slide Control, nor any
source code. While (as you say) it hasn't been released yet (combined
with FluidSynth), I'd be expecting the release in October not to
include linkable object files or licensing information (but I could be
wrong).

Just an aside, one thing that concerned me is here:
http://ipadloops.com/tag/rouet-productions/
I don't know who wrote that page (it's on a different site), but it
says "Fluidsynth (by the same company of course) is a sound font
player" -- I don't know who this company is, but I don't think they
can claim to have written FluidSynth.

> Maybe you know much more than I, then. Is Paul Brossier, the guy that posted 
> that question, working for Rouet Production? Are them related somehow?

Again, I was speaking in general terms, and didn't mean to imply any
connection between Brossier and Rouet.

> You need a compiler and some other tools to produce an executable in any 
> platform. To compile FluidSynth for  Linux you need to accept a license of 
> the GCC compiler as well, which is also the official iOS and Mac OSX 
> compiler, distributed by Apple under the GPL, of course. You can download the 
> Xcode package from Apple (containing GCC and other tools) to build Mac and 
> iOS applications, and it doesn't cost money. Note that "gratis" is not 
> required by the GPL, anyway.

While it doesn't explicitly say "gratis", I believe that point is
countered by the last two paragraphs of LGPL 2.1, which I quote in
full:

"For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.

"It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute."

So you could consider GCC, the Win32 API, the underlying binary
interface of iOS, etc, to be included in that exception, as they are
all either distributed with the operating system or easily available
for free. However, the Apple iOS developer tools do not fall under
that category, do they?

You said that Xcode is free. I don't know much about Apple
development, but from what I gather, even if you are allowed to build
software for an emulator, it is still not possible to transfer or run
compiled applications onto an Apple iOS device without the Apple
developer fee. Am I wrong about this? If so, I believe that that
constitutes "utility programs needed for reproducing the executable"
(where I would interpret "reproducing the executable" as meaning
reproducing something which can be run the same way, not a pile of
bits that is useless until Apple signs it). You might also go so far
as to argue that Apple's App Store approval process is part of the
process "for reproducing the executable", and that certainly isn't
readily available. But again, I am not a lawyer.

> And _this_is_the_real_problem_ with Apple's App Store. By distributing a GPL 
> program with additional restrictions, they are violating the GPL. Not the 
> program authors, or the release team, but Apple.

But it doesn't matter (from FluidSynth's perspective) *who* is
violating the (L)GPL -- Apple or the developers -- unless you actually
plan to sue them. If you just plan to file a complaint, then it will
be the same either way -- you will be demanding that the app is pulled
from the App Store, Apple won't care (so may or may not comply), and
the person who wrote the app will be upset.

> David:
> But even if Rouet would plan not to give out source code to the extent needed 
> to relink FluidSynth,
> one thing keeps bothering me. They actively chose to credit us by having our 
> logo at startup,
> mentioning it on Youtube etc. This is positive, and they could have just have 
> hidden that fact away
> and the chances anyone would notice it would be fairly small I guess. I'm 
> just afraid that going after
> them with threats will lead to the next iPhone app developer just using 
> FluidSynth without telling
> anyone instead, and likely getting away with it.

I can't disagree with that. But that's why I'm encouraging (in my
previous emails) an educational stance (a policy and clear statement
of it on the FluidSynth website) so that *if in fact* this is deemed
unacceptable, people thinking about starting such a project will know
not to bother, as opposed to threatening existing projects.
Alternatively, *if this is* deemed acceptable, what are the guidelines
(as a bare minimum, you do have to release either the full source code
to your program or linkable object files, and you must preserve the
FluidSynth copyright notice)?