You're misunderstanding the licensing issue with GPLed libraries. The licensing issue is that by linking against the GPLed library, you are using the actual GPLed code as part of your product, not just the headers, thus making your code a derivative work of that GPLed code because it depends on that code for correct operation. Now there is some room for debating whether or not that really is the case, but that's the basic argument.
If you built the library [into your code] statically, the outer program would become [virally] GPL. If the GPL library is a dll/so, this becomes murkier. To be completely clean, the following would probably work. To protect a proprietary program (A) from a GPL library (B), create a program (C) that links with library (B). You distribute (C) to comply with the GPL. (A) talks to (C) through a socket interface and sends RPC-like requests. Since (A) has no direct contact with (B), (A) is free to remain proprietary.
So does that mean the derived work ends up running "privately" on a hypothetically large number of people's machines, without ever being propagated in the language of the license?
Quite possibly. The infringement would be a "private affair" of the end user. As Julia Child once said [regarding what happens in one's own kitchen] "Who's to know?"
However, IANAL, but, it would appear to run afoul of the Grokster decision, which would make Maven liable, because it condones/induces infringement by others.
That depends on whether they assigned the copyright along with the submission. If they had already assigned the copyright to Sun (as I believe was required to have it accepted), then they would no longer have the right to submit it anywhere else. Such is the stupid world we live in, which is why I can easily believe that a developer would have forgotten they did it, especially on such a trivial function.
Your point is well taken, so I did some checking. openJDK submissions require that you accept the "Oracle Contributor Agreement" [nee Sun]. From that document:
2. With respect to any worldwide copyrights, or copyright applications and registrations, in your contribution:
- you hereby assign to us joint ownership, and to the extent that such assignment is or becomes invalid, ineffective or unenforceable, you
hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights
under those copyrights. This includes, at our option, the right to sublicense these same rights to third parties through multiple levels of
sublicensees or other licensing arrangements;
- you agree that each of us can do all things in relation to your contribution as if each of us were the sole owners, and if one of us makes
a derivative work of your contribution, the one who makes the derivative work (or has it made) will be the sole owner of that derivative
work;
- you agree that you will not assert any moral rights in your contribution against us, our licensees or transferees;
- you agree that we may register a copyright in your contribution and exercise all ownership rights associated with it; and
- you agree that neither of us has any duty to consult with, obtain the consent of, pay or render an accounting to the other for any use or
distribution of your contribution.
The first two clauses appear to cover it. The joint ownership clause seems mostly concerned that any submission grants rights to Sun/Oracle to use the code. But, the original submitter retains parallel rights [as long as they don't try to revoke Oracle's right]. The derivative work clause implies that either party may make a derivative work without consulting the other and gets full rights to the new work.
Thus, giving the rangeCheck function to Android is allowed by this agreement under either of these two clauses.
That wasn't the Jury deciding whether they were copyrightable; they'd been asked about their opinion assuming it was (juries are supposed to determine facts, rather than law). That was the jury (failing to) decide whether Google were nonetheless allowed to use the API under fair use, even if it were copyrighted.
Yes. It was prudent of Alsup to ask the jury to decide this because it removes one of the grounds for appeal (e.g. if he hadn't and subsequently rules that the law is that the API itself [rather than the API document] is copyrightable).
Given that he evinced an interest in the recent EU ruling that a program [even one that is copyrighted] may be dissected (e.g. disassembled) to support clean room recreation, it seems likely he will rule that the API is not copyrightable. That is, if disassembly is okay for clean room, merely reading the API document [a lesser offense] to clean room implement Dalvik would be okay.
To rule that the API itself is copyrightable, would probably make anybody who has ever written a Java program guilty of infringement [if they didn't have an explicit license]. This would have severe negative implications for software development on any platform, open/free or commercial, Java or not.
It doesn't matter anyway. There were only nine lines of copied code and the only reason it was there is because the guy that submitted it originally to openJDK is the same guy that put it in Android.
IANAL, but if this is so, this would indicate the original submitter would be the copyright author for the code ("rangeCheck"). If s/he was not a Sun employee at the time (e.g. the submission was done as free software), s/he would be free to submit to both code bases. This person would be the only person in the world that has such right. Thus, rangeCheck is not even copied from one code base to another. Ergo, even if the code is identical, there is no copyright infringment.
The story dwells on one person's story. There are any number of people (both Americans and immigrants) who take any available job and try to work their way up, but opportunities never appear.
The story also has a link to a [105 page] PDF titled "Silicon Valley's New Immigrant Entrepreneurs". But, it's from 1999... I skimmed it. Part history of immigration and some statistics and a few case studies. But, as far as I could tell, it offers no comparison to American entrepreneurs [hence the title, I guess].
The algorithm can probably be retrofitted onto some/most equipment [via a firmware upgrade]. Since it's not a protocol change, it doesn't affect other routers in the path (e.g. mandate that it be implemented as an all-or-nothing). The incentive is that after you charge your premium for QoS, you actually have to deliver it.
Isn't this different? Google recreated/copied that language and still call it Java. To use car analogy Oracle Java(TM) is like Ford Mondeo(TM) and Google created their own unlicensed Mondeo and even named it Mondeo, Microsoft for example branded it J++ instead of Java. Google is using the word Java all over in their documentation. To me this look is more like trademark and design patent (Java syntax) problem then a copyright issue.
This ruling says that Google was within its rights to reverse engineer Java and create Dalvik (the VM). While you're correct about the possible trademark angle, trademarks are a funny thing.
For one, "java" is a slang term for coffee. This was true before the language. That's why the java logo is a steaming cup of coffee. Thus, because it's a common term, it may not be eligible to be trademarked.
Unlike patents [where you may selectively pursue infringers as you choose without losing any rights], trademarks must be vigorously enforced. You must take legal action against just about anybody using the trademark improperly.
If you don't, you lose the right to the trademark (e.g. Kleenex for tissue, Thermos vs vacuum bottle, Sanka for decaf coffee). All these trademarks/brands allowed a usage (and it only takes one) in a generic way and lost the right to the trademark. That's why aspirin is a trademark [of Bayer Pharmaceuticals] in Europe, but in the U.S., it's a generic term for a pain reliever that any manufacturer may use.
I suspect that Sun/Oracle has been too loose about this and we'll be able to strip them of their trademark readily enough.
You are not a common carrier simply because you install a cell repeater to serve your own customers in your own premises. They aren't disputing being a common carrier because nobody said they were such.
BART is a common carrier. You're confusing it with a private business. They're not disputing it because they want to be one to get the safe harbor provisions [which I mentioned in my last message, but you chose not to read].
Cell repeaters are not illegal, and you can go here and buy one for yourself:
It's not illegal to buy one. It is illegal to use one unless you have a license. Particularly, if you've set it up incorrectly [and are causing interference], you'll have a representative from your local cell phone company showing up on your doorstep. You must have the consent of the licensee.
The FAQ you cited [cleverly] omitted any reference to legality of operation. You got bamboozled into thinking that just because you can buy one, it's legal to use it. It's also legal to buy a cell phone jammer but it is not legal to use it.
Once I got this far, I realized you don't have a clue what you are talking about and lost interest
Absolutely I do know what I'm talking about and everything I've said is verifiable on the web if you had taken the time to check it yourself [using a source that is a tad more credible than a site whose sole purpose is to sell you something].
It has yet to be established that the cell service in the subway was common carrier.
If you provide these services to the general public [which BART did], it is common carrier. Not even BART is disputing this. Their argument is more along the line of the circumstances justified an exception to the rules.
It may have been simple off the shelf cell repeaters operated by Bart itself.
It is illegal for individuals and businesses to install/use cell repeaters. Only a licensed carrier may do this. That is, if you're a business/individual, the carrier/licensee must install/maintain the repeater for you. A rogue repeater subjects the owner to possible equipment forfeiture, fines, and/or imprisonment.
After all, you don't find Verizon suing Bart do you?
That's because [in all probability] Verizon set up the repeater system for BART.
And further, there was no discrimination. Simply a system wide outage.
An outage due to technical reasons/failure is vastly different. Deliberately pulling the plug [because of the potential speech/content] violates basic rules for common carriers.
The reason for this is that common carriers enjoy a "safe harbor" from the actions of their users. That is, if person X decides to kill person Y and uses BART to travel to Y's residence, BART enjoys immunity. Without such immunity, BART would an accomplice before the fact. In exchange for such safe harbor immunity, BART may not discriminate. If it does, it risks losing its common carrier status and exposes it to all sorts of liability.
However, in the above example, if a person Z (rather than BART) transports X to Y's place, Z is an accomplice [because Z is not a common carrier].
This safe harbor is also true for telecommunication carriers [common carriers]. If X uses the carrier's network to discuss/plan the murder of Y with Z, the carrier is not liable for their actions.
Apparently its illegal to jam cell phone transmitters
A felony if I'm not mistaken.
but not technically illegal to unplug them.
Its entirely possible the FCC will find itself powerless in this fight, because there is no mandatory "must operate" regulations in place.
Uh, no. Cell phone operators [and telcos] are common carriers, subject to Title II regulations, under the Communications Act of 1934. Common carriers [by definition] are prohibited from discriminating service, based on the content of messages (e.g. voice, data). The FCC has complete authority to regulate this matter [from this Act].
If you are going to rush in and pronounce something "illegal, plain and simple" please provide your credentials, and what year you were appointed to the bench.
But the eye is seeing a picture rate (to be unambiguous) of 60, if you're talking about video (sports, news, etc).
I'm a computer engineer with extensive R&D experience with HD H.264 video compression but I'm not sure what you mean by "picture" rate. Interlaced video content has a field rate of 60. A frame is composed of two fields: top/odd and bottom/even. Standard video is 60 fields/sec which is 30 frames/sec. But, if you converted the video to progressive and transmitted it that way (at 30 frames/sec), it would look jerky.
So, I'm going to assume that what you mean by picture rate is the field rate for interlaced material or the frame rate for progressive. A picture rate of 30 is too slow to produce smooth motion for the eye. You need a picture rate that is higher. That's why film (at 24/fps) is double shuttered to produce [pseudo] 48/fps). This gets you closer, but some people can [still] see flicker at 48. Interlaced video material has a picture rate of 60. A picture rate of 60 is generally the requisite in the video world. Interlacing gets you 60, even though the frame rate is still 30. That's why it's popular with the industry. You get the effect you need with only half the data being sent.
It still sounds like you're suggesting that, from 30fps-based (i.e. "filmy" material), displaying those two halves of the same moment in time one after the other somehow improves the apparent smoothness, but it won't.
Actually, it does. That is what interlacing is all about. Additionally, film content is 24 frames/sec [not 30]. To be transmitted over a video channel [or put on DVD], this has to be converted to an interlaced field rate of 60. This process is called telecine (2:3 pulldown). Telecine is accomplished by splitting the film frames into fields and repeating them:
Those last two are equivalent. They might look slightly different on interlaced/progressive CRT screens, but one will not look smoother than the other.
Uh, no. They are not equivalent. The "interlaced film-rate" has a picture rate of 60. The "progressive film-rate" has a picture rate of 30. The latter is too slow and will produce a [noticeably] jerky result.
NTSC/PAL video is interlaced because it was originally meant for display on CRT TVs.
Uh, no. The original reason is that you can get sufficient [apparent] frame rate in half the channel bandwidth (e.g. 6Mhz for interlaced, but you'd need 12Mhz for progressive). And, at the time that NTSC/PAL were being developed, there were no transistors, only relatively slow tube amplifiers. CRT's can be either interlaced or progressive. TV CRT's were interlaced because that's the method that NTSC/PAL used.
If you display "progressive" video on a CRT, when the electron gun reaches (=lights up) the lines at the bottom of the screen, the phosphors of the lines at the top will already be too dark and this will be perceived like a flashing of the image. With interlaced video instead the electron gun is passing on every single line 60 times per second, reducing the line fading between a pass and the next one.
Possibly. I'm not sure about what the persistence characteristics of early orthicon/display phosphors were. But, these days, you can request just about anything you might want.
In related trivia, did you ever wonder why PAL is 50fps and NTSC 60fps? It's because the field rate of the first TV radio transmissions (in the 1950s) was synchronized with the AC power lines (while now it is sent to the TV set through a glitch in the signal itself). And while in the US the power lines frequency is 60 Hz, in Europe, were PAL was later adopted fixing the color problems of NTSC (at the time nicknamed the "Never Twice Same Color" standard), the frequency is 50 Hz. These number refer of course to the interlaced 60/50 Hz "field rate", and not the progressive 29.97/25 Hz "frame rate".
Uh, sort of. Matching the refresh rate to the power frequency eliminates intermodulation/beating (which produces rolling bars on the screen). When color was added to NTSC, the rate was reduced from 60 to 59.94 to eliminate distortion due to the difference in the sound and color subcarriers.
Although the NTSC color spec (1953) had a precise definition for colorimetry, this was frequently ignored (hence the "Never Twice Same Color"). The reason was that early color phosphors in cameras had poor brightness characteristics. This required very bright/hot lights for color programs. Camera manufacturers were constantly improving the brightness characteristics of their phosphors. But, each manufacturer's phosphor had different color characteristics.
It wasn't until the "SMPTE 'C' phosphor" standard came along in 1969 that introduced the notion of a "standard" phosphor. After that, each manufacturer was able to calibrate the difference between their phosphor and the standard one, and add color correction circuitry to their equipment.
Post 1987, SMPTE C was fully ratified as a best practice. By this time, phosphor technology had reached the point where sufficient brightness was available and manufacturers adjusted their phosphors to produce the standard output without the need for correction circuitry.
Perhaps you're not explaining yourself clearly, but it's not like that at all. Interlaced video really does have twice the temporal resolution (at the cost of vertical resolution) - the eye isn't being made to believe anything that isn't true.
I'm a computer engineer that has done extensive work with HD H.264 video compression but I was trying to keep it simple for the intended audience. Also, more people [apparently] are familiar with field/frame rates than the double shutter technique in film.
What the eye is being made to believe is that it is seeing a frame rate of 60 when in fact that's field rate and the frame rate is half that. And that two fields sent in sequence form a single frame [and don't remain as fields]. Without interlacing (progressive scan), the data rate would be insufficient to provide [somewhat] smooth motion.
In general, the eye is being made to believe that a [rapidly changing] sequence of still images have motion [at all]...
All modern/ordinary film is shot in the camera at 24 fps but projected with a shutter speed of 48 fps. Each frame is double shuttered in the projector and has been for years.
---
This is a bit like TV that has a frame rate of 30 (29.97) but a field rate of 60 (59.94) because it's interlaced. It prevents jerky motion because the eye believes it's getting a frame rate higher than the true frame rate (e.g. it perceives the field rate to be the frame rate). When film is put on a DVD it has to undergo a telecine process to raise the field/frame rate.
Some people I know [with better eyes than mine] can see flicker in 24/48 film content. They actually prefer video because of the higher frame rate.
Without knowing the specific patent in question, it's difficult to provide accurate non-legal advice. However, from the TED/talk article, a few points come to mind:
---
- While tacking on a fee of a few thousand to read your response might be reasonable, going from 2% to 4% seems like harassment. The "triple reverse legal fees" argument might apply.
- Also, if the original 2% figure was just, why would a simple letter from you be a reason to up it to 4%? Either somebody's manic or your letter showed [to them] that you're not infringing and they're now just trying to bluff you into settling [because they fear the same argument will be made to a judge].
- Is the patent "obvious" or is their prior art? While a literature search in support of prior art can be expensive, it may be less expensive than alternatives. Requesting a reexamination at the USPTO might be appropriate [filing fees are modest].
- Contact the EFF. They might not want to take up your cause, but they might be able to point you in the right direction.
- What are the patent claims? Reexamination might strike some of the claims and reduce the burden.
I remember that slogan. Not too long ago even. Before that it was "Think different" and buy the most common mp3 player on the planet. I dislike apple because I dislike marketing, and Apple is like an avatar of marketing; the essence of style over substance given form.
Well consider the slogan "Think different". You can say "Think: different" [with a colon] or "Think differently" but the actual slogan is just defective grammar. And Apple didn't replace that either...
The problem is that there's more than Java at stake. Oracle also has a bunch of patents pertaining to VMs in general, especially JIT-compiling. From what I've heard, those are broad enough that e.g. Microsoft licenses them to cover.NET - and.NET is fairly different, implementation-wise, from HotSpot. Now Oracle is arguing that those same patents also apply to Dalvik's JIT. If that's still on the table in this lawsuit, dodging it would be much harder than just changing languages.
VM's go back to the 60's. Java was released in 1995. But, perl has a VM and it was created in 1987.
To me, JIT-compiling isn't much different than a multistage regular compiler (e.g. gcc--released in 1987). The first stage ("front end") parses the language and produces an intermediate meta description (e.g. register transfer language or RTL). This is passed off to the next stage which does optimization and code generation. The RTL is very much like a VM. Thus, all the papers on compiler optimization techniques that have been published for regular compilers serve as a basis for prior art against JIT. I vaguely recall some entity shipping the RTL files and having the target system do the final stage dynamically. That's an example of WORA/JIT prior art.
MS licenses things because it has its own patent portfolio. It's easier to license and MS doesn't want to set a precedent of patent busting because that might give others such ideas. Also, no doubt MS has some patents that they have cross-licensed to Oracle. "So, why rock the boat"?
But, as I mentioned previously, when Sun went after MS and wanted an injunction, MS fought back. Since Oracle wants an injunction, Google will fight back and I suspect that regardless of the trial outcome, the patent busting effort will continue unless Oracle sobers up.
Oracle seems intent on alienating just about everybody. HP is upset that Oracle is dropping support for its database products on Itanium architectures (of which HP has a lot). If Oracle keeps this up, they're going to become the subject of an antitrust investigation. Also, I suspect people (e.g. programmers) will retaliate by designing out Oracle products.
If Oracle does win, and Android is killed, it will anger telcos. Oracle might wake up one day with telephone/internet service to its corporate headquarters cut off:-) So, Oracle, who's your daddy now?:-)
They can argue FRAND in that case because Moto has actually signed a bunch of disclaimers when they submit their patents to the standard org. I very much doubt you can argue FRAND on a random technology by claiming that it is a "de facto standard".
Fair enough. That doesn't mean Google won't try [and may be successful]. This may be strengthened slightly by Sun's previous two separate attempts to submit Java as a standard to JTC1 and ECMA.
Oracle is playing a dangerous game [for themselves] on several fronts.
The reason that Java became popular was the "write-once-run-anywhere" [WORA] and that Oracle [nee Sun] would provide access for any platform. If Oracle wins, this collapses and many independent developers would see the need to reconsider their strategy in light of the fact that Oracle [on a whim] could deny access to a platform that is the developer's primary market.
The implications go far beyond Google. If Oracle wins, this would imperil not just Google, but telcos, handset makers, and tens of thousands of software developers. Legalities aside, the court will be aware of the potential widespread economic chaos that might ensue and temper its judgement accordingly. The court might refuse the injunction and compel Oracle to offer a license [Google might have to pay the $30M damages + license fees but it would be free to pursue Dalvik/Android]
Further, if Oracle prevails, the federal government might view Oracle as a "sole source supplier". In other words, no government contract would be able to use Java in it. For example, because Apple is considered to be a sole source supplier, the FDA will not approve any medical system that uses Apple/Mac technology. That's why you always see PC's (or Sun's) at your local doctor's office. Or, if Java has found its way into certain gov't systems, the federal gov't may seize/nullify the patents under national security grounds.
Also, I believe Google has filed with the USPTO for a reexamination on the patents, arguing they are obvious or there is prior art, etc. Personally, I'm not currently up on what patents are being asserted. But, as a computer engineer, I'm hard pressed to see what could patentable in the JVM as machine architecture simulators/emulators have been around since the 1960's.
In the 1980's, when [AT&T] Unix was the only variant around, they were controlling it and didn't want a formal standard. That's how POSIX came about. Using [court tested] "clean room" techniques, they were able to come up with a standard that gave rise to other implementations (e.g. minux and linux). That's why linux is called POSIX-compliant and not Unix-compliant. This could happen for Java (HP had a clean room Java implementation for embedded systems in the 90's).
In the late 1990's when Microsoft was creating a Windows specific variant of Java [mainly to eviscerate Java], Sun took them to court and got a preliminary injunction. The appeal [which MS won] was that the punishment did not fit the crime. In other words, a breach of contract should not be punished by means of an injunction. No doubt this ruling will be cited in the current case.
Google didn't clean room the Dalvik JVM for the same purpose as MS. The Sun/Java JVM assumes, more or less, a fairly powerful machine (e.g. a PC/Mac/mainframe, etc.). It is too slow/bloated for "low power" (e.g. CPU speed, memory, disk space) handset/tablet. Likewise for the Java Runtime Environment (JRE). It's meant to be a one-size-fits-all kitchen sink approach. Way too big to fit on a small nimble device, yet it would need additional handset specific classes and the generic classes that have no use in a handset would need to be trimmed.
Weaning off Java might be as herculean a task as the U.S. converting to the metric system. At worst, Google might have to call it something other than "Java". But, end users kn
Does google even have any direct revenue for android?
Jason
Not in pure form directly. It is completely free.
They encourage developers to download the source SDK (all 8.1 GB of it). I have it on my machine and take updates all the time. This doesn't include the Android kernel, but this is also freely available for download. In fact, the Android mods to Linux have [just recently] been added back to the mainline kernel tree.
All of the "front facing" [to app developers] APIs are common. If you're a small shop app developer, you're good to go.
But, handset manufacturers may need some custom mods to the kernel to provide optimal performance on their platforms or support a unique device they have. They can [and some do] make the mods themselves. They can maintain their own source deltas [which is easy enough to do because everything is maintained by git].
If, however, you want professional developer support [beyond filing a bug tracking report], Google will [probably] provide that--for a fee (or some other revenue sharing arrangement). Since most telcos and handset/tablet manufacturers are risk averse, they will usually have such an arrangement.
Seriously dude. Oracles remedy seems to involve killing davlik. That means no java on the android. Its a scorched earth aproach to IP litigation, and you better hope oracle fails on that.
Yes, I noticed the scorched earth approach. However, there may be a ray of hope against that approach. Because Java is a standard [if only de facto], Oracle may be compelled to offer a license under FRAND [fair, reasonable, and non-discriminatory] terms. Google's offer of 1/2 of 1% is in the FRAND ballpark for a mass market item.
In the Apple/Moto fight in Germany, Moto got an injunction against Apple for infringing some Moto patents. They got the injunction because Apple had not negotiated in good faith [stalling for five years]. However, latest ruling appears that Apple might reverse this on the FRAND argument.
Ok, I created an account. It will be simpler for others to follow. Comparing me to Linus or Eric Raymond is really over-the-top. I'm just a PhD student who has been working on power management in nouveau for little more than 1.5 years.
I'm not hairyfeet that you did the reply to. But, since you referenced info from my post in your reply to his, I'm assuming you just tried to consolidate things. One of the advantages to having an account is that your posts start at level 1 (vs 0 for AC) and people are more likely to "mod you up" and improve your "karma" if you post as yourself (or even a pseudonym as I and many others do--slashdot!=facebook). Eventually, if your karma goes high enough, your posts automatically start at level 2.
Anyway, the answers to your post are right, clean-room REing is legal. The shady part is for the firmwares that you have to decode in order to re-implement them. Fortunately, we know nvidia used a compiler to compile them. As we write them in asm only and don't use the same interface, I guess we are pretty covered.
I was familiar with clean room because I was once part of such a project. I was aware nVidia drivers had parts that they considered to be "secret sauce" algorithms (and ATI didn't?). From what you said, I'm assuming it was the firmware which must be loaded onto the card?
As for video decoding, nVidia though about us and added a "safe" for the encryption keys. So yes, we can re-implement video decoding (it is an on-going work, but it's ugly) but the compliance with hdcp will never come.
I'm only vaguely familiar with the requirements for HDCP compliance, but I'm guessing that safeguarding keys is part of it. So, my assumption is that nVidia needed to do that, in general, rather than to specifically make it difficult for the nouveau project.
Perhaps, the libdvdcss approach by players will work. The players don't have de-CSS capabilities themselves, but they do look around for the lib. If it "happens to be around" (e.g. liability is shifted to the end user who downloaded it separately), they will use it.
Lastly, nVidia said they would neither help nor hinder the project. If there is something they don't like, I'm sure they will let us know before going to court. If they wanted to go to the court, that would be one hell of a pain since they would have to sue individuals from many countries, mostly european.
I'm a software engineer who writes drivers for realtime H.264 hardware encoders. The company's take on this was that the card itself was the protection of the "secret sauce". The drivers were merely conduits to that. The amount of engineering to design logic, verify it, layout the chip, get it fabbed, etc. is so huge, that the driver is a relatively small part of it. In other words, you always need the card, so everything else is protected without needing specific protection of its own.
Another assurance for nVidia is that they know how slow going the RE is, compared to what they can do. They'll always be several steps ahead, no matter what. So, nouveau is no "threat" to them. The only people they're really concerned about are competitors like AMD/ATI and Intel that make HW.
Broadcom used to have the same philosophy for their wireless chip driver. In particular, no linux driver of any kind. The only way to get it to work was to use the windows driver with a glue interface. There was a native FOSS driver done, but you still had to extract the firmware from the windows driver. Finally, after years and years [and realizing that linux was no mere fad], Broadcom relented and produced a binary driver for linux and actually split off the firmware into a separate file. The irony in all this was that Broadcom had been using embedded linux internally on their chips/cards for years.
Most of us are students, that would be bad PR to sue us:D
Be thankful you're in Europe. In the US, the RIAA has been known to sue widows and orphans:-)
Now for my other question, since you are basically snatching the data from a binary blob which i'm sure is full of proprietary code, after all if it wasn't they could just FOSS the thing, do you worry about DMCA? i know that AMD can't release full specs on their GPUs because protected path isn't theirs and would break DMCA and since Nvidia cards i'm sure have protected path as well do you have to worry about legal ramifications? or have you set up the project in some place that doesn't recognize software patents?
What nouveau development does is feed data through the API and look at the I/O ports and what data they get. The developers are feeding data they "own" [e.g. the address of a frame buffer they created] and then retrieving it after it is transmuted. Virtually all devices in a system (e.g. disk controllers, etc.) have a port list so just having that is not novel (i.e. not patentable). Since nVidia isn't publishing a document on the port list, no copyright either. Might be claimed as a proprietary trade secret, but it's okay to reverse engineer in this manner [reverse engineer is a protected activity under the right "clean room" circumstances].
The "clean room" methodology has been court tested many times. In this instance, we have three groups that do not communicate, except in controlled ways. Group A does the above "port probing" and writes a document of their findings. Group B writes an API document using only Group A's report. Group C uses the API document generated by Group B to write the device driver code.
If you ARE Mr Peres I would like to say I admire your guts, frankly I wouldn't want to go within 100 yards of anything to do with video as long as all these crazy patents and lawsuits are going on. And how about hardware acceleration of video? How can you do that without ending up in the whole H.26x patent minefield?
No doubt nVidia has a license to H.264 patents. Under the exhaustion doctrine, anyone can benefit from using the API to output H.264 video. If that were not the case, any end user [even using nVidia's proprietary driver], would be required to pay H.264 patent licensing fees. Likewise for the use of one's home entertainment system.
However, that doesn't mean some folks don't try. Lodsys [a patent troll] licensed a patent to Apple. Apple incorporated the technology under an API that software developers can use. Lodsys has been trying to extract license fees from all software developers that use the Apple API. Apple is intervening in court to stop Lodsys using the exhaustion doctrine as the basis for their challenge against Lodsys in defense of the developers.
Frankly I think its a shame that such questions even have to be asked as while i have no problems with proprietary software and use both FOSS and proprietary software every day i do NOT support software patents but as long as that minefield exists I am curious how you intend to approach feature parity with the blob driver without stepping into the whole patent mess since one of the big uses of GPUs is video processing and that's patented up the wazoo.
It's not so much the patent mess (as I mentioned above), but rather the difficulty of deducing the port list, API doc, etc. using the clean room method. The 2D case is [relatively] easy enough. The 3D case [with a large number of acceleration modes, etc.] is a lot more work, many more test cases, etc. Sheer scope of such an undertaking is the biggest limiting factor.
There have been many 3D movies. Unlike the groundbreaking movies you mention, they haven't really had much impact beyond what they would as 2D movies. Nobody cared that The Jazz Singer wasn't 7.1 surround sound with the ability to blow the audience through the back wall, just having sound at all was enough because people wanted movies to have sound.
You're mixing my metaphors. I didn't hook 7.1 to "The Jazz Singer". What I said was that TJS killed off the silent film industry overnight.
The color in early color films was far from perfect but people loved it anyway because they wanted movies to have color. Color TV suffered a bit because it couldn't live up to a color film, but ultimately, people wanted color TV as well.
Not everybody thought color film was a great idea. In actual fact, Carole Lombard was against it on artistic grounds, technology notwithstanding. As I mentioned elsewhere, Hitchcock's "Rebecca" uses cinematographic techniques that would be impossible in color. It's a much more sinister/better film in B&W.
Unfortunately, you have to move your head around until you find a sweet spot to get decent 3D, and then you can't move or the spell is broken. That isn't what I would call an improvement.
There are several competing glasses-free systems.
But there IS perception of 3D in 2D. Do I know when someone is walking towards the camera? Yes! Do I know when one person is behind the other? Yes! Does it look like the outfielders are going to collide when they're not? No. I can perceive the depth.
I never said that there wasn't perception of 3D in 2D. But, this is the human mind synthesizing the missing 3D parallax information that is not given to the eye in a 2D system (as they both get the same information), based on [psychovisual] clues.
I didn't say that 3D provided nothing, I said it merely enhances an existing perception rather than adding one that wasn't there before. Enhancement can be nice, but it doesn't have the same impact.
3D isn't merely enhancement of perception. 3D is giving different parallax views to each eye. That is what 3D vision is, whether real life or not. Please... Do some research as mixing them up as you're doing is just showing ignorance and lack of understanding. No professional video R&D engineer will agree with your description.
I didn't see Avatar, but I have seen polarization based 3D. I've seen color based 3D in the theater and on a conventional Color TV. I've even seen wigglevision demoed on TV in the late '70s. It's All pretty good as a visual spectacle. The wigglevision had the most potential for impact since it could take you by surprise, but it never even got used for a commercial.
So, you didn't see Avatar [as I had already surmised]. You missed out on the seminal 3D work? You're basing your opinion on the [inevitable] dreck that follows? After Jazz Singer and Robin Hood there were many forgettable sound/color films.
However, anyone who saw Avatar 3D doesn't believe 3D is failing. It's more like "I'm disappointed that some of the other films aren't living up to what I saw in Avatar". But, they're willing to wait, because they saw the technology work [a proof of concept]. To them, they're just waiting for the next great 3D film that they know will come eventually.
As for the rest, it reads an awful lot like "Well, yeah, 3D is down by 50 games in September, but We'll get 'em next year!" (or in 10 years). We'll see in 10 years when the technology is ACTUALLY suitable, but that will still mean the push right now to do 3D everything will have failed.
You failed to read other parts of the thread [as I had suggested] where I explained many things in more detail.
Slashdot Mirror
You're misunderstanding the licensing issue with GPLed libraries. The licensing issue is that by linking against the GPLed library, you are using the actual GPLed code as part of your product, not just the headers, thus making your code a derivative work of that GPLed code because it depends on that code for correct operation. Now there is some room for debating whether or not that really is the case, but that's the basic argument.
If you built the library [into your code] statically, the outer program would become [virally] GPL. If the GPL library is a dll/so, this becomes murkier. To be completely clean, the following would probably work. To protect a proprietary program (A) from a GPL library (B), create a program (C) that links with library (B). You distribute (C) to comply with the GPL. (A) talks to (C) through a socket interface and sends RPC-like requests. Since (A) has no direct contact with (B), (A) is free to remain proprietary.
So does that mean the derived work ends up running "privately" on a hypothetically large number of people's machines, without ever being propagated in the language of the license?
Quite possibly. The infringement would be a "private affair" of the end user. As Julia Child once said [regarding what happens in one's own kitchen] "Who's to know?"
However, IANAL, but, it would appear to run afoul of the Grokster decision, which would make Maven liable, because it condones/induces infringement by others.
That depends on whether they assigned the copyright along with the submission. If they had already assigned the copyright to Sun (as I believe was required to have it accepted), then they would no longer have the right to submit it anywhere else. Such is the stupid world we live in, which is why I can easily believe that a developer would have forgotten they did it, especially on such a trivial function.
Your point is well taken, so I did some checking. openJDK submissions require that you accept the "Oracle Contributor Agreement" [nee Sun]. From that document:
2. With respect to any worldwide copyrights, or copyright applications and registrations, in your contribution:
- you hereby assign to us joint ownership, and to the extent that such assignment is or becomes invalid, ineffective or unenforceable, you hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under those copyrights. This includes, at our option, the right to sublicense these same rights to third parties through multiple levels of sublicensees or other licensing arrangements;
- you agree that each of us can do all things in relation to your contribution as if each of us were the sole owners, and if one of us makes a derivative work of your contribution, the one who makes the derivative work (or has it made) will be the sole owner of that derivative work;
- you agree that you will not assert any moral rights in your contribution against us, our licensees or transferees;
- you agree that we may register a copyright in your contribution and exercise all ownership rights associated with it; and
- you agree that neither of us has any duty to consult with, obtain the consent of, pay or render an accounting to the other for any use or distribution of your contribution.
The first two clauses appear to cover it. The joint ownership clause seems mostly concerned that any submission grants rights to Sun/Oracle to use the code. But, the original submitter retains parallel rights [as long as they don't try to revoke Oracle's right]. The derivative work clause implies that either party may make a derivative work without consulting the other and gets full rights to the new work.
Thus, giving the rangeCheck function to Android is allowed by this agreement under either of these two clauses.
That wasn't the Jury deciding whether they were copyrightable; they'd been asked about their opinion assuming it was (juries are supposed to determine facts, rather than law). That was the jury (failing to) decide whether Google were nonetheless allowed to use the API under fair use, even if it were copyrighted.
Yes. It was prudent of Alsup to ask the jury to decide this because it removes one of the grounds for appeal (e.g. if he hadn't and subsequently rules that the law is that the API itself [rather than the API document] is copyrightable).
Given that he evinced an interest in the recent EU ruling that a program [even one that is copyrighted] may be dissected (e.g. disassembled) to support clean room recreation, it seems likely he will rule that the API is not copyrightable. That is, if disassembly is okay for clean room, merely reading the API document [a lesser offense] to clean room implement Dalvik would be okay.
To rule that the API itself is copyrightable, would probably make anybody who has ever written a Java program guilty of infringement [if they didn't have an explicit license]. This would have severe negative implications for software development on any platform, open/free or commercial, Java or not.
It doesn't matter anyway. There were only nine lines of copied code and the only reason it was there is because the guy that submitted it originally to openJDK is the same guy that put it in Android.
IANAL, but if this is so, this would indicate the original submitter would be the copyright author for the code ("rangeCheck"). If s/he was not a Sun employee at the time (e.g. the submission was done as free software), s/he would be free to submit to both code bases. This person would be the only person in the world that has such right. Thus, rangeCheck is not even copied from one code base to another. Ergo, even if the code is identical, there is no copyright infringment.
The story dwells on one person's story. There are any number of people (both Americans and immigrants) who take any available job and try to work their way up, but opportunities never appear.
The story also has a link to a [105 page] PDF titled "Silicon Valley's New Immigrant Entrepreneurs". But, it's from 1999 ... I skimmed it. Part history of immigration and some statistics and a few case studies. But, as far as I could tell, it offers no comparison to American entrepreneurs [hence the title, I guess].
The algorithm can probably be retrofitted onto some/most equipment [via a firmware upgrade]. Since it's not a protocol change, it doesn't affect other routers in the path (e.g. mandate that it be implemented as an all-or-nothing). The incentive is that after you charge your premium for QoS, you actually have to deliver it.
http://arstechnica.com/tech-policy/news/2012/05/oracle-google-judge-asks-for-comment-on-eu-court-ruling.ars
Isn't this different? Google recreated/copied that language and still call it Java. To use car analogy Oracle Java(TM) is like Ford Mondeo(TM) and Google created their own unlicensed Mondeo and even named it Mondeo, Microsoft for example branded it J++ instead of Java. Google is using the word Java all over in their documentation. To me this look is more like trademark and design patent (Java syntax) problem then a copyright issue.
This ruling says that Google was within its rights to reverse engineer Java and create Dalvik (the VM). While you're correct about the possible trademark angle, trademarks are a funny thing.
For one, "java" is a slang term for coffee. This was true before the language. That's why the java logo is a steaming cup of coffee. Thus, because it's a common term, it may not be eligible to be trademarked.
Unlike patents [where you may selectively pursue infringers as you choose without losing any rights], trademarks must be vigorously enforced. You must take legal action against just about anybody using the trademark improperly.
If you don't, you lose the right to the trademark (e.g. Kleenex for tissue, Thermos vs vacuum bottle, Sanka for decaf coffee). All these trademarks/brands allowed a usage (and it only takes one) in a generic way and lost the right to the trademark. That's why aspirin is a trademark [of Bayer Pharmaceuticals] in Europe, but in the U.S., it's a generic term for a pain reliever that any manufacturer may use.
I suspect that Sun/Oracle has been too loose about this and we'll be able to strip them of their trademark readily enough.
You are not a common carrier simply because you install a cell repeater to serve your own customers in your own premises. They aren't disputing being a common carrier because nobody said they were such.
BART is a common carrier. You're confusing it with a private business. They're not disputing it because they want to be one to get the safe harbor provisions [which I mentioned in my last message, but you chose not to read].
Cell repeaters are not illegal, and you can go here and buy one for yourself:
It's not illegal to buy one. It is illegal to use one unless you have a license. Particularly, if you've set it up incorrectly [and are causing interference], you'll have a representative from your local cell phone company showing up on your doorstep. You must have the consent of the licensee.
The FAQ you cited [cleverly] omitted any reference to legality of operation. You got bamboozled into thinking that just because you can buy one, it's legal to use it. It's also legal to buy a cell phone jammer but it is not legal to use it.
Once I got this far, I realized you don't have a clue what you are talking about and lost interest
Absolutely I do know what I'm talking about and everything I've said is verifiable on the web if you had taken the time to check it yourself [using a source that is a tad more credible than a site whose sole purpose is to sell you something].
It has yet to be established that the cell service in the subway was common carrier.
If you provide these services to the general public [which BART did], it is common carrier. Not even BART is disputing this. Their argument is more along the line of the circumstances justified an exception to the rules.
It may have been simple off the shelf cell repeaters operated by Bart itself.
It is illegal for individuals and businesses to install/use cell repeaters. Only a licensed carrier may do this. That is, if you're a business/individual, the carrier/licensee must install/maintain the repeater for you. A rogue repeater subjects the owner to possible equipment forfeiture, fines, and/or imprisonment.
After all, you don't find Verizon suing Bart do you?
That's because [in all probability] Verizon set up the repeater system for BART.
And further, there was no discrimination. Simply a system wide outage.
An outage due to technical reasons/failure is vastly different. Deliberately pulling the plug [because of the potential speech/content] violates basic rules for common carriers.
The reason for this is that common carriers enjoy a "safe harbor" from the actions of their users. That is, if person X decides to kill person Y and uses BART to travel to Y's residence, BART enjoys immunity. Without such immunity, BART would an accomplice before the fact. In exchange for such safe harbor immunity, BART may not discriminate. If it does, it risks losing its common carrier status and exposes it to all sorts of liability.
However, in the above example, if a person Z (rather than BART) transports X to Y's place, Z is an accomplice [because Z is not a common carrier].
This safe harbor is also true for telecommunication carriers [common carriers]. If X uses the carrier's network to discuss/plan the murder of Y with Z, the carrier is not liable for their actions.
Apparently its illegal to jam cell phone transmitters
A felony if I'm not mistaken.
but not technically illegal to unplug them. Its entirely possible the FCC will find itself powerless in this fight, because there is no mandatory "must operate" regulations in place.
Uh, no. Cell phone operators [and telcos] are common carriers, subject to Title II regulations, under the Communications Act of 1934. Common carriers [by definition] are prohibited from discriminating service, based on the content of messages (e.g. voice, data). The FCC has complete authority to regulate this matter [from this Act].
If you are going to rush in and pronounce something "illegal, plain and simple" please provide your credentials, and what year you were appointed to the bench.
Et tu, Brute?
But the eye is seeing a picture rate (to be unambiguous) of 60, if you're talking about video (sports, news, etc).
I'm a computer engineer with extensive R&D experience with HD H.264 video compression but I'm not sure what you mean by "picture" rate. Interlaced video content has a field rate of 60. A frame is composed of two fields: top/odd and bottom/even. Standard video is 60 fields/sec which is 30 frames/sec. But, if you converted the video to progressive and transmitted it that way (at 30 frames/sec), it would look jerky.
So, I'm going to assume that what you mean by picture rate is the field rate for interlaced material or the frame rate for progressive. A picture rate of 30 is too slow to produce smooth motion for the eye. You need a picture rate that is higher. That's why film (at 24/fps) is double shuttered to produce [pseudo] 48/fps). This gets you closer, but some people can [still] see flicker at 48. Interlaced video material has a picture rate of 60. A picture rate of 60 is generally the requisite in the video world. Interlacing gets you 60, even though the frame rate is still 30. That's why it's popular with the industry. You get the effect you need with only half the data being sent.
It still sounds like you're suggesting that, from 30fps-based (i.e. "filmy" material), displaying those two halves of the same moment in time one after the other somehow improves the apparent smoothness, but it won't.
Actually, it does. That is what interlacing is all about. Additionally, film content is 24 frames/sec [not 30]. To be transmitted over a video channel [or put on DVD], this has to be converted to an interlaced field rate of 60. This process is called telecine (2:3 pulldown). Telecine is accomplished by splitting the film frames into fields and repeating them:
Film: ABCD
Tf: At,Bt,Bt,Ct,Dt
Bf: Ab,Bb,Cb,Db,Db
How about this:
(Fictional) fully-progressive 60fps source: ABCDEF (1/10th of a second)
Smooth interlaced video: [A1/B2][C1/D2][E1/F2]
Interlaced film-rate video: [A1/A2][C1/C2][E1/E2]
Progressive film-rate video: [A][C][E]
Those last two are equivalent. They might look slightly different on interlaced/progressive CRT screens, but one will not look smoother than the other.
Uh, no. They are not equivalent. The "interlaced film-rate" has a picture rate of 60. The "progressive film-rate" has a picture rate of 30. The latter is too slow and will produce a [noticeably] jerky result.
NTSC/PAL video is interlaced because it was originally meant for display on CRT TVs.
Uh, no. The original reason is that you can get sufficient [apparent] frame rate in half the channel bandwidth (e.g. 6Mhz for interlaced, but you'd need 12Mhz for progressive). And, at the time that NTSC/PAL were being developed, there were no transistors, only relatively slow tube amplifiers. CRT's can be either interlaced or progressive. TV CRT's were interlaced because that's the method that NTSC/PAL used.
If you display "progressive" video on a CRT, when the electron gun reaches (=lights up) the lines at the bottom of the screen, the phosphors of the lines at the top will already be too dark and this will be perceived like a flashing of the image. With interlaced video instead the electron gun is passing on every single line 60 times per second, reducing the line fading between a pass and the next one.
Possibly. I'm not sure about what the persistence characteristics of early orthicon/display phosphors were. But, these days, you can request just about anything you might want.
In related trivia, did you ever wonder why PAL is 50fps and NTSC 60fps? It's because the field rate of the first TV radio transmissions (in the 1950s) was synchronized with the AC power lines (while now it is sent to the TV set through a glitch in the signal itself). And while in the US the power lines frequency is 60 Hz, in Europe, were PAL was later adopted fixing the color problems of NTSC (at the time nicknamed the "Never Twice Same Color" standard), the frequency is 50 Hz. These number refer of course to the interlaced 60/50 Hz "field rate", and not the progressive 29.97/25 Hz "frame rate".
Uh, sort of. Matching the refresh rate to the power frequency eliminates intermodulation/beating (which produces rolling bars on the screen). When color was added to NTSC, the rate was reduced from 60 to 59.94 to eliminate distortion due to the difference in the sound and color subcarriers.
Although the NTSC color spec (1953) had a precise definition for colorimetry, this was frequently ignored (hence the "Never Twice Same Color"). The reason was that early color phosphors in cameras had poor brightness characteristics. This required very bright/hot lights for color programs. Camera manufacturers were constantly improving the brightness characteristics of their phosphors. But, each manufacturer's phosphor had different color characteristics.
It wasn't until the "SMPTE 'C' phosphor" standard came along in 1969 that introduced the notion of a "standard" phosphor. After that, each manufacturer was able to calibrate the difference between their phosphor and the standard one, and add color correction circuitry to their equipment.
Post 1987, SMPTE C was fully ratified as a best practice. By this time, phosphor technology had reached the point where sufficient brightness was available and manufacturers adjusted their phosphors to produce the standard output without the need for correction circuitry.
Perhaps you're not explaining yourself clearly, but it's not like that at all. Interlaced video really does have twice the temporal resolution (at the cost of vertical resolution) - the eye isn't being made to believe anything that isn't true.
I'm a computer engineer that has done extensive work with HD H.264 video compression but I was trying to keep it simple for the intended audience. Also, more people [apparently] are familiar with field/frame rates than the double shutter technique in film.
What the eye is being made to believe is that it is seeing a frame rate of 60 when in fact that's field rate and the frame rate is half that. And that two fields sent in sequence form a single frame [and don't remain as fields]. Without interlacing (progressive scan), the data rate would be insufficient to provide [somewhat] smooth motion.
In general, the eye is being made to believe that a [rapidly changing] sequence of still images have motion [at all] ...
---
This is a bit like TV that has a frame rate of 30 (29.97) but a field rate of 60 (59.94) because it's interlaced. It prevents jerky motion because the eye believes it's getting a frame rate higher than the true frame rate (e.g. it perceives the field rate to be the frame rate). When film is put on a DVD it has to undergo a telecine process to raise the field/frame rate.
Some people I know [with better eyes than mine] can see flicker in 24/48 film content. They actually prefer video because of the higher frame rate.
---
- While tacking on a fee of a few thousand to read your response might be reasonable, going from 2% to 4% seems like harassment. The "triple reverse legal fees" argument might apply.
- Also, if the original 2% figure was just, why would a simple letter from you be a reason to up it to 4%? Either somebody's manic or your letter showed [to them] that you're not infringing and they're now just trying to bluff you into settling [because they fear the same argument will be made to a judge].
- Is the patent "obvious" or is their prior art? While a literature search in support of prior art can be expensive, it may be less expensive than alternatives. Requesting a reexamination at the USPTO might be appropriate [filing fees are modest].
- Contact the EFF. They might not want to take up your cause, but they might be able to point you in the right direction.
- What are the patent claims? Reexamination might strike some of the claims and reduce the burden.
I remember that slogan. Not too long ago even. Before that it was "Think different" and buy the most common mp3 player on the planet. I dislike apple because I dislike marketing, and Apple is like an avatar of marketing; the essence of style over substance given form.
Well consider the slogan "Think different". You can say "Think: different" [with a colon] or "Think differently" but the actual slogan is just defective grammar. And Apple didn't replace that either ...
The problem is that there's more than Java at stake. Oracle also has a bunch of patents pertaining to VMs in general, especially JIT-compiling. From what I've heard, those are broad enough that e.g. Microsoft licenses them to cover .NET - and .NET is fairly different, implementation-wise, from HotSpot. Now Oracle is arguing that those same patents also apply to Dalvik's JIT. If that's still on the table in this lawsuit, dodging it would be much harder than just changing languages.
VM's go back to the 60's. Java was released in 1995. But, perl has a VM and it was created in 1987.
To me, JIT-compiling isn't much different than a multistage regular compiler (e.g. gcc--released in 1987). The first stage ("front end") parses the language and produces an intermediate meta description (e.g. register transfer language or RTL). This is passed off to the next stage which does optimization and code generation. The RTL is very much like a VM. Thus, all the papers on compiler optimization techniques that have been published for regular compilers serve as a basis for prior art against JIT. I vaguely recall some entity shipping the RTL files and having the target system do the final stage dynamically. That's an example of WORA/JIT prior art.
MS licenses things because it has its own patent portfolio. It's easier to license and MS doesn't want to set a precedent of patent busting because that might give others such ideas. Also, no doubt MS has some patents that they have cross-licensed to Oracle. "So, why rock the boat"?
But, as I mentioned previously, when Sun went after MS and wanted an injunction, MS fought back. Since Oracle wants an injunction, Google will fight back and I suspect that regardless of the trial outcome, the patent busting effort will continue unless Oracle sobers up.
Oracle seems intent on alienating just about everybody. HP is upset that Oracle is dropping support for its database products on Itanium architectures (of which HP has a lot). If Oracle keeps this up, they're going to become the subject of an antitrust investigation. Also, I suspect people (e.g. programmers) will retaliate by designing out Oracle products.
If Oracle does win, and Android is killed, it will anger telcos. Oracle might wake up one day with telephone/internet service to its corporate headquarters cut off :-) So, Oracle, who's your daddy now? :-)
They can argue FRAND in that case because Moto has actually signed a bunch of disclaimers when they submit their patents to the standard org. I very much doubt you can argue FRAND on a random technology by claiming that it is a "de facto standard".
Fair enough. That doesn't mean Google won't try [and may be successful]. This may be strengthened slightly by Sun's previous two separate attempts to submit Java as a standard to JTC1 and ECMA.
Oracle is playing a dangerous game [for themselves] on several fronts.
The reason that Java became popular was the "write-once-run-anywhere" [WORA] and that Oracle [nee Sun] would provide access for any platform. If Oracle wins, this collapses and many independent developers would see the need to reconsider their strategy in light of the fact that Oracle [on a whim] could deny access to a platform that is the developer's primary market.
The implications go far beyond Google. If Oracle wins, this would imperil not just Google, but telcos, handset makers, and tens of thousands of software developers. Legalities aside, the court will be aware of the potential widespread economic chaos that might ensue and temper its judgement accordingly. The court might refuse the injunction and compel Oracle to offer a license [Google might have to pay the $30M damages + license fees but it would be free to pursue Dalvik/Android]
Further, if Oracle prevails, the federal government might view Oracle as a "sole source supplier". In other words, no government contract would be able to use Java in it. For example, because Apple is considered to be a sole source supplier, the FDA will not approve any medical system that uses Apple/Mac technology. That's why you always see PC's (or Sun's) at your local doctor's office. Or, if Java has found its way into certain gov't systems, the federal gov't may seize/nullify the patents under national security grounds.
Also, I believe Google has filed with the USPTO for a reexamination on the patents, arguing they are obvious or there is prior art, etc. Personally, I'm not currently up on what patents are being asserted. But, as a computer engineer, I'm hard pressed to see what could patentable in the JVM as machine architecture simulators/emulators have been around since the 1960's.
In the 1980's, when [AT&T] Unix was the only variant around, they were controlling it and didn't want a formal standard. That's how POSIX came about. Using [court tested] "clean room" techniques, they were able to come up with a standard that gave rise to other implementations (e.g. minux and linux). That's why linux is called POSIX-compliant and not Unix-compliant. This could happen for Java (HP had a clean room Java implementation for embedded systems in the 90's).
In the late 1990's when Microsoft was creating a Windows specific variant of Java [mainly to eviscerate Java], Sun took them to court and got a preliminary injunction. The appeal [which MS won] was that the punishment did not fit the crime. In other words, a breach of contract should not be punished by means of an injunction. No doubt this ruling will be cited in the current case.
Google didn't clean room the Dalvik JVM for the same purpose as MS. The Sun/Java JVM assumes, more or less, a fairly powerful machine (e.g. a PC/Mac/mainframe, etc.). It is too slow/bloated for "low power" (e.g. CPU speed, memory, disk space) handset/tablet. Likewise for the Java Runtime Environment (JRE). It's meant to be a one-size-fits-all kitchen sink approach. Way too big to fit on a small nimble device, yet it would need additional handset specific classes and the generic classes that have no use in a handset would need to be trimmed.
Weaning off Java might be as herculean a task as the U.S. converting to the metric system. At worst, Google might have to call it something other than "Java". But, end users kn
Does google even have any direct revenue for android?
Jason
Not in pure form directly. It is completely free.
They encourage developers to download the source SDK (all 8.1 GB of it). I have it on my machine and take updates all the time. This doesn't include the Android kernel, but this is also freely available for download. In fact, the Android mods to Linux have [just recently] been added back to the mainline kernel tree.
All of the "front facing" [to app developers] APIs are common. If you're a small shop app developer, you're good to go.
But, handset manufacturers may need some custom mods to the kernel to provide optimal performance on their platforms or support a unique device they have. They can [and some do] make the mods themselves. They can maintain their own source deltas [which is easy enough to do because everything is maintained by git].
If, however, you want professional developer support [beyond filing a bug tracking report], Google will [probably] provide that--for a fee (or some other revenue sharing arrangement). Since most telcos and handset/tablet manufacturers are risk averse, they will usually have such an arrangement.
Seriously dude. Oracles remedy seems to involve killing davlik. That means no java on the android. Its a scorched earth aproach to IP litigation, and you better hope oracle fails on that.
Yes, I noticed the scorched earth approach. However, there may be a ray of hope against that approach. Because Java is a standard [if only de facto], Oracle may be compelled to offer a license under FRAND [fair, reasonable, and non-discriminatory] terms. Google's offer of 1/2 of 1% is in the FRAND ballpark for a mass market item.
In the Apple/Moto fight in Germany, Moto got an injunction against Apple for infringing some Moto patents. They got the injunction because Apple had not negotiated in good faith [stalling for five years]. However, latest ruling appears that Apple might reverse this on the FRAND argument.
Ok, I created an account. It will be simpler for others to follow. Comparing me to Linus or Eric Raymond is really over-the-top. I'm just a PhD student who has been working on power management in nouveau for little more than 1.5 years.
I'm not hairyfeet that you did the reply to. But, since you referenced info from my post in your reply to his, I'm assuming you just tried to consolidate things. One of the advantages to having an account is that your posts start at level 1 (vs 0 for AC) and people are more likely to "mod you up" and improve your "karma" if you post as yourself (or even a pseudonym as I and many others do--slashdot!=facebook). Eventually, if your karma goes high enough, your posts automatically start at level 2.
Anyway, the answers to your post are right, clean-room REing is legal. The shady part is for the firmwares that you have to decode in order to re-implement them. Fortunately, we know nvidia used a compiler to compile them. As we write them in asm only and don't use the same interface, I guess we are pretty covered.
I was familiar with clean room because I was once part of such a project. I was aware nVidia drivers had parts that they considered to be "secret sauce" algorithms (and ATI didn't?). From what you said, I'm assuming it was the firmware which must be loaded onto the card?
As for video decoding, nVidia though about us and added a "safe" for the encryption keys. So yes, we can re-implement video decoding (it is an on-going work, but it's ugly) but the compliance with hdcp will never come.
I'm only vaguely familiar with the requirements for HDCP compliance, but I'm guessing that safeguarding keys is part of it. So, my assumption is that nVidia needed to do that, in general, rather than to specifically make it difficult for the nouveau project.
Perhaps, the libdvdcss approach by players will work. The players don't have de-CSS capabilities themselves, but they do look around for the lib. If it "happens to be around" (e.g. liability is shifted to the end user who downloaded it separately), they will use it.
Lastly, nVidia said they would neither help nor hinder the project. If there is something they don't like, I'm sure they will let us know before going to court. If they wanted to go to the court, that would be one hell of a pain since they would have to sue individuals from many countries, mostly european.
I'm a software engineer who writes drivers for realtime H.264 hardware encoders. The company's take on this was that the card itself was the protection of the "secret sauce". The drivers were merely conduits to that. The amount of engineering to design logic, verify it, layout the chip, get it fabbed, etc. is so huge, that the driver is a relatively small part of it. In other words, you always need the card, so everything else is protected without needing specific protection of its own.
Another assurance for nVidia is that they know how slow going the RE is, compared to what they can do. They'll always be several steps ahead, no matter what. So, nouveau is no "threat" to them. The only people they're really concerned about are competitors like AMD/ATI and Intel that make HW.
Broadcom used to have the same philosophy for their wireless chip driver. In particular, no linux driver of any kind. The only way to get it to work was to use the windows driver with a glue interface. There was a native FOSS driver done, but you still had to extract the firmware from the windows driver. Finally, after years and years [and realizing that linux was no mere fad], Broadcom relented and produced a binary driver for linux and actually split off the firmware into a separate file. The irony in all this was that Broadcom had been using embedded linux internally on their chips/cards for years.
Most of us are students, that would be bad PR to sue us :D
Be thankful you're in Europe. In the US, the RIAA has been known to sue widows and orphans :-)
Now for my other question, since you are basically snatching the data from a binary blob which i'm sure is full of proprietary code, after all if it wasn't they could just FOSS the thing, do you worry about DMCA? i know that AMD can't release full specs on their GPUs because protected path isn't theirs and would break DMCA and since Nvidia cards i'm sure have protected path as well do you have to worry about legal ramifications? or have you set up the project in some place that doesn't recognize software patents?
What nouveau development does is feed data through the API and look at the I/O ports and what data they get. The developers are feeding data they "own" [e.g. the address of a frame buffer they created] and then retrieving it after it is transmuted. Virtually all devices in a system (e.g. disk controllers, etc.) have a port list so just having that is not novel (i.e. not patentable). Since nVidia isn't publishing a document on the port list, no copyright either. Might be claimed as a proprietary trade secret, but it's okay to reverse engineer in this manner [reverse engineer is a protected activity under the right "clean room" circumstances].
The "clean room" methodology has been court tested many times. In this instance, we have three groups that do not communicate, except in controlled ways. Group A does the above "port probing" and writes a document of their findings. Group B writes an API document using only Group A's report. Group C uses the API document generated by Group B to write the device driver code.
If you ARE Mr Peres I would like to say I admire your guts, frankly I wouldn't want to go within 100 yards of anything to do with video as long as all these crazy patents and lawsuits are going on. And how about hardware acceleration of video? How can you do that without ending up in the whole H.26x patent minefield?
No doubt nVidia has a license to H.264 patents. Under the exhaustion doctrine, anyone can benefit from using the API to output H.264 video. If that were not the case, any end user [even using nVidia's proprietary driver], would be required to pay H.264 patent licensing fees. Likewise for the use of one's home entertainment system.
However, that doesn't mean some folks don't try. Lodsys [a patent troll] licensed a patent to Apple. Apple incorporated the technology under an API that software developers can use. Lodsys has been trying to extract license fees from all software developers that use the Apple API. Apple is intervening in court to stop Lodsys using the exhaustion doctrine as the basis for their challenge against Lodsys in defense of the developers.
Frankly I think its a shame that such questions even have to be asked as while i have no problems with proprietary software and use both FOSS and proprietary software every day i do NOT support software patents but as long as that minefield exists I am curious how you intend to approach feature parity with the blob driver without stepping into the whole patent mess since one of the big uses of GPUs is video processing and that's patented up the wazoo.
It's not so much the patent mess (as I mentioned above), but rather the difficulty of deducing the port list, API doc, etc. using the clean room method. The 2D case is [relatively] easy enough. The 3D case [with a large number of acceleration modes, etc.] is a lot more work, many more test cases, etc. Sheer scope of such an undertaking is the biggest limiting factor.
There have been many 3D movies. Unlike the groundbreaking movies you mention, they haven't really had much impact beyond what they would as 2D movies. Nobody cared that The Jazz Singer wasn't 7.1 surround sound with the ability to blow the audience through the back wall, just having sound at all was enough because people wanted movies to have sound.
You're mixing my metaphors. I didn't hook 7.1 to "The Jazz Singer". What I said was that TJS killed off the silent film industry overnight.
The color in early color films was far from perfect but people loved it anyway because they wanted movies to have color. Color TV suffered a bit because it couldn't live up to a color film, but ultimately, people wanted color TV as well.
Not everybody thought color film was a great idea. In actual fact, Carole Lombard was against it on artistic grounds, technology notwithstanding. As I mentioned elsewhere, Hitchcock's "Rebecca" uses cinematographic techniques that would be impossible in color. It's a much more sinister/better film in B&W.
Unfortunately, you have to move your head around until you find a sweet spot to get decent 3D, and then you can't move or the spell is broken. That isn't what I would call an improvement.
There are several competing glasses-free systems.
But there IS perception of 3D in 2D. Do I know when someone is walking towards the camera? Yes! Do I know when one person is behind the other? Yes! Does it look like the outfielders are going to collide when they're not? No. I can perceive the depth.
I never said that there wasn't perception of 3D in 2D. But, this is the human mind synthesizing the missing 3D parallax information that is not given to the eye in a 2D system (as they both get the same information), based on [psychovisual] clues.
I didn't say that 3D provided nothing, I said it merely enhances an existing perception rather than adding one that wasn't there before. Enhancement can be nice, but it doesn't have the same impact.
3D isn't merely enhancement of perception. 3D is giving different parallax views to each eye. That is what 3D vision is, whether real life or not. Please ... Do some research as mixing them up as you're doing is just showing ignorance and lack of understanding. No professional video R&D engineer will agree with your description.
I didn't see Avatar, but I have seen polarization based 3D. I've seen color based 3D in the theater and on a conventional Color TV. I've even seen wigglevision demoed on TV in the late '70s. It's All pretty good as a visual spectacle. The wigglevision had the most potential for impact since it could take you by surprise, but it never even got used for a commercial.
So, you didn't see Avatar [as I had already surmised]. You missed out on the seminal 3D work? You're basing your opinion on the [inevitable] dreck that follows? After Jazz Singer and Robin Hood there were many forgettable sound/color films.
However, anyone who saw Avatar 3D doesn't believe 3D is failing. It's more like "I'm disappointed that some of the other films aren't living up to what I saw in Avatar". But, they're willing to wait, because they saw the technology work [a proof of concept]. To them, they're just waiting for the next great 3D film that they know will come eventually.
As for the rest, it reads an awful lot like "Well, yeah, 3D is down by 50 games in September, but We'll get 'em next year!" (or in 10 years). We'll see in 10 years when the technology is ACTUALLY suitable, but that will still mean the push right now to do 3D everything will have failed.
You failed to read other parts of the thread [as I had suggested] where I explained many things in more detail.
However, do you believe that people are