<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 10, 2016 at 7:41 PM, Roberto C. Sánchez <span dir="ltr"><<a href="mailto:roberto@connexer.com" target="_blank">roberto@connexer.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Except that by that logic, it would be illegal for me to develop, for<br>
example, a valve cover gasket for GM trucks and then sell it (assuming<br>
the design was not some publically available licensed design).</div></blockquote></div><br>IANAL and this is not legal advice, but... It would seem to be more like you developed said gasket and then called it exactly whatever GM called it (down to the part number), printed an installation manual for it that was verbatim the copyright'd GM manual, packaged it in a box printed with the same GM-copyright'd instructions as were on the GM box, included a part drawing that was identical to the copyright'd GM part drawing, and included preventative-maintenance instructions that were verbatim the copyright'd GM maintenance instructions for their part.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The issue appears not to be that Google used the API or even (as I'd mistakenly thought) that they implemented the API; it appears to be that they copied all of the header files verbatim (some 7000 lines of code). To the casual observer (say, a Federal judge), that sounds an awful lot like a copyright violation. See <a href="http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF" target="_blank">http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">I would bet that Google just has to go back and do what the Appeals Court says ("Second..." at the bottom of page 36 and the point on pages 44-45) that they failed to do: assert/prove that the [use of the] API(s) is so commonplace that there can be no other way to express it (than the well-known names of the classes, members, etc.).</div><div class="gmail_extra"><br></div><div class="gmail_extra">It looks like they also need to go and remove the bullet from their foot (page 50-51), where they said that they weren't trying to implement a JVM but wanted instead to use the API for some another purpose -- implementing Android (and thus confusing the court as to why the API was more general than the JVM -- that the API is more like part of the Java language than it is part of a JVM or Android).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyway, that's my 2 cents.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Jeff</div><div class="gmail_extra"><br></div><div class="gmail_extra">P.S. I wonder if this explains why the variable names of the parameters (and implementation hierarchy of implicitly included files) used in the same functions that are part of sections 2/3 of Unix/Linux vary all over the place in the header files and man pages across different Unix API implementations. AT&T/Bell Labs had one way, UCB had another, Sun had another, IEEE/POSIX had another, Linus had another, ... Maybe if Google had done a bit of rewrite of the header files (e.g., use different parameter names, change up the order that member functions appear in the class definitions, etc.), there wouldn't have been an argument to be made?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>