The madness stops here - don't pay a VC any fees - <AUTHOR> http://uk.techcrunch.com/2009/09/29/guest-post-the-madness-stops-here-%E2%80%93-don%E2%80%99t-pay-a-vc-any-fees/

<comment><USER2> I'm not surprised that the day has come where someone actually has to write this. Because, off and on, I've browsed through message boards frequented by writers, where there's a scam - the literary agent scam - that has become so standard that there's practically a manual for it. Google _Dorothy Deering_ to learn more about it; anyone who ever thinks of writing a book or screenplay should read something like this.

The prevalence of people who claim to be "insiders" and who charge you money up front to be represented by them led to the coinage of Yog's Law: _in publishing, money flows toward the author_. Looks like we need the same rule for startups.

If you start a company or write a book, you'll have to pay expenses (Ramen and pencils) but you don't have to pay to be rejected by the marketplace. The market is happy to reject you for free, as many times as necessary for you to get it right. Be sure to take advantage of that offer. :)

<comment><USER3> Please tell me this (the first result in Bing) is a different Dorothy Deering :-)

[http://www.cla.purdue.edu/english/directory/Faculty/Deering%...](http://www.cla.purdue.edu/english/directory/Faculty/Deering%2C_Dorothy.html)

<comment><USER2> I believe it is probably a different one, yes. Try "Dorothy Deering SFWA".

What an unfortunate naming collision for poor Professor Deering.

</comment></comment></comment><comment><USER4> It's almost universal for VCs' legal fees to come out of the money they invest, though you don't have to pay unless the deal closes. Basically you just subtract these from the deal in your mind in advance.

Trevor and I were talking about this custom a few days ago. We think the purpose here is not to mislead startups so much as to mislead LPs. By taking the legal fees out of each deal, the VCs are able to make their annual management fees look artificially low-- or more precisely, to spend a larger percentage of a given management fee on partners' salaries.

<comment><USER5> > It's almost universal for VCs' legal fees to come out of the money they > invest

It's surprising is how large the fees are. It's almost like VCs have never done a comparable deal before.

Misleading LPs about management fees is small potatoes. If you believe the "disproportionate return" argument that VCs make, excessive legal fees have a disproportionate effect on returns.

<comment><USER4> It's not that surprising when you understand where the money goes. It's not spent on preparing documents, but on arguing about terms. It's really the cost of the negotiations between termsheet and closing, to the extent they're done through lawyers.

The solution is to make deals more standardized, so that when you see the termsheet you know what the deal's going to be.

That would be good for other reasons besides saving money. The time it takes deals to close is very damaging to startups. I'm convinced most investors have no idea how damaging. A startup raising money will get next to nothing done till the deal closes, and getting nothing done is the worst possible thing that can happen to a startup.

<comment><USER6> I quite disagree WRT legal fees and what causes them (I am a VC, not a lawyer, believe it or not).

The substantive terms usually get argued about, up-front, by the business people (VC and entrepreneur).

It's true that there are ambiguities left even by a detailed term sheet. However, decent attorneys go with what's "market" for a given type of deal and don't spend a bunch of time on it.

What really kills you is that there are almost always a ton of i's to dot and t's to cross, things that entrepreneurs (and for that matter, VCs) don't and shouldn't care about (so long as they get done, by hook or by crook). For example: do you have your articles filed correctly? Up to date? Foreign corporation authorization in your physical location? Minutes from regular board meetings? Properly issued stock certs and register? Voting agreements / etc. from all cats-and-dogs shareholders (angels, uncle Larry, etc.)? Options properly approved, issued, expensed? Right number of shares authorized for each class and type, and for all options and warrants? blah blah blah blah blah.

And that's even before you get to stuff like reps and warranties. Screwups on any one of these things, conceivably, could allow someone or some government to screw up the deal later on, even if the business takes off.

Don't think of the definitive documentation of a round solely as a hangup en route to getting the wire. Think of it as a cleansing ritual where you pay the high priests to go back, expurgate your sins and omissions by papering over them, and make sure you don't end up going to jail or getting sued by the SEC later. Having your round definitively documented by non-dipshit attorneys basically gives all sides a reasonable comfort that the legal risk in the deal is low.

It's a PITA, yes, but it does good for all parties involved.

The "make deals more standardized" trope is oversimplified. It could work, yes, but only if the deal used a precise template for the ENTIRE history of the company, from ideation to handshakes to incorporation to seed money to A round. Since that can't be so, removing the legal risk is just going to require tens of hours of smart people slogging through paper and data.

Now -- should the VCs pay for this out of our piece or not? Look, frankly, we want to get our 20% for $2 M (or whatever). If you insist, I suppose we could reduce the premoney a tiny bit, get our 20% for $1.95 M, and pay the $50k out of pocket. You get the same net cash for a lower putative valuation, I'm still out $2 M.

Frankly: it's not worth the brain damage, just do it the way every other deal has been done. (I'm only replying because I'm in an ornery mood and too caffeinated to resist the bait right now...)

<comment><USER4> Good point. The money doesn't all go to negotiation, so standardized terms wouldn't eliminate all the cost.</comment></comment></comment></comment></comment>


An introduction to mobile messaging and analysis of the Threema protocol [video] - <AUTHOR> https://media.ccc.de/v/33c3-8062-a_look_into_the_mobile_messaging_black_box <comment><USER2> They are taking apart Threema. While it's not open-source, it's not exactly a "black box" either -

[https://threema.ch/press- files/cryptography_whitepaper.pdf](https://threema.ch/press- files/cryptography_whitepaper.pdf)

<comment><USER3> Ok, we replaced 'black box' with 'Threema' above.

<comment><USER4> How about using the official subtitle 'A gentle introduction to mobile messaging and subsequent analysis of the Threema protocol.'?

<comment><USER3> Ok, we can shorten that to fit.

</comment></comment></comment></comment><comment><USER5> Excellent, nice work. Have been a fan of Threema for a long time.

</comment><comment><USER6> Would be so great if they open sourced it.

<comment><USER7> I doubt that it'll going to happen soon: [https://threema.ch/en/faq/source_code](https://threema.ch/en/faq/source_code)

On the other hand, the web client they're about to release _is_ open source.

Anyway, it's the most secure messenger at the moment, IMHO, and I love the fact that no phone number is required.

<comment><USER8> I think it's the best messenger I have used all around, in terms of UI.

I particularly like their take on the verification levels using a traffic light metaphor - giving visual feedback on how well trusted a contact is on my list; I wish other clients would adopt it something similar and encourage more people to verify keys out of band.

<comment><USER7> Agreed, the UI is very clean and polished. (I use the Android version.)</comment></comment></comment></comment>


Glossary of Science Fiction Ideas, Technology and Inventions - <AUTHOR> http://www.technovelgy.com/ct/ctnlistalpha.asp

<comment><USER2> "Acceleration couch" at [http://www.technovelgy.com/ct/content.asp?Bnum=443](http://www.technovelgy.com/ct/content.asp?Bnum=443) is attributed to Niven's 'The Mote in God's Eye' (1974), but it exists in Heinlein's "Methuselah's Children" (1958); on p83 of my copy:

> Ford struggled heavily out of the acceleration couch he was in.

(This is as they are leaving Earth, accelerating towards the Sun, before they engage the star drive.)

The site does let people send in comments, and indeed someone already commented at [http://www.technovelgy.com/ct/Content- Comments.asp?Bnum=443](http://www.technovelgy.com/ct/Content- Comments.asp?Bnum=443) that Heinlein's "It's Great to be Back" (1947) is an earlier citation.

However, that comment is from 2008, which makes it feel like the site is effectively dead.

Personally, I prefer the effort of about 15 years ago to collect SF citations for the OED, at [http://www.jessesword.com/sf/list](http://www.jessesword.com/sf/list) . That's specifically about words, not concepts, so it's not the same thing. But what I like about it is the curational decision to focus on terms which are used in more than one book, and to give a longer quote what uses the term.</comment>


NEJM editor: "No longer possible to believe much of clinical research published" - <AUTHOR> http://ethicalnag.org/2009/11/09/nejm-editor/ <comment><USER2> Blogspam.

OP is two years old: [http://www.nybooks.com/articles/archives/2009/jan/15/drug- co...](http://www.nybooks.com/articles/archives/2009/jan/15/drug-companies- doctorsa-story-of-corruption/?pagination=false)

<comment><USER3> But note the news update to OP detailing the slap on the wrist sanctions applied to the three Harvard doctors...

"Massachusetts General Hospital Discloses Sanctions against Three Psychiatrists for Violating Ethics Guidelines", July 1, 2011: The Boston Business Journal said today that three psychiatrists have been sanctioned for failing to adequately report seven-figure payments they received from drug companies.

Drs. Joseph Biederman, Thomas Spencer and Timothy Wilens disclosed the disciplinary actions against them in a note to colleagues. According to a copy of the note made public upon request by the hospital, the three doctors:

• must refrain from "all industry-sponsored outside activities" for one year

• for two years after the ban ends, must obtain permission from Mass. General and Harvard Medical School before engaging in any industry-sponsored, paid outside activities and then must report back afterward

• must undergo certain training

• face delays before being considered for "promotion or advancement."</comment></comment>


The computer that can't crash - <AUTHOR> http://www.humansinvent.com/#!/11109/the-computer-that-cant-crash/

<comment><USER2> _So that's why, if one of them locks up or freezes, your whole computer can crash because it's not actually doing things in parallel._

What utter BS. Does this guy know nothing about privilege levels [1]? or anything about operating system and processor development from the past 20 years?

[1] <http://en.wikipedia.org/wiki/Privilege_level>

<comment><USER3> >What utter BS.

What silly outrage. That explanation is _so_ close enough for an audience full of laypeople.

<comment><USER2> It's a lie (intentional or not), and one that does the author a disservice by (a) making him look like a fool to his peers, and (b) obfuscating the _actual_ benefits of his computing model (which, from the paper, look to have more to do increasing performance of certain parallel algorithms rather than fault- tolerance).

</comment></comment></comment><comment><USER4> This article makes it sounds like he is applying a microkernel with user space modules to multi-processor systems.

New scientist article on this has better info. Data and instructions are packaged together, are passed around, and executed with a pseudo-random timer offsetting a unit of work to avoid a single thread over consuming resources. They also want to apply machine learning to have certain error conditions self repair through auto code manipulation.

Here's a much better article on the topic:

[http://www.newscientist.com/article/mg21729045.400-the- compu...](http://www.newscientist.com/article/mg21729045.400-the-computer- that-never-crashes.html)

</comment><comment><USER5> Here is a paper of Bentley's that appears to be talking about the idea mentioned in the article:

<http://www0.cs.ucl.ac.uk/staff/p.bentley/SABEC2.pdf>

He has written other relevant stuff, but publicly available full-text versions are hard to find. For those who want to search, the key phrase seems to be "systemic computation".

And just in case it isn't clear: this is front-line research. There is no _product_ to get the technical specs of.

</comment><comment><USER6> Looks interesting, but it'd be nice to get the detailed, technical description of it, rather than some journalist's take on things.

</comment><comment> guard-of-terra That kind of computer will also make subtle and unpredictable mistakes.

Compared to a system which either gets it completely right or it doesn't.

</comment><comment><USER7> _The computer that can't get stuck in an infinite loop._

I don't think that is necessarily the same as one that can't crash.

<comment><USER8> It's not at all the same.

</comment></comment><comment><USER9> "Humans Invent does not support your browser as it is many years old- continue at your own risk!

Please consider upgrading to one of the following more modern browsers: \- Google Chrome \- Mozilla Firefox \- Apple Safari \- Internet Explorer 9"

I'm using IE10. Sterling effort there. If you can't even get your website to work, what hope is there for computers that don't crash?

</comment><comment><USER10> Whenever I hear about something like this (eg, 'the uncrashable computer' or the 'indestructible drinking glass') it begs the question - what about one of the greatest misnomers of all? The Unsinkable Ship, her royal majesty's Titanic

<comment><USER9> George V was on the throne then. So if it were a royal ship, which it wasn't, then it would be _his_ majesty's ship Titanic (HMS Titanic).

The prefix RMS which was used for the Titanic means Royal Mail Ship. i.e. it delivered mail.

</pedant>

</comment></comment><comment><USER11> Holy yellow bar. Couldn't read.

</comment><comment><USER12> So all this guy is doing is cluster computing on a micro scale?

</comment><comment><USER13> The article that can't give any details or make any sense.</comment>


Netflix: Disgruntled customers rejoining service - <AUTHOR> http://news.cnet.com/8301-1023_3-57435709-93/netflix-disgruntled-customers-rejoining-service/ <comment><USER3> What, I rejoin last night and there's already an article about it? ;)

Seriously though, in my search for cheap/free movies what pushed me off the fence about rejoining Netflix was that they were offering the first month free, even though I'm not a new customer. All the details of my account were saved, and all I had to do what update the security code and expiration date on my card. Pretty damn good UX through the re-signup process.

The annoyance factor came when I tried to watch a movie. I got an error message with an obscure DRM error code, and instructions to call a Netflix 800 number. Rather than wake Reed Hastings up at an ungodly hour, I Googled around and followed advice to delete a particular Silverlight related file, and restart the browser.

Again, no dice, but at least now the error code was one that prompted me to upgrade my version of Silverlight. Downloaded, installed, restart browser. Log back in for the third or fourth time. NOW I can watch my movie.

Let's just say that was only mildly annoyed by all of this because the first month was free. And the process in the end was somewhat less painful than hunting for a working stream (...or what that must be like, I'm sure). ;)

One free month is more than enough time to re-evaluate whether their streaming catalog is worth the 7.99 monthly price. I do hope they've added more A-list movies on the streaming side, because it's just not worth it for me to tack on another eight bucks to get access to the DVD catalog.

</comment><comment><USER4> I know I'm like the only person in the world who cares about this but I quit Netflix the moment I saw they used pop-unders for advertising.

People used to be screaming at all the popups and popunders in the early 2000s. People stopped screaming because adblockers and customer complaints in general end up getting rid of them.......except for Netflix! WTF!

They still use them. Saw a few this week, and I still won't support Netflix because of it.

Personally, I think as a geek, you shouldn't support them either.

<comment><USER5> I've never seen a pop-under ad on netflix. I've never seen any advertising on netflix. You may have some malware or something.

<comment><USER6> greggman is referring to Netflix pop-unders on 3rd-party sites.

</comment></comment></comment><comment><USER7> I don't think it's too surprising. What were their viable alternatives --besides cutting off from video entertainment altogether?

I don't think they have credible competitors§ yet. There's Hulu and there's Amazon Prime videos, but neither, to me, have the same breadth.

§I mean, via internet delivery. Even DVD mail delivery, they are very good, but that's not a growth market.

<comment><USER8> Hulu's advantage is that they have more things that are available on cable - <USER2> can see Bob's Burgers and Once Upon A Time the day after they air.

The downside is that I cannot watch the first season of the former... unless I fire up Netflix :)

<comment><USER3> How have you found the browsing experience on Hulu? I tried it recently and was shocked at how difficult it was to look through the different titles.

One advantage of Netflix is that they give you a really dense page full of easy to read selections when you're hunting for something to watch.

<comment><USER8> Hulu's XBox UI actively conspires against me. Aside from the couple of actual bugs, it's frustrating as hell. What's worse, Netflix seems to be copying them. The web interface is better, but still not fantastic.

But they're the only two legal games in town that don't charge an arm and a leg.

</comment></comment></comment></comment><comment><USER9> Here's one disgruntled customer who doesn't miss Netflix at all. Redbox fills the void nicely and it's way cheaper for my viewing habits.

<comment><USER10> So, how many discs do you rent a month? Because if it's <5, then I'd say, okay, you'd be better off without the $8 netflix. But, if it's more...

We love netflix at home. They're seriously starting to ramp up on TV series licenses and 80s and 90s hit movies now (where we as Gen-Xers go for our nostalgia trips).

And, I'm starting to see _some_ AAA blockbusters show up from the recent past (<5 years ago). So, it's coming along nicely for our needs and _definitely_ for the price. I've never understood how people who say "well, cable has bigger hits faster", but not only do you have to _pay_ $50+ for digital HD cable, but >$10 on top for HBO/Cinemax/premiums, _and_ pay to "rent" on-demand recent hit movies.

Now _that_ is the ripoff.

<comment><USER11> Haven't you heard of Amazon Instant Video? It has no subscription fee and has the latest movies for rent, on demand, and the highest they go is, I believe $3.99. I don't have a cable or satellite TV subscription at all but I have a PS3 and can use Amazon Instant Video with it, I believe there are devices that you can get to use it if you don't have a current gen video game system.

Personally, I don't like Netflix's streaming video model, I much prefer that of Amazon's but I would definitely like to see the price decrease. Having a large library of movies (mostly older, some fairly recent), doesn't do me any good unless it has the movie I want to watch at that time. I don't watch all that many movies so when I do watch one I want it to choose from any movie to do so, not be limited to a subset of movies for which they were able to negotiate rights to stream them.

I think the "buffet" model of streaming content works for TV shows a lot better since they're shorter and most people are more willing to watch what they consider a "sub-optimal" choice of a show than a movie.

<comment><USER12> > and the highest they go is, I believe $3.99

So that's 2 movies a month for roughly the same amount? With Netflix, I watch 2 movies a day. Have to agree that the offering is a little sparse, but it's a much better alternative than watching regular TV.

<comment><USER13> > With Netflix, I watch 2 movies a day.

You watch too many movies :)

<comment><USER14> Perhaps you watch too few?

</comment></comment></comment></comment></comment></comment><comment><USER15> Isn't Hulu going to become exclusive to cable subscribers soon (a la HBO GO?)

<comment><USER11> Where did you hear this? Its hard to believe given that they've expanded to so many devices now, I could only see this if they were bought out, in which case I think another competitor would arise.</comment></comment>


Oracle wins appeal re Java API copyrightability [pdf] - <AUTHOR> http://www.cafc.uscourts.gov/images/stories/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF <comment><USER2> Disappointing as this result is for those who want IP law to adapt more cleanly to developer realities, and much as I loved Judge Alsup's decision in the lower court ([https://news.ycombinator.com/item?id=4051761](https://news.ycombinator.com/item?id=4051761)), this is certainly not some badly reasoned decision by this particular 3-judge panel of the Ninth Circuit.

What the panel essentially did was continue to apply Ninth Circuit law as it has existed since the 1989 _Johnson Controls_ case holding that the sequence, structure, and organization (so-called "SSO") of a computer program may be entitled to copyright protection depending on the facts of a case. Judge Alsup had not disregarded this precedent but had found what in my view were superb ways of treating APIs in particular in a special way that rendered the copying of their SSO non-infringing - to wit, acknowledging that developing an API was even highly creative, a structure of this type, functioning as a method for compatibility only, should not in itself be protected by copyright but should be protected, if at all, only if it rose to the level of warranting patent protection. How he got there was somewhat complex given that this is a complex area of law. But that is where he had landed. The result, as a matter of policy, was very clean for developers: it gave the courts a workable roadmap for moving the copyright analysis into conformity with the modern digital age on the critical area of APIs and inter-operability without the need of having Congress address the issues.

This panel did the exact opposite. It held that, when it comes to the subject matter of copyright, if a form of expression meets the threshold of being "original," that is enough to make it copyrightable no matter what its function. If the developer of an API had to make creative choices in deciding how to set up the SSO of the API (and almost certainly he will), then the API is protectible and any attempt to copy the same SSO is infringing on its face, subject only to fair use and similar defenses. In so holding, this panel vigorously reasserted the _Johnson Controls_ precedent that has hung over SSO analysis in the Ninth Circuit for many years - meaning, in the case of APIs, it is for a jury to determine case-by-case whether any particular SSO is protectible by copyright. The panel here by no means disregarded the concerns and issues raised by Google (and highlighted in Judge Alsup's decision) but it relegated them to being a potential defense under fair use analysis for acts that are otherwise presumptively infringing. The result: stronger IP protection for APIs and a wealth of uncertainty created for developers in trying to work with inter-operability issues in our modern age.

This case sparked intense interest and drew upon many top lawyers on both sides to argue the issues. It is by no means some hack result. Indeed, it could be argued to be far more in line with Ninth Circuit precedents than Judge Alsup's decision. It can be appealed further, possibly to the full Ninth Circuit complement of judges and possibly to the Supreme Court, and who knows whether it will be upheld or not.

But the really sad thing is the missed opportunity. This was a chance to bring clarity and order to an otherwise muddled area of law and this panel, rightly or not, chose to go back to the muddle. Should it ultimately be upheld, the only real solution in light of this is for Congress to amend the Copyright Act to do a carve-out for APIs to enable them to get special handling under the law to facilitate inter-operability.

<comment><USER3> The federal circuit ruled that an API is a "creative" work and thus is copyrightable. But is it really creative? It is an interface and made according some rules, not some sort of art... I must point out I have read the 28 pages ruling.

<comment><USER4> Im no lawyer, but an API is the most creative part of an entire developer ecosystem to my mind. not the implementation. What made Cocoa so joyful to work with while years of previous Java and MS coding were dissonant painful experiences? All of them manage to get a button on the screen, respond to user input, etc. The naming and organization of different features in a clear and developer friendly way is entirely the API spec.

Whether you should be able to protect such a creation from copying is an issue for society to choose. So far it has chosen poorly.

</comment></comment></comment><comment><USER5> Ironically (and not surprisingly), Oracle themselves do not abide by this, and freely copy the APIs under copyright of others where and when it suits them.

One recent, concrete and particularly brazen example is the llquantize() DTrace aggregating action, which was added to illumos[1] after Oracle forked OpenSolaris by closing it.[2] Oracle has copied this API verbatim in Oracle Solaris 11.2[3], despite not holding copyright to it. One presumes that they didn't copy the implementation (it's open source, but with a weak copyleft that would prevent its inclusion in closed source software like Oracle Solaris), but by Oracle's principles in the Google case, they would have violated copyright. While I would love to pursue this on a purely personal level, the reality is that the principle itself is wrong: Oracle actually should be able to implement the llquantize() API, just as Dalvik should be able to implement the Java APIs. But it would make my day if llquantize() could somehow be used by Google's lawyers to show that Oracle themselves do not abide by the perverted and depraved principle that they espouse...

[1] [http://dtrace.org/blogs/bmc/2011/02/08/llquantize/](http://dtrace.org/blogs/bmc/2011/02/08/llquantize/)

[2] [https://www.youtube.com/watch?v=-zRN7XLCRhc](https://www.youtube.com/watch?v=-zRN7XLCRhc)

[3] [http://www.oracle.com/technetwork/server- storage/solaris11/d...](http://www.oracle.com/technetwork/server- storage/solaris11/documentation/solaris11-2-whatsnew-2191087.pdf)

<comment><USER6> As I've noted below, Oracle's API copying goes all the way back to their beginning. After all, Oracle doesn't own any of the original SQL copyrights (and somehow I doubt they've ever licensed them from IBM).

<comment><USER7> Except that the ruling differentiates between languages (which are not copyrightable) and APIs, which are. Google claimed that all of the Java APIs are part of the language, while the court ruled that only 3 (out of fortysomething are).

<comment><USER8> May I ask why languages are different from APIs, since both are programming interfaces?

<comment><USER9> It mostly has to do with the way you squint and look at it. You're a smart guy, give it a few goes and it'll make sense.

<comment><USER10> To whoever downmodded the parent: I'm pretty sure it was sarcasm. That is, I'm pretty sure when he says "it has to do with the way you squint and look at it", he's saying that there really is not much difference.

<comment><USER11> sarcasm generally does not add signal to the conversation, so it is downvoted here like humor and other noise.

<comment><USER9> I felt that that particular piece of sarcasm added more to the conversation than a simple statement of my agreement, which _is_ distinct from an upvote, however, I was also unaware of this general policy/behavior of the forum as it is mentioned in neither the FAQ nor the guidelines. Thanks for the heads up.

edit: just to be clear, this is _not_ sarcasm.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> This is really bad for open source. A lot of people can now get sued for making compatible API implementations, and their only argument will be whether it is fair use (which is an affirmative defense).

IE Say FredCo has C++ and Java clients for their API. You decide to make and publish a Ruby client. If you use the same Structure, Sequence, and Organization of the API (IE you use the same API), congrats, the court thinks you are infringing copyright.

This is the simple version. Think about compilers and ABI's and SQL extensions and all sorts of things, and you can see this decision is truly terrible for open source.

<comment><USER13> I wouldn't say it's bad for open source. Java was always a proprietary technology. Anybody who wasn't aware of this didn't do due diligence. It's bad for java. Who wants to bet the company jewels on someting that Oracle controls? It won't be happening in the future.

Apple's decision to stick with (objective) C is turning out to be a really smart move. That it runs 2x faster than java is another bonus.

Bottom line: you can use java but don't get stuck so bad you can't refactor out of it. And don't trust Oracle. Regardless.

<comment><USER14> Except that iOS is based on Unix, and the freedom to re-implement copyrighted Unix APIs was litigated and won. What if SCO/Novell/USL/whoever owns the Unix copyrights now, comes back and sues anyone reimplementing them? That includes OSX and iOS which are dependent on Unix compatibility.

Also, what's being litigated here is not Java-the-language but Java-the-core- API-interfaces.

You could refactor your way out of those, just provide alternate versions of java.io, java.lang, etc, new redesigned core APIs.

It would break core Java compatibility, but Android is so big, most people would port their Java libraries, and in the end, Oracle would be hurt more, since they rely far more on server-side Java, but most of the world's Java programmers would be migrating to writing mobile apps, probably with non-Java backends, or Java + new Core APIs.

<comment><USER15> Except UNIX

[http://en.wikipedia.org/wiki/Unix](http://en.wikipedia.org/wiki/Unix)

is owned by "The Open Group"

[http://en.wikipedia.org/wiki/The_Open_Group](http://en.wikipedia.org/wiki/The_Open_Group)

One of its purposes is to provide Single Unix Specification (SUS) certification.

[http://en.wikipedia.org/wiki/Single_UNIX_Specification](http://en.wikipedia.org/wiki/Single_UNIX_Specification)

Mac OS X is SUS v3 certified (I don't think iOS is) and can call itself UNIX, and there is 0 danger of anyone suing you for implementing POSIX API or SUS. You just can not claim you are providing a UNIX without getting certified. This is why Linux is UNIX-like OS and not a UNIX.

<comment><USER14> You're confusing Trademark with Copyright. The Open Group owns the Unix trademark, it does not own the API. The fact that POSIX uses the API does not mean any claims to "structure, sequence, organization" of the APIs or command line utilities are invalid.

This has never been litigated before. Past UNIX copyright wars were fought over copying actual code between Unix and clones. No one has ever tested whether API reimplementation of Unix is copyrighted. Implementing as public spec won't save you. Java has a public, open, specification and was clean-room reimplemented in much the same way that Linux is not Unix, Android Java is not Java.

Claiming there is 0 danger in being sued sounds like naively wishful thinking, especially with Apple's deep pockets, there are plenty of lawyers out there looking for ways to crack that nut.

<comment><USER16> The Open Group own both the UNIX trademark and the POSIX spec. They used to demand a lot of money for copies of the spec, but you can get it online for free nowadays ( [https://www2.opengroup.org/ogsys/catalog/G101](https://www2.opengroup.org/ogsys/catalog/G101) is a good place to start). They put copyright notices on the spec, but (at least until this ruling) that was widely believed to only apply to the description of what functions needed to do, and not to the function declarations.

<comment><USER17> Is it clear that The Open Group or IEEE actually have a clear right to claim copyright of the POSIX api given this ruling? Were they assigned or licensed that copyright by AT&T or any of its successors? It seems likely enough that in the 80s this was not seen as necessary, and the old guard of UNIX implementers were still being quite belligerent towards each other at the time, afaik.

<comment><USER16> I believe the Open Group was assigned whatever copyright AT&T had when the Open Group was created.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Oracle haven't won yet, Google still have the opportunity to show that Android is fair use:

 _we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection. Because there is an insufficient record as to the relevant fair use factors, we remand for further proceedings on Google's fair use defense._

Some further detail found later on:

 _On balance, we find that due respect for the limit of our appellate function requires that we remand the fair use question for a new trial. First, although it is undisputed that Google's use of the API packages is commercial, the parties disagree on whether its use is "transformative." Google argues that it is, because it wrote its own implementing code, created its own virtual machine, and incorporated the packages into a smartphone platform. For its part, Oracle maintains that Google's use is not transformative_

So it looks like there will be a new trial.

<comment><USER19> > Oracle haven't won yet, Google still have the opportunity to show that > Android is fair use

And the opportunity to appeal the CAFC decision on copyrightability to the Supreme Court.

<comment><USER18> I'd like to see that, a sensible copyrightability precedent would surely reduce the number of future "is this specific API fair use?" cases which might arise if Google wins on fair use only.

</comment></comment></comment><comment><USER14> There's be no PC revolution if this ruling existed in the 80s.

[http://ckolderup.tumblr.com/post/48362660527/phoenix- technol...](http://ckolderup.tumblr.com/post/48362660527/phoenix-technologies- cloning-the-ibm-pc-bios)

The entrenched players benefited from an enormously more free era of software development, we now live in an age where every line of code, every UI widget, every pixel, is going to be patented and copyrighted.

If you develop any code and achieve any success at all, there will always be a sword hanging over you.

The whole system is going to have to implode before it will be reformed. Last year 92% of patent applications were approved. Every area of human thought is being fenced off.

<comment><USER7> No need to get hysterical. BIOS is not the same as a software API, and copyright is not the same as patents. I think software patents are terrible, but I definitely want software to be copyrighted. Regarding the copyrightability of APIs, I don't think either ruling has much of an effect in today's ecosystem.

<comment><USER20> If not BIOS, consider the operating systems themselves.

If AT&T had strong copyright claims on the "APIs" that make up the system calls of UNIX, for example there goes Linux (and essentially the entire GNU and BSD projects as well), there goes modern MacOS, etc, and the reverberations would be enormous even with fully closed sourced OSes like Windows... With strong copyright on APIs there, essentially, goes the Internet as we know it when there isn't a clear path of UNIX->BSD/POSIX->sockets for everyone to copy (and thus be interoperable with each other).

And even if we shift the strong copyright event later into the 90s then consider the modern web, if Netscape (which at one point was a very different entity than today's Mozilla in terms of openness) had a strong copyright on the definition of JavaScript's APIs? Or if nobody dared implement their own XMLHttpRequest for fear of Microsoft's API copyright?

This is something developers (and anyone who cares about technology, really) should _absolutely_ be hysterical about.

<comment><USER7> Unless the reason those technologies spread is precisely because no one had strong claims, or no one chose to pursue protection. If Netscape had chosen to make JS proprietary, JS wouldn't have become a de-facto standard.

I am not aware of any significant proprietary API today that is in widespread use, and is cloned by FOSS. But I could be wrong on that. If you know of such APIs, I'd love to know which ones are in danger.

<comment><USER14> That's not really true, things can become de-facto standards even if they're proprietary, especially if the actual status is in doubt. Many developers don't think about the long term consequences of licenses when they start using stuff, especially if it is useful and free of charge.

Linux is a perfect example of a proprietary API (Unix) which is in very widespread use, which was cloned by FOSS. Most of the Unix command line utilities were explicitly cloned by the FSF to be compatible with existing shell scripts on Unix.

Adobe made Flash proprietary and it became incredibly widespread, so widespread that if you turned if off, many websites would break, despite the fact that it had numerous performance and security issues. Flash made it to something like 97% penetration of all Web clients (prior to Apple iPhone) People have cloned Flash (hAXE for example), but there was really no reason to do it, because Adobe offered the player free of charge.

WINE is in widespread use. Samba is in widespread use. Lots of Website REST APIs have been cloned.

Adobe PDF was proprietary and widespread cloned until in 2008 it became an open standard.

Cloning APIs is a time honored tradition for "embrace and extend". Microsoft even cloned proprietary APIs, and DOS itself started out as an unauthorized clone of CP/M. Where would Bill Gates be today without Seattle Softworks?

I hate having to resort to the tired ole idea of rich people having gotten rich by theft, but in many cases, it's quite true, that Gates and Jobs both freely copied, cloned, and modified other people's stuff, got stupendously wealthy off of it, but somehow, it's wrong for us to want to practice their methods?

<comment><USER7> What happened in the past is irrelevant, because after this ruling, it probably won't happen again. The freedom to clone proprietary APIs is not essential to FOSS any more, because the FOSS ecosystem has become powerful on its own. Either proprietary vendors choose to license their APIs to FOSS, or risk being replaced by an incompatible FOSS implementation.

My question was about how the current ecosystem will be disrupted. Now, with WINE -- I agree, but I don't think it's in widespread use, and I don't think Microsoft will go after them. AFAIK, Samba implements a networking protocol, not an API (but I may be mistaken).

It really all comes down to Linux. If Linux is in danger, then obviously the ecosystem can be disrupted by this ruling; if not -- then probably not. I must say I don't know enough about the current legal status of Linux, and whether or not it's in real danger.

<comment><USER14> >What happened in the past is irrelevant

In other words, "I got mine". People who profited and got stupendously rich, get off scott free, and are free to deploy lawyers to interfere with the next wave of participants. Not unlike immigrants who settle in, and then want to slam the door on the next group of immigrants.

>Samba implements a networking protocol, not an API

Protocols and APIs are another distinction without a different. If the sequence, structure, and organization of an API can be copyrighted, then surely, the sequence, structure, and organization of a wire protocol or file format can, after all, the only real different is the invocation mechanism.

<comment><USER21> > If the sequence, structure, and organization of an API can be copyrighted, > then surely, the sequence, structure, and organization of a wire protocol or > file format can, after all, the only real different is the invocation > mechanism.

While it might be easy to analogize between an API and a wire protocol in terms of technology, that doesn't mean that analogy holds within the framework of copyright law. The Fed. Cir. opinion was expressly couched in terms of the "sequence, structure, and organization" of the names in the API. Indeed, the opinion concedes that if Google had chosen different names, then things would be fine. Putting the same bytes at the same offsets is not at all the same as naming things the same way.

<comment><USER20> Yeah but doesn't the distinction become way less clear when talking about protocols that aren't traditional fixed-structure binary protocols?

We live in a world of protocols that are increasingly RPC/REST based which as others have mentioned are really just APIs you happen to access over a network connection.

<comment><USER21> Good point.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Sigh. Allowing Copyright for API declarations is a poor choice, and analogous in my mind of allowing patent protection on a thread radius and spacing. That APIs and the constants they use are declared in words is an artifact of how computer languages evolved and not the 'art' part of the work. We might just as well copyright any story that involves a young man falling in love with a young woman where the parents disagree that they should be together. Such structural elements which are required for constructing a story are similar to the structure of an API which is required for creating an interoperable program.

Ideally this goes to the Supreme court and gets knocked flat. Doubly ideally someone amends to the Copyright act to specifically disallow this sort of argument for Copyright.

</comment><comment><AUTHOR> The appeals court looked to a decades-old "abstraction, filtration, comparison" test. In essence, that test requires the judge and jury to play the role of a patent examiner. See slip opinion at pages 23, 40. The expense and uncertainty aren't much fun for either party (or for the judge, jury, and law clerks for that matter). But yippee, say the IP litigators, because cases like this require lots of billable hours.

EDIT in response to @crashandburn4: Oracle still hasn't won the case, because the appeals court ordered a retrial of Google's fair-use defense, as to which the jury deadlocked in the first trial. See the slip opinion at pages 60-62 (and preceding pages if you want the legal background).

</comment><comment><USER23> The only winners of the current software patent system are lawyers.

I sincerely hope we look back at this dark time and laugh at it like we do with powdered wigs. Unfortunately I just don't see any change on the horizon, so it's just as likely things will only get worse and worse, and innovation will be stifled even more.

<comment><USER7> This is about copyright, not patents. Even the biggest opponents of software patents support copyright. If there's no copyright, anyone can take your software and just make it their own.

<comment><USER21> Not really. The modern generation of web developers don't sell software, they sell eyeballs. So they don't really care about copyright. But trademark, that's important! No advertising dollars without trademark! /cynic

</comment></comment></comment><comment><USER24> I see a lot of people downplaying the impact of this, saying that it just means the defense falls back to "fair use" \- but isn't that the point? Every single open source project that implements any kind of API now has an individual legal threat that their work might not be "fair use" which can only be decided on a case by case basis. It seems to me like the worst case is that any large corporation, whether it be Microsoft, Google, Oracle or Apple can exterminate just about any open source project with a simple cease and desist letter that they are unable to afford to challenge. Without a crystal clear ruling that APIs are not copyrightable a great portion of open source and non- open source that is now out there seems to be essentially in an untenable position.

I really wish Google had invested in the "nuclear" option and pursued a parallel development strategy to move Android entirely away from dependency on Java. If they had started 3 years ago and offered an alternative API (say, for example, based on Go, but it could be anything relatively efficient, even a brand new language), by now there would be a significant base of users and Google would be able to threaten Oracle with a wholesale migration away from Java. Even in their most delusional moments Oracle must know that losing Android would be a huge loss in terms of the mindshare and userbase. I think it's unlikely we'd be seeing Oracle pursuing this to the death if Google hadn't left themselves in such a weak position. (I have a secret hope that they _have_ been doing this and will astonish us all by taking the wraps off it at Google I/O one day ...)

</comment><comment><USER25> I wonder how this will impact MariaDB's future development. In theory the original APIs were forked under an open license, but new MySQL features probably can't be legally replicated with application compatibility because of the API.

Also, how does this impact things like Wine, as the MS API set has never been open source (to my knowledge)

Actually in a wider perspective, I wonder how this will impact emulators in general.

</comment><comment><USER26> If you can copyright an API, I can't see anything that would prevent you from copyrighting a protocol. This is a terrible decision for interoperability, and for competition. It favors entrenched players at the expense of everyone else (including users).

</comment><comment><USER27> It's quite ironic that Oracle, of all companies, would be making this argument, when they got their start attempting to clone IBM's system and API.

<comment><USER28> It's a common pattern. Disney got it's start by making derivative works. Now Disney is the champion of draconian & perpetual copyright laws.

Give someone dominion and that person takes on the role of the overlord.

</comment></comment><comment><USER29> Doesn't Oracle have many systems that depend on API compatibility with competitors?

Are they shooting themselves in the foot? I sure hope so.

<comment><USER6> Oracle isn't shooting themselves in the foot (now). Today they have the money required to pay lawyers to put on a vigorous fair use defense of any potential API copyright infringements.

Of course, back in the late 1970s when Oracle was just starting out by building a database based on a query language developed at IBM it would have been another matter entirely...

</comment></comment><comment><USER30> I think that this is absolutely right in principle. An API is tricky to get right and good one is definitely creative (it is a work of design) and there are many copyright able things that are less worthy.

The fair use/enforceability side of things is where the interesting questions lie and that is the place for a messy compromise to allow some forms of interoperability. I would be most in favour for attempts at drop in compatibility and actually find Google's incompatible embrace and extend commercial manoeuvre quite unsympathetic.

<comment><USER10> Yes, an API is tricky to get right, and a lot of work, and can have creativity in it.

But not everything that meets those criteria are, legally, things that can be copyrighted. Until Oracle, nobody assumed that an API (as opposed to the text describing it) could be copyrighted, since it is legally settled that a single function declaration (that is, not implementation) cannot be copyrighted, and an API is just a collection of function declarations.

</comment></comment><comment><USER31> Probably too early to discuss, but what's the status of the VM + bytecode spec? The preface of the SE 5.0 VM spec [1] says:

 _We intend that this specification should sufficiently document the Java virtual machine to make possible compatible clean-room implementations._

IANAL, but isn't the "clean-room" giving permission or at least encouraging others to reimplement the VM without Sun/Oracle's involvement? Or is this a non-legally-binding statement and all bets are off with respect to the VM specification? (Or something else?)

[1] [http://docs.oracle.com/javase/specs/jvms/se5.0/html/Preface....](http://docs.oracle.com/javase/specs/jvms/se5.0/html/Preface.doc.html)

<comment><USER32> IANAL, but I'd take that as a non-legally binding statement, as it merely specifies that the documentation should be specific enough to make a clean- room implementation possible, not that such implementations are allowed.

</comment></comment><comment><USER33> Why did they decide that APIs are copyrightable? It's a complete lunacy. Can Google appeal it again? Would it be Supreme Court in such case?

<comment><USER19> > Can Google appeal it again?

Yes.

> Would it be Supreme Court in such case?

Probably. In theory, I think they could first ask for _en banc_ review by the Federal Circuit.

</comment></comment><comment><USER34> It seems pretty likely that this will go to the SCOTUS. The court has been taking a lot of IP related cases recently and this one is pretty huge.

</comment><comment><USER35> If Oracle wins, is Linux the next target, as an api-compatible re- implementation of Unix?

<comment><USER36> Unix != POSIX

<comment><USER35> Sure it's not, but the existence of a spec to guide (arguably) _licensees_ of Unix to have greater compatibility with each other will not necessarily protect non-licensees. (That the spec doesn't address this case is neither here nor there, if Oracle eventually wins this case.)

</comment></comment></comment><comment><USER37> I wish Groklaw was still around to give a good analysis of this :(

<comment><USER14> Don't work, we still have Shillian Mueller to spike the ball, I mean, analyze it.

</comment></comment><comment><USER38> My only use of Java is for Android.

The Android VM - Dalvik - uses Dalvik not JVM byte code. Now ART - the new Android runtime replacing Dalvik - is native - no more byte code.

There's not much Java left apart from the (poor) syntax. Why doesn't Google bless one of the alt-Java's, like Kotlin, and cut out Java entirely.

<comment><USER39> Sun used to make a good portion of their revenue from Java licensees. Then Google copied Sun's JVM, language, and APIs with a few very minor tweaks in Android. Sun's Java revenue dried up because its licensees didn't renew because they could just use Android.

Dalvik and JVM bytecode map 1:1 with one or two exceptions for initializing arrays with data instead of a sequence of instructions. Even if you want to pretend that Dalvik isn't a JVM then you must accept that it is a derivative work, as even the names of the bytecode instructions are the same.

Google killed Sun and if they end up paying for it by APIs being copyrightable that may be a disaster for the tech industry, but it's karma for Google.

<comment><USER40> Java is used in a great many places other than Android. Google most certainly did not kill Sun.

<comment><USER39> An analyst came up with a $250 million annually for Java licenses. Andy Rubin said (exhibit 13) that "Sun is prepared to walk away from a $100M annual J2ME licensing business" into a deal with Google for some portion of Android income, which obviously is not an exact but indicates the scale.

Java wasn't going to power a Sun-sized company by itself, but having this income dry up while already trying to save the company from linux is a death blow.

</comment></comment></comment></comment><comment><USER41> We've just harmed innovation in the US even more. Oracle, the same place you made it you are destroying the future of, just stop. Ellison has forgotten his engineering roots entirely. Java is also going to be limited due to this, one of their own products now.

</comment><comment><USER42> Does anyone have any idea what the practical significance of this for android and google is? IANL and find these documents hard to parse.

<comment><USER6> Other than a pile of legal fees, it's not clear that there will be any direct impact on Android and Google. Even if you assume Google loses all their appeals (a big if - the Federal Circuit and the Supreme Court often don't see eye-to-eye on IP law), Google didn't lose on fair use - the jury deadlocked.

So the issue of fair use would need to be re-tried, and there's a good chance they'd win - the deadlocked jury was 9-3 in favor of Google. That may even be overstating Oracle's support. According to some reports, only one juror was a holdout for Oracle on the fair use question [1].

The problem isn't Google's, it's everyone else's. If this decision holds up on appeal, the legality of a compatible re-implementation of an existing API will often be a question of fair use that needs to go to a jury. Practically speaking, that means API re-implementation (a previously standard, commonly- used part of the interoperability toolbox) is dead for anyone who doesn't have the millions required to try this sort of case. I can't even begin to comprehend how that will change software development.

[1] [http://www.reuters.com/article/2012/05/24/net-us-oracle- goog...](http://www.reuters.com/article/2012/05/24/net-us-oracle-google- idUSBRE84M18K20120524)

<comment><USER21> Obviously, non-copyrightability is the best possible outcome, because then such cases wouldn't even be worth bringing. But the opposite holding doesn't necessarily mean every such case has to go to a jury trial. If the facts are such that no possible jury could find in favor of one party, a fair use question may be disposed of on summary judgment: [https://www.eff.org/document/opinion-granting-summary- judgme...](https://www.eff.org/document/opinion-granting-summary-judgment- fair-use).

Getting a case to summary judgment isn't cheap, but the fair-use factors aren't super fact intensive: [http://fairuse.stanford.edu/overview/fair- use/four-factors](http://fairuse.stanford.edu/overview/fair-use/four-factors). They center around the nature of the work itself, which can be described in pleadings, rather than specific facts about the creative process that might require extensive discovery.

</comment></comment></comment><comment><USER43> Hm. I'm gonna check what Groklaw says to this....

....wait. Oh.

</comment><comment><USER44> Why is American government the best government? Because of our endless appeals system.

<comment><USER45> Although not overly on topic, for those that don't know, this is a quote from the movie "Thank You for Smoking" \-- I normally wouldn't upvote a comment like this, and maybe shouldn't, but it really is a fantastic movie for those that may not have seen or heard of it before!

[http://www.imdb.com/title/tt0427944/](http://www.imdb.com/title/tt0427944/)

</comment></comment><comment><USER46> When can Go be used for android development?

<comment><USER10> My guess: five minutes after the Supreme Court rules that Oracle is correct.

If Google doesn't have something like that started, they should. If they didn't start it immediately after this ruling, they are far dumber than I think they are.

</comment></comment><comment><USER47> This can cut both ways. Certainly parts of the Java API are essentially copied (SSO) from APIs they did not license. Google should be able to argue their rights are terminated under fruit-of-a-poisoned-tree doctrine.

But realistically, I can't see much except federal corruption in the decision to hold the copyrightable SSO higher than the functional requirements. In this digital age, that is a boot-licking verdict.

Alsup got it right.

</comment><comment><USER48> _[...]The accused product is Android, a software platform that was designed for mobile devices and competes with Java in that market.[...]_

How does Android compete with Java? Wasn't it supposed to be a good thing for the whole language to have Android out there especially in times when many other languages emerged that have been touted as "the new Java" or "the next C++"?

</comment><comment><USER49> Let's rewrite the story some for a bit of perspective.

Instead of Google, let's use Microsoft, and say we're in the 90's and it's Sun's Java, not Oracle.

Oh wait. That happened, and Sun and Microsoft settled out of court to the tune of some $2 Billion.

<comment><USER50> Microsoft paid because they called it "Java", in blatant breach of their contract with Sun. I don't like Google, but they never did anything remotely like that.

<comment><USER51> [https://developer.android.com/guide/index.html](https://developer.android.com/guide/index.html)

"Android provides a rich application framework that allows you to build innovative apps and games for mobile devices in a Java language environment."

<comment><USER52> > Java language environemnt

Java the language is not Java the platform

</comment></comment></comment></comment><comment><USER53> I herby copyright:

        Object *(Object...);

I'll take a check Oracle. Thanks.

</comment><comment><USER54> If the API headers are copyrighted, wouldn't any program that uses them be a derivative work? In that light, every Java program is infringing. Every program on earth would be infringing something wouldn't it?

<comment><USER55> To be fair, the free software foundation takes the opinion that using a library _is_ a derivative work of that library, which is why they provide both the GPL and the LGPL. If using a library was not a derivative work of that library, then there would be no need for an LGPL.

<comment><USER56> LGPL has nothing to do with API, but rather the definition of a derivative work.

Using a library i akin to put a engine into a car. One could argue that the engine would still be a separate piece and thus not "part of the car", but its a tough sell to do in court. The line that separate "a thing" with "other things" is determined by judges, juries (and in some cases, common sense). In 23 years, no one has dared yet to do so.

Using an API however is like putting your own engine into the car, but it happens to use the same input/output of similar car engines. The GPL do not have a dog in that fight, but FSF argues against such stretching of copyright.

</comment></comment></comment><comment><USER57> As much as I dislike the impact this could have I must say that designing a clean, orthogonal, complete API can take longer than actually implementing it. A properly thought out API will dictate the implementation and strongly optimize it. I've done API's and then the code to implement them and there is no way I can see API creation as other than a highly creative endeavor.

The designer in me says, yes this is the right decision, but my pragmatist is worried.

Processor instruction sets are no less API's than are the means of accessing a software product. Can they be copyrighted?

</comment><comment><USER52> I ask a question, Sun changed the Java license to GPL, doesn't that means that Google can now use it to reimplement Android API's?

<comment><USER58> You can comply with the GPL or you can comply with the original license. Neither of which allows you to BSD license the code, if in your use of the code you violate copyright. GPL is very specific in that every copy of GPL'd code must be in turn GPL'd. Re-Releasing code of BSD breaks that chain, and thus isn't allowed.

If you don't like what licenses are available to you, then you negotiate a new one or you don't use it. Every vendor knows that when they modify Linux and embed it, their changes to Linux must be available. No vendor has done more than pay lip service to challenging this aspect of the GPL, the reason being, is the strength of copyright.

</comment></comment><comment><USER28> The commercial legal system favors the entrenched players who have money to prosecute and defend against prosecution.

The whole game is rigged to consolidate power & dominion. The only way to get away from the game is to stop playing.

Software free of, or successfully loopholed from, this system are viable alternatives that deserve more mindshare.

</comment><comment><USER59> If this isn't the death nail in the coffin for Oracle Java, I don't know what is. Why would anyone continue to use Java when they can potentially be sued into oblivion by Oracle for trying to use their products? Run for the exits while you can.

</comment><comment><USER60> So, I have been going through the opinion (though I haven't finished reading every single word of it, I do intend to do this, and I hope that many other people do as well; certainly, I wanted to skim enough of it to have an informed opinion, rather than operating only off of things I've heard in popular news articles). I care a lot about this case (doing interoperable development), and there is some nuance to what is going on that I don't think many of the people commenting on this matter in the general developer public appreciate.

To fail to summarize ;P, this nuance stems from separating the question of whether Oracle's APIs are copyrightable from whether Google can claim "fair use" in copying them for their purposes. Much like with trademarks (where people get really uptight that someone "trademarked a word", ignoring context restrictions), I think people lose these nuances while talking about situations like this, and presume that if something is protected in some way then it is an ironclad protection that applies even in ludicrous circumstances.

Keeping this difference in mind, if the court said "APIs are copyrightable, but what Google did was a clear example of fair use: creating interoperable implementations is allowed", some people might still be angry, but I think many fewer people would be bothered: it changes what the opinion means. And, in fact, this is closer to what this opinion is saying than many people seem to be reading from it: they talk a lot about whether what Google is doing might be fair use, but they essentially punt that call back to the lower court.

> Because the jury deadlocked on fair use, we remand for further consideration > of Google's fair use defense in light of this decision.

We then have to ask "what happened" with this fair use argument, as we would _hope_ that in the situation that APIs are copyrightable that interoperating with those APIs would be considered fair use: "something went wrong here". I think we can actually see some disappointing mistakes in Google's argument from reading this opinion: even though it wasn't trying to decide this matter directly, it talks a lot about fair use and models of interoperability. It frankly seems like Google just did a really really bad job of arguing the case :(.

If we go back to the beginning of this, most of Sun's core arguments about Java surround the idea that code written against Java should run on anything claiming to support Java. Microsoft was really excited about Java, but because they wanted to add a few extra features--some classes that would exist for UI purposes on their implementation of Java but on no other--the Internet has ever since considered them horribly evil people and were happy when Sun won in court against them (which is why Microsoft decided to build C#, btw).

Google seriously did not want to build something interoperable with Java under this definition: they have their own class libraries for handling large regions of the platform, including basic things absolutely any application would be using a lot of, such as UI and RPC. Given this, Google trying to claim "we want to be interoperable with Java" is horribly confusing. You find the opinion trying to understand Google's position on interoperability and failing: it almost makes Google look like they are lying about "interoperability".

> Indeed, given the record evidence that Google designed Android so that it > would _not_ be compatible with the Java platform, or the JVM specifically, > we find Google's interoperability argument confusing. While Google > repeatedly cites to the district court's finding that Google had to copy the > packages so that an app written in Java could run on Android, it cites to no > evidence in the record that any such app exists and points to no Java apps > that either pre-dated or post-dated Android that could run on the Android > platform.

> During oral argument, Google's counsel stated that "a program written in the > Java language can run on Android if it's only using packages within the 37. > So if I'm a developer and I have written a program, I've written it in Java, > I can stick an Android header on it and it will run in Android because it is > using the identical names of the classes, methods, and packages." Counsel > did not identify any programs that use only the 37 API packages at issue, > however, and did not attest that any such program would be useful. Nor did > Google cite to any record evidence to support this claim.

Now, I have certainly seen many Java libraries that manage to only use this subset of features; and to me, being able to use those libraries is an interesting aspect of "interoperability". Sadly, however, Google's lawyers seem to have not bothered making that argument: they were probably doing the important thing where they simplify the kinds of words and ideas they are using for the jury to quickly understand, but the difference between applications and libraries needs to not be understated and left to implicit context :(.

The result is that rather than seeing what Google was doing as building an interoperable implementation of an API, the panel sees Google as instead building their own _non_ -interoperable platform that _happens to share striking similarities to Oracle 's Java_. They feel like Google is just copying a bunch of effort and work and even creative expression that Sun had put into Java in the construction of Google's competing way of developing applications for the seemingly-purposely unrelated platform that they are using on Android.

> The compatibility Google sought to foster was not with Oracle's Java > platform or with the JVM central to that platform. Instead, Google wanted to > capitalize on the fact that software developers were already trained and > experienced in using the Java API packages at issue. The district court > agreed, finding that, as to the 37 Java API packages, "Google believed Java > application programmers would want to find the same 37 sets of > functionalities in the new Android system callable by the same names as used > in Java."

Let's say that Microsoft's C# happened to have a programming library that had large regions of API that were "directly copied" from the standard library of Java, even if there were no way to even attempt to run a Java class/jar on the .NET Virtual Machine. While many people would still say "that clearly should be allowed", I think that changes the character of the discussion quite a bit: I think many of the same people angry at Samsung about copying things off Apple would find themselves angry at Microsoft for copying things off Sun.

Again, I want to stress that I am not saying this should sit well with everyone: I can easily appreciate the arguments of people who feel that APIs should simply fundamentally not be subject to copyright. (That said, I can also appreciate the arguments of people who feel that software in general should not be subject to copyright, and I appreciate the arguments of people who believe that absolutely nothing should be subject to copyright as they think the idea of copyright is flawed. These are all somewhat reasonable positions to me.)

Instead, I point this stuff out as I think people are extrapolating too much from this decision and are taking it to mean things that it doesn't: in particular, it doesn't mean that you can't build systems that interoperate with an API designed by another party. It is then unfortunate that people are extrapolating this decision all the way up to hyperbole like "the PC revolution wouldn't have happened under this ruling". It just doesn't help when people make these kinds of grandiose statements: everything becomes emotional :/.

Really, what we are looking at (and I think grellas is saying something similar, though from a different direction) is an opinion that leaves an area of law in a state where it is not entirely clear: that is a problem, as it leads to individuals having to make horrible and oft-flawed decisions as to whether specific actions they want to perform are or are not allowed. But this uncertainty is not the same as saying "this is not allowed"; and even if Google's usage was not allowed, maybe a intended-to-be-fully-interoperable Java is.

<comment><USER14> A fully-interoperable Java on smartphones IMHO would be a market failure out of the gate. The OpenJDK/JDK was designed for desktop environments, most of the APIs left how have no applicability to mobile. To include them would needlessly bloat an already slow Java platform on mobile. These devices are extremely constrained by memory and battery.

So, you can either have Java on 800 million devices where the APIs are subsetted and retargeted towards modern smartphones, or you can have a hopelessly bloated, too-many-cooks-in-the-kitchen JDK on devices no one wants to use, but they, they'd be capable of running Java apps from the 90s.

This is like saying, I won't let you subset the Win32 APIs unless you guarantee that DOS 3.0 apps will still run.

<comment><USER60> Right: as I said, I think Google needs to make a point that compatibility with libraries, even though "apps" are not compatible; apparently they didn't.

</comment></comment></comment><comment><USER61> Pretty simple solution - legislation that explicitly classifies as fair use the copying of the SSO, the Structure, Sequence, and Organization, of an API for the purposes of interoperability

<comment><USER10> Your "simple" solution has a huge problem, which is named "Congress". Under current circumstances, do you really think we can get an IP bill through Congress that makes things better, rather than worse?

</comment></comment><comment><USER62> I havent grasped my head around the core issue Oracle is trying to sue them for.

Are they saying you need a license to use the API? For example something like java.util?

<comment><USER63> 1) When you download a JDK you get a license to use the API.

2) They are saying that the java header files are copyrightable. It would be challenging to create a compatible java implementation that didn't include something awfully close to the java header files (and it appears that google copied them verbatim). Depending on future rulings, it make make it hard or impossible to create a java-compatible implementation without violating Oracle's copyrights.

<comment><USER64> This isn't quite right. Google didn't copy the API classes verbatim -- they made an implementation of the API. Big difference, and that's why the outcome of this case is so huge.

There is nothing fundamentally copyright-able about an API. It's just a bunch of methods and descriptions. The implementation is the secret sauce. By finding for Oracle the courts have essentially said that you're not allowed to reverse-engineer a library.

<comment><USER63> Google copied the _declarations_ verbatim. Doing so makes sense, if indeed "There is nothing inherently copyrightable about an API" which is probably why Google did this.

On the other hand, this ruling says that there is something inherently copyrightable about the declarations.

<comment><USER65> Every JDK I'm aware of contains the following text in its license. It specifically grants a license to the specification (API) for the purposes of creating a clean room implementation. There is only ONE possible expression of the specification, in Java.

"Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally practice the Specification for the purpose of designing and developing your Java applets and applications intended to run on the Java platform or creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java. _" or "javax._" packages or subpackages or other packages defined by the Specification; (vi) satisfies all testing requirements available from Sun relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code materials without an appropriate and separate license from Sun. The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification."

</comment></comment></comment></comment></comment><comment><USER47> Normally I'd hope to see Google appeal it to the Supreme Court. But not this Supreme Court.

</comment><comment><USER52> The irony is that was not Google the ones that copied Sun's Java, they used Apache Harmony

</comment><comment><USER66> what does this mean to developers and users? what's the impact to android?

</comment><comment><USER67> I will bring up my prediction again: [https://news.ycombinator.com/item?id=7282162](https://news.ycombinator.com/item?id=7282162)

"My take is [APIs] would be found copyrightable, but Google may probably prevail on fair use." [1]

Unlike most here, I think this is the right decision given the current framework of copyright protection. This is because what copyright protects is the _creative expression_ of a work. APIs, after all, are just another form of code, and requires the same (if not more) amount of creativity to design properly [2].

I see a lot of people here seemingly conflating this with patents (which protect functionality) or patent-like scope of protection. Copyright does not protect functionality, only the _exact_ expression thereof. There are an unlimited number of ways to design an API for the same functionality. For instance, the file system APIs for Posix, Java, C# and Python are all completely distinct in their expression.

The arguments against API copyrightability, taken to their logical conclusion, would remove copyright protection for _all_ code. I'd like to see cogent arguments as to why copyright _as it currently exists_ should apply to all other code but not API. ("Because we should be able to re-implement APIs" is not a valid answer, as that is begging the question. Without justification, you may well say that about any code.)

I suspect that any valid arguments would indicate that copyright is not an appropriate means of protection for software. That would be unsurprising; code was shoehorned into copyright because it was a close enough approximation and didn't require formulating a whole new framework from the ground up [3]. Many others [4, 5, 6, 7] have explored the weird interplay of copyright protection and code, which at its heart, is functional (which copyright does not protect) yet is also creative (which copyright does protect).

[1] Even if Google prevails on fair use, I still think that is unfair to Sun (and by proxy, Oracle). People ignore the massive investment, not only in engineering, but in _marketing_ that Sun undertook to make Java as prevalent as it is today. I don't think it's fair to let another party hijack a hard- earned ecosystem without permission from its creators.

[2] Some may argue the Java APIs are poorly designed. All I can say is, even the Twilight series gets copyright protection.

[3] "The Uneasy Case for Software Copyright", [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171451](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171451)

[4] "The Strange Odyssey of Software Interfaces and Intellectual Property Law", [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818)

[5] "Sum Greater than its Parts?: Copyright Protection for Application Program Interfaces", [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1325104](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1325104)

[6] "Copyright Protection of Computer Program Structure", [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1438164](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1438164)

[7] "IP's Problem Child: Shifting the Paradigms for Software Protection", [http://papers.ssrn.com/sol3/papers.cfm?abstract_id=901604](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=901604)

<comment><USER68> > I'd like to see cogent arguments as to why copyright as it currently exists > should apply to all other code but not API.

For the same reason a textbook publisher shouldn't be able to copyright the table of contents of a calculus textbook:

1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text.

2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard.

For example: imagine an API for accessing student information. You have certain common characteristics for those students: Name, Address, Contacts, Schedule, Grades, Absences etc. I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. And if showed a person who had studied the different APIs some specific part of a particular API they wouldn't be able to tell you which one it came from. They would not differ enough in 'style' to be readily distinguishable.

Now imagine Strings. Or authentication or routes or any number of other aspects of computing that we have to deal with every day.

Now, can the same thing be said of ten different authors of say a writing prompt that says "Write about a student who is having an altercation with a gym coach"?

I'd argue that you'd get some very different and and easily distinguishable stories and styles.

<comment><USER67> _> 1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text._

As anyone who has designed enough APIs will tell you (including engineers testifying on Google's behalf during the trial, and many commenters here who disagree with the decision), an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation _usable_ by others is no less a creative task. The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs. For a well designed API it's always the other way around. With enough creativity and forethought put into an API, the implementation flows naturally, and in practice, it's exactly the opposite of the table of contents analogy.

(Not to mention that a ToC may also be copyrightable.)

 _> 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard._

The "nature of information being organized" sounds like "functionality" to me. As before, it is distinct from expression.

 _> I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another._

Consider the corollary of your argument. If you asked those same people to write actual implementations for that same problem. I'd bet you get the same "80% or more would be so close" results. Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case.

Unless you provide a detailed spec and enforce some conventions, I'm willing to bet nobody will have an exact duplicate of another, either for implementation or for API. An API for the same functionality, say for getting the number of absentees, may be labeled getAbsenteeCount() or nAbsentees() or NumNotPresent(). Or even absenteeList().length(). Or a poorly defined API may require something like classSize() - numPresent(). Or a really badly defined API would require iterating over each member of the class and checking the "present" flag. And that is the point: each expression of the same functionality can be unique, and hence a candidate for copyright.

<comment><USER68> >an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation usable by others is no less a creative task.

"Difficult to do well" and "creativity" does not equal "copyrightable". Mathematical proofs are hard to do well and require creativity but are not copyrightable.

If the form is necessary for practical application, it belongs to the public.

>The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs.

You generally don't start writing prose before you have the overall structure fleshed out, either.

>Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case.

Perhaps you are right. Copyright may be the wrong tool for code. Patents may be the wrong tool for code. It may be time to set aside these grossly imperfect abstractions that were built for wildly different purposes hundreds of years before programming was conceived and think through something that fits this type of intellectual property better.

<comment><USER67> _> "Difficult to do well" and "creativity" does not equal "copyrightable". _

But how you express it _is_ covered by copyright. A mathematical proof is not, but if you write it out so that it rhymes, that specific expression _is_. You can now state the same proof a thousand different ways, even those that rhyme differently. But all those original those of the same proof remain protected.

I would tend to agree that copyright and patents are probably not a good fit for protecting software, and maybe a new framework is needed. But given the current means at hand, this decision is internally consistent.

</comment></comment></comment></comment></comment><comment><USER69> Congratulations to Oracle, it's about time justice needs to be served.

<comment><USER70> "There's no justice. There's just us."</comment></comment>


Joe Hruska, founder and CEO of RescueTime (YC W08), has died - <AUTHOR> http://blog.rescuetime.com/2017/07/07/joe-hruska-founder-and-ceo-of-rescuetime-passed-away-july-4th-2017/ <comment><USER2> I used RescueTime to kick my social media habit and learn to code 5 years ago. I was working in the retail industry and found a way to spend 10 hours a week coding on my own for almost two years before I got my first full-time development job, largely due to RescueTime.

I didn't think much of it then, but in retrospect, the impact Joe's product had on my career turned out to be pretty significant. RIP Joe.

<comment><AUTHOR> Thanks for sharing that. That means a lot to us here at RescueTime, and would have meant the world to Joe.

</comment></comment><comment><USER3> Wow - literally just saw an article about RescueTime on the frontpage of NYT ([https://www.nytimes.com/2017/07/05/your-money/where-does- the...](https://www.nytimes.com/2017/07/05/your-money/where-does-the-time-go- you-can-find-out-if-you-dare.html)). And installed it 5 minutes ago. Coincidence, if I've ever seen one... RIP.

</comment><comment><USER4> Fuck that's sad.

Never knew him but from his app/site he definitely "made the world a better place".

I don't know how many person-years he had on earth, but he helped people liberate many thousands of their own.

</comment><comment><USER5> My sincere condolences to the whole RescueTime team. I read about this for the first time here, today. I mentioned it to my wife - we met some of the RT team a long time ago and then lost touch. Her first reaction was total shock and then "omg, Joe was such a nice guy." That's the impression Joe left both of us with. I'm sure his passing has left a huge hole in many people's hearts.

</comment><comment><USER6> This is so sad. I always have subscribed to RescueTime during their sales and pay for a year upfront. So even though I never used it as much after the first couple months, it made sense to continue subscribing year after year. He has helped so many people like myself. RIP Joe. I talked to him twice in the early days of RT. Time to find those emails. RIP.

</comment><comment><USER7> This was a shocker to read. I never really thought of the CEO of RescueTime, but the product that was made truly fit into the mold of "changing lives". I took my habits of random social media visits from 3 hours a day (stuff accumulates terribly), to two planned and focused visits totaling 20 minutes a day.

That over a period of 3 years, is almost 87 days of my life saved. I pay for the product because of all the good it has given me. Feels really sad to see someone who gave me back so much time having to leave so soon. RIP Joe. If anyone from the rescuetime team is reading this, stay strong. Condolences to all of you as well.

<comment><AUTHOR> Thanks so much for sharing that story, and for the condolences. It really does mean a lot.

</comment></comment><comment><USER8> I recently reinstalled RescueTime as I wanted to better track my productivity since I am studying deep learning and soon doing the Udacity self-driving car engineer nanodegree. My condolences to the RescueTime team and Joe's family. Beyond the grave I would like to sincerely thank him for the awesome product he has built.

</comment><comment><USER9> RescueTime is a phenomenal piece of technology, one that helps makers with the hardest problem in art — spending time with your ass in the chair.

If growth necessitates measurement, RescueTime is a hugely important tool in the belt of anyone who hopes to make their contribution to the human race.

This review is maybe slightly tinged by my having just read Pressfield's "War of Art", but I've been using RescueTime for years, and it has helped me celebrate countless victories against Resistance and that has guaranteed them all the more.

Thanks, Joe & co.

</comment><comment><USER10> I have a very heavy heart from this news. Joe's wife was my son's favorite teacher (he still talks about her two years later) and I'd met and spoken with Joe several times socially, though he was quite ill through much of the time I knew him. We had some good "geek out" times when my wife and his chatted (both are teachers so they'd talk teach and we'd talk tech.) They were a wonderful, loving, caring and giving couple, and Joe was just a good soul. You are missed Joe.

</comment><comment><USER11> I've been an on-and-off paid user of RT for several years and it has probably saved me thousands of hours. Since the software is somewhat popular, I think he had a great impact on the world. Thanks to the RT team for this thoughtful announcement.

</comment><comment><USER12> I was not aware of RescueTime or Joe until I read this.

Now I know what it is, it looks like a very good fit for me. Horrid circumstances for me to find out about it, and I don't know what else to say about this.

Family, friends, colleagues: I am sorry for your loss.

</comment><comment><USER13> When we started out with our company, RescueTime was one of our "competitors": more or less the same technology, but different use cases (discovery vs productivity). I would often find Joe having the same issues and posting in the same support tickets are I did.

I have always followed them since and think they actually have a very relevant product in this world of ever increasing interruptions. My condolences.

</comment><comment><USER14> His impact... was immeasurable.

RIP

..now if Apple would only let RT track all our app use..

</comment><comment><USER15> I didn't know Rescue Time was from YC and I've used their product for years.

Sad to hear about this though.

</comment><comment><USER16> Thank you all for such a great showing in these comments. It really cements what kind of person Joe was, and how much he meant to us at RescueTime.

</comment><comment><USER17> Awesome vision, product and person. I started using RescueTime back in '09 and it has helped me immensely over the years. I would say incalculably but I can actually calculate the impact quite well. :)

RIP and best to his family, friends and team.

</comment><comment><USER18> Rescue Time has helped me stay focused on work and to quit doing so much news browsing during business hours. Joe's work has saved a lot of people a lot of hours of their lives, and that's something to be proud of.

</comment><comment><USER19> Even though I never knew Joe, it's sad to hear of his passing. RescueTime is one of the most eye-opening products I've ever used, and has improved my life considerably the last few years.

</comment><comment><USER20> Oh no. I had a few conversations with him years ago when I interviewed there. Super nice guy. My condolences.

</comment><comment><USER21> It is inspiring to read the story of how Joe continued to be involved and lead despite his illness. RIP>

</comment><comment><USER22> RT was innovative, or "innovative enough," when I used it years ago, and it really helped me get a handle on my unfocused internet travels. I hope my freeloading didn't affect his passing. RIP.

</comment><comment><USER23> RIP and condolences to his family, friends and colleagues. RescueTime looks like a product I should've gotten several years ago.

I wish I heard of it earlier from some other news.

</comment><comment><USER24> I'm so sorry to hear this. I was in the same YC batch as Joe and the other RescueTime founders back in 2008. Joe will be sorely missed by all who knew him.

</comment><comment><USER25> RIP -- he seems like a great person.

</comment><comment><USER26> After using numerous productivity apps I keep coming back to rescuetime. Kudos and RIP.

</comment><comment> ryan-allen Poor guy, Rescue Time is a great product and I use it to keep myself honest. RIP.

</comment><comment><USER27> So so sad. I learned a lot from the RT business model while building WakaTime.

</comment><comment><USER28> Thank you Joe for saving me countess hours and from social media addiction. You certainly left a great great legacy and your family should be very proud.

</comment><comment><USER29> RIP I have been using RescueTime for almost 2 yrs now

</comment><comment><USER30> Seems like this would deserve a black bar here on HN

</comment><comment><USER31> RT is a major part of my working environment. From the comments here it's obvious his work has touched many lives. R.I.P.

</comment><comment><USER32> I was just wondering how I could get more productive and just learned about this product via this (odd, eh?)

</comment><comment><USER33> Very sad to hear this news. I have used RescueTime for many years and think it is an excellent service.

</comment><comment><USER34> Not the first time I heard about RT, but just signed up! RIP Joe.

</comment><comment><USER35> RIP

Amazing application and great mission.

</comment><comment><USER36> Really sad to hear. Big fan of his work. RIP.

</comment><comment><USER37> A man who helped us get back our own lives has lost his. RIP good sir.

<comment><USER37> :( why downvote?

</comment></comment><comment><USER38> Deepest condolences :(

</comment><comment><USER39> Rest In Peace Joe.

</comment><comment><USER40> RIP

</comment><comment><USER41> RIP

</comment><comment><USER42> RIP.

</comment><comment><USER43> RIP</comment>