remove old drama from README.md

Author: comex

README.md

@@ -95,160 +95,3 @@ Todo list (approx. priority order)
     - some API to load/unload from all existing processes
 - Linux
 
-Why rewrite Substrate?
-======================
-
-iOS jailbreak community drama incoming.  I hope that this library eventually
-becomes useful to a wide variety of people that have no knowledge or interest
-in the following, because that is itself one of the answers to the above
-question.  But if you are interested, read on.
-
-As a bit of background: Substrate used to be open source.  (This is where the
-LGPL version of the compatibility header comes from; the current one in the
-Debian package has the GPL on it, not that it really matters.)  In fact, it was
-open source for two(?) contiguous periods, but it has been closed for years
-now, and looks to remain that way.
-
-Do I really have to have a reason to create free software alternatives to
-proprietary software?  I was recently watching Richard Stallman's talk at 31c3,
-and reflecting on the fact that while I'd been worrying about this, he'd
-consider it immoral *not* to work on such a project.  - Yes, I do?  Well,
-then...
-
-In the short view, because iMods asked me to.  The reason they can't use
-Substrate (allegedly; I haven't myself discussed this specific issue with
-saurik, and don't really care, due to the other use cases for this library; I
-hope I am not fundamentally misrepresenting anyone's view here) is that saurik
-does not want to support them because he does not think competition is healthy
-for the ecosystem.  This is described in detail in his article [Competition vs.
-Community](http://www.saurik.com/id/20), and it appears to be an essentially
-irreconcilable difference between the two.
-
-After reading that, you may ask, why am I trying to subvert saurik?  After he
-correctly says -
-
-> I could sit around and first-party the entire stack: this would be much
-> easier than you'd even think; after all, Dustin already did the "hard work"
-> of figuring out what was even possible and what kind of solution solved the
-> problem.
-
-why am I proceeding to write a new library, which even goes to the extent of
-having an API compatibility later, once saurik did the hard work of figuring
-out what kind of solution did a good job solving the runtime code modification
-problem on iOS?  When saurik worries that competitors to Cydia will sap the
-funding he relies on to support his essential, but less glamorous, software
-plumbing, and his many jailbreak community initiatives, why am I enabling
-exactly that?
-
-Well, I'd be lying if I said I was sure it was a good idea.  But to be honest,
-with all respect to iMods, I don't think it's likely to supplant Cydia, not in
-the foreseeable future or, in its current form, ever.  And the kind of group
-that could hypothetically supplant Cydia would likely not have difficulty
-replicating Substrate by themselves.  So I consider my own involvement to be a
-low-stakes game in terms of practical consequences, which makes the upsides I
-perceive more compelling.
-
-What are those upsides?
-
-It's worth noting that between the aforementioned two open source periods for
-Substrate, a younger version of me repeatedly expressed a desire for it to be
-open source, and when the source was released again, was quite pleased.
-(Being slightly less enthusiastic in practice than principle - although much of
-that was just timing - I don't think I noticed when it went back to closed
-source.)  So this really goes back a lot longer than iMods, and the upsides I
-perceive now are pretty much the same ones I did then.
-
-Starting on the practical end and ending on the idealistic one:
-
-First of all, it was during that period that I was working on tools to cleanly
-hook into the iOS *kernel* for reverse engineering purposes.  As part of that,
-I wanted a function hooker.  If Substrate had been open source, I could have
-easily copied out the (pretty small) bit I wanted into my kernel code; instead
-I had to write my own, inferior version.  This is notable because, whether or
-not it was actually useful, the work I was doing was unambiguously pro-social
-and not harmful to the jailbreak community.  saurik has on [various
-occasions](http://forum.xda-developers.com/showthread.php?t=2466101&page=2)
-mentioned the possibility (history?) of forks of his software hoarding fixes or
-whatever, and stated that there isn't much legitimate reason to modify
-Substrate, as opposed to building on it; certainly this is mostly true, but
-'not much' is not the same as 'none'.  If my software is useful to anyone else
-doing good work along the same lines, I will be very happy.
-
-I vaguely remember saurik suggesting that an alternative would be cooperating
-to come up with an official way for Substrate to be integrated into the kernel,
-or something.  But I thought and think this really wasn't a good idea - since
-I'm the only one I know of who actually used those tools (except for an
-implementation of unionfs that formed part of JailbreakMe 3.0), it would be
-quite pointless for saurik to maintain, and I wanted to preserve agility for
-that little project.
-
-Second, while iOS-related environments other than userland are a pretty niche
-use case, there are innumerable environments unrelated to iOS in which
-Substrate-like hooking would be useful; it is for this reason that I intend to
-port Substitute to OS X and Linux, and anyone who just wants function hooking
-in some embedded environment can copy that bit easily enough.  (To be fair,
-Substrate already is ported to both of the former platforms, but that doesn't
-really help if it's not freely available.)  Sure, it would be nice if there
-were an official Cydia Store for OS X and Windows and toasters, but saurik
-doesn't seem to have time to work on that (maybe there were other reasons to
-stop working on OS X? don't remember), and I don't think it's reasonable to
-expect everyone who wants this fairly low-level functionality to work with
-saurik on what is otherwise their own project.
-
-This isn't just theoretical.  Several years ago, I wrote more primitive version
-of a subset of the functionality found in this library as
-'inject_and_interpose':
-
-https://github.com/comex/inject_and_interpose
-
-Since it's been around for years, it's had time to gather attention.  Despite
-me doing absolutely no promotion of it, and the repo not even having a readme
-or license (which is not a good thing), three different people have posted
-issues implying they have tried to use it.  More importantly, after I bought
-the Flavours app for OS X, I was surprised to receive an email from the
-developer offering me a refund, on the basis that I had already supported its
-development by writing inject_and_interpose!  (In case you're reading this:
-Sorry I didn't respond; I tend to be very shy and so often don't reply to
-emails I should.)  I think it's incredible that I was able to help a project
-totally unknown to me get developed; this is the kind of outcome only free
-software can achieve.  I doubt it would have worked out as well if I had
-demanded coordination first.
-
-Third... this one is more subjective, but it's also probably the most
-important.  The way I see it, jailbreaking is *fundamentally* about taking
-something closed and fixed and opening it up to hacking and modification:
-perhaps allowing a mess to be made, but quite possibly ending up with something
-unique and different.  This ideal of openness is very similar to that of free
-software, and I therefore believe that it's in the spirit of jailbreaking to
-make as much low-level stuff open as possible, both for inspection and
-modification by curious users (who, after gaining knowledge that way, might end
-up becoming quite valuable to the community).  Polished tweaks that are sold
-commercially are one thing (although they too benefit from general openness,
-especially the ones with a lot of reverse engineering behind them, since the
-same reverse engineering can often support multiple use cases), but the
-underlying framework is another - especially since it's free of charge,
-removing at least the most obvious motivation for closing source.
-
-(Like most people, I don't entirely agree with Stallman's rhetoric - otherwise
-I wouldn't have just praised a commercial application! - but all in all my
-views are aligned in a very similar direction, just with less magnitude.)
-
-Incidentally, this affects the jailbreaks themselves even more than Substrate.
-I have often advocated for open source jailbreaks, and all of my own jailbreak
-code has been open source.  There would be practical benefits there, too; past
-experiences aside, a certain project I've had on the backburner for years will,
-if I ever get to it, certainly require customizing an existing jailbreak, which
-currently is likely to mean reimplementing it.  Not that that would be
-particularly hard compared to the *rest* of the project, but it's just an
-unnecessary speed bump, and unnecessary things frustrate the hell out of me.
-Especially when the jailbreaks are distributed for free!
-
-Oh, and when I say "the spirit of jailbreaking", I don't mean to change history
-by implying "original plan" - iOS jailbreak has always suffered from
-balkanization of closed source tools.  Indeed, I'm happy that the open source
-Cydia supplanted the closed Installer, and with it saurik's generally open,
-community-based management style.
-
-But when I say spirit, I do mean the best part of it.
-
-comex, 30 January 2015