Re: [gnugo-devel] GnuGo License compatibility with the iPhone and iPad?

[Pierce T. Wetter III]

On Jan 29, 2010, at 9:21 AM, David Fotland wrote:

> The iPhone digitally signs apps and makes it impossible for customers to
> modify the apps, even if they have full source code.  The Apple license
> agreement forbids developers to use open source code that has a license that
> conflicts with the Apple license, especially the terms about digital
> signing.

  That's not strictly true.  

    You can modify an app if you have full source code. 

    You can even put it on iPhones.

    The catch is that it requires access to iPhone development tools. Apple 
charges $99/year for that, which Richard Stallman calls a "tax", but for that 
you get a certificate which is used for signing and all the crypto 
infrastructure.

     So its not that simple. Are you paying a $99 "tax" to produce software, or 
are you paying $99 for some crypto infrastructure? You can pay $500/year for a 
code signing certificate elsewhere so $99 is kind of a deal actually, and you 
can re-use those certs for your regular MacOSX apps too. Microsoft charges a 
significant amount more for their development tools per year...

       Signing a _binary_ has nothing to do with modifying source code, and is 
becoming a security requirement on Windows/Mac anyways, because trust is scarce 
in this world. So I don't think you can say that because an app is signed, 
you're not allowed to modify it. 

    Digression: I think the FSF folks need to think about the code signing 
issue here, outside of their tendency to be anti-corporation and in the context 
of a larger picture. Code signing is not going away, people need a way to 
verify that such and such binary was produced by such and such company. That 
said, the $ cost for certificates is ridiculous. I don't know what the solution 
is, perhaps there should be a FSF web of trust like solution? 

     Now lets say you then want Apple to distribute said application. This is 
where people run afoul of GPLv3 vs. GPLv2. It relates to the fact that the 
Apple App store is "distributing" the app, which technically puts them on the 
hook to distribute the source as well according to the GPLv3 terms, which they 
don't want to do, because they don't want to have to know anything about your 
source code, make sure you've included the latest source, etc. So Apple's 
license agreement says that if your license agreement requires them to do 
anything like that, you need to go elsewhere or give them a different license. 
Which isn't an unreasonable position, especially because some of the open 
source apps are free in the store anyways. 

   In practice, what really happens is that people who distribute apps under 
GPLv3 make the source code available (often on googlecode), and Apple doesn't 
notice much. In fact, it mostly only matters if the copyright is owned by 
someone other then the original provider of the source code, for instance, as 
in GnuGO's case, if all the source has been assigned to the FSF. 

    If you own the copyright, but license the source with GPLv3: Then 
presumably you can provide Apple with a different license agreement, that looks 
more like v2, where you're on the hook for providing the source. 

    If FSF owns the copyright, then knowing Richard, he would want to push 
Apple to be on the hook for distributing the source as well. But that seems 
silly to me, if the FSF is already distributing the source. 

    If either FSF or Apple really pushed on this issue I suspect the ultimate 
outcome would be one where everyone loses, because I think the GPLv3 clause 
that's the issue here should have some exception such that if you're 
distributing binaries from someone else, but that someone else provides the 
source, I don't think you should then have to re-distribute the source as well. 
Or perhaps if that's unacceptable, it can be a matter of providing the source 
to a third party (FSF, GoogleCode, SourceForge). 

 Pierce

smime.p7s
Description: S/MIME cryptographic signature