SoylentNews is people
SoylentNews
The Obama administration has asked the United States Supreme Court to decline Google's appeal against a 2014 federal appeals court ruling finding copyright infringement of Oracle's Java code:
The case involves how much copyright protection should extend to the Java programing language. Oracle won a federal appeals court ruling last year that allows it to copyright parts of Java, whilst Google argues it should be free to use Java without paying a licencing fee. Google, which used Java to design its Android smartphone operating system, appealed to the U.S. Supreme Court. The high court then asked the Obama administration in January for its opinion on whether it should take the case because the federal government has a strong interest. The Federal Trade Commission, for instance, must ensure companies do not break antitrust laws when claiming software copyright protection against each other.
According to Google, an Oracle victory would obstruct "an enormous amount of innovation" because software developers would not be able to freely build on each others' work. But Oracle says effective copyright protection is the key to software innovation.
In the court filing on Tuesday, U.S. Solicitor General Donald Verrilli said Google's argument that the code is not entitled to copyright protection lacks merit and did not need to be reviewed by the Supreme Court. Verrilli added that Google had raised important concerns about the effect that enforcement of Oracle's copyright could have on software development, but said those issues could be addressed via further proceedings on Google's separate "fair use" defence in San Francisco federal court.
Google v. Oracle, U.S. Supreme Court, No. 14-410
[Editor's Comment: Original Submission]
(Score: 4, Informative) by lentilla on Friday May 29 2015, @01:39AM
sudo does not do redirection. If it did, it would defeat the purpose because then you could redirect the output of your permitted command to clobber any file you wanted
sudo does not do redirection - correct - but not for the reason you supplied. It is the shell that is responsible for redirection.
As you point out we've been over this multiple times. I don't want to nit-pick but I see this is a common misunderstanding which should all make perfect sense once we clearly grasp what is going on at a fundamental level.
Let's have a look at proposed command (which will not do what is intended):
sudo echo 127.0.0.1 www.google-analytics.com >> /etc/hosts
The command being passed to the shell (usually "bash" in GNU/Linux) is "sudo". The shell parses the line and finds a redirection operator (">>" "append to file") - so it knows to append the output of "sudo" to the specified file (in this case "/etc/hosts"). Now, here is the important part: which user is doing the appending? Answer: the user that executed "sudo". This is why the command won't do what was wanted - a normal user probably doesn't have write permission to /etc/hosts.
"echo 127.0.0.1 www.google-analytics.com" are the arguments that are passed to "sudo". When "sudo" starts, it checks its configuration and; assuming the requested command is allowed; prompts the user for a password to elevate permissions. "sudo" now parses its arguments, using the first argument as the command to execute and the rest as arguments to that command. In this case, the command is "echo" and it is supplied with the arguments "127.0.0.1 www.google-analytics.com".
There are various ways to Do What I Mean (namely append a line to a file that needs elevated permission to write in to) and an elegant solution appears in Michael's sig. There are; of course; other methods, many of which have been discussed here before.
Unless interested, this paragraph can be safely ignored since it's in the "more than you needed to know department". Note there is a subtle difference between "echo hi" and "sudo echo hi" that is not related to permissions. The former command is (usually) executing a shell builtin whereas the latter is executing a program (usually "/bin/echo"). You can test this for yourself by finding a shell builtin that doesn't have a executable analogue: "ulimit" under bash would do the trick. Plain old "ulimit" produces some output. "sudo ulimit" complains "sudo: ulimit: command not found".
I wish he would just take it out of his sig already, its so pointless.
Me too! I think; Michael; that you are preaching to the choir. Anyone that can grasp the issue is probably already doing that (I know I certainly am). Those who can't grasp the issue are just going to be left scratching their heads. Getting the word out is great but; at least in this case; if people haven't understood by now they probably never will.