How you could possibly interpret that statement as meaning anything other than "we need to negotiate a license" is beyond me. I may not like Oracle's aggressiveness in pursuing the issue, but I can't read this email as being anything other than an acknowledgement that Google needs a license.
Read the context prior to that. At the point that email was sent, Google's plan was to use the name Java in their marketing. Java was Sun's trademark, so of course they would have needed to licence it.
They decided not to, however, instead hiding the connections between Android and Java in developer-oriented documentation, and being careful never to claim that Android implements Java in any way (it implements a system that is compatible with programs for the Java programming language, or some other such nonsense, that is always careful not to suggest any Sun/Oracle endorsement of the system).
Actually, the license discussed in the email is for TCK, which is a tool for testing and certifying that Java implementations correctly implement the Java standard.
The discussion we're talking about was about procurement, too, albeit on a larger scale -- the android dev team were deciding they needed to procure Java, because the alternatives they considered (primarily objective C) "sucked" in their opinion. So they were suggesting buying a license for Sun's Java TCK, a prerequisite for producing an officially sanctioned version of Java at the time.
No. But you would expect employees (well, maybe except for janitors) to understand the implications in the current legal climate, and refrain from putting things so bluntly as "we're clearly violating these patents and must get a license", even in internal email - unless they are explicitly asked to express their legal opinion. At least, that sort of thing has been part of on-boarding training in pretty much every place I've worked in the last eight years.
Except that's not what he says. Patents are not, at any point, mentioned in the memo. The memo expresses a desire to use the Java trademark in marketing Android. It is well-known that Sun required licensing of the Java Technology Compatibility Kit and a successful pass of its tests before it would allow you to use the Java trademark in this way, so the license stated as required (a license for the TCK software, not a patent license) would most definitely have been required IF google had proceeded with the plan as it was described in that memo. They did not proceed with this plan, however, instead deciding to distance themselves from Java, make their virtual machine incompatible with the Java virtual machine (although providing tools supporting automated translation between the two formats), and not use the Java trademark in any of their marketing material. So it is unclear what relevance a (correct) statement about the licensing terms on the Java trademark has on a court case about a system that does not use that trademark. This so-called "smoking gun" is just misdirection on Oracle's part.
Reality? The reality is that a design document written before coding starts is likely to never be accurate enough to perform the kind of annotation you're talking about, because as soon as coders sit down with it to actually implement stuff, they'll realise the design missed some crucial point of logic about how the application should work. And as soon as the code is demonstrated to the customer, the customer will point out misunderstandings about the design. And as soon as you start changing requirements your entire cross-referencing scheme starts taking more time than actually implementing the software does. The developers begin to hate it. The managers start to hate the developers because they can't stick to an apparently simple scheme. QA wonders why the software that has been produced appears to be different to the software they expected to be testing (because the coders had to update the spec to fix logical ommissions, but nobody forwarded the revised spec to QA), and starts filing bugs against correct behaviour. Before long the entire system falls apart and people are bickering about whose fault it is.
Been there, done that, and it's the last time I ever work for an FTSE250-listed corporation.
Actually, he's talking about something entirely different to literate programming. LP advocates writing a single document that contains both documentation and code, whereas what this guy's actually advocating is basically finding a reason to take a second pass at looking at the code, which is what happens when you document it separately. You'd get the same benefit from, for example, having a policy of self-reviewing code after completion, or in TDD the refactor phase of the red-green-refactor cycle.
But as for finding bugs, I don't know. You may document exactly what you intended, and thought the code did, but still be wrong because of some corner case. Documenting it isn't likely to reveal all of these situations any better than the code itself.
Handling corner cases is accomplished by identifying what they are and specifically implementing code to handle them when necessary. In order to identify them, we must think about what the code is doing. As programmers, there are three times we do this:
- When writing the code - When testing the code - When writing the documentation
It happens that we tend to pick up different corner cases in each case. This happens because different corner cases require different ways of thinking to identify them, and while performing these three activities we tend to be thinking in different ways (logically, spatially, and verbally, as a rough approximation). So, yes, I think coding and documenting is likely to reveal corner cases better than coding alone, particularly if we leave a few days between coding and documenting (thus allowing us to forget how we were thinking about the code at the time we wrote it, and get more into the verbal method of thinking about the problem).
The site you link to only appears to have a subset of the import tariffs based on origin country. If you click a specific product code to get to the country list it will show you the countries it has data for. If you select (e.g.) China from the drop down list at the top right, it will tell you it has no data for import tariffs on the product you selected from China. It also doesn't have data for Taiwan. As broadcom's preferred manufacturers are located in these countries, it is highly likely one or the other will be the relevant country.
To get the full list, you apparently have to pay a subscription to HMRC.
Has this been marketed so many dilettante geeks who didn't already know about the myriad of options may buy them? Yes
What myriad? Which other products have a multi-hundred-megahertz 32-bit processor, 128 or higher MB of RAM, and respectably powerful DSP and GPU functionality for under $40? For under $80?
Duty is 15% at most on electronics imported into the EU
You don't know what you're talking about. The situation is very complicated, and varies depending on the type of component and the country of origin, but, for example, the duty on DRAM imported from Korea is 32.9%.
I wouldn't be sure. Most architects claim the right to prevent other people from building buildings from their blueprints, even if they have legally acquired copies of those blueprints. I don't know if this has ever been tested in court.
MUDs are unlikely to satisfy the requirements of the patent, as I'm pretty sure that none of them (at least none of the ones I played) send updates of only some of the positions of players in a room based on whether they are visible to the client. In fact, all the ones I remember only sent enter/exit position updates, which were sent to everyone in the room.
receiving, by the client device, position information associated with fewer than all of the other user avatars in an interaction room of the virtual space, from a server process
Doesn't matter. The technique described in the claims (essentially, a server that works out which other users a user's avatar is able to see and only sends position updates for those, with various variations - all of which are obvious - involving how the necessary information is to be stored in a database) is so fundamental, I find it highly unlikely that there was no prior art older than even that. The defendants should be looking at, for example, CitySpace, a networked virtual world system that was demonstrated in 1993. Failing that, any number of examples of similar behaviour in different fields could be used as a basis for an argument of obviousness.
This is just like the judge in the UK that ruled that an electronic key was quiet different to a physical one (the infamous Prestel hacking case) - where any "reasonable" person would say they perform the same function so they are the same.
As Spock said "A difference that makes no difference, is no difference"
The difference made by this difference is that if you steal something physical, the original owner no longer has it. In this case, the original owner still had their code, hence it wasn't stolen.
Slashdot Mirror
AFAIK, there is no GPLv3 code in Android. The only GPL code is Linux, which is GPLv2.
How you could possibly interpret that statement as meaning anything other than "we need to negotiate a license" is beyond me. I may not like Oracle's aggressiveness in pursuing the issue, but I can't read this email as being anything other than an acknowledgement that Google needs a license.
Read the context prior to that. At the point that email was sent, Google's plan was to use the name Java in their marketing. Java was Sun's trademark, so of course they would have needed to licence it.
They decided not to, however, instead hiding the connections between Android and Java in developer-oriented documentation, and being careful never to claim that Android implements Java in any way (it implements a system that is compatible with programs for the Java programming language, or some other such nonsense, that is always careful not to suggest any Sun/Oracle endorsement of the system).
Actually, the license discussed in the email is for TCK, which is a tool for testing and certifying that Java implementations correctly implement the Java standard.
The discussion we're talking about was about procurement, too, albeit on a larger scale -- the android dev team were deciding they needed to procure Java, because the alternatives they considered (primarily objective C) "sucked" in their opinion. So they were suggesting buying a license for Sun's Java TCK, a prerequisite for producing an officially sanctioned version of Java at the time.
No. But you would expect employees (well, maybe except for janitors) to understand the implications in the current legal climate, and refrain from putting things so bluntly as "we're clearly violating these patents and must get a license", even in internal email - unless they are explicitly asked to express their legal opinion. At least, that sort of thing has been part of on-boarding training in pretty much every place I've worked in the last eight years.
Except that's not what he says. Patents are not, at any point, mentioned in the memo. The memo expresses a desire to use the Java trademark in marketing Android. It is well-known that Sun required licensing of the Java Technology Compatibility Kit and a successful pass of its tests before it would allow you to use the Java trademark in this way, so the license stated as required (a license for the TCK software, not a patent license) would most definitely have been required IF google had proceeded with the plan as it was described in that memo. They did not proceed with this plan, however, instead deciding to distance themselves from Java, make their virtual machine incompatible with the Java virtual machine (although providing tools supporting automated translation between the two formats), and not use the Java trademark in any of their marketing material. So it is unclear what relevance a (correct) statement about the licensing terms on the Java trademark has on a court case about a system that does not use that trademark. This so-called "smoking gun" is just misdirection on Oracle's part.
Reality? The reality is that a design document written before coding starts is likely to never be accurate enough to perform the kind of annotation you're talking about, because as soon as coders sit down with it to actually implement stuff, they'll realise the design missed some crucial point of logic about how the application should work. And as soon as the code is demonstrated to the customer, the customer will point out misunderstandings about the design. And as soon as you start changing requirements your entire cross-referencing scheme starts taking more time than actually implementing the software does. The developers begin to hate it. The managers start to hate the developers because they can't stick to an apparently simple scheme. QA wonders why the software that has been produced appears to be different to the software they expected to be testing (because the coders had to update the spec to fix logical ommissions, but nobody forwarded the revised spec to QA), and starts filing bugs against correct behaviour. Before long the entire system falls apart and people are bickering about whose fault it is.
Been there, done that, and it's the last time I ever work for an FTSE250-listed corporation.
Actually, he's talking about something entirely different to literate programming. LP advocates writing a single document that contains both documentation and code, whereas what this guy's actually advocating is basically finding a reason to take a second pass at looking at the code, which is what happens when you document it separately. You'd get the same benefit from, for example, having a policy of self-reviewing code after completion, or in TDD the refactor phase of the red-green-refactor cycle.
Writing documentation after writing the code shows that he doesn't exercise TDD, either.
He could be writing *extra* documentation. Not everyone is happy with the idea that tests are documentation.
But as for finding bugs, I don't know. You may document exactly what you intended, and thought the code did, but still be wrong because of some corner case. Documenting it isn't likely to reveal all of these situations any better than the code itself.
Handling corner cases is accomplished by identifying what they are and specifically implementing code to handle them when necessary. In order to identify them, we must think about what the code is doing. As programmers, there are three times we do this:
- When writing the code
- When testing the code
- When writing the documentation
It happens that we tend to pick up different corner cases in each case. This happens because different corner cases require different ways of thinking to identify them, and while performing these three activities we tend to be thinking in different ways (logically, spatially, and verbally, as a rough approximation). So, yes, I think coding and documenting is likely to reveal corner cases better than coding alone, particularly if we leave a few days between coding and documenting (thus allowing us to forget how we were thinking about the code at the time we wrote it, and get more into the verbal method of thinking about the problem).
The site you link to only appears to have a subset of the import tariffs based on origin country. If you click a specific product code to get to the country list it will show you the countries it has data for. If you select (e.g.) China from the drop down list at the top right, it will tell you it has no data for import tariffs on the product you selected from China. It also doesn't have data for Taiwan. As broadcom's preferred manufacturers are located in these countries, it is highly likely one or the other will be the relevant country.
To get the full list, you apparently have to pay a subscription to HMRC.
Has this been marketed so many dilettante geeks who didn't already know about the myriad of options may buy them? Yes
What myriad? Which other products have a multi-hundred-megahertz 32-bit processor, 128 or higher MB of RAM, and respectably powerful DSP and GPU functionality for under $40? For under $80?
Duty is 15% at most on electronics imported into the EU
You don't know what you're talking about. The situation is very complicated, and varies depending on the type of component and the country of origin, but, for example, the duty on DRAM imported from Korea is 32.9%.
Methods aren't copyrightable, only fixed works.
The x86 architecture may be Intel's, but the instruction set was largely based upon the Z80. Zilog would still hold the copyright on that.
The Z80 was a clean-room reimplementation of Intel's 8080, I believe.
I wouldn't be sure. Most architects claim the right to prevent other people from building buildings from their blueprints, even if they have legally acquired copies of those blueprints. I don't know if this has ever been tested in court.
Internet Explorer is a derivative work of NCSA Mosaic. Does this mean Internet Explorer isn't copyrightable?
MUDs are unlikely to satisfy the requirements of the patent, as I'm pretty sure that none of them (at least none of the ones I played) send updates of only some of the positions of players in a room based on whether they are visible to the client. In fact, all the ones I remember only sent enter/exit position updates, which were sent to everyone in the room.
You missed a bit:
Doom did not do this.
The application date was November 95, so presumably not.
VRML was a client side technology. This patent describes a server side technology for sending real-time updates to a 3d client.
Doesn't matter. The technique described in the claims (essentially, a server that works out which other users a user's avatar is able to see and only sends position updates for those, with various variations - all of which are obvious - involving how the necessary information is to be stored in a database) is so fundamental, I find it highly unlikely that there was no prior art older than even that. The defendants should be looking at, for example, CitySpace, a networked virtual world system that was demonstrated in 1993. Failing that, any number of examples of similar behaviour in different fields could be used as a basis for an argument of obviousness.
Cool, there will be chicks with three boobs soon :D :D
Yes, but unfortunately they'll look like they're made from plastic.
Paper is available for open access here: http://ijass.org/On_line/admin/files/2)(014-026)11-030.pdf
Haven't read it yet, but they seem to have analysed with multiple definitions of complexity.
This is just like the judge in the UK that ruled that an electronic key was quiet different to a physical one (the infamous Prestel hacking case) - where any "reasonable" person would say they perform the same function so they are the same.
As Spock said "A difference that makes no difference, is no difference"
The difference made by this difference is that if you steal something physical, the original owner no longer has it. In this case, the original owner still had their code, hence it wasn't stolen.
No golden age lasts forever.
True. Any fool knows, golden ages last 20 turns.