|
From: | David Henningsson |
Subject: | Re: [fluid-dev] Another application using FluidSynth announced |
Date: | Mon, 12 Sep 2011 09:58:12 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110906 Thunderbird/7.0 |
On 09/11/2011 09:28 PM, Pedro Lopez-Cabanillas wrote:
On Sunday 11 September 2011, David Henningsson wrote:On 09/07/2011 10:38 PM, David Henningsson wrote:I'm unfamiliar with exactly how development for iPhone works here. If I develop for iPhone, how do I put my own software on there? I mean, even Apple would think there should be a way to test your software on the real thing before publishing? Is that a legitimate path for distributing source code to e g FluidSynth?From what I can understand the development tools are free to download and use, but testing your software on the iPhone or iPad costs $99 per year. [1] Interestingly enough, this is a relatively low fee compared to buying an iPhone/iPad.This is true, latest Xcode release is available for download in the Mac App Store at no charge: http://itunes.apple.com/us/app/xcode/id448457090?mt=12 Older releases where in the second DVD, named "Mac OS X Install Disc 2" distributed with the Macs, like mine. I've downloaded also some version from Apple as well, and I'm not a member of the iOS Developer Program. But as I've said, if the compiler and developer tools are "freeware" or not is irrelevant from the license point of view, in my opinion.
Do you consider the $99 fee part of the compiler in this case?
These are the same tools used to build all Mac OSX applications; any legal restriction because a GPL interpretation would mean that developing GPL applications for Mac OSX would be forbidden as well.I'm assuming that this "testing" is not crippled in any way to make it different from running the App Store distributed one.The documentation says that testing an application in iOS devices requires a certificate signed by Apple, that is available only to the members of their club (paying $99 per year): http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iphone_development/128- Managing_Devices_and_Digital_Identities/devices_and_identities.html#//apple_ref/doc/uid/TP40007959- CH4-SW2 But there are alternatives: http://www.saurik.com/id/8
That link, as I understand it, is about jailbreaked devices (as it starts with saying that the iPhone dev team has changed the kernel).
For me, jailbreaked devices are out of the question - you can do anything with them anyway, and they are not guaranteed to be available to the people you make the binary available to.
As for my own opinion, I tend to be pragmatic in the sense that I look for practical possibilities rather than the letter of the law.Let me clarify this a bit. LGPL contains a lot of rules and regulations, but let me point out the two types of freedom, that the end user is given, and that are important to me: 1) Available source code. I e, if the developer fixes a bug in FluidSynth and makes that version of FluidSynth publicly available, we should be able to take that fix and incorporate it into the next FluidSynth release, and release that version under LGPL. In this case, Rouet can fulfil that requirement by publishing their FluidSynth source code changes, or publicly state that they haven't done any changes. 2) Updating FluidSynth. If the end user finds a bug in FluidSynth by playing around with "Slide control", he/she should be able to fix it and run the fixed version on the same hardware. The question is if Apple fulfils its part of this deal by the $99 developer program [1]. On one hand, the program is widely available and relatively cheap, on the other hand, it's still a cost, and Apple can probably choose to deny this program on an individual basis. So I'm not really sure what to think about it at this point. Anyway, Rouet can fulfil that requirement by publishing the entire source code to "Slide control". I don't know if they can also choose to supply some kind of linkable object code, that depends on what you can and can't do with XCode.No objection. I think that documenting a clarification about this interpretation of the license would be enough,not requiring a license addition explicitly accepting exceptions, or license changes.
Note that the above is not a full interpretation of the license, I'm just pointing out what is important to me. There might be other problems with the App Store distribution channel, which are important to someone else of FluidSynth's copyright holders. (Especially taking into account the code already present when I got involved with the project.)
// David
[Prev in Thread] | Current Thread | [Next in Thread] |