> 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)? _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
