
Why Apple's 3.3.1 is great for hackers and (smart) founders. - MaysonL
http://andreyf.tumblr.com/post/522294486/why-apples-3-3-1-is-great-for-hackers-and-smart
======
jacquesm
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.

~~~
plinkplonk
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.

~~~
hga
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!

------
baguasquirrel
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.

~~~
extension
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.

~~~
jasonlotito
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.

------
andr
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.

~~~
jacquesm
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.

~~~
hga
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.

------
reitzensteinm
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.

~~~
hga
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.

------
tlrobinson
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.

~~~
ryanpetrich
In the jailbreak scene, a lot of us abuse the C preprocessor and Objective-C's
runtime functions to make method hooking simpler.

Example: <http://wiki.github.com/rpetrich/CaptainHook/>

------
Zak

        csc helloworld.scm
        strings helloworld.scm|grep -i chicken|wc -l
    
        2
    

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

------
StevenObua
I said pretty much the same on "Lambda the ultimate", <http://lambda-the-
ultimate.org/node/3905#comment-58598>

~~~
confuzatron
Your comment on LtU reads like satire :)

"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."

~~~
StevenObua
:-)

------
city41
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.

~~~
commieneko
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..."

