SoylentNews is people
SoylentNews
Having written an IDE, an API, and having gone through the copyright process for software before, I have at least a little understanding the current debate between Google and Oracle. While the general consensus seems to be that Google is right, I disagree. Here are my reasons.
1. There is very poor support for software copyrights at the U.S. Copyright Office. This is true to such an extent that it is practically trade interference. Like or not, the copyright office is almost universally unwilling to review file formats that are aren't developed by Microsoft.
The costs associated with patents are extraordinarily high, and the procedures for using the patent system is so obfuscated that it is meaningless for software. It might be practical to create a filing system for APIs that are separate class of design patent. But the real issue here, is nobody in the USPTO or the the Copyright Office wants to serve the software industry.
API copyrights provides an abbreviated basis for for dealing with the copyright office, and provides an easier mechanism for courts to understand. It is trivial to rename elements of source code in a piece of work and make it appear to not be the same work, though fundamentally it is. Contrary to this APIs must be the same to be useful. This means that distinguishing infringement is easier for them, which makes it easier for me to establish a protectable space for my work.
2. Protocols are underdeveloped. One of the huge arguments made by Google supporters is that API copyright will break protocols. Yes they will. This is a good thing. We should be doing more in protocol development and less in presentation development. It is a simple fact that civil rights in domestic communications is a technically achievable thing that has very little support from the commercial sector. Backwards compatibility has created market pressures that have preserved insecure systems architectures, and that has had a very negative effect on civil rights.
API copyrights will break backwards compatibility. But more importantly, they will preserve the market space of forward compatibility. Which is to say that API copyrights will have a positive effect on mitigating Embrace Extend Extinguish (EEE) business strategies. This is very good for FOSS in particular, and it will be good for the Internet, because it will force a more diverse protocol stack into existence. Sorry IETF, but we are way past the point where there is any excuse for the current state of the TCP/IP Internet.
3. If you are writing clean code, you are writing an API. If you are using Object Orientation correctly, everything you do during the development cycle contributes to the creation of an API. The only exception is the main() loop, which aggregates all of these API calls. Which means (drum roll) if you write clean code in a modern programming language, you are writing protectable code.
The semantic differences that people make over API vs. code are ridiculous. The Copyright Office currently accepts "compendiums" as copyrightable works. An API is a compendium of function calls, sans the underlying functions. But BOTH are copyrightable. There is nothing in an API copyright that prevents you from copyrighting the underlying source code as well. C has always done something similar by separating header and source files. So does your header file deserve less copyright than your source code? Hardly.
All the API copyright does is create a legal namespace that is unique to your project. It is more akin to a trademark than it is copyright or patent. But in any case, there is a need for lawfully protectable namespace in software.
4. It will fragment the software industry. Software engineers are notoriously cantankerous characters. If small software projects and library writing become more protected by copyright, then independent software development will be more profitable.
5. The whole case might be a put-on. Maybe Google is just shouting: "Don't throw me in that briar patch!", to each judge as they pass by. Both of these companies have huge back catalogs of software, all of which would be massively more litigable if Oracle wins. I believe this to be true and regard the variability of the outcome as slight. If they are playing Potemkin village to the highest court in the land, well that is their prerogative. They paid the lawyers to put on the show after all.
YMMV
Anonymous
(Score: 0) by Anonymous Coward on Wednesday November 20 2019, @03:55AM (11 children)
What's a specific example that would be prevented by allowing API patents? I'm still having a hard time trying to convert your generalizations into specific scenarios, real or hypothetical.
(Score: 0) by Anonymous Coward on Wednesday November 20 2019, @03:47PM (10 children)
OK,
You write a spreadsheet. You write an API that allows elements of text to be exported into a database for some reason. That API becomes popular. Vendor X comes along, writes a "silicon valley virgin" copy of your API, and then adds one feature, but breaks some other feature. Vendor X relies on established market share and their now malicious incompatability to appropriate your marketshare. Customers accept this even though the new product is inferior because the bundle appears to be a greater value. Of course it isn't a greater value because there will be add-on charges later. But initially it appears to be cheaper. Vendor X has stolen your I.P. but because it was a copyright, only the fixed copy of the source, (not the API) is protected.
For end users it is a simple commodity sale. But in many cases the "new" feature in the API creates privacy rights problems that consumers don't understand. This is typical EEE.
Under the current system, you have no recourse. With an API copyright, if the portion of the API they copied was substantial, (which it would have to be in order to be accepted into the market at all) then you would have legal recourse.
If API's were copyrightable 20 years ago, WordPerfect would probably still exist. Javascript wouldn't have had half the security problems it has had over the years. There have been dozens of these sorts of thefts in Email systems alone. I think Samba was also EEE'd. In any case a lot of security problems derive from architectures that are intentionally bad, for no other reason but to sabotage competitors. Setting HTML as a default mime-type for email for example. This was criminal negligent, there is no question the vendor in question knew it was criminally negligent, but it was done to EEE competing vendors. This still causes hundreds of thousands of cases of computer trespass annually.
There are things that are wickedly stupid that would happen less if the original authors had more control. An argument against this might be: "Well they will just buy out the original technology". But companies often sell because they have to, not because they want to. Not all owners want to sell, often they do because their current market space is undefendable. But even if they do, it will be after a longer period of development resulting in a more robust and secure framework. (at least sometimes)
If there was less monopoly control over right of way, would there be more diversity in the ISP market? Yes. Same is true for I.P. rights in software. The Copyright Office, by failing to provide that basis of defense, has created abusive monopolies in the software industry by neglect.
(Score: 0) by Anonymous Coward on Wednesday November 20 2019, @04:45PM (9 children)
Spreadsheets are judged by a lot of other factors besides their API's. If your primary selling point of your spreadsheet app is that it "has great API's", you have a business problem. If you could patent them, then you lock out other spreadsheet makers from interfacing with apps that use the API's. Such API users couldn't switch vendors as easily, limiting the power of competition incentives. We want to system to reward the better spreadsheet maker, not the API interface "hogger".
The fact that one of the other vendors may be dodgy is a side issue. We should make the patent laws based on the average case, not the worse case. I will agree that competition can sometimes "go wrong", but anything can sometimes go wrong. Competition in API implementation is OVERALL a good thing. You are overemphasizing the edge cases. Your scenario that sometimes a competitor is slimy is a GENERAL issue with competition, not specific to API's. Those who are slimy with X are probably also slimy with Y and Z and A and B etc. We hope that over the longer term, slime-bags don't have repeat customers and die. If that's not the case, then capitalism in general will fail. (In some cases or services it does fail, but that's a long side issue.)
Those are rather bold claims. I cannot concur. WordPerfect's market failure was not driven by API problems. I watched it unfold in cubicle-land with my own eyes. Do you have a specific step-by-step example of how API IP issues made JavaScript less secure? I'm still not getting enough details to see your generalized claims unfold as examine-able actions to verify they are real and likely.
(Score: 0) by Anonymous Coward on Wednesday November 20 2019, @05:47PM (8 children)
"If you could patent them, then you lock out other spreadsheet makers"
Have you looked at the patent system? Patents are not an easy thing, let alone software patents. This is not something that is really achievable at scale for independent developers.
"slimy is a GENERAL issue with competition, not specific to API's"
OK lets narrow it down. You copyright an API for something akin to an IPSEC framework. You've spent a lot of time and money auditing it and it is, to the best of your knowledge secure. Vendor X. EEE's the protocol and their implementation breaks something so that it is now insecure. (something similar happened to OpenSSL (though it was apparently an accident, rather than malicious) which is why it is now LibreSSL)
There is a financial loss incurred by the developer, and by the public. Defensible API's would assist in litigating over that issue. Or are you willing to say, that intentionally broken code doesn't cause financial loss, and/or shouldn't be defensible?
The copied work is not only stolen, but a public nuisance. How do you defend yourself, and the people who are being abused by perpatrator? This isn't an edge case. I imagine it is repeated in home Wifi security systems by the score at this point.
"Do you have a specific step-by-step example of how API IP issues made JavaScript less secure?"
It has been a very long time since I've used java or javascript. But it didn't get the moniker "write once debug everywhere" because Suns implementation was stable. It got that reputation because Microsofts implementation broke things. Which was about the time I stopped looking at it as a viable tool. It was also about the time when people just gave up on the idea of security when it came to a "virtual machine in a browser". Secure virtualization was the real value of javascript. When that went away because of Sun v. Microsoft javascript stopped being a development tool and became a pestilence on the Internet instead.
If I hunted I could find dozens of workarounds in javascript that cause security problems. But I am not going to do that for you. If you use it, you know they're there, or you ignore them because "la! la! la! I don't hear you!", you are with the "fuck everybody elses privacy but us" crowd.
This is the part where you say: "Because your not willing to audit somebody elses code for a forum post you're an idiot and a dick!".
Okie dokie.
You have a nice day now.
(Score: 0) by Anonymous Coward on Thursday November 21 2019, @04:54AM (7 children)
That doesn't affect my argument that I see.
Let's compare that to light-bulbs. Because the socket is an open standard, any company can make bulbs, including ones that catch fire or explode. Is that a reason NOT to have an open outlet standard?
Proprietary companies can go rogue also. Just because they start out nice doesn't mean they'll stay nice. Thus, probability of rogue-ness between each option is about the same and is not a difference maker between allowing patenting vs. not patenting. Having a monopoly on something doesn't mean you'll be nice with it. Plus, if a monopoly goes rogue you'd have no alternative. When MS's browser sucked too much, people found alternatives. If the patent system prevented alternatives, they'd be high and dry, married to the Bride of Satan Gates.
I believe you are confusing Java and JavaScript. Microsoft never made their own Java compiler. (C# is a rough clone but never intended to be compatible with Java.) Yes, MS's JavaScript did suck, but as I mentioned above, fortunately we have alternatives in FireFox, Chrome, Palemoon, Opera, etc. Your preference would erase these.
(Score: 2) by Zinho on Thursday November 21 2019, @01:20PM (4 children)
Either you're ignorant of history or being intentionally pedantic. Microsoft's Java Virtual machine implementation [wikipedia.org] is a classic example of EEE. From the above-linked Wiki article:
Despite this, I'm on your side; I don't believe that API copyrights are the right solution to this problem. At best, Microsoft would have created a competing software ecosystem that would have even more rapidly and completely eclipsed Java, as they were still blatantly abusing their monopoly market position in exactly that way at the time. We want multiple, competing, 100% compatible implementations of common protocols in place. API copyrights would prevent that, and would result in stagnation and vendor lock-in. No thank you.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 0) by Anonymous Coward on Thursday November 21 2019, @04:40PM (3 children)
Okay, I was ... wr, wr, wrong. But almost nobody used that, that I know of. As I remember it, people habitually used Netscape Navigator to run early applets because MS-IE was behind the curve (in many features). Maybe that "habit" was local to my town, I can't say.
It looks like the lawsuit is about MS's claim that it was "Java 1.1 compliant" when it probably wasn't. Sun owned the name "Java" as a trademark. The suit was about trademark abuse, not directly about API's. Had MS called it something different without any mention of Java, there would be no (legitimate) lawsuit.
https://www.javaworld.com/article/2077055/what-does-sun-s-lawsuit-against-microsoft-mean-for-java-developers-.html [javaworld.com]
Android OS cloners/forkers face a similar issue in that they cannot call it "Android" or "Android compatible" without trademark risk because Google owns the name "Android" (in the context of OS's). Thus, the clones usually just avoid any mention of "Android" and its logo.
But such is really about product names and logos, not API's.
(Score: 2) by Zinho on Thursday November 21 2019, @06:00PM (2 children)
My memory of that period was different. In 1997 IE had, by various counts, [wikipedia.org] between 1/8-1/4 of the browser market and was gaining share rapidly. Claiming built-in Java compatibility and faster Java performance than Netscape was a big part of that rise in popularity.
Re-read the javaworld article you linked: the problem with Microsoft's java implementation was that they omitted several crucial portions of the API in their implementation, added several new methods and fields into the API, and altered the behaviors of others. FTFA:
So, Sun already had legal protections on their API via their licensing agreement with Microsoft. The lawsuit was entirely about abuse of the API by Microsoft in an attempt to gain market share for IE. This abuse, among many others, is what helped IE rise to > 80% market share by the year 2000.
Sun wanted multiple implementations: the licensees competed to see who could build the fastest runtime engine for java bytecode, and we all benefited. Copyright would have been the wrong tool to protect the API, as it would have prevented such widespread implementation. A license, such as the one Sun used and Microsoft violated, was a much better solution.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 0) by Anonymous Coward on Friday November 22 2019, @12:46AM (1 child)
If Sun had full legal control over Java, that's only good as long as Sun is good. Yes, MS may be a "bad cloner" and in that case Sun having more legal control could indeed perhaps dampen MS's embrace-extend-and-extinguish (EEE) efforts. However, it's also possible for Sun to go bad. In fact, Java was sold to Oracle, and Oracle are NOT known for being nice to standards and customers.
Let's run a mini simulation here. Let's say 1/3 of companies are "bad" on average. We'll consider 6 API's/languages.
Scenario A: API's are open (assuming on average there are 3 implementors)
API 1: G,B,G // G=good co., B=bad co.
API 2: G,G,G
API 3: B,G,G
API 4: G,B,G
API 5: B,B,G
API 6: G,G,B
Scenario B: API's are protected IP
API 1: G
API 2: B
API 3: G
API 4: G
API 5: B
API 6: G
Under your scenario, B, API's 2 and 5 are completely held hostage by bad custodians of the API. Orgs dependent on them can't do much.
Under scenario A, almost every API will have at least one non-bad alternative.
Plus under A since the multiple players are competing with each other, there is incentive to be nice to customers, because they can then take business away from the other baddies. Under B, the single custodian may decide to milk locked-in customers to the very end because they want money here and now.
(Score: 2) by Zinho on Friday November 22 2019, @05:38AM
This is the second time in as many days that a soylentil has replied to one of my posts accusing me of supporting a position I never said I favored. I wonder if I'm not communicating clearly this week...
Yes, this is exactly what the result would be of using copyright to protect APIs. And exactly why I think it is a horrible idea. Why, then, is that "my" scenario? Let's look back at what I actually said...
Yeah, I kinda like scenario A a lot better.
And here I predict scenario B as an apocalypse scenario.
I really think we agree with each other, why are we even arguing???
Oh, right, it's because arguing on the internet is fun. ;^)
In that light...
I have no idea what your point is about Sun being good/turning bad/selling to Oracle. Legal protection or no, some of the actors in the world will turn evil and do things that make them money at the expense of the good of their customers and the world at large. That doesn't make copyright (or any other legal protection) for APIs good or bad; the two things are nearly disjoint form each other. Sun had legal protection in the form of a license agreement, and it did them little good when Microsoft gave away a faster, broken runtime engine. Microsoft would have acted the same way with or without the legal protections (insert joke here about 600lbs gorilla sitting wherever it wants).
I guess I should be clear about my position now to avoid any further confusion:
Open protocols, a guaranteed right-to-interoperate, and healthy competition in the market are the best ways to prevent vendor lock-in and bad actors. Copyright on APIs would do the opposite; it would encourage/enforce vendor lock-in and discourage competition. Also, I don't believe [soylentnews.org] it's a legitimate use of Copyright under U.S. law. People should be free to offer their code under whatever terms they prefer, and can choose to enforce that preference via a contract with their customers. How good or bad that is depends entirely on the license and whether the customers are being coerced into a bad license due to the vendor's superior market leverage. If it were up to me all code would be published under the GPL, but it's more important that everyone is free to choose than that I am happy with the state of the world.
I honestly can't tell what part of that position you might have been arguing against in your post. Can you help me out?
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 0) by Anonymous Coward on Thursday November 21 2019, @04:27PM (1 child)
"That doesn't affect my argument that I see."
How unfortunate for you.
"Let's compare that to light-bulbs."
A socket is OSI layer 1. Hell it isn't even networking unless you are using it to send morse code. But the drawing that created the specification for that socket is copyrightable. The socket itself is patentable.
"Is that a reason NOT to have an open outlet standard?"
Actually you are making my point for me. SMB was an open standard. Microsoft EEE'd it, and then it wasn't. The original protocol could have been copylefted, in which case the original author could have sued to preserve the open standard. But because API isn't copyrightable, the original author in possession of the copyleft has no legal recourse.
The ability to legally defend a standard, doesn't make a standard closed. A standard can be licensed under a FOSS, or a formal abandonment of rights could be declared by the author. An API copyright is more akin to a design patent. The difference is that an API is itself a discription (as well as code). It has no need for all the jargon that goes along with the patent process.
I've never argued that the terms lengths provided by copyright are just. They certainly aren't. But there needs to be SOME protection for what an API does. Whether that is through a new classification of patent, or through an API copyright, it doesn't really matter.
From a comparison standpoint API's are much simpler than most things that are patented. Infringement is self evident. An API only has utility if it is uniform. Breaking that uniformity is a common unethical business tactic. The lack of protection available to software developers creates a public hazard.
(Score: 0) by Anonymous Coward on Thursday November 21 2019, @05:10PM
If you wanted to make an open specification, you typically wouldn't copyright/patent it. My point was the fact that we have lots of light-bulb makers and thus choice because the socket standard is open. And some bulb makers do make crappy bulbs. Making the sockets proprietary wouldn't reduce the frequency of bad bulb makers.
(My argument was not really about if bulb sockets should be IP-protected, but about what happens in the bulb market under the open vs. closed socket IP scenarios. If somebody invents a really grand socket that saves money and energy, they may indeed deserve a patent. How that would impact the bulb market depends on the specific details.)
Then it wasn't? Please elaborate. And MS's EEE has often failed. You seem to be saying that open API's are bad because evil companies may EEE them and make them closed or equivalent. But if it starts out closed, then we are already in the hole. It's the Express Tram to proprietary hell instead of the scenic route MS has to take now.
Again, I don't dispute that "things go wrong" with open API's, I just question that they go wrong MORE OFTEN then they would under copyrightable/patent-able API's. It's a matter of frequency and probability. You haven't made a case that it would improve the ratio of good to bad, only that sometimes bad happens with the current system. Compatibility-oriented freedom and open standards have given us many great benefits, even though there are some downsides.
Perhaps you are arguing that the API designer has a "right" to their work, as a universal moral principle, regardless of whether allowing protection is a net benefit to the general economy. If not, then you need to work on the "ratio issue" of your argument.