If you think that license agreements have terms only to be enforced in reasonable cases then probably you also believe that laws that do not make sense will not be used in cases where they really shouldn't.
By introducing a bunch of legalese in its license agreement that states you are not allowed to do a bunch of stuff, then to willfully transgress those rules predicated on
"apple doesn't care and doesn't have the resources to go after you"
is setting yourself up for a big fall. If you happen to be successful and you happen to be in the way of apple in some way or other you've just handed them your termination clause on a platter.
It's a bit like saying everybody should drive too fast because the government doesn't have the resources and they don't care about it too much anyway. Until some law enforcement officer decides he needs a 'probable cause' to go after you. Of course, since the government doesn't have the resources to go after every driver that would never happen, would it ?
If Apple doesn't care about 'high level languages' they should re-write their terms, and say what it is that they're really after, in stead of 'smart founders' and 'hackers' reading the mental message between the lines that this isn't really about them and will never be enforced.
I don't think Apple should have a say about what stuff runs on computers they sell anyway, if they want to get in to the rental business that's fine with me but then they should say so outright. It looks like these devices are being sold, not rented to me, so Apples influence over them should end as soon as they leave the store.
If you were "in the way of apple in some way or other," they would just drop your app from the store, with no explanation given (or required.) They don't need to add a clause in their contract to prevent you from publishing your app in their store; they just don't publish your app. The only reason 3.3.1 exists is so they can drop developers from the store for something Adobe did, instead of something they did. In other words, it's actually a "this isn't your fault" clause—if they didn't have it, they'd just be banning individual developers who happened to try submitting Flash-compiled apps, and that would suck for those developers much more than just being told "make an actual, iPhone-native app from scratch and we'll talk."
But more importantly, a rule that is selectively enforced only upon your competitors gives you an advantage. Those who live off the Apple sharecropping gold-rush know they could be kicked out at any time, for any reason; in such an atmosphere, the best thing that can happen is all your competitors being kicked out while you're ignored. The fact that there's a rule against what you're doing doesn't change the fact that you could be kicked out at any time—it just heightens the risk/reward ratio for both you and the other people doing it.
I think Section 3.3.1 is good for hackers in a very different way than explained in the blog post. Good hackers will (by and large) follow the law for their commercial endeavours rather than try to work around Apple's insane (and ever shifting) policies. I for one wouldn't set out to build a business based on explicitly breaking the law and with the possibility of a lawsuit looming.
That said, the IPad, IPhone and AppStore have raised the bar for UI design, user installation, sales (and payment) processing and so on where there is now a clearly defined "what hackers want" gap in the ecosystem. The Apple AppStore is an existence proof of what is possible and this is orthogonal to languages used and so on (as demonstarted by games using Unity3D).
Hackers want to build their own languages that compile down to the "native" language and APIs but they also want the AppStore style payment processing and so on with better facilities for updating our apps, a faster and more comprehensive review cycle (assuming that a review is a good thing) and so on.
If someone (Google? Microsoft? someone totally new? ) were to fill this gap (and someone eventually will), it will be "good for hackers". Section 3.3.1 is good insofar as it will spur development of alternative ecosystems and force disgruntled hackers off the Apple path. No one who has a choice and wants to stay within the bounds of the law will accept such inane terms and conditions. Microsoft had far less onerous policies and far less competition than Apple in the mobile space, and yet, over many years there was a drain of top class developers from MS's platforms to Linux/BSD and later to Apple. Once upon a time MS was the only game in town for commercial projects. The advent of teh Web and Open Source changed that game. The same scenario, with different players and technology, will play out with Apple, but it won't be instant and will take a while.
You comments about the importance as an existence proof of the creation of this ecosystem are I think the most interesting and useful thing I've read in all these Section 3.3.1 discussions. Thanks!
The part you have in quotes is really wrong because he is not saying something like that. Why are you changing what he said? This is really irritating. People use quotes when they want to refer to a statement as it was made.
which is "technical resources to tell whether an executable has been compiled from human-written C code or compile-target C code"
> People use quotes when they want to refer to a statement as it was made.
Apologies, you're right. That was not the intention of the quoted bit, it was meant as a statement of what this piece makes me feel like. If I 'quote' a statement online I use the > mark (like above), I don't know of a typographical convention that would convey what I tried to do here other than using quotes.
The thing is that most of the times, people read comments and then the article. So, I think it would be best if you are going to comment on a certain aspect to just include the original peace and then comment on it.
Other than that I am not aware of a more conventional way.
Single 'scare quotes' in English can provide the needed signal to the reader that you are using a paraphrase or exaggerated characterization of a position.
"I said pretty much the same on "Lambda the ultimate",
well the very next comment (on LTU) was interesting. Titled " Steve Jobs' Sales Prevention Program", it says
"Back in the NeXT days, some of us involved with the NeXT in one way or another used to talk about Steve Jobs' "Sales Prevention Program" because it was all too common for him to implement policies or do something that would kill a particular sale (in some cases a sale of many machines), or destroy NeXT's prospects in a market.
It was the flip side of his amazing intuitive sense of elegance and form. This sense allowed him to instantly 'know' the right way to do things, most of the time. But because he lived by that intuitive sense, when it came up wrong he had no way to rationalize an alternative. Just as there was no way to express why he was right in the 'right' cases, there was no way to argue with that intuitive sense when it was wrong - and quite often there was no way to know whether he was right or wrong until later. "
I suspect that many people are planning to pass under the radar with their own custom made solution. The reason why we haven't heard more about it is that it depends on secrecy, and if that's your plan then writing a blog post about it would be about the dumbest thing you could do.
Arrgh ... yep, and that's another hit by Apple against good development practices and the general improvement in our ability to develop software that the Internet has brought.
Starting in 1996 when I've always had the net available while developing software my productivity has steadily increased, whether it was finding a snippet of free code for CRC calculations (the first thing I can remember) or higher level stuff.
This is like apologizing for the Patriot Act. As long as you play nice with the feds and you don't look like one of the undesirables, we won't mess with you.
The blog post strikes me as a pragmatic observation rather than an ethical justification. It makes a very good point too.
If you use an in-house tool that compiles lisp/ruby/whatever to Objective C, I seriously doubt Apple is going to go through the trouble of detecting this. Even if they did, I don't see them giving two shits as long as you follow the HIG, stick to public APIs and keep the tools to yourself.
Since the do-gooders can't release the tools publicly, the only people who have them are the people who can make them. If you are one of those people, you can probably come out ahead from this whole debacle, even if it doesn't give you a warm freedom fuzzy inside.
The flip side is the consumer side: This isn't good for the consumer. I simply have no desire to add apps now, knowing that Apple can remove them at any time. Especially now with all the changes, it's obvious that even a 'legal' app might be removed. Or updates won't be approved. There are just so many problems.
I realize that the average consumer won't see this, but it's a problem. You could argue that it benefits the consumer, because better apps will get through. With more restrictions, less apps will be sent in, freeing up more manpower to approve legit apps quicker. This might happen.
Still, I try to avoid buying software that I can't install at any time, and I avoid buying into harsh DRM. I don't always succeed, but I don't want to rely on a single vendor who has proven their willingness to eliminate popular content, stall important updates, and drastically change rules whenever they please.
I wonder how far you could get bending a combination of the C, C++, Objective-C, and the C preprocessor (assuming it's allowed) to you will to come up with an interesting new language.
But I guess most people don't want a new language, they want whatever existing non-Objective-C language they're already comfortable with.
The piracy comparison is bogus. I don't think anyone is worried about Apple suing them for using Flash/MonoTouch/whatever. The problem is investing a month or three into writing an app only for Apple to say "Nope, sorry."
Or even worse, getting your 1.0 in the App Store, only to have your 1.1 rejected as their "defenses" against translation layers grow stronger with time. It's a peculiar case of FUD against your own partners.
It's the weirdest thing ever. To try to control what software runs on your computer is already way out of bounds, to try to limit the tools that can be used to produce software is simply nuts. Developers are a platforms best friends, it's the applications that will make or break it once the 'novelty' factor wears off.
It's not entirely nuts if Apple's game is to maintain its lead in the smartphone market by suppressing development on other platforms.
I think Apple is past the "novelty" stage now; the price will be paid in the longer term as certain classes of developers only develop for those other platforms (either they use cross platform tools or non-blessed tools (Scheme, Lua, whatever)). This also makes things messy for companies like Sugar for which there's no compelling reason to make a really good native app, the value they sell in more in what's behind it.
On the other hand, while Apple's approval capriciousness has been a significant issue, this hits developers closer to home in a day in, day out way. And even if they're using blessed tools today, they might aspire to use higher level stuff later. E.g. after they see how much faster it can be to develop with a REPL.
There are more giveaways that may be harder to hide. I suspect most other cross-compilers have similar giveaways. I suspect Apple will use an automated tool to check for them
He mentions even ObjC compiles down to C. He neglects to mention it does so with the aid of a runtime that a native C app would not have, and is easily detectable.
Writing your apps in C is within the terms of the agreement. As is writing your code in Javascript if it is interpreted by Webkit, which is why _Phone Gap_ seems to be okay.
"...Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs..."
29 comments
[ 3.1 ms ] story [ 77.9 ms ] threadBy introducing a bunch of legalese in its license agreement that states you are not allowed to do a bunch of stuff, then to willfully transgress those rules predicated on
is setting yourself up for a big fall. If you happen to be successful and you happen to be in the way of apple in some way or other you've just handed them your termination clause on a platter.It's a bit like saying everybody should drive too fast because the government doesn't have the resources and they don't care about it too much anyway. Until some law enforcement officer decides he needs a 'probable cause' to go after you. Of course, since the government doesn't have the resources to go after every driver that would never happen, would it ?
If Apple doesn't care about 'high level languages' they should re-write their terms, and say what it is that they're really after, in stead of 'smart founders' and 'hackers' reading the mental message between the lines that this isn't really about them and will never be enforced.
I don't think Apple should have a say about what stuff runs on computers they sell anyway, if they want to get in to the rental business that's fine with me but then they should say so outright. It looks like these devices are being sold, not rented to me, so Apples influence over them should end as soon as they leave the store.
But more importantly, a rule that is selectively enforced only upon your competitors gives you an advantage. Those who live off the Apple sharecropping gold-rush know they could be kicked out at any time, for any reason; in such an atmosphere, the best thing that can happen is all your competitors being kicked out while you're ignored. The fact that there's a rule against what you're doing doesn't change the fact that you could be kicked out at any time—it just heightens the risk/reward ratio for both you and the other people doing it.
That said, the IPad, IPhone and AppStore have raised the bar for UI design, user installation, sales (and payment) processing and so on where there is now a clearly defined "what hackers want" gap in the ecosystem. The Apple AppStore is an existence proof of what is possible and this is orthogonal to languages used and so on (as demonstarted by games using Unity3D).
Hackers want to build their own languages that compile down to the "native" language and APIs but they also want the AppStore style payment processing and so on with better facilities for updating our apps, a faster and more comprehensive review cycle (assuming that a review is a good thing) and so on.
If someone (Google? Microsoft? someone totally new? ) were to fill this gap (and someone eventually will), it will be "good for hackers". Section 3.3.1 is good insofar as it will spur development of alternative ecosystems and force disgruntled hackers off the Apple path. No one who has a choice and wants to stay within the bounds of the law will accept such inane terms and conditions. Microsoft had far less onerous policies and far less competition than Apple in the mobile space, and yet, over many years there was a drain of top class developers from MS's platforms to Linux/BSD and later to Apple. Once upon a time MS was the only game in town for commercial projects. The advent of teh Web and Open Source changed that game. The same scenario, with different players and technology, will play out with Apple, but it won't be instant and will take a while.
which is "technical resources to tell whether an executable has been compiled from human-written C code or compile-target C code"
Apologies, you're right. That was not the intention of the quoted bit, it was meant as a statement of what this piece makes me feel like. If I 'quote' a statement online I use the > mark (like above), I don't know of a typographical convention that would convey what I tried to do here other than using quotes.
Suggestions ?
Other than that I am not aware of a more conventional way.
well the very next comment (on LTU) was interesting. Titled " Steve Jobs' Sales Prevention Program", it says
"Back in the NeXT days, some of us involved with the NeXT in one way or another used to talk about Steve Jobs' "Sales Prevention Program" because it was all too common for him to implement policies or do something that would kill a particular sale (in some cases a sale of many machines), or destroy NeXT's prospects in a market.
It was the flip side of his amazing intuitive sense of elegance and form. This sense allowed him to instantly 'know' the right way to do things, most of the time. But because he lived by that intuitive sense, when it came up wrong he had no way to rationalize an alternative. Just as there was no way to express why he was right in the 'right' cases, there was no way to argue with that intuitive sense when it was wrong - and quite often there was no way to know whether he was right or wrong until later. "
"Hey ya know, the good thing about WW3 was we all learned really useful survival skills like how to get all the meat offa rat and such."
Starting in 1996 when I've always had the net available while developing software my productivity has steadily increased, whether it was finding a snippet of free code for CRC calculations (the first thing I can remember) or higher level stuff.
If you use an in-house tool that compiles lisp/ruby/whatever to Objective C, I seriously doubt Apple is going to go through the trouble of detecting this. Even if they did, I don't see them giving two shits as long as you follow the HIG, stick to public APIs and keep the tools to yourself.
Since the do-gooders can't release the tools publicly, the only people who have them are the people who can make them. If you are one of those people, you can probably come out ahead from this whole debacle, even if it doesn't give you a warm freedom fuzzy inside.
I realize that the average consumer won't see this, but it's a problem. You could argue that it benefits the consumer, because better apps will get through. With more restrictions, less apps will be sent in, freeing up more manpower to approve legit apps quicker. This might happen.
Still, I try to avoid buying software that I can't install at any time, and I avoid buying into harsh DRM. I don't always succeed, but I don't want to rely on a single vendor who has proven their willingness to eliminate popular content, stall important updates, and drastically change rules whenever they please.
I invoke Godwin's law - you lose your argument.
But I guess most people don't want a new language, they want whatever existing non-Objective-C language they're already comfortable with.
Example: http://wiki.github.com/rpetrich/CaptainHook/
Or even worse, getting your 1.0 in the App Store, only to have your 1.1 rejected as their "defenses" against translation layers grow stronger with time. It's a peculiar case of FUD against your own partners.
I think Apple is past the "novelty" stage now; the price will be paid in the longer term as certain classes of developers only develop for those other platforms (either they use cross platform tools or non-blessed tools (Scheme, Lua, whatever)). This also makes things messy for companies like Sugar for which there's no compelling reason to make a really good native app, the value they sell in more in what's behind it.
On the other hand, while Apple's approval capriciousness has been a significant issue, this hits developers closer to home in a day in, day out way. And even if they're using blessed tools today, they might aspire to use higher level stuff later. E.g. after they see how much faster it can be to develop with a REPL.
"...Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs..."