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
Related Stories
Arthur T Knackerbracket has found the following story:
More than a decade ago, Google re-implemented the Java programming language as part of its new Android mobile operating system. Oracle, the owner of Java, then sued Google for copyright infringement in 2010. Later this month, the Supreme Court will hear oral arguments in this epic copyright case that will have huge implications for the entire software industry—and that could cost Google billions of dollars.
Google says it has done nothing wrong. Copyright law specifically excludes "systems" and "methods of operation" from copyright protection. Google argues that the aspects of Java it copied—function names, argument types, and so forth—fit squarely into these exceptions. Google also argues that copyright's fair use doctrine allows for this kind of copying.
The case is being closely watched by the software industry. Companies like Microsoft and IBM have warned that Oracle's stance could create chaos for the industry. They argue that making this kind of copying illegal would not only create legal headaches for a lot of software companies—it would be bad for customers, too.
Software companies copy software interfaces—known in industry jargon as application programming interfaces (APIs)—of their competitors' products all the time. This allows competing software products to be interoperable so that a customer can take software designed to work on one platform and re-use it on another. That means lower switching costs for customers. It also means lower barriers for entry for software startups, since it's easier to sell a new product if it's compatible with a software product that customers already know and trust.
If anyone should understand the importance of such copying, it's Oracle. After all, Oracle got its start in the 1970s selling a database product based on the then-new structured query language (SQL). SQL was invented by IBM. And Oracle doesn't seem to have gotten a license to use it.
If Oracle wins its legal battle, one ironic result will be to make the software industry less hospitable to future startups like Oracle. Incumbent software companies would have a greater ability to lock customers into their own proprietary standards. Startups wouldn't be allowed to do what Oracle did four decades ago: make its product compatible with an established competitor, then make that interoperability a selling point.
[...]Despite the lack of a licensing deal, Sun CEO Jonathan Schwartz was enthusiastic when Google ultimately announced that Android would be based on Java.
(Score: 5, Informative) by EJ on Tuesday November 19 2019, @03:16AM (4 children)
You're wrong.
(Score: 3, Redundant) by aristarchus on Tuesday November 19 2019, @09:21AM
Without doubt the best frist piste ever! Bravo, EJ!
(Score: -1, Troll) by Anonymous Coward on Tuesday November 19 2019, @03:07PM (2 children)
How does this get a +5 informative.
(Score: 3, Insightful) by tangomargarine on Tuesday November 19 2019, @04:23PM
Probably because people have already modded several other posts saying "No, you're categorically, point-by-point wrong" up and still have mod points left over they want to express
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 4, Insightful) by PartTimeZombie on Wednesday November 20 2019, @12:30AM
Because EJ is correct and the author is wrong.
(Score: 5, Informative) by Kymation on Tuesday November 19 2019, @03:20AM (9 children)
Every bit of code that has ever been written follows the rules of mathematical logic. That's why every modern language has the same basic functionality: it's merely expressing the rules of mathematics in a usable form.
Mathematics has never been copyrightable and never should be. Therefore, all computer software should be free of copyright restrictions. Make everything free for others to use and build on. The software will be a lot better for it.
Worried about making money out of software? Don't, there will still be plenty of people willing to pay you to customize some code for them.
Discuss.
(Score: 3, Insightful) by FatPhil on Tuesday November 19 2019, @08:41AM (1 child)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by c0lo on Tuesday November 19 2019, @11:09AM
As any law/legal system is. And TFA(uthor) tries to make an appeal to laws. No wonder it traps people unable or unwilling to look at the problem from a vantage point beyond laws.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by ledow on Tuesday November 19 2019, @09:09AM (2 children)
I'm a mathematician and a computer scientist.
You're wrong.
The facts of maths may well be protected, but copyright is about expression. If I write a maths book, you can't just copy it word for word and sell it or give it away. Same for a computer program. Everyone can write an A* algorithm but YOUR A* algorithm is under your copyright as an expression of your own.
Nobody is trying to "copyright" 2+2. You can't. It would be thrown out as a nonsense. But if you write a 3rd-year university textbook about the deep internals of calculus, or a piece of software that calculates flightpaths, you have to protect that in some fashion. Failing to do so means that nobody bothers to try to find new things, because they can't make a living doing so. Universities hire lecturers and professors because they create content that the university can sell, be that books, papers or just sheer knowledge in a lecture format. Without that, they wouldn't bother - universities would become nothing more than closed off, secretive research-labs that wouldn't want to tell you a thing about anything they discovered because you'd just "steal" it.
As a result, most of the lecturers and professors would run a mile for a country that protects their income and their organisations and their rights. There's a reason that universities tend to be the bastions of things like copyright law and open-source licensing enforcement.
Though I hold close to view that are considered socialist/communist in some respects, it's really more than I believe in a utopia where we could just do this - where taxes would pay for people to do research which would be open to all and everyone benefited from every discovery automatically. It ain't gonna happen in a human society, at least for a very, very, long time. Governments themselves are money-driven and greedy, enough to make education a pay-for exercise nowadays.
Fact is that the current system actually tends to work - imagine spending your life writing your first novel only to have it cloned and distributed worldwide in seconds, with your name stripped off, and you get nothing for it except "having written a book" that you can't prove and nobody else believes. Copyright is there for a reason. It's often abused, but that just means it needs tweaking (e.g. ridiculous copyright terms until things fall into the public domain).
But, in this case, copyright boundaries happen to be about right. Your expression of a task is copyrightable. But the interface that you are conforming to for that task, which is a largely arbitrary decision of very limited scope, is not. That lets people build on your software, replace your software, improve your software, but not steal your software.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @12:30PM
you cannot copyright digital media.
as a scientist you know that a computer onky wirks because it processes data and to do that it needs to make (internal) copies. it is a copy machine.
next: one should not be able to copyright data/information that helps humans understand the world better and thus make humans happier.
we are thus left with stuff that is basically useless data (knowing or not knowing it doesnt contribute to your overall wellbeing) that can be copyrighted out the wazzo and back again (and only if it is not reliant on a digital data processing device -aka- computer).
that's my opinion only.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @12:38PM
Who owns the copyright of 'hello world'? In every language there are just so many ways to write it (sure there are countless ways to obfuscate/make it your own but using the most basic cout or printf in main, there's not that many)
(Score: 4, Insightful) by theluggage on Tuesday November 19 2019, @02:04PM
Everything is mathematics - for a given definition of "mathematics", "everything" and "is". "Software is Mathematics" is, at best, a non-falsifiable claim: Ask N mathematicians to define mathematics and you'll get e^(iN) definitions.
You can turn an image of Mickey Mouse into the mathematical description of a bunch of ellipses (and he was actually designed that way - c.f. a tiny proportion of software being designed mathematically) - now, there are plenty of reasons why Mickey shouldn't still be under copyright, but "being mathematics"
There's also a big difference between "software" and individual snippets of code that implement well-mathematically-defined functions (I'm going to use "algorithms" to describe that henceforth) or, if you prefer, "TeX" vs. "Quicksort"). Any substantial piece of software combines a whole bunch of algorithms combined in a unique way, combined with a ton of creativity (e.g. with the TeX example, a metric shitload of insight and research into the practicalities and aesthetics of typesetting). Even describing, say, JPEG compression as "do a discrete cosine transform and just keep the firstN coefficients" leaves out a lot of vital detail (see what I did there? :-)) on how you practically apply that to an image in order to avoid humans spotting the artefacts.
Even mathematical "formal methods" (used to create a vanishingly small subset of software) just shift the "uniqueness" from the code to the specification.
Genuine question - was the "mathematics exemption" in Copyright/Patent law added before or after the work of Russel, Godel, Turing et. al. really made logic and algorithms part of mathematics? Pretty easy to argue in court that Benjamin Franklin wouldn't have seen a sorting algorithm as mathematics.
NB: TFA is still bullshit doublethink - I'm not supporting the idea of software copyright in its current form - but the "Software as mathematics" argument has already failed in patent law by being (a) too academically debatable and (b) having potential effects far beyond software (the EU just ended up with the "computer implemented invention" bullshit as a result). No sense in wasting time and effort on a weak, ineffectual argument when there are already other, more specific clauses that should eliminate software being ignored. If you can't get a consensus via valid debate then the argument won't stand a snowflake in hell's chance against the sort of FUD and Chewbacca defenses that Big IP will mount.
Arguments based on abstract principles like "software is mathematics" just reinforce the notion that there is some natural, moral justice behind IP that can be defined. There was never natural justice behind patents, and copyright is reaching far beyond any natural justice it might have had. Copyrights/Patents exist because they claim to have practical benefits for science/art/industry. There is plenty of evidence that patents and the current implementation of copyright have the opposite effect on software. Those are the arguments that should be advanced. "Software=mathematics" is just grabbing the tar baby.
If TFA has any valid point it is that the current application of copyright to software is a kludge. Personally, I think the "information should be free" principle is a nice ideal if you have tenure (the 'lots of work customising code' argument might work in some niches, but is unlikely to pay for the initial code - plus, selling code paid for my house, so I can't protest too much) so we need something that allows people to make a reasonable profit from their work for a reasonable time - so really copyright and/or patents need to be fixed to explicitly cover (or not) software with appropriate quid-pro-quos. Not holding my breath, since any new law would probably be dictated by Big IP. However, its worth remembering that pretty much all Open Source licenses currently rely on copyright law to back up their terms of use (whether its full-blown "copyleft" like GPL or attribution requirements and disclaimers in more permissive licenses).
(* I'm aware that Copyrights and Patents are different things, but the 'software=mathematics' argument gets applied to both, there are many other issues in common, and the catch-all "IP" sticks in my craw)
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @03:11PM (1 child)
"Mathematics has never been copyrightable "
Perhaps, but "expressing the rules of mathematics in a usable form." is. You can copyright a compendium of mathematical functions, as in the case of a school textbook.
-OP Author
(Score: 2) by barbara hudson on Wednesday November 20 2019, @06:00PM
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @10:11PM
"Worried about making money out of software? Don't, there will still be plenty of people willing to pay you to customize some code for them."
What if I'm a programmer and I don't want to wipe some oligarchs ass for a living? What if I want to write MY code with MY API implementation.
(Score: 5, Insightful) by fustakrakich on Tuesday November 19 2019, @03:22AM (6 children)
We have to eliminate all those copyright extensions that make it almost indefinite. Bring it back to the original 28 years absolute max
La politica e i criminali sono la stessa cosa..
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @03:37PM
Totally agree with this. The current term lengths are an incursion into the 13th amendment, and represent real fascism. And I mean that from an economics perspective rather than programming perspective.
-OP Author
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:22PM
I wholeheartedly agree! I see value in copyrighting original creative work for the benefit of the creator for a period of time. But not so long that others can't eventually improve upon it, and definitely not so long as to allow their great grandchildren to benefit from it.
(Score: 2) by Gault.Drakkor on Tuesday November 19 2019, @09:58PM (3 children)
How about different rights of copy right have different durations?
Full rights: 10 years.
Able to restrict commercial or public reproduction: 20 years
Rights of attribution: 80 years.
As for the topic:
I can understand a different form of protection such as an API patent/trademark. That would be it own unique protection. Such that if I got an API patent for "Fooble v1". Only those entities(including my self) could say their product uses/supports "Fooble v1" if it implements all of "Fooble v1" interface. Enables the owner(as long as defended) to define and create subsequent Probably requires some optional clauses of mutual communication to block embracce extend situations.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @10:35PM
Totally,
Something like this needs to happen. The lack of correct handling for software copyright patent is one of the things that is creating a lot of security problems. UI code is expensive. You can write clean protocol code cheaper than UI code.
But because the courts and the copyright office don't really recognize the difference between application code and a visual representation of that code, it virtually impossible to really protect something like a lib. So nobody writes clean secure code, because there is no lawful protection for it.
-OP Author
(Score: 1) by fustakrakich on Wednesday November 20 2019, @01:42AM (1 child)
Attribution [original creator, author?] in name should stay fixed forever, even in public domain works, but a license holder should never be granted attribution unless he created the work.
I think the original numbers would work fine. Full rights for the 28 years, and after that, public domain. Gotta keep it simple.
La politica e i criminali sono la stessa cosa..
(Score: 2) by barbara hudson on Wednesday November 20 2019, @06:03PM
Which just goes to show how messed up the current situation is.
SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
(Score: 3, Insightful) by Anonymous Coward on Tuesday November 19 2019, @03:24AM (1 child)
Fuck off with that kind of thinking, protocols are NOT the software. Do you know how many more man hours will be spent reengineering the wheel if road gravel is made by another entity from the car manufacturer?
Why would main() be exempt? It is just an entry point. would _start be exempt? What about plugin interfaces? What if I called it main()? What if I called it efi_main? What if its just ad address?
Do you think anyone will use these "small software projects and library"? Will people start moving off Windows somehow because there are more use case specific Linux distros?
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @03:29PM
"Fuck off with that kind of thinking"
If it is thinking that offends you, then I consider your distemper adequate reward.
"protocols are NOT the software"
Lawfully speaking, or in an engineering context?
From an software engineering perspective, certainly protocols are software. They are a "fixed" format that is very temporarily stored on a hardware (fiber/copper/airwave) medium. This is not different from a declaration of statics on a disk that was disconnected from one machine and connected to another. Though a protocol may be implemented by multiple vendors, so can a programming language. Borland, vs, Visual Studio, vs. GNU C for example. All implement C arrays. All are mostly compatible. And if you've done protocol development, you know that protocols are "mostly" compatible too.
"Why would main() be exempt?"
Because main is not a "compendium". Formatting makes a difference to the Copyright Office.
"What about plugin interfaces"
I get your your point. I don't know. They are going to have to bring somebody in who understands software. Which would be different from how things currently are.
"Do you think anyone will use these "small software projects and library"?"
You mean like all of github?
-OP author
(Score: 5, Insightful) by The Mighty Buzzard on Tuesday November 19 2019, @03:39AM (19 children)
1) Oh do fuck off and die. Even source code should not be copyrightable, much less fucking APIs. Copyright was meant for works of art not functional creations. That's what patents are for.
2) Yeah, all this shit working together nonsense is just a fad. Let's go back to the days where nobody could talk to each other unless they used a single vendor's software, that'll be much better.
And no, it wouldn't improve protocols. What it would do, assuming nobody actually wanted to talk outside their much, much smaller groups, is create a million new protocols that have fuck-all in the way of developer time put into them. It would create piles and piles of insecure, buggy shit.
3) Everybody who doesn't code the way you do is doing it wrong? Eat a dick.
4) You're actually right about your first sentence, you're just a young idiot and don't remember when everything was fragmented. It lead to a lot of cocktacular code produced by world+dog instead of fostering cooperation to produce something that didn't suck balls.
5) When your argument blows goats, float a conspiracy theory.
Asshole shill.
My rights don't end where your fear begins.
(Score: 5, Informative) by c0lo on Tuesday November 19 2019, @04:12AM (8 children)
More specifically, from the U.S. Code § 102. Subject matter of copyright: In general [cornell.edu]
I don't know how a software can escape the clause of "method of operation" (of a computer).
Mind you, this is not to say the result of operating a computer is or is not copyrightable (I don't agree with the position "everything generated by a computer is mathematics").
Pretty much the same as "how to paint using a brush" is clearly not copyrightable, but the paintings that result from that operation may be subject to copyright.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by The Mighty Buzzard on Tuesday November 19 2019, @04:19AM (3 children)
Yup, it'd be like asking for copyright on a typewriter. Even brilliantly designed tools are still only tools.
My rights don't end where your fear begins.
(Score: 2) by FatPhil on Tuesday November 19 2019, @09:10AM (2 children)
But, in order to throw some splashy shit under the wheels of common-sense, I'll respond to your "typewriter" comment with "design patents".
Time to burn it all down?
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by c0lo on Tuesday November 19 2019, @11:03AM
Tzs, tzs... Acute hypoalcoholemia syndrome, too serious look at life, contrary to its user manual.
Time to top your tab, I reckon.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by The Mighty Buzzard on Tuesday November 19 2019, @11:29AM
You must've not said it with as much class and style.
Patents are all fine and good for functional stuff (well, they 're another discussion anyway). Copyright is not.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @02:47PM (3 children)
"I don't know how a software can escape the clause of "method of operation" (of a computer)."
By that logic an auto repair manual would also not be copyrightable.
(Score: 3, Informative) by All Your Lawn Are Belong To Us on Tuesday November 19 2019, @03:52PM (2 children)
Very good example. Because the steps involved in carrying out a particular repair job are not copyrightable.
1) Elevate car.
2) Remove oil plug.
3) Allow oil to drain out.
4) Remove Filter
5) Put New Filter On.
6) Restore oil plug.
7) De-elevate car.
8) Fill car with oil.
You are more than welcome to create an auto repair guide with those 8 steps listed. You can use the exact words that I used there, because none of them are original expressions and none of them show any creativity in the expression. Although if you use periods on all steps and omit the period on Step 4 then I can prove that you actually took the expression of my work and copied it, just as cookbook makers used to include a false recipe to prove copy. That little thing aside, the facts contained within auto repair manuals are not copyrightable. You just can't copy the text and pictures directly but have to set your own form for them.
You are also more than welcome to build a car where the above 8 steps must be followed periodically - no auto maker can copyright the steps involved with an oil change.
So, why are protocols and interface standards copyrightable again?
This sig for rent.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:26PM (1 child)
I recommend you mosey on down to the auto parts store and check the title pages of the repair manuals.
(Score: 2) by All Your Lawn Are Belong To Us on Tuesday November 19 2019, @07:37PM
I didn't say the manuals weren't copyrightable, just the opposite. I said the facts and processes contained in them are not. I recommend you learn what copyright covers and what it does not. Lest you believe a front page telling you, "you can't copy any part of this," not realizing that you can write whatever you like and the question is still open to legal interpretation. Then again, I bet you believe them when they say, "This broadcast is copyrighted by NFL Productions for the private use of our audience. Any other use of this telecast or any pictures, descriptions, or accounts of this game without the consent of NFL Productions is prohibited," too!
This sig for rent.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:21PM (3 children)
"Copyright was meant for works of art not functional creations." Actually, "art" as used in copyright law was about functional creations (as apposed to pure science), that is, technology. It was never about artistic creations.
(Score: 2) by The Mighty Buzzard on Tuesday November 19 2019, @10:09PM (2 children)
Yes, I'm aware that "useful Arts" in the constitution refers to engineering and such. For the purpose of patents. Unfortunately they were terribly drunk when they wrote that, got confused, and went on to specifically mention authors.
My rights don't end where your fear begins.
(Score: 2) by dry on Wednesday November 20 2019, @04:41AM (1 child)
It was based on the Statute of Anne, the full name of which was
The whole idea was that works would go into the public domain to advance learning or the "Arts and Sciences"
(Score: 2) by The Mighty Buzzard on Wednesday November 20 2019, @03:35PM
Yup, I'm well familiar with the history. Our current situation is one of my major annoyances, so I've put in some time researching it. I dislike government granted monopolies on principle. Now there's a valid argument to be made for the existence of copyright and patents but only at a small fraction of their current levels of absurdity.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @10:19PM (5 children)
"Oh do fuck off and die."
I'll do you one better. Your mother smells of elderberries!
"they used a single vendor's software, that'll be much better."
Considering invasive DNS mining in monopoly telecom markets, isn't that is what is happening now?
"Everybody who doesn't code the way you do is doing it wrong? Eat a dick."
You clearly were a poet in a former life.
"fostering cooperation to produce something that didn't suck balls."
What makes you think that API copyrights will suddenly make people not want to work together? Actually stable top level namespaces will probably result in less reinventing the wheel.
(Score: 2) by The Mighty Buzzard on Wednesday November 20 2019, @01:56AM (4 children)
sudo emerge -a net-dns/bind
Problem solved.
I can't make you see the beauty in simplicity. I can only keep providing examples.
You're not really that stupid, are you? Or are you just that young? Learn your history. Hell, learn your present.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday November 20 2019, @05:12PM (3 children)
"I can't make you see the beauty in simplicity. I can only keep providing examples."
There is a correct level of abstraction for every problem. The disagreement here is whether Copyright has the appropriate level of abstraction as it stands. You are apparently under the impression that failing to have an API copyright is simpler than having one.
The reason you are wrong, is that the lack of this particular function (an API copyright) is creating spaghettii code that wouldn't be there if a proper object interface was defined.
Status Quo != Simpler
(Score: 2) by The Mighty Buzzard on Wednesday November 20 2019, @11:05PM (2 children)
Neat attempt there at completely changing what you were applying the word "simplicity" to but unfortunately I noticed. I award you no points and may God have mercy on your soul.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Thursday November 21 2019, @04:34PM (1 child)
"I award you no points "
Since you are clearly lord and master of the universe and all things software, you may now crawl back down your hole, little narcissist troll boy.
(Score: 2) by The Mighty Buzzard on Thursday November 21 2019, @05:04PM
You are sadly lacking in cultural knowledge.
My rights don't end where your fear begins.
(Score: 1, Funny) by Anonymous Coward on Tuesday November 19 2019, @04:03AM
Are you trying to get hired [soylentnews.org] by Annette Hurst [techdirt.com]?
(Score: 2) by HiThere on Tuesday November 19 2019, @04:13AM
Even were I to agree with your assertions, I would not accept that it was reasonable to change the "easement" after decades of public accessibility.
Of course, I don't agree. Functions material is not supposed to be copyrightable. At most I would accept patenting the order in which the interfaces were presented, or the precise terms used to describe them. But if it's automatically generated from the source code, that shouldn't qualify either.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Touché) by darkfeline on Tuesday November 19 2019, @04:20AM (1 child)
I agree as long as I get copyright ownership over all of the RFC Internet protocols. Shouldn't be a problem, right, since it "will preserve the market space of forward compatibility".
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:28PM
Actually there are RFC's on protocols that are patented. I've read the submission requirements for the IETF (and previously submitted a draft). They do not distinguish between protocols based on intellectual property ownership.
-OP Author
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:41AM
Here are my reasons:
1. Good. There shouldn’t be. If you knew anything about Oracle’s algorithmic copyright claims, the why of this would be obvious to you.
2. They’re right and you are wrong, by definition.
3. You are losing all credibility because this is a ludicrous conflation of concepts.
4. Hilariously naive.
5. Who cares?
(Score: 3, Informative) by RamiK on Tuesday November 19 2019, @05:14AM
1.
Good.
Why would API copyrights fair any better? That is, what would prevent the regulator from treating APIs like files and only letting big players take advantage of the protections?
I'm sure they'll continue to serve their corporate masters. See above.
You seem to have a grave misunderstanding of how the USG dysfunctions: Easily register-able and enforceable copyrights leave corporations at the mercy of the markets, lawyers without court cases and bureaucrats not having paperwork to justify their existence or chances to take bribes and make private market contacts to advance their careers. Even putting aside the corruption, this turns government unable to target foreign corporations' IP in its low-key trade wars.
2.
No they're not. Every web-dev cooks up their own UDP implementation on some point - usually after reading some KISS article - and realizes the increased efficiency isn't worth the effort. Now Google is pushing newer binary protocol that will mostly eliminate most of those gains too.
3.
This is an argument against software IP. Not in favor of API IP.
4.
How would adding more parasitic litigation costs increase profitability for small developers?
5.
It might be fine for Apple, Microsoft and Oracle, but Google isn't a major federal contractor that can afford risking their entire business portfolio on what an American court decides when they need to compete globally.
compiling...
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @05:25AM (3 children)
Uh by your own logic you would be in violation of many calls to functions yourself.
printf("You would basically have to re-write everything you have.\n");
I used printf as an example here. That thing is everywhere. Implemented thousands of times in many different ways.
Code copyright is a fairly *new* thing in copyright terms. Before it existed people just copied whatever. Not because they were being malicious or anything like that. They did it to get things done.
What you are asking for is literally to let the likes of Google, Oracle, Apple and Microsoft to be the arbiters of what is allowed in code. Do not think for one second they would not all lock down their APIs then sue the H out of you for up to 95 years.
You are wildly mixing copyright and patent law treating them as the same thing. They are not.
Without backwards compat the industry we have now would not exist. We would have hundreds of islands of mostly sorta the same software that basically did not do what we want. We have been there already. We called it the 80s.
Copyright/patent the APIs and you will lock in the current top dogs to own our industry forever. For when they are done they *will* turn to rent seeking. See Oracle.
(Score: 2) by hendrikboom on Tuesday November 19 2019, @12:46PM
I call it the 60's. (and perhaps the 50's, although I wasn't around to experience those)
Everything was bound to particular machines made by particular manufacturers. Right down to the character set and character coding.
It was only in the late 60's that researchers started developing tools to break open these walls, with the development of "portable" software. (see, for example, STAGE2 or ML/1, which were macro systems designed to enable the writing of portable software)
By the 80's the predominance of C created bridges between the various software islands. Most machines had acquired C compilers by then. They weren't completely compatible, but with care they could be used in compatible ways.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @03:02PM (1 child)
"I used printf as an example here."
printf is a single function. An API an a compendium of functions. You cannot copyright the world "printf" (though you can trademark it). But you can copyright for example, the documentation that defines all the built in functions of a language. And if you wrote the language yourself, you can copyright the language as two things, the actual source of the language, and a seperate copyright including just the examples that you show users how your language works. Which is to say that all languages are API's. I don't know about you, but the only time I really work at a bit/byte level is with protocols.
"Code copyright is a fairly *new*"
Programming is more than 40 years old. How long should the Copyright Office wait?
"Copyright/patent the APIs and you will lock in the current top dogs to own our industry forever."
More reason to use FOSS. Seriously. It is pretty clear that Redmond has adjusted to the fact that there are alternatives, and are currently playing catchup by trying to infest the FOSS environments with their crap. Yes this will become more pervasive. But it will be more self evident to people what a bunch of douche bags they are because there will be more cases going to court for many years to come.
They are already doing what your complaining about. If Oracle wins it will be worse for a while, but at least it will be in the light.
"Without backwards compat the industry we have now would not exist."
Hard to say. My expectation is, had Compaq not gotten away with their whole "Silicon Valley Virgin" thing with the IBM BIOS, something else would have come along to take its place.
"arbiters of what is allowed in code."
Yes they will do horrible shit. But it won't be anything new compared to what they've already done. What will change is the API's from private projects will be easier to protect. Which means that the theft that is normal in the EEE business tactic, will be more defensable.
-OP Author
(Score: 3, Insightful) by Zinho on Tuesday November 19 2019, @05:46PM
Correct, and neither can you copyright an alphabetical list of all externally-available function calls in your code. At its essence, that's all an API is: a list of available function calls, what arguments they take, and what output they provide. This is factual information, and a specific presentation of it is copyrightable; the information itself is not.
Right. The source code is copyrightable. So is an O'Reilly-style manual, so are online help pages that give examples.
The list of function calls is not. The list of arguments for those functions is not. The list of data types returned as output is not.
Also true, in the same way that courts have recently ruled that "Klingon" as a language cannot be copyrighted. The "Official Paramount Dictionary and Grammar of the Klingon Language", however, can. A list of all words recognized as Klingon, stored in flat text, sorted in alphabetical order, cannot. And Paramount cannot use their copyright claim on their dictionary to prevent anyone from publishing wholly-original literary works in Klingon.
Comparisons of what an API is to already-settled copyright law make it obvious what the answers should be. Re-implementing the fundamental elements of a programming language is not an infringement of the original author's copyright. Having the exact same function calls and arguments is unavoidable if the new implementation is 100% compatible, and the right to inter-operate is enshrined in U.S. law.
If we want a different discussion; say, of how the law "should be" versus "is", and why, by all means, let's do that. The people wanting to copyright APIs will still be wrong, just for different reasons.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 2) by Arik on Tuesday November 19 2019, @06:08AM (2 children)
You should send a few copies to the Library of Congress as well, though it's unfortunately no longer required.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:17PM (1 child)
Not necessary. A work is copyrighted once it's "fixed in a tangible medium." Simply writing software makes it automatically copyrighted (for good or bad).
(Score: 2) by Arik on Tuesday November 19 2019, @04:24PM
Shouldn't be, however.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Insightful) by sjames on Tuesday November 19 2019, @06:57AM
One major point in the study of literature is essentially boiling literary works, great and not so great into "API"s. TFA argues there can be only one member of a genre. Just one murder mystery, one horse opera, one romance novel, etc. (note, no space operas at all since they are basically horse operas with starships and lasers) At some level, all novels have the same "API". Digging deeper, certainly all works of a given genre have a common API (That's how we define the genre in the first place).
If there is anything in software that should be eligible for copyright, it will be the implementation, not the interface.
(Score: 2, Interesting) by aristarchus on Tuesday November 19 2019, @06:59AM (1 child)
Well, that went well. [youtube.com] (Notice: quote from Cap't Malcolm Reynolds, which should be parsed as Commander Fox, but in the episode wherein a buxom wench kiss-drugs the Captain, no, wait, this is later when she comes back, and so the playing the con on the con-artist is all the more sweeter, like being able to say to khallow, or TMB, wilst sitting on a rock totally nude, "That went well.")
(Score: 2) by The Mighty Buzzard on Tuesday November 19 2019, @11:37AM
Meh, I can't think up a decent "I swear by my pretty floral bonnet" reply before at least one cup of coffee's in my blood system.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @07:02AM (15 children)
Re: "Like or not, the copyright office is almost universally unwilling to review file formats that are aren't developed by Microsoft."
Do you have evidence for this? I know MS are big jerks, but they are not the only big jerks.
Re: "API copyrights provides an abbreviated basis for for dealing with the copyright office, and provides an easier mechanism for courts to understand."
Dumbing stuff down for judges should not be the end goal, but rather doing things RIGHT should be the end goal. If it's not practical to adjudicate software because too many judges are clueless, then the real argument should be to toss software patents altogether.
Re: "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 [encouraging new stuff]"
Having to constantly upgrade shit is already a pain in the butt. You'd make us grow two butts to contain the extra pain. And it's usually easier to inspect a non-moving target. Old road-tested software usually has fewer bugs than newer software, and that generally includes security issues, since regular bugs and security bugs are caused by roughly the same mechanism.
Re: "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."
How is it notably different than using functions? If one patents an algorithm, then which API calls or function calls are used to implement it are different matter anyhow, independent of the algorithm. Perhaps an example would help.
Re: "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."
We already have source code copyrights. How is this notably different?
Re: "It will fragment the software industry...If small software projects and library writing become more protected by copyright, then independent software development will be more profitable."
That's a wild guess. It could make things worse.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @03:56PM (14 children)
"Do you have evidence for this?"
They publish a list.
"Dumbing stuff down for judges should not be the end goal, but rather doing things RIGHT should be the end goal."
I agree with that, but at some point you have to make decisions about practicality.
I just got done refactoring a big block of code to accommodate a necessary design change. This was essentially doing maybe 100 global match-replace functions on maybe 50 or so files. The source code totally changed, but the API that is exported into the main() namespace remained almost exactly the same. The whole point was to allow for the development of some new functions that would be unmaintainable without the refactor.
Now let me ask you this: The code does almost exactly the same thing as before, but it LOOKS totally different. So should my previous copyright make my current code undefensable in court?
"How is it notably different than using functions?"
The difference between a function and an API is that an API is a "compendium".
"We already have source code copyrights. How is this notably different?"
In software the underlying source code can change without the API ("compendium") changing. This feature is what creates the need for two recognized types of copyrights. There is distinct differences in the value that is represented by the source code and the API. The source code is valuable as means of production, the API is valuable as a means of maintaining institutional knowledge.
-OP author
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @08:11PM (13 children)
Algorithms are currently patent-able and source code is currently copyright-able. You can protect both if you want. What more are you asking for? If somebody makes software that does the same thing as your but has completely different source code and uses completely different algorithms, then good for them. You can't own goals. (You can also copyright the specific UI.)
Okay, "collection of functions". I've used Fortran 66 libraries (APIs) before, and using them is not much different than the OOP versions. OOP gives better error checking of "mismatched state", but otherwise the difference is mostly cosmetic.
I'm still not clear. I'd probably have to examine a specific specimen of something to know what you have mind. People use them for different reasons.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @09:55PM (12 children)
"You can't own goals."
Sure you can. Patents are issued without workable prototypes all the time. Trademarks are issued for companies that don't yet have customers.
"I'm still not clear. I'd probably have to examine a specific specimen of something to know what you have mind. People use them for different reasons."
How about this one: https://api.libreoffice.org/docs/java/ref/index.html [libreoffice.org]
The underlying source code for this API has probably a hundred or more contributors.
The API consists of a very small percentage of all of the respective code. And while I say that the API is code, that doesn't preclude it from also being something else. The API is maintained to be consistent from version to version because there is value in that consistency.
We know this because we've seen other vendors break API's intentionally over the years to screw competitors, and it has cost thousands of companies millions of dollars to patch their software to accommodate completely unnecessary changes. If this stability wasn't valuable, the product sporting the above API probably wouldn't exist. You can code for many office suites. But you do less work if you code for one that isn't maintained by a spazz.
There is a value intrinsic to interface stability. That is the value that an API creates. If you've ever said: "The current implementation sucks, I'm going to roll my own because it is the ONLY way I know the code will still work next week.". Then you understand the value of interface stability. You shouldn't reinvent the wheel, but sometimes it is the only choice if you want maintainable code. IMHO this exact circumstance has been a driving factor for many many FOSS projects.
Interface stability has a value that is distinct from say submitting a patch to fix a bug. The patch improves (or potentially detracts) from the value of the code by making its intended functionality better. The patch makes the API work better. The API permits the developer not have to reread a ream of documentation just because the patch was added.
A toolbox is box, but it is also a tool. Its function is to make it easier to use all the other tools. If a tool is protected by copyright, the fact that the toolbox is a box, doesn't deprive it from also being a tool. In OO speak what we are talking about here is the concept of inheritance.
Code is copyrightable. An API is code. But an API is also a compendium that is used to provide interface stability. They serve distinct purposes. It is a subtle difference, but it is hugely different in terms of the time and capital invested in a project.
Microsoft has split this hair for antitrust purposes over the years. It is so frequent there is a term for it: EEE. Really we could regard this case as an attempt to overturn Sun MicroSystems v. Microsoft from back in the 90's.
It isn't unfair to suggest that new product developers should have a right to create an exclusive namespace that doesn't suffer the kind of pig fucking that happened to Sun MicroSystems over its javascript license. That hugely bad decision was single handedly responsible for (conservatively) 10% of all privacy and security problems on the Internet over the past two decades. Sorry but there it is. EEE is a menace when it comes to infosec.
I do however agree with a previous post that said that copyrights are abusively long. I don't really care how they do it, but there should be either a class of copyright or patent that permits API's to be protected, and it should be short. Like maybe 10 years. If you haven't made money on a code base by then, its probably deprecated, so any longer is really constraining the market unnecessarily.
(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.
(Score: 2) by shortscreen on Tuesday November 19 2019, @07:26AM (2 children)
Copyrighting an API is like copyrighting the address of the grocery store and thereby disallowing anyone from driving there. (You may notice that it's also entirely self-defeating.)
P.S. Header files deserve to not exist, as languages better than C don't even need them. All those megabytes of includes for Win32 are non-essential data. Even function names can be discarded in favor of ordinals (although it's far from ideal). Every parameter passed to every function is just a DWORD value in the end.
(Score: 2) by FatPhil on Tuesday November 19 2019, @09:19AM
Strange - I consider those to be languages worse than C. Could it be that you're just expressing personal preferences, rather than facts?
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Wednesday November 20 2019, @05:04PM
A more correct car analogy might be:
Putting the steering wheel, break peddle, etc. in the same place across multiple makes and models. People move from one car to another have difficulty driving if the controls are different. The value presented by the API is the consistency of the control layout.
Current copyright would say that, only a picture taken of the layout was copyrightable, and that the layout itself wasn't. So a third party vendor chooses to buy the brake peddle from the guy who designed the layout but put it in the wrong place. Customers get into accidents because of it. If the brake maker had the right to control whether the brake was installed correctly as a condition of selling the brake, the accident doesn't happen.
The seller can sell under these terms with a patent, but not with copyright. So the issue is that software contains attributes that are appropriate and inappropriate for both patent and copyright.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @07:50AM
What a beatiful, distopic world of dwarfs crouched to look at their navel...
«nanos gigantum humeris insidentes»
https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants [wikipedia.org]
CYA
(Score: 3, Insightful) by meustrus on Tuesday November 19 2019, @01:58PM (4 children)
You make an interesting argument, Anonymous Coward. I think it deserves to be discussed on its merits.
But that does not mean that your concept of a protectable API has anything to do with existing copyright law.
Copyright law was designed to protect artistic expression. It is needed to ensure that if you write a book, somebody can't just do their own print run of a "generic" brand version of it. But in service to the needs of artistic expression, copyright law allows for existing ideas to be expressed in new ways. Otherwise, a copyright on Sherlock Holmes would pre-empt any other detective stories.
Copyright law does not apply the way you want it to apply to software. It is a pretty poor fit, really, because it protects the expression of an idea, completely ignoring the idea's utility. Copyright is reasonable when applied to manufacturing duplicate disks for Microsoft Office or Starcraft, but not so great at managing the complexities of derivative work. And copyright isn't actually a good enforcement mechanism for software because it is so easy to pirate; this is why Starcraft 2 and Microsoft Office 365 use the always-authenticated-online SaaS model.
There may be value to the argument presented here - #2 presents an interesting assertion, that allowing corporations to be jerks with their copyright favors FOSS, raising the question of why the EFF isn't making this fight - but the argument needs to be legislative, not judicial. Which is to say that instead of trying to influence how copyright is viewed in the courtroom, try to influence how copyright is viewed in Congress.
Copyright law doesn't mean what you think it should mean, it means what it does mean. If you want it to mean something different, stop trying to change the meaning of the words and go try to change the words themselves. Make a new law that specifically protects computer software, effectively and for the right reasons. When you do, make sure it also migrates all the existing copyrights and patents into the new system and ends software copyright and patents completely. They're not the right tool to protect software and they never will be.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @02:36PM (2 children)
" But in service to the needs of artistic expression, copyright law allows for existing ideas to be expressed in new ways. Otherwise, a copyright on Sherlock Holmes would pre-empt any other detective stories."
So, consider how Harry Potter fits into this. The author created 2 things, the story/plot lines and the fictional world/environment that they are told in. Both are valuable and protected. Although the useful arts would benefit from a new author writing new plots in the fictional world, they don't seem to be able to.
Superficially, this seems a lot like programs versus language environment. I think it's different because of value and author intent.
When Sun released a new language, it had little value unless folks were willing to use it. Now that language has great value mostly because folks other than those that created the language, wrote programs using it. This somehow seems different to me than the Harry Potter situation above. Most of the value in Java is in work done by folks outside Sun. This was as Sun intended, but now that others have done this work, the successors of Sun are trying to limit it's usefulness.
This case may not turn on if an API is copyrightable, but rather on the intent of Sun as shown in what they did to do to get folks to embrace the language.
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @10:09PM
People aren't going to stop working together just because of API copyright. The reverse may also be true, which is that because of API stability, FOSS projects that are successful may get more support.
(Score: 2) by meustrus on Wednesday November 20 2019, @12:15AM
That's a pretty good comparison. Even more so because while you did not mention this, Harry Potter has a huge fan-fiction community. J.K. Rowling is technically within her rights to shut it all down, but she does not. The fan fiction does not reduce the value of her work. In fact, it most likely enhances the value of the core property.
Similarly, Sun allowed - even encouraged! - third party developers to contribute Java "fan fiction", as it were. Unlike Harry Potter, however, the contributions are likely the majority of the value of the whole product. And maybe it didn't have to be this way; C#.NET is significant even though most of its libraries are produced by Microsoft (and we can be glad that Java copyright can't be used against C# and the idea of garbage-collected object-oriented programming on a VM/CLR).
Meanwhile, one could publish a book that follows the plot of Harry Potter and the Philosopher's Stone (no, I'm not British, just salty that they changed this historically-significant name for the US release) as long as it changed all the names and invented words and was not a sentence-by-sentence copy pasta. Would it be plagiarism? On this scale, absolutely. But it arguably would not constitute copyright infringement.
So what is the equivalent in programming? If you change all the names and legitimately re-implement everything without any copy pasta, does the copyright of the original work not apply? What are the "names"? The literal class names, or the method signatures?
This provides an interesting way of framing the API copyright question. It leads to the question of whether something like `void main(int argc, void *argv)` deserves the same kind of protection as Mickey Mouse.
Unfortunately, it's hard for me to answer that question because I believe Mickey Mouse's copyright protections stifle creativity. My answer is that neither deserves that level of protection.
The answer is probably closest to the other reply from the other AC, who may be the OP:
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:16PM
Thank you for your reply,
" It is a pretty poor fit, really, because it protects the expression of an idea, completely ignoring the idea's utility"
Yep. So the question is then whether an API is an expression that is distinct from the source code itself. And certainly it is, because the API can remain constant while the underlying source code changes. Indeed that is the whole point of having an API in the first place, and further the entire point of using modern OO design practices.
Code modularity exists specifically to make distinct these two concepts. When people say "black box" what they are talking about is the API. Correspondingly there needs to be two different kinds of protections.
"Make a new law that specifically protects computer software, effectively and for the right reasons."
Totally agree. But whose going to administrate it... Its either the USPTO or the Copyright office.
Copyrights are cheap. Patents are expensive. Copyrights are currently so perversely long that they (IMHO) conflict with the 13th amendment (involuntary servitude). Patents have more sane lengths. I wouldn't be against this being done as a class of design patent. But the way patents are written, vs. the way copyright registration takes place is just overwhelmingly inappropriate.
Obviously what it needs to be, is a short term (say 7 years), but have a filing process like a copyright. But to do that you actually have fund the copyright office. Because it represents more work.
The copyright process is more appropriate for software, but the terms are insane. The Patent process is totally wrong for software, but the terms are somewhat sane. There needs to be a middle ground.
-OP Author
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @03:37PM
Oh no no no
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @04:14PM
You are a moron.
(Score: 2) by Rich on Tuesday November 19 2019, @09:32PM (1 child)
What IDE and API that might that have been?
(Score: 0) by Anonymous Coward on Tuesday November 19 2019, @10:26PM
"Astroturfing or just Butthurt?"
You really shouldn't talk about your mother that way. Though she does have a tight ass, or so the neighborhood football team tells me.