On 23 Jun 2010, at 13:58, Philippe Laporte wrote: > Hi, > > So you see no legal impediements in proceeding? No patents, no royalties, no > rules in any agreement?
Software patents are not valid in the jurisdiction where I live, so they're not an issue. There used to be a rule in the iPhone developer agreement, preventing you from working on something like GNUstep. It's not clear whether this is actually enforceable (it probably isn't, but check with your favourite lawyer), but I did not agree to the iPhone developer agreement so it's irrelevant to me. > Would you say it is like coming up with a Java implementation 10 - 12 years > ago? Did the rules for the Java technology, the JDK, disallow > reverse-engineering? If they did, we are OK, and there are several competing > “Java” implementations. You can't copyright an interface in most of the world (including the USA), and implementing a documented interface is entirely legal. > Of course, we need only the public APIs specs for our work. But these may be > governed by their web site’s terms of use, no. Then is it sufficient to > rename the classes with a common project-related prefix? See above - you can't copyright an interface, and attempting to enforce such a copyright even if it were possible would likely generate some interest from antitrust regulators. A better comparison is WINE. They are implementing both APIs and ABIs (we only care about source compatibility), but they have no legal problems. > What bout the SDK rules against reverse-engineering? Do they affect our task? > Documents that should be analyzed include the iPhone SDK Agreement and the > iPhone Developer Program License Agreement. Not sure if they still do, but this is only relevant to people who have agreed to the SDK agreement. Nicolas mentioned that this clause has gone, but it may have come back. > But since the XMLVM project has proven that a Java version of Cocoa-Touch is > legal, an Objective-C version should be clean as well, no? I've not come across this project, but it appears to be related to running Java apps on the iPhone. This is a different problem - Apple is legally allowed to block anything from the iPhone store for any arbitrary reasons (including, but not limited to, just not liking your face) until such a point as they are told not to be regulators. Running UIKit apps on other platforms does not involve Apple's store. If you support other platforms with the same app then Apple may decide not to permit you to sell your app through the store, but hopefully they would see that this is more likely to damage them than anyone else (if you can run an app anywhere except the iPhone, it's not great for the iPhone). > There is also an Open-Source project which implements some of the UIKit while > only adding a prefix to the file and type names. We have contacted the leader > to seek his advice on the legality of the endeavor. I've also not come across this project. Given the similarities between UIKit and AppKit, implementing it in terms of the same core code should be relatively easy, reusing much of the existing code. Given that most iPhone applications make heavy use of CoreGraphics and CoreAnimation, it's currently waiting for us to have a more complete CG and at least a stub CA implementation before I put much effort into it. I would anticipate factoring out a core subset of GNUstep-gui that is usable by both AppKit and UIKit, and then implementing the new UIKit stuff on top of that. Implementing UIKit in terms of AppKit would also be possible, but not so elegant. Either way, I'd like us to be able to mix UIKit and AppKit code in the same app, making incremental porting of desktop apps easier. This might be useful even for people thinking of taking desktop Mac apps to the iPhone; compile for the N900 with AppKit, slowly replace bits with UIKit, and then send the AppKit-free version to the Apple store for the iPhone. David -- Send from my Jacquard Loom _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
