Google really needs to decide then how they want to proceed, instead of sending mixed signals. They enjoy beating their competitors over the head with "Open", and decide not to be open. This to me wouldn't be such a big deal had Google not made it such a big deal in the past.
Either you have a selective memory, or you weren't paying attention. This is not at all the first time that google has delayed Android source release -- they were doing it at the start.
This move also shows how Honeycomb was indeed rushed to production just to try and beat the new iPad. Competition is good, up until the point you harm your own product in a clear money grab attempt. The long term damage to the Android image isn't worth that initial rush, but they went for it anyhow. Every review I read about the Xoom mentioned numerous app crashes and hangs.
So what should google do? Release early and release often? Or wait until they have something more stable? You seem to be simultaneously complaining that they aren't doing both these contradictory things.
There is no question that google is in this to make money. Feel free to second-guess their strategy, but AFAICT, google isn't doing anything immoral, unethical, or even that bad business-wise, here.
And for Sega v. Accolade I don't even know where you intended to go with the fair use case since that all applied to whether Accolade had fair use to dissasemble the Sega games too see how they worked.
C'mon. Interfacing Accolade's software to Sega's own copyrighted software against Sega's wishes is the elephant in the room here. Sega tried trademark law to protect against this precisely because it was inconceivable to them to think that a customer who had legally acquired their ROM with a console didn't have the right to use that ROM as it was designed.
Baystate v. Bentley was about...
The whole point of these cases is that, once a copyright owner sells a copy, he loses control over what the copy owner can do with that copy. Things may be different with shrink-wrapped "licensed, not sold" software, but the GPL doesn't seem to put copies in that category.
And we probably won't get any much longer with this issue:)
(1) The GPL has been tested in court. Just not on this issue of shipping non-GPLed code that requires the end-user to link it to GPLed code.
(2) I never said any tested licenses were "similar", just that they attempt (unsuccessfully) to control what the user can do, just like the GPL's attempt would be unsuccessful.
See, for example, Vault v. Quaid, Galoob v. Nintendo, MICRO STAR v FORMGEN, and Baystate v Bentley. Or even start with the granddaddy of them all, Sega v Accolade. Don't be fooled that Sega was a reverse-engineering/trademark case -- the 9th circuit directly addressed fair use in the appellate decision.
But you have to carefully read the reasoning to understand that these cases define some of the limits of copyright protection, and that no magic GPL pixie dust can extend those limits. The GPL is based on copyright, and grants users rights that bare copyright does not. It cannot take away those rights that copyright law already grants.
But have they ever considered this regarding the GPL and whether you are allowed to distribute your software at all if you don't meet the license requirements regarding linking?
Courts have certainly considered this issue in the context of licenses that attempted to disallow unlicensed run-time linking, and have found that it is perfectly legal to distribute program "A" that depends on program "B" at runtime, without the permission of the author of program "B", and in fact, over the strenuous legal objection of the author of program "B".
No they haven't so no one knows at this moment.
That's a completely bogus argument. The GPL is not some sort of magic fairy dust, and can't provide any more protection to the author than a myriad of other proprietary licenses do. It is eminently predictable what would happen if the FSF took someone to court over this particular issue, which is precisely why they never have and never will, because they find it far preferable to be able to spread FUD, and that ability would stop as soon as they lose.
Of course it's the FSF position that you violate by linking regardless of who does the linking (the developer or the customer) since the app is a derivative due to the fact that it uses functionality from the GPL library.
But, until the pieces are linked, there may be no derivative work involved. And the customer is allowed to do his own linking, as long as he doesn't distribute.
But you still have to remember that copyright works in such a way that you are not allowed to use anything without the authors consent.
That's sometimes true, and it partly depends on whether the copy is licensed or owned. Reality is considerably more complicated and nuanced than that. For example, with music there is a compulsory (meaning that the author has no choice but to grant it) copyright license available under some circumstances.
Or as it is written in the GPL: "All rights granted under this License are granted... provided the stated conditions are met"
...
So if you claim that some parts of the license is not valid then you are not meeting all the conditions and you then have no right to use the library.
Not true. As is also written in the GPL: "You are not required to accept this License in order to receive or run a copy of the Program." Again, the teeth in the license only apply to distribution of other authors' GPLed code.
What is still to be determined by any court is if linking with the library is considered to be a derivative work or not.
Several courts have considered the issue of one piece of software interacting with another via an API, and to my knowledge, none have found that this act creates a derivative work.
But you will have a hard time distributing your application if it means that you cannot also distribute the libraries that you depend upon.
The internet is a great thing.
Stallman, et al. have publicly taken the position that it doesn't matter who does the linking (the app developer or the customer), that it's still a violation.
I believe that if I write an application that needs a GPLed dynamic library component (for example, one that just happens to be available on most modern Linux distros), that I'm in the clear if I distribute the app. Or even if I distribute the app in a package that calls out the GPLed component as a dependency.
Now, I can easily believe that someone like Canonical might be in trouble if they distribute this app, because they're also distributing the GPLed library. But I think I would be fine just distributing my app, and I think that if I did so, the FSF might wail and gnash their teeth about it, but in the end they wouldn't do anything.
For example, the Eclipse license FAQ states that a plugin is not a derivative work, and yet that "Based upon the position of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses."
This is IBM very charitably saying "we don't believe this and don't care or enforce it, but obviously the FSF believes this deeply.
I, myself, contribute to a BSD licensed library that can make use of a GPLed library if it's installed. We don't distribute the GPLed library, so I don't think there is an issue. In a way, I'd actually like to see the FSF sue someone about this to get some caselaw on the subject, but they're way too smart for that. Much easier just to sling FUD, even if you do have to write all sorts of monotonous FAQs filled with half-truths. (At least, the FAQs do serve the valid purpose of keeping someone from committing an actual license violation by shipping GPL and non-GPL code side by side, but all the dancing on the head of the pin to avoid admitting there are some nuanced cases that the GPL can't and doesn't control gets annoying after awhile.)
The only thing granting you use of the library is the text of the GPL.
Sure, but nowhere in the GPL is this batshit-insane definition of derivative work ever written. I will give RMS this -- unlike a lot of shrinkwrapped licenses, the GPL itself, as written, is mostly quite reasonable, and it would be hard to claim that people using it are engaging in copyright misuse. From GPL v3:
To "modify" a work means to copy from or adapt all or part of the
work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
At least in the US, the mere creation of program B which can communicate with GPLed program A (not copying from or adapting program A) via an API doesn't require copyright permission, so the GPL doesn't cover any distribution of program B by itself, much as that appears to offend RMS's sense of fairness.
And since the GPL doesn't disallow running your own legally acquired copy of a program, you can certainly test your own program B with program A before you distribute B by itself.
So if you don't agree with the GPL then you have no right to use the library.
The GPL teeth aren't about use. They're about distribution. So if I'm not distributing someone else's GPLed code, there are no worries. BTW, this happens all the time with open source projects that are BSD-licensed, but that can interoperate with GPLed components.
BTW, I addressed the exact same Eben Moglen quote (from a slashdot interview in February 03) on a discussion thread on the Python mailing list in November of that same year. About the only thing that has changed in the intervening 7 years is that there are now enough important non-GPLed opensource projects that it is much harder for Stallman and his acolytes to cow all the FOSS developers into believing that he's always right on everything.
that a direct quote from the article, "I believe this is the first time someone has taken an integrated circuit and said, 'Let's get rid of the part that we don't need,'" is directly contradicted by reality.
It's up to the court to decide if he broke a law. IMHO, he didn't -- there are several different exemptions in the DMCA, each of which should cover what he did.
But first, they have to decide if California is the right place to decide that. Unfortunately, it looks like Illston and Spero are in Sony's pocket on that one.
Co-counsel defending Microsoft against a putative consumer class action alleging that it had violated wiretapping statutes and common law privacy rights by designing Windows to permit third parties to place cookies on computers. Obtained dismissal of complaint.
and this:
Represented Microsoft in several dozen lawsuits against resellers and corporate end-users of counterfeit, infringing, and unlicensed software.
At least he seems to know which side his bread is buttered on.
Well, I think you should need a permit to create one of those goofy bassackward thread screw systems that go the wrong way -- those things are confusing!
First, there's a huge difference between a display app and an authoring app.
Second, the native file format of most authoring apps is not the same as the output format of those apps. For example PDF is not normally considered an editable document, and things like OpenOffice can output to PDF, but don't read it very well.
InkScape has grabbed the bull by the horns. Not only is it an authoring app (as opposed to a mere display app), but its native file format is exactly the same as its output format.
I used to be a DOS/Windows expert. I used to write device drivers and VxDs for Windows back in the day. I used to fully support Windows at home and know absolutely nothing about Linux.
Then, sometime around 2000, I got tired of coming home and having to scrub the stupid purple gorilla swinging back and forth across the screen one more time, and tired of worrying if the AV toolkit actually got everything.
I probably could have gone Apple at that point, but back then that seemed like an awful lot of money. So, I switched to Linux.
If the grandparent thinks that her not being able to download music easily affects domestic tranquility, he obviously haven't considered how domestic tranquility would be affected by some drive-by malware stealing her banking credentials.
lets me save it, or stream it to multiple devices easily
We've bought a few tracks here and there, but my wife isn't all that computer literate, and I don't support Windows or Apple stuff.
So, for her to buy with confidence and know she isn't losing it and can use it again, it has to be pretty robust, but since Apple is actively hostile to Linux, it can't be iTunes.
Again: you pay for what you're granted by the EULA.
Bullshit. I pay at the store, I take it home. Copyright and/or patent law might forbid me to use my replicator on it, but it's mine.
You don't agree with the EULA - you don't buy it and instead buy what let's you do what you want it to do.
You don't see the stupid EULA at the store, moron.
In case you haven't heard - PS3 up until recently has been sold at a loss, presuming that various fees from stuff sold for it would compensate the loss.
Sony's broken business model is not my problem, and the courts should not be propping them up.
Slashdot Mirror
Either you have a selective memory, or you weren't paying attention. This is not at all the first time that google has delayed Android source release -- they were doing it at the start.
So what should google do? Release early and release often? Or wait until they have something more stable? You seem to be simultaneously complaining that they aren't doing both these contradictory things.
There is no question that google is in this to make money. Feel free to second-guess their strategy, but AFAICT, google isn't doing anything immoral, unethical, or even that bad business-wise, here.
C'mon. Interfacing Accolade's software to Sega's own copyrighted software against Sega's wishes is the elephant in the room here. Sega tried trademark law to protect against this precisely because it was inconceivable to them to think that a customer who had legally acquired their ROM with a console didn't have the right to use that ROM as it was designed.
The whole point of these cases is that, once a copyright owner sells a copy, he loses control over what the copy owner can do with that copy. Things may be different with shrink-wrapped "licensed, not sold" software, but the GPL doesn't seem to put copies in that category.
Probably not.
(2) I never said any tested licenses were "similar", just that they attempt (unsuccessfully) to control what the user can do, just like the GPL's attempt would be unsuccessful.
See, for example, Vault v. Quaid, Galoob v. Nintendo, MICRO STAR v FORMGEN, and Baystate v Bentley. Or even start with the granddaddy of them all, Sega v Accolade. Don't be fooled that Sega was a reverse-engineering/trademark case -- the 9th circuit directly addressed fair use in the appellate decision.
But you have to carefully read the reasoning to understand that these cases define some of the limits of copyright protection, and that no magic GPL pixie dust can extend those limits. The GPL is based on copyright, and grants users rights that bare copyright does not. It cannot take away those rights that copyright law already grants.
You're entitled to your own opinion, but not your own facts, and the fact is that in phones, Android is kicking some serious iOS butt at the moment.
Courts have certainly considered this issue in the context of licenses that attempted to disallow unlicensed run-time linking, and have found that it is perfectly legal to distribute program "A" that depends on program "B" at runtime, without the permission of the author of program "B", and in fact, over the strenuous legal objection of the author of program "B".
That's a completely bogus argument. The GPL is not some sort of magic fairy dust, and can't provide any more protection to the author than a myriad of other proprietary licenses do. It is eminently predictable what would happen if the FSF took someone to court over this particular issue, which is precisely why they never have and never will, because they find it far preferable to be able to spread FUD, and that ability would stop as soon as they lose.
But, until the pieces are linked, there may be no derivative work involved. And the customer is allowed to do his own linking, as long as he doesn't distribute.
That's sometimes true, and it partly depends on whether the copy is licensed or owned. Reality is considerably more complicated and nuanced than that. For example, with music there is a compulsory (meaning that the author has no choice but to grant it) copyright license available under some circumstances.
Not true. As is also written in the GPL: "You are not required to accept this License in order to receive or run a copy of the Program." Again, the teeth in the license only apply to distribution of other authors' GPLed code.
Several courts have considered the issue of one piece of software interacting with another via an API, and to my knowledge, none have found that this act creates a derivative work.
The internet is a great thing.
Stallman, et al. have publicly taken the position that it doesn't matter who does the linking (the app developer or the customer), that it's still a violation.
I believe that if I write an application that needs a GPLed dynamic library component (for example, one that just happens to be available on most modern Linux distros), that I'm in the clear if I distribute the app. Or even if I distribute the app in a package that calls out the GPLed component as a dependency.
Now, I can easily believe that someone like Canonical might be in trouble if they distribute this app, because they're also distributing the GPLed library. But I think I would be fine just distributing my app, and I think that if I did so, the FSF might wail and gnash their teeth about it, but in the end they wouldn't do anything.
For example, the Eclipse license FAQ states that a plugin is not a derivative work, and yet that "Based upon the position of the Free Software Foundation, you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses."
This is IBM very charitably saying "we don't believe this and don't care or enforce it, but obviously the FSF believes this deeply.
I, myself, contribute to a BSD licensed library that can make use of a GPLed library if it's installed. We don't distribute the GPLed library, so I don't think there is an issue. In a way, I'd actually like to see the FSF sue someone about this to get some caselaw on the subject, but they're way too smart for that. Much easier just to sling FUD, even if you do have to write all sorts of monotonous FAQs filled with half-truths. (At least, the FAQs do serve the valid purpose of keeping someone from committing an actual license violation by shipping GPL and non-GPL code side by side, but all the dancing on the head of the pin to avoid admitting there are some nuanced cases that the GPL can't and doesn't control gets annoying after awhile.)
if you hate the language you have to do that much work in so much.
Sure, but nowhere in the GPL is this batshit-insane definition of derivative work ever written. I will give RMS this -- unlike a lot of shrinkwrapped licenses, the GPL itself, as written, is mostly quite reasonable, and it would be hard to claim that people using it are engaging in copyright misuse. From GPL v3:
At least in the US, the mere creation of program B which can communicate with GPLed program A (not copying from or adapting program A) via an API doesn't require copyright permission, so the GPL doesn't cover any distribution of program B by itself, much as that appears to offend RMS's sense of fairness.
And since the GPL doesn't disallow running your own legally acquired copy of a program, you can certainly test your own program B with program A before you distribute B by itself.
The GPL teeth aren't about use. They're about distribution. So if I'm not distributing someone else's GPLed code, there are no worries. BTW, this happens all the time with open source projects that are BSD-licensed, but that can interoperate with GPLed components.
BTW, I addressed the exact same Eben Moglen quote (from a slashdot interview in February 03) on a discussion thread on the Python mailing list in November of that same year. About the only thing that has changed in the intervening 7 years is that there are now enough important non-GPLed opensource projects that it is much harder for Stallman and his acolytes to cow all the FOSS developers into believing that he's always right on everything.
Note that they've never sued anybody about this. It's just posturing.
The claim that the GPL has now been tested in court, while true, doesn't address this issue, and IMHO probably never will.
When it runs, the entire program is arguably a derivative work. When your software alone is just sitting there, no, it's not.
Otherwise, you might as well argue that a single GPLed plugin will force Microsoft to opensource IE.
Is that so wrong?
Uh huh. If they're stealing all your stuff at gunpoint, why are they going to let you keep the video camera?
Umm, no. DeCSS allowed you to decrypt DVDs.
Jailbreaking the PS3 allows you to sign your own programs so that you can run them on your own PS3 computer.
But first, they have to decide if California is the right place to decide that. Unfortunately, it looks like Illston and Spero are in Sony's pocket on that one.
From the original resume:
and this:
At least he seems to know which side his bread is buttered on.
Well, I think you should need a permit to create one of those goofy bassackward thread screw systems that go the wrong way -- those things are confusing!
Second, the native file format of most authoring apps is not the same as the output format of those apps. For example PDF is not normally considered an editable document, and things like OpenOffice can output to PDF, but don't read it very well.
InkScape has grabbed the bull by the horns. Not only is it an authoring app (as opposed to a mere display app), but its native file format is exactly the same as its output format.
We're pretty happy with the Roku for Netflix.
I used to be a DOS/Windows expert. I used to write device drivers and VxDs for Windows back in the day. I used to fully support Windows at home and know absolutely nothing about Linux.
Then, sometime around 2000, I got tired of coming home and having to scrub the stupid purple gorilla swinging back and forth across the screen one more time, and tired of worrying if the AV toolkit actually got everything.
I probably could have gone Apple at that point, but back then that seemed like an awful lot of money. So, I switched to Linux.
If the grandparent thinks that her not being able to download music easily affects domestic tranquility, he obviously haven't considered how domestic tranquility would be affected by some drive-by malware stealing her banking credentials.
We've bought a few tracks here and there, but my wife isn't all that computer literate, and I don't support Windows or Apple stuff.
So, for her to buy with confidence and know she isn't losing it and can use it again, it has to be pretty robust, but since Apple is actively hostile to Linux, it can't be iTunes.
Nobody's yet shown that Hotz has violated any laws. OTOH, Sony is a known rootkit maker/distributor.
Bullshit. I pay at the store, I take it home. Copyright and/or patent law might forbid me to use my replicator on it, but it's mine.
You don't see the stupid EULA at the store, moron.
Sony's broken business model is not my problem, and the courts should not be propping them up.
Any real security company would either say "you're hosed on this platform" or "do x, y, and z and you'll be fine."
I say it's an ad.