Another relevant thing I learned about recently is that Dali was apparently considered massive sellout by his peers and seems to have gotten so famous thanks to a strategic move to America.
Surely you know that gravitational force is indistinguishable from acceleration and the idea of 'down' sensed by any mass inside the plane is the vector sum of both.
I guess everyone means UVC here. A UVA flashlight is cheaper than lunch ;) edit: my facts were scrambled. C is the nasty one... maybe my favorite (unsafe) language will help me remember that from now on.
The people "you" elected and the people they appointed are all doing their jobs and everything is going to be Oh Kay™
...ever since I was too young to vote. Now I'm a little unhappy about the Hanford Site and about tetraethyl lead, for example. I know that has nothing to do with satellites.
This varies with goals, attitudes, background, bias, etc. Besides, if you know a little C, you can livecode over at glslsandbox or shadertoy and be immediately rewarded.
> It isn't the kind of thing you tackle because you need hirable job skills by the end of the month.
No, not really. This also roughly says "JS doesn't necessarily require lots of experience" which is not much of a plus, as someone already pointed out.
Referring to the article in [0], facts are not copyrightable.
If you're going to write some code, then you usually choose to base your work on a particular language, which means you copy a lot of the design decisions and original work that went into it, and that is hopefully what everyone wanted ITFP. You (or O'Reilly) copyright a thorough description of the language's syntax, not the syntax itself. An API's function signatures are a more specific and elaborate kind of syntax, but all are just facts about the world now that someone published the thing. edit: I mean that the uncopyrightable fact is that "if you are going to use this thing, here is exactly the way it must be done".
This goes much further than 'imitation is the sincerest form of flattery'. The reason e.g. Microsoft published the reference for MFC is because they wanted people to be able to use it, and actually use it. My shallow opinion is that interfaces are like that. You want people to build on top of it rather than making up a new and utterly foreign thing every time, so you want people to copy the exact things about it that make this possible, correctly.
You could argue that Oracle didn't own any of the code that different bits of Android were interfacing with, so they didn't have any incentive there. But that only means Oracle forgot or doesn't care about that thing called 'mindshare'. People learning and using identical interfaces "should" have been something that Oracle wanted.
(I don't mean to imply any notable similarity in the two cases, but people knowing when and where the trains were running-- so they could use those and keep on deciding to use those-- "should" be something that MTA wanted.)
On the side, obsessing over protection is precisely what I've said is distasteful about the GPL.
You Seem to Assume that the language in question and the API’s must have identical license requirements. Sure, if someone write a novel in English they can get a copyright on the book but not the language. But If I invent a different language and publish it in a book, why should I lose the rights to it simply because of what the language is or how people would use it. You can’t copyright the European history because it’s facts, but you definitely can hold a copyright to the Written. history of Westeros.
Also, just to note. Even authors of completely proprietary languages want people to use them. Only they also want to make money when people use term. The intention that people should use your product does not give anyone rights to copy outside of license allowances or to break copyright where that applies.
> You Seem to Assume that the language in question and the API’s must have identical license requirements.
Maybe. I seem to be saying that with both languages and APIs, licensing-related restrictions are worse than useless. Anyone can go write a compiler that translates a pre-existing language into object code, right? If you can insist on being the only one who can compile your language, good luck getting people to write in it.
> But If I invent a different language and publish it in a book, why should I lose the rights to it simply because of what the language is or how people would use it.
Which rights? Isn't that the original question, the one of what rights are implied as 'granted' when you publish a thing, such as 'the right to read and understand it'? (No I didn't purchase your book, I found it at a library.) You don't "lose the rights" to it, that sounds a bit like false dichotomy. You merely would not have had all the rights you had hoped, from the beginning.
---
I can almost see it Oracle's way: they own all the results of a great deal of work that Sun('s employees) did, and later on Google managed to avoid a chunk of that work and so help their own bottom line. Google also takes advantage of the industry's pre-existing familiarity with it. I still think Oracle is on the wrong side of common sense because Google was also helping Oracle's thing stay popular by increasing the motivation for anyone to gain familiarity with it, and I would call it a fair trade. But that's me, and my business sense is rather like a phantom limb.
"If you're going to write some code, then you usually choose to base your work on a particular language, which means you copy a lot of the design decisions and original work that went into it, and that is hopefully what everyone wanted ITFP. You (or O'Reilly) copyright a thorough description of the language's syntax, not the syntax itself."
Yes, exactly like APIs.
"An API's function signatures are a more specific and elaborate kind of syntax, but all are just facts about the world now that someone published the thing. "
This is just plainly not true.
Nobody on this thread has given a reasonable argument as to why APIs are not more or less like code.
In fact, almost everyone's attempt to demonstrated that 'API
s are different that code' have done the opposite, and highlighted how similar they are.
I believe HNers just don't like copyright, and don't like Oracle.
> Nobody on this thread has given a reasonable argument as to why APIs are not more or less like code.
I think they did, though. An API is designed and written, and then it is "a design". (OK "an interface" but that's jargon, the design and formal requirements and patterns are what matters) Code is designed and written, then it is "an implementation". If there's anything special about your design so that you want to control how and whether people are legally allowed to implement it, you get a patent, not a copyright. Then (IINM which seems probable because IANAL) the separate (perhaps royalty-paying) patent licensee can still copyright their own implementation. Don't get me wrong-- I don't want even more patents around software, I just hope people will call things what they are. I have to admit that I could merely be mincing words, if only because that's what I want to accuse someone else of doing. I don't envy the court.
Yes, that's actually a good attempt at making the case, along the lines of some some of the amicus brief filings. (Most of the arguments on this thread are missing the point).
So here is where people are crossing streams I think:
'The interface' to something is not copyrightable as the law says today - fair enough.
But the description of said interfaces may in fact be.
In many cases, probably most, the API is literally part of the code - which is copyrighted already.
So it might be possible that the articulation of an interface is a creative work like anything else, but the implementation is not.
So you can release an implementation of some copyrighted platform - that does the exact same thing with the exact same interface, but the description of said interface in some descriptive language is copyrighted.
The paradox of the fact that the API is often part of the copyrighted code ... is hard to get past.
This part is pretty settled, I think - an .h file is copyrightable, for example, because it is code (that happens to define an API). That's fine, well-established, and people have worked around it for a long time now - e.g. MinGW uses their own <windows.h> for this exact reason, even though it describes the same API as the one that comes with MSVC.
The question at stake is whether the API itself is copyrightable, and that workaround is therefore not sufficient.
It has been conflated in this particular case, because IIRC there were some infringement claims around the literal contents of the .java files, and others over the "structure, sequence, and organization" (i.e. the API proper). But then for that first part, Google pointed out that in Java, there is usually only one way to describe one particular API; and if you use the standard coding style, then even independent definitions will end up looking the same verbatim.
In this subthread, we were discussing "the interface something is not copyrightable as the law says today, but the description of said interfaces may in fact be". The header file was an example of how this is already generally assumed to be the status quo - the API is not copyrighted, but the particular description of that API, in form of <windows.h> that ships with MSVC, is copyrighted. So MinGW could do this for Win32 API, so long as they rolled their own header.
> ou want people to build on top of it rather than making up a new and utterly foreign thing every time, so you want people to copy the exact things about it that make this possible, correctly.
As the copyright holder you are free to grant that right to anyone. In fact, if Google wins, you just won't have a choice in the matter. If Oracle wins it's far more inline with how licensing currently works - the developer chooses who and how their code is used.
Ironically enough, Oracle winning gives developers more power over their code. Google winning will allow any large company to replace open source software with proprietary software with no ability for devs to protect themselves.
> if Google wins, you just won't have a choice in the matter.
> Google winning will allow any large company to replace open source software with proprietary software with no ability for devs to protect themselves.
Can you back this up? What should I be reading if I wanted to convince myself that this is true? What if I'm not releasing a FOSS library (and necessarily publishing the API) which I hope people will use if only to justify the time I spent designing and implementing it?
This is just the way licensing works today. So just take the existing rules for a software license and apply them to an API.
> What if I'm not releasing a FOSS library (and necessarily publishing the API) which I hope people will use if only to justify the time I spent designing and implementing it?
If Oracle wins you are the copyright holder of that code, including the API. So feel free to let anyone use it if you would like.
Oracle winning means you get more control over your code. Google winning means you have no control over the API.
> If Oracle wins you are the copyright holder of that code, including the API.
I said "what if I'm NOT", as in, "how will this ruin everything for me in the most common case, that of being only a user?"
But I am planning a library and it is meant to be free-as-in-sunlight if it ever gets there. I'm not worried, I just find it easier to agree with those who are saying the opposite. They seem to think Oracle winning will be precedent for an incredible amount of control to be exercised by software publishers, especially regarding operating systems... this would basically throw a bucket of sand into the proverbial gearbox, for everyone, down to the last user.
Not everyone wants more control. On the flip side, not everyone wants more users just for the sake of proving they made a more useful thing.
IIUC Google winning means I have to be mentally prepared for someone to someday take advantage of my work, which is what I wanted from the very beginning. Whether or not that feels "fair" depends entirely on my definition of "fair", not the court's. Anyone who decides to do that will have paid me a compliment, unless of course someone reuses my work to do something specific that I happen to really dislike. But people are very different from me, so that's almost inevitable, and I might not even learn about any of it, and anyway I accept the possibility.
MetroPCS (prepaid MVNO now something like a subsidiary of TMo) required the 8-digit PIN on the account in order to change IMEIs. A bot would take down all the info, then if/when it was to a phone you'd never used on their network before, you got put on hold to wait to talk to a human and provide your PIN and new IMEI all over again. Then you'd hang up, power off, and move your SIM. But that was ~18 months ago, before it became "Metro by T-Mobile", so I don't know.
