In the red corner, Big Red, and in the blue corner... the rest of the tech industry Later this spring, the US Supreme Court will hear Google v Oracle. This is the final appeal of a decade-long case in which Oracle claims Google stole the Java application program interface (API) structure that defines how programs interact with Java's own libraries. That Google reproduced the API in Android is not in doubt; …
ack. Back in the day, Benz had a patent on "the automobile" and wouldn't let Ford make cars, at ALL, because they simply refused to license the patent to Ford. So Ford literally CHALLENGED THEIR PATENT and its validity, and WON. Since then, pretty much EVERYONE owns cars, and NOT just "the very rich".
Similarly with APIs and protocols. Using a copyright to STIFLE COMPETITION or determine who can play in the sandbox - this is what it's about.
Problem is, patents were only 10-20 years at best. Copyright might as well be forever with 120+ year durations.
You think the automobile patent was bad? The APIs for punch cards won't go out of copyright until sometime in the 22nd century. If the court decides the wrong way, I'd wager that copyright itself will suddenly be under direct fire from companies with much larger budgets than Disney ever had.
Oh, and it's not a matter of look around 'cause this is where things stay. It's a matter of look back at the 1960s because that's where we're going (but with pervasive government and corporate surveillance of your low tech lives. Yay?). Everything around you that uses any programming language suddenly becomes legally unsafe, and with all new innovation blocked it's going to be downhill for a very long time. Generations, in fact. If this goes the wrong way, the US (and by extension outsourced Asian) tech sector is going to crash so hard it's going to make the recessions and depressions of the 20th century look like blips.
Think of the rest of the world - this is a USA issue.
If Oracle wins, then no one but the USA and a couple treaty partners will be affected.
The rest of the world will benefit from the flood of incoming talent and business to keep doing things the good old way...
If the supremes see this - and I'm sure at least one amicus brief lays it out - then they just need to find a way to make it look like they based their decision on law. There's no way they beggar the US even if it IS the right interpretation - which I firmly believe it isn't, but then ...
Was the individual mandate fine in the unconsitutional ACA a "tax"? The do get pretty far from actual legal matters and into politics - and money talks.
Also, it means the EU and China had better have a path off of Windows yesterday. When this particular brown stuff hits the rotary impeller, it will have interesting effects that could include sudden cessation of support and license activation for Windows 10.
> Think of the rest of the world - this is a USA issue.
No it's not just a USA issue. It affects the entire world.
Because the vast majority of computers and mobile devices in the world run an operating system that was developed in the US, and exposes API's that are copyright some Big US Corporation, Inc.
Do you know who owns the copyright to all the interfaces (API's) in the Standard C Library? What about the interfaces in <unistd.h>?
The SCOTUS ruling won't be confined to Java. It will apply everywhere.
Do you know who owns the copyright to all the interfaces (API's) in the Standard C Library? What about the interfaces in <unistd.h>?
These are now enshrined in formal standards (like ISO C, and POSIX). Standards bodies have some ways to deal with patents (FRAND terms), but I really don't know what would happen if someone suddenly asserted a copyright on every API in a standard.
Hmm, this could even resurrect the infamous SCO lawsuit...
(mushroom cloud, as the effect on the IT industry would be similar...)
This is why engineers need to talk w lawyers about contracts and what not.
And this is why we need to educate people that software is more than coding monkeys.
Look, to make this simple...
The SCOTUS case between Oracle and Google may not extend past this specific ruling. It depends on what ruling is written by SCOTUS. Its complicated because you have a series of courts and lawsuits and counter suits twisted into a decade old case that goes back to Google's refusal to license Java ME at any cost. (Meaning that they rejected FRAND.) Google's clean room attempt wasn't so clean. You'd have to go to Google (irony) or if you have Lexis/Nexus access to go through the lawsuit and the numerous pages of documents involved to find Google's own admissions to this.
To be blunt, this is not a simple lawsuit and goes beyond the issue that many seem to be raising...
<b><i>
If you create a software package/app , and expose a series of APIs so that people write code to interact with your application, does that mean its fair use for a competitor to write a competing application that utilizes your specific APIs?
</i></b>
You would think that this would be a simple case, but there is more to it than that.
There are a lot of issues, including intent, that goes into the case.
Sorry, but there are no winners and those who fear the ruling, regardless of the ruling, need to learn more about the law.
What about the interfaces in <unistd.h>?
Best I can tell (from ten minutes of research, and IANAL), that copyright still belongs to Micro Focus, via Attachmate Group, via Novell. And attempting to charge UNIX vendors copyright fees would probably not be in our best interest.
I think you need to really go back and do some research on this long running battle.
IMHO , SCOTUS will side with Oracle.
I also believe that it won't lead to the panic that the author seems to believe will fall down on us.
Both Oracle and Google are evil corporate giants and Google has trampled more on our digital rights than any other company.
I could say the same to you. The original judge made a well researched an documented ruling. This appellate court has a history of overstepping when it comes to allowing things to be locked up, first with patents and now with copyrights. The supreme court has overturned their overreach before and looks to do so again.
It isn't a matter of evil corporations, or which might be more evil than whom.
"The richest companies in the world are the tech giants - Apple, Google, Microsoft itself - all borne aloft ultimately on open hardware, open software and most critically, open networking."
And Oracle itself. That's the biggest irony of all. Actually the best way of tackling this would be for everyone who has an API Oracle might be using to serve writs to that effect a couple of days before it goes to court.
"Google on the other hand has amassed a formidable set of allies prepared to testify in its favour - Microsoft, IBM, industry associations and hundreds of academics"
...and I very sincerely hope that they prevail in this instance because otherwise the implications for developers are horrendous.
"...and I very sincerely hope that they prevail in this instance because otherwise the implications for developers are horrendous."
At least in Europe the situation is reversed - English law (Copyright Designs and Patents Act) allowed reverse-engineering for compatibility for a long time, and the ECJ ruled similarly in 2012 in a similar case involving SAP (i.e. if the Oracle case were being tried in Europe, Oracle would have lost).
Interoperability in not what you think. It's about the use of a non-published API, not the cloning of a whole product. You don't even need to clone the API with wholly identical names - you just need to ensure the ABI is correct. So Samba may use the SMB protocol even before it was fully published, but doesn't need to replicate the identical Windows APIs.
But of course you user would need to adapt their code to use it - Google wanted a direct replacement of Java to save costs and get Android apps quickly - libraries and compilers would have not worked with different names.
It has nothing to do with published vs. non-published. There are many levels of interoperability. In this case Google was trying to for interoperability with the Java language.
In the Samba case, some of the API would need to be replicated. All SMB compliant code would have to use the same data structures and the same keywords. What language you used to create/call those structures could be different.
The Google case is more like someone creating a compatible compiler. The Sun(Oracle), IBM, Apache, OpenJDK, and to a great extent Google have to re-implement the Java API in order to process Java source code. Using a different API would mean that it wouldn't be able to compile Java source code. Which is the whole point of the exercise.
You wrote; "But of course you user would need to adapt their code to use it..." In that you admit that if Google didn't do what they did, the result wouldn't have been interoperable. The whole point of interoperability is that the developer doesn't have to re-write their software to run on a different system, or to learn a new language to write it in. Programs written in PC-DOS ran just fine under MS-DOS. This isn't possible if PC-DOS didn't re-impliment the MS-DOS API.
...Stay for the digs at Orlowski.
The article puts the entire case very succinctly, regardless of how much Oracle are determined to extract money from Google, copywriting APIs will benefit absolutely nobody, even Oracle themselves. It would be like way back when before electrical plugs were standardised and each town would have different wall sockets depending on who supplied their electricity. Except worse, in that you couldn't just buy a device and change the plug to match what your home was equipped with.
Orlowski's issue was never with the case at hand though, it was just another way for him to grind his axe against Google. While I intensely dislike Google and their business methods, I'm able to see beyond my personal feelings to judge each individual matter on its own merits.
I sometimes think of trolling Orlowski by sending him a picture of Stephen Fry googling his own entry on Wikipedia.
"copywriting APIs will benefit absolutely nobody, even Oracle themselves"
Long term, yes.
Short term, Oracle claim copyright over Android and claim very significant damages against Google, possibly to the point of destroying Google or breaking it up and making Oracle very rich.
Day n+1 when the world is burning doesn't worry Oracle. Yet.
And the author didn't developed a wholly DOS clone (which is what people still accuse DOS of being of CP/M - so after all Bill was right to clone it then? It was all about freedom, after all?). but just something alike a driver. Still, DOS was more an ABI than an API - put some values into some registers, INT21! With 8 registers , some dedicated, the combination were quite few. Google wanted its own fully controlled implementation of Java - yet still able to exploit all the available tools to hasten Android adoption, with no need to implement them itself - that's not innovation, that's exploitation.
Today expect any successful server-side application be cloned immediately by all the big cloud providers and the original developer won't see a dime after it. They can also kill any library they may have to pay licenses for replicating its API. They won't even need to buy the company to get the IP. That's why they are all so much interested a small player can't block them using copyright. And while an API has to be published, so it's easy to look at it and see if it is a copy, good luck at asking for the non public code and see if they copied it too....
You all believe it will make the world more free - instead if will just put it in the hands of a few Molochs that have enormous resources to crush everybody else. Even more simple with open source, for the project, make a few changes that lock users in, make the service available... and f*****f all the developers without those resources.
Google was advised by its own people it should have licensed the API, it just decided it was too big to be constrained by anything. So let's say it it's right, it's big enough to be above the law, any law....
In a few years you all will see the effect, and unless you work for Goggle & C. - you will not like them.
Sorry to see you are still demonstrating your confusion between API's and source code from your posts on other articles on the same subject.
If the big cloud providers want to replicate the API by writing all their own source code more power to them. To do otherwise would be for nothing to be able to communicate with anything else. You won't be able to move your software from one operating system to another (no more compatible software without a costly re-write assuming you would even be allowed to do so). You wouldn't be able to get your data from one format to another (document formats are also an API). Want a different compiler or IDE for a computer language? Sorry, you can no longer re-implement the API in your world.
Google toyed with the idea of licensing Java ME, but it wasn't useful, they wanted to modify Java SE and Sun insisted that only Java ME could be used on mobile devices. So Google did what any self respecting software house did, they looked at the current resources available (like the Apache licensed Harmony project, and the fact that API's weren't covered by copyright) and set out to re-implement the language to suit their needs. Sun management was aware and even publicly encouraging of the effort, believing it would get more people interested in writing in Java. It wasn't until Oracle bought out Sun that this rediculous interpretation, and resulting lawsuit, came to be.
To any who have been around more than five minutes, it is obvious that a set of very large corporations have the power and the personnel and the lawyers to tie up any but the largest other corporations in such a way that they will be bankrupted. That is the way that our courts often work on the civil side. Unless there are criminal penalties for their actions, they can laugh off efforts to deflect or punish them. As long as corporations are treated as people with all the rights of individuals, we cannot win out against them.
If Google wins, we will have access to API's, but we will still be vulnerable to Google's knowledge about all of us. If Oracle wins, then any corporation that has an API can successfully sue any who use that API.
And the statement that an API is a protocol is such a simplistic definition that it may exclude many API's A protocol is all the elements that are needed to complete a conversation between two programs. It may require many API's or the two programs may discover a way to communicate by challenge and response. Of course, that requires some common set of API's for the challenge and response. for such a common standard to be reliable, it must be declared as public domain or under a license such as gnu that effectively makes it free for public use.
The C standard libraries are now defined as a part of an international standard (the same one that defines the language); there is a long-standing convention that no-one can claim ownership of them (although if anyone had a claim, I suspect K&R would be at the front of the queue).
What I'd like to know is what external libraries/APIs does Oracle use in any of their products!
Interesting. Yes the Java API that Oracle is claiming copyright ownership of, does indeed copy names and ideas from other places, including the C standard libraries.
I'm pretty sure I first encountered the C "index" function for finding a character in a string in 1985 in K&R (https://en.wikipedia.org/wiki/The_C_Programming_Language). I always thought it was poorly named. Java's version (called indexOf) is here: https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#indexOf-int- and works in exactly the same way - returning -1 if the character is not found.
The irony, of course, is that open computing has produced the most fevered upsurge in new technology since the Industrial Revolution.
When I was using a Netware LAN (that rather date it!) I was asked to come up with a way to determine what logical disks were local and which were on a network drive by the primary applications team (I was known as a programmer with an emphasis on low level structures and hardware).
That feature was part of the Undocumented internals of DOS. That book (and articles from numerous magazines of the day) helped me enormously as it documented the List of Lists (a veritable treasure trove of internal information) where the type of storage (local or remote) could be determined, among other things.
If what Oracle wants is granted, that book might never have been published (and many useful programs would never have been written).
It was the determination of those who wanted to understand the entire system (and therefore could control it in ways Microsoft did not want) that opened up programming in a way that enabled huge amounts of application software to be developed effectively.
Undocumented Internals was superb.
And don't forget Ralf Brown's Interrupt List. https://en.wikipedia.org/wiki/Ralf_Brown%27s_Interrupt_List
A treasure trove of information, much of it about what other programs were doing - helpful in ensuring anything you were writing wouldn't conflict (too badly) with anything else.
Or so that you could do things like send commands to disk cache TSRs, and so forth...
Undocumented internals of DOS
I remember having (and using) that book in the early/mid 1990s - I wrote a little program to enumerate all the LAN Server print servers and trawl their shared drives for anything interesting..
I ended up having to run it overnight because it had a tendency to somewhat flood my local 4mb token-ring segment. But I did discover quite a bit of 'interesting' graphics and applications that people were clandestinely sharing..
(Mind you, this being the era of CGA / EGA graphics there wasn't anything too... graphic.)
"we had a disassembler" ... iirc everyone with an early PC had a disassembler it was 'built in', which I think is how Peter Norton was able to rapidly bring out his invaluable PC-DOS Users' Guide (with the disassembled DOS/BASIC bios source code in the Appendix).
I had thought the case was that Google hadn't just re-implemented the APIs but in part had copied some of the Oracle code to give them a foot up. Headers I think, but it might be other stuff. Anyway, not a clean room re-implementation. Or did I just imagine that. It's been going on a while...
That's how Oracle tries to muddy the water ...
Oracle basically claims that the hard thought-out and innovative names of functions and parameters, aka "the API" were copied/stolen by Google.
They never claimed the implementation itself was copied/stolen - but they sure as hell make it sound like that to the judges.
I agree with you here, to an extent. The implementation code definitely not. The API (function declarations and necessary structures for example) yes, the difficulty is then separating what is API from what is implementation. In C traditionally that would mean the header files (since it's where interface declarations live), but wouldn't cover things like documentation comments in those files. (Or C++ template monstrosities that stick template based code in there.)
On stuff that there's no copyright protection I don't think it matters that you copied it, this means that things like whitespace that might show it was directly copied don't carry any weight. It doesn't matter if I write:
int printf(const char *format, ...);
or
int printf(const char* format, ...);
But if this portion is not copyrightable then the original version isn't protected. (This is the converse of the argument that if it was copyrightable then the trivial change to "int printf(const char* format, ...);" wouldn't be enough to protect me.)
That's called Re-Implementing the API.
If:
APIs are not copyrightable,
Then:
you can just copy and paste the code*.
That's what not copyrightable means.
*In this case code means the structure, names, function signatures, etc. Google wrote the source code themselves (or copied the Apache licensed Harmony code). Don't confuse API and source code with your loose use of the term "code". That's Oracle trying to muddy the waters.
"*In this case code means the structure, names, function signatures, etc. Google wrote the source code themselves (or copied the Apache licensed Harmony code). Don't confuse API and source code with your loose use of the term "code". That's Oracle trying to muddy the waters."
I thought they did copy the source code. If that's not the case, then sure. I tried to dig out the original complaint on the Register and find out exactly what was (allegedly) copied, but I cannot find it easily.
Nope. Excepting for a couple of security files and a rangeCheck() function, which were accidentally copied by Google, all of the source code that implemented the API was in there legally. A large amount was Apache licensed Java source from the Harmony project. Some was written by Google's developers in house. Whether or not it was a copyright violation or covered under Fair Use is a separate question.
To a non-developer, a printed out API looks indistinguishable from source code. As the joke goes; "It's all geek to me." Oracle, and the appellate court, would have you believe that an API is source code for any of their arguments to make sense.
The judge of the original case was fortunate enough to be able to write code himself, admittedly simple programs ( https://www.theverge.com/2017/10/19/16503076/oracle-vs-google-judge-william-alsup-interview-waymo-uber ). Here is a link to the original ruling ( https://www.eff.org/files/alsup_api_ruling.pdf ) it's clear and well written.
From pages 40-41 of the original ruling the judge wrote:
"In closing, it is important to step back and take in the breadth of Oracle’s claim. Of the 166 Java packages, 129 were not violated in any way. Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines. Oracle must resort, therefore, to claiming that it owns, by copyright, the exclusive right to any and all possible implementations of the taxonomy-like command structure for the 166 packages and/or any subpart thereof — even though it copyrighted only one implementation [emphasis mine]. To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition."
I hope that help clear things up.
I tried to dig out the original complaint on the Register and find out exactly what was (allegedly) copied, but I cannot find it easily.Reading the original complaint wouldn't help you much, as the copying of APIs was just one claim of many in the complex original complaint. There were many other elements, including as previously mentioned copying of the rangecheck() function. You'd have to follow along the whole history to see what has and has not been excluded and resolved outside this appeal. Or get a summary from somewhere ;)
This appeal is not about the entire original complaint, it is about the only claim still surviving in that complaint, copying APIs.
The original complaint is way out of date - the legal battle has changed over the many years it's been running. Various claims have changed, or been thrown out.
I recommend reading the latest appeals court ruling: https://regmedia.co.uk/2018/03/29/oracle_v_google_opinion.pdf
The original is here: https://regmedia.co.uk/2010/08/13/oracle_complaint_against_google.pdf
C.
IIRC, Android was developed by a San Francisco company when there was still a Sun Microsystems to sue a Microsoft that insisted on Microsoft-only extensions to Java. Then the original Android got bought by Google, followed a few years later by Oracle buying Sun Microsystems.
Sun Microsystems never raised an eyebrow over this original Android company developing their Java UI OS extension to Linux. The impression I get from the Sun suit against Microsoft, was that anyone could re-implement Java if they wanted to, they just had to make it fully compatible with Sun's Own Java Definition.
It sounds like Oracle are swimming against an already strong legal current in the form of the precedent already set by the Sun-vs-Microsoft lawsuit. Ellison must love the taste of his own toes.
I'm not going mad. From wikipedia, not my favorite source, but concise. From the second appeals court judgement.
"It It is undisputed that Google copied verbatim the declaring code of the 37 Java API packages 11,500 lines of Oracle’s copyrighted code. It also copied the SSO of the Java API packages. It is also established Google recognizes that the software copied is creative and original."
It's judgment was also that fair use was not proven. The reuse was not transformative as it was used for the same purpose. Nor was it minimal as only a small amount of the copied code was needed for the re-implementation. It was not for interoperability as no effort had been made to permit this. Finally, the second transformative test was failed as Android affected Oracles market by being given away.
Don't get me wrong. I have no love for Oracle (see some of my other posts) but lets look at the case and not leap to doomsday conclusions about the death of software and open source projects.
I just wish the Supremos could just rule against both sides as this is just a pissing contest.
You might want to go back to the link I provided in an earlier response to the original ruling. It's well thought out. This appellate court, which has never seen anything that it didn't think shouldn't be patented/copyrighted the law be dammed, in a first, decided that API's and source code were the same thing. Since you can copyright source code you can copyright APIs. From there it overturned the original ruling and because the fair use question didn't need to be addressed in the original trial sent it back down for a ruling on that part.
The lower court then ruled, that if APIs were subject to copyright, then what Google did was the quintessential fair use of that API. Oracle appealed again to the same court and this time, completely misunderstanding what Google was trying to achieve, overturned the lower court again. The appellate court ruled that because Google could have used a different API (say, C, or Python, or FORTRAN, etc.) they didn't have to copy the existing Java API. Of course then it wouldn't have been interoperable. This just goes to show that the appellate court had no idea what interoperability means.
After the first ruling the supreme court decided not to jump into the matter, probably hoping that if it was ruled that interoperability was fair use of an API, it wouldn't cause too much damage and they could stay out if things. Unfortunately for Oracle, and perhaps fortunately for Google and the rest of us, the appellate court couldn't resist trying to impose their maximalist view of intellectual property forcing the supreme court's hand.
I hope that helps clear things up a bit.
Not sure I'd have said that TCP/IP was barely three years old in 1987. Its widespread, standardised use might have only been 3-4 years old, but it was invented in the mid 70s (74? 75?), several prototype implementations were developed in numerous places during the late 70s and early 80s, the US DOD declared it the standard for all military networking in 1982 and the migration of ARPANET to TCP/IP was completed by January 1983.
Anyway, that's a minor quibble. In all other respects, the article is bang on the money. Hopefully, Oracle will get shown the door in no uncertain terms on this one. Although, this is the USA we're talking about where corporate money appears to be king. Who knows how it will actually play out.
but it was invented in the mid 70s (74? 75?)
Yeah - but outside ARPANET (and possibly early versions of JANET) it wasn't really used. One of my first projects after I cheerfully gave up trying to pretend to be a programmer was to implement a TCP/IP stack on DOS 5/Windows 3. That would have been somewhere around 1995-96.
(I seem to recall I settled on Chameleon TCP/IP and then had to go through the faff of getting it to bind along with all the token-ring and netbios drivers..)
outside ARPANET (and possibly early versions of JANET) it wasn't really used
I don't believe that's true. While other protocol families such as DecNET, SNA, and XNS were also still common at the time, even in the first half of the '80s TCP/IP had a significant share of local networks and small-i internets in academia and some businesses. The CMU/IBM Andrew Project was always TCP/IP-based, for example, and it started in 1982. The same was true of MIT/DEC/IBM's Project Athena, which started in 1983. I think BSD 4.1a with TCP/IP came out in '82.
For the big-I Internet, besides ARPANET there was CSNET (routing TCP/IP over X.25, starting in 1981), NSFNET (1986), and others.
Wikipedia says JANET (an X.25 network) didn't start routing IP traffic until the 1990s. BITNET, a prominent US academic network, and IBM's VNET (the largest internet in the world until it was surpassed by the TCP/IP Internet sometime in the '80s) ran on RSCS, a pre-SNA IBM protocol. RSCS was a store-and-forward protocol somewhat like UUCP.
In 1987 IP was 7 years old: IEN123, published December 1979. TCP was 12 years old: RFC675, published December 1974.
As you noted, the TCP/IP Internet was 4 years old, since ARPANET Flag Day was 1 January 1983.
I don't know where "TCP/IP barely three years old" came from, but it's wrong any way you look at it.
The earliest TCP/IP implementations for MS-DOS seem to have been PC-IP (1984, though portions were available as early as 1982) and KA9Q (1985).
Maybe someone ought to get together the copyright owners for BSD sockets, the unix ioctrl interface, oh, and the POSIX read and write interfaces (actually, ioctrl is POSIX too isn't it?), and hold Oracle to ransom - if they choose to peruse and win the case then stop them using other people's APIs
See how far they get without the ability to use just the above handful of APIs, never mind anything else that one might add to the list
If this case goes Oracle's way then the industry will inevitably focus on using interfaces and APIs that are copyright by owners that can be trusted to own them in a fair and non-prejudicial manner.
So SOAP and REST for example, being W3C copyright, will be safe as a core standard/technology. Industry specific mark-ups layered on top will be evaluated based on the reputation of the industry body behind each one. Those proposed by individual companies will be treated cautiously or will require contractual guarantees; those owned by industry bodies will be more readily accepted.
As another example, EDIFACT is UN defined so won't be affected.
This doesn't mean to say that an Oracle win won't be a big step backward - just that the world won't completely stop turning.
Clearly you haven't paid attention to the current status of our own culture. Fair and non-prejudicial basically doesn't exist when copyright comes into play -- about the closest anyone has come is some of the open source licenses, and those don't make anyone any money on direct licensing of the copyrighted work itself.
The entire movie industry (which is a good model for the theoretical value of copyrighted APIs) has zero concept of anything that even so much as looks fair in terms of licensing. They've figured out how to give you the worst and most restrictive deal possible (streaming only, DRMed, pay per view) on content that for the most part they've stolen from other people (cultural theft seems to be all the rage right now, for instance why isn't Disney paying the Sami or Viking descendants royalties for their mythology?), and they understand the monopoly they have and as a result literally won't offer anything else such as permanent, non-expiring sale of a copy of the work.
Why do you think that software would be any different?
> Clearly you haven't paid attention to the current status of our own culture. Fair and non-prejudicial basically doesn't exist when copyright comes into play
The film industry might not be the best example. The 'rights' you get when hiring a DVD or watching a film are indeed minimal but that is because of the particular nature of the film industry: namely that bypassing the studio and making your own film is extremely expensive, rather impractical and won't give the same result. Therefore you have no real choice other than to put up with what you get.
Making your own software API is not nearly so impractical. In fact, the worst outcome if Oracle win is that there may well be a proliferation of alternate APIs for the same job: so exchanging sales orders with one supplier may require different APIs to exchanging the same info with a different supplier. (Except that's not a good example because there are open standards already - but you can see what I mean, I hope.)
"for instance why isn't Disney paying the Sami or Viking descendants royalties for their mythology?"
Probably because they're TOO OLD and have passed the copyright Statute of Limitations. Last I checked, the works of Hans Christian Andersen, Rudyard Kipling, and a number of others also fall outside of copyright due to age.
I'm entirely OK with the idea that a header file is a factual description of a library (etc.) which is otherwise opaque. The function names are a statement of fact, the types- in conjunction with documented compiler behaviour- are a statement of fact, and the order and type of parameters are a statement of fact. The names of function parameters are not necessarily a statement of fact, but can be changed without altering the API.
What I'm rather less OK with is when a header file contains macros, which are themselves functional and as such are not a simple statement of fact. In my opinion complex macros have no place in published header files, since they blur the distinction between the purely factual definition and the implementation detail.
MarkMLl
Just to reverse the lens, I worked on an application which used a database. It was made crystal clear in the licensing that the only approved way to access the database was via calls to the application which was licensed on a per seat basis.
One clever customer decided the rules didn't apply to them and quickly worked out we were using access under the covers so tapped into the database.
The problem was the actual database structure was very code-defined, so never stayed the same.
One day (I imaging most Regtards are way ahead here) there was a very pissed off call to our sales team, as the new release of our app had "broken" their ERP system. Of course the reality was we had changed the code, structure, and nothing was broken.
This was the 1990s when the level of entitlement people felt to openly pirate software was probably at it's peak.
Not entirely sure that "not using software as intended" equals "piracy". In fact, I'm fairly sure those attempts to add onerous legal restrictions on what was purchased (versus technical or process limitations, which seem to be what are described here) are what drive a lot of "piracy" today.
Of course, if the reason this backend access was used was to skirt simultaneous connection licensing costs, then naturally that's different. But if going after the backend for legitimate reasons is in and of itself is considered "piracy", all that does is weaken the moral case for strong copyright and drive people to real piracy.
Sigh,
I tried to be as clear as I could.
The client didn't like the idea of paying for another copy of the software which would have been needed to interface with their ERP system. So they decided to hack into the database. We explicitly provided no support for such action. So when we changed the database and "broke" their ERP it cost them a hell of a lot more than just another licence as they had to pay us consultancy to deliver the interface in a supported form. (Because it had to be done quickly).
Anyway, that was always the danger of using an undocumented API. They also tend to be unsupported. Even if the authors use them, they could change them on a whim.
No, you were not clear. You implied they used undocumented APIs (for example, Apple/MS do this in their OS, purely for the power trips of "I have this nice toy, you don't). Then you implied other people/some people pirate software. You never mentioned if that customer was circumventing additional software purchases.
And IMO you should have put that extra API/software in the other purchase, and not tried to "hide" it in the existing one, if the customer only paid for one not the other. However, leaving the customer to their own mess is also another solution. But similar to the spike on the steering wheel.
It might be wrong for someone to steal my intellectual property, but not really right for me to hurt them back in retaliation! (Though I see the "error" was not intentional, so you did not use that kind of retaliation)
> No, you were not clear.
It seemed clear enough to me: buyers of the software were told to use the API because that was the supported access mechanism. Buyers were expressly told not to access the underying database directly.
This one client chose to ignore those instructions and were caught out when the underpinnings they were relying on changed. The API did not change and was still supported.
The fact that they chose not to use the API in order to avoid a licence cost was their choice.
Was the licence charge justified? Well that's a completely different question.
I had the IBM-PC bible with full firmware listings in assembler and circuit diagrams, so all could be copied without infringing on copyright. All clone hardware had equivalent gating for the same functionality or enhanced to extend capabilities. Debugging anyone's prom bios uncovered equivalent code. My clone-pc came with a rom bios in sockets and a separate set of proms which were IBM. Debug was my disassembler of choice.
I'm afraid having the schematics and code listings in assembly has nothing to do with being able to copy without infringing copyright. Just as having a book to read doesn't mean you can start making copies of the book.
But the important thing was that IBM didn't try to enforce copyright on the interfaces so you could re-implement the same functionality and retain compatibility.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
