The thing in question is a Web app. That means that the end user doesn't make or get a copy of the program. It runs on the server, the user accesses it but never actually copies it. Which left the possibility of someone taking a GPL'd program, adding their own extensions and setting it up as a Web application, offering access to it without having to give users the source code to it as they normally would.
The AGPL was the response. The end user may not be copying, but the operator of the Web app would've had to copy the AGPL'd software onto their server. They can't make that copy without a license. The AGPL license says that if you make a copy and run it on your own server, you have to give users a copy of the code if they ask as a condition of you being able to copy the software to use in the first place. The intent of the AGPL was that it'd be applied to entire applications or to Web services (which're isolated by a network interface, so the AGPL wouldn't extend to software that used those Web services). Oracle here is trying to use it on a small but important component to force Web app developers to choose between AGPLing their entire Web app or buying a proprietary license to BDB.
Personally I'd have no problem with using the AGPL this way from the start. I wouldn't use a component like that, but the author IMO has every right just like they have the right to use the GPL instead of the LGPL on a conventional library intended for use in other programs. But I have heartburn with Oracle changing the license rules in such a fundamental way now, after people have committed to use based on the original rules. NB: I have the same heartburn with an LGPL project going GPL after widespread adoption.
It's not that they have to provide source to BDB. It's that the AGPL changes the rules. Before usage as an embedded database in a Web app was considered internal use, not distribution, so BDB's license didn't impact the licensing of the Web app itself and didn't require release of the source code for the Web app. The AGPL means that if you use BDB in a Web app then the Web app itself has to be licensed under AGPL-compatible terms. That's... a huge change. And even though I normally use GPL terms, I don't really agree with it. If you were talking about an entire Web app framework, AGPL is appropriate. But for such a small component? That smacks to me of arm-twisting in a bad way, of trying to force users into buying proprietary licenses without coming out and saying that's what you're trying to do.
Similar things are why we have the LGPL, and why so many library components use it instead of the GPL. The GPL is suitable for entire programs, the LGPL is more suitable for libraries used by other programs. And while I don't have a problem with a library declaring itself licensed under the GPL, I do have a problem with a library starting out under the LGPL and then changing it's licensing to GPL. That changes a fundamental rule about what kinds of usage impact licensing, and it feels to me like I was suckered in.
Worse: where I work we're subject to regulatory requirements about data disclosure. Having an external entity (Microsoft) be made aware of what we're doing before it's officially disclosed is a violation of Federal securities regulations. Having an external entity be made aware of private consumer credit information (which I work with regularly) is a violation of Federal privacy, consumer-protection and banking laws. The day this goes in, there's going to be a directive from Legal come down: this feature must be disabled completely or we must cease using Windows.
My bet would be that Microsoft refuses to sign the loader, saying that they can only sign if the loader's coded to only load binaries signed by a trusted authority (ie. Microsoft) and that allowing a loader that can load untrusted (ie. unsigned or not signed by Microsoft) binaries compromises the security of the boot process.
It's going to fail for the same reason it failed last time: Windows 7 won't magically go away overnight. DirectX is something users don't care about, nor do they need to. They don't care which version of DirectX they're using so long as their games run. Developers care about DirectX because they need to know what version(s) to target. The problem here is that, as with XP in it's day, Windows 7 is going to be a large chunk (probably even the majority) of the market for at least a year after Windows 8.1 comes out. Console game makers will be able to target whatever's on the console, but PC game developers can't just write off the majority of their market and say "Sorry, can't run our game.". That makes base DX11 the latest version PC game makers can safely target, or DX9.0c if they feel they need to keep the XP market (obsolete it may be, but ~36% of the desktop market it still is).
And if your games all require base DX11, why as a user would you feel any pressure to upgrade to get 11.2?
The ones that go on rampages, though, aren't merely saying stupid things. They were doing lots of stuff in addition to what they were saying, stuff that should've raised the red flags. You're demonstrating the very problem that causes those massacres: people in a position to do something about them getting "target fixation", focusing so much on one single thing that they completely ignore all the other warnings blaring because those warnings aren't the one single thing they're concentrating on.
See the input ports on DVI-D-capable monitors, with contacts for both analog and digital signals. It should also be obvious, contacts can be used for anything so once you have contacts in a connector for one thing it's a simple and straightforward idea to add a few more contacts for another thing. And you have USB charging cables which separate the +5/GND power pins from the D+/D- data pins, hooking power up to provide for charging but ignoring data since it's irrelevant. So yeah, this patent ought to be smacked down based on at least the KSR v. Teleflex ruling.
The parents ought to submit a filing to the court with just one thing in it: a photocopy of the page from the dictionary with the definition of "sarcasm" highlighted, and the comment "Apparently the <SARCASM> tags in his post failed to render correctly.".
I think it's time to start pranking the authorities mercilessly and without respite. They want to be Dolores Umbridge, they need the same treatment.
I think the logic there is that sales over the counter aren't interstate commerce, so they're open to state regulation. Mail-order direct to consumers would be interstate and a Federal matter.
Of course that's the opposite of what the Feds claim when it comes to a lot of other regulation, where anything that crossed a state line at any point or involved any party in another state, no matter how peripherally, is "interstate commerce", but nobody said the government had to be consistent...
It's not that they'd be hiding, it's their normal non-deductible development expenses. They shove all their developers over under the non-profit. They provide a "contribution" to the non-profit that just coincidentally covers the costs of those developers. They can write that contribution off on taxes and it counts as a cost so they don't lose any of the salary-related deductions they could take against profits. The non-profit does all the development work and the company "buys" the results back off the non-profit. The cost of purchasing the software counts as a cost they can take on taxes and against profits. Over on the non-profit side the money from that goes into salary and bonuses for the management of the non-profit, who just coincidentally happen to be upper management or shareholders from the company. That gains them some write-offs they couldn't get otherwise, and allows them to pay upper management bonuses and additional salary without having to say so openly in the financial filings which makes the P&L statement look better (the bottom line's the same, but the big numbers are hidden in "Charitable contributions" rather than "Executive bonuses").
Real R&D is done in-house, and then the non-profit contributes to a double-whammy: the company can write off the R&D costs, then turn around and claim another deduction for the value when they "donate" the results of that R&D to the non-profit.
The software the non-profit produces would be technically open-source, but not under any of the standard licenses. They'd use a custom license that made it open-source for non-commercial use only, with any commercial use requiring a paid license. It'd also be open-source only for use. Modification and redistribution would not be permitted under the license. The only way third parties could get their own changes distributed would be by contributing them back to the non-profit and assigning copyright to them, hoping that the non-profit would include those changes in the mainline code.
That requirement sounds reasonable. Google used to work that way: you had highlighted boxes at the top and on the right that contained the paid placements, and the unhighlighted regular search results in the body of the page. There's no technical reason it can't be done that way now. Lots of business reasons maybe, but no technical ones which is all the FTC should be caring about.
That doesn't mean the FTC should be unreasonably interfering in a search engines' business. But saying the search engine has to clearly indicate which results it's being paid to show people is hardly unreasonable.
My guess is it's the fact that most of the membership in those open-source projects are developers for for-profit businesses. The IRS would be on the lookout for businesses hiding their normal development activity over in a tax-exempt organization. I note that the IRS position is "no particular advice, look it over and punt it higher up the food chain if you can't make a clear call on it". Which I think is the standard procedure for anything. I'd rather have that in place, when a Tier 1 bureaucrat makes a wrong call it's easier to argue "They admit it's not clear here and here, according to IRS procedures they should've sent it up to a higher level to decide." as opposed to "They made the wrong call.".
If there's several simultaneous valid complaints alleging something like a serious illness, the water system may have to be shut down while it's tested or risk spread of a contamination. We've had that happen several times where I live (and I live in a major metropolitan area) when initial tests have shown a possible bacterial problem and they've needed several days for comprehensive tests to tell whether there really is a problem or not. I'd be outraged if a single complaint would have them labeling the complainant a terrorist, but I suspect the missing context is that they're discussing concerted multiple reports filed with the intent of forcing a shutdown and possibly where the complainants are aware they don't have a reasonable basis for the complaints (think anti-fluoridation kooks wanting to "send a message").
Yep. But again, in your example the people inside are taking measures (opaque walls) to keep the activities private, and seeing them requires special equipment that a person wouldn't ordinarily have. The equivalent for WiFi would be putting a Faraday cage around your house to contain radio emissions and having them leak out anyway. I don't think you've posited a Faraday cage being involved, have you?
Most of that, though, is feature tests. You don't care about the API level, you test "What's this device's screen resolution?", "Does this device have NFC?" and so on. If the test is positive, you start using that feature. If the test was negative, you avoid using it. In terms of code, you set a minimum API level to the lowest common denomiator that you require, then target the minimum API level that supports the features you want to use and code to check feature support before trying to use features. There's a trick to testing when you don't know if the API level you're running on supports what you want to test, but if you're a serious Android developer you don't need me to hand-hold you through it. If you're a serious Java developer you probably already know it too, it's how you write code to take advantage of Java 7 API additions if you're in a J7 VM while still being able to run in a J6 VM.
Most of it's that the "fragmentation" in Android really isn't visible at the developer level. Sure you've got a lot of versions. But in general the API changes between versions don't break backwards compatibility: if you wrote code for API level 8 (Android 2.2), it's almost certainly going to run just fine on a device running API level 17 (Android 4.2.2). It mostly comes down to picking the minimum API level that supports all the features you need and writing to that. There's only a relatively few places where you need to explicitly handle differences, eg. coding for "If the device supports NFC then hook up the handlers for it, otherwise don't bother.". Most of those are just like that, simple feature tests: does this device have GPS, does it have a camera, and so on. Only a small minority are truly complicated to handle and need special coding based on the Android version.
It's a lot like cars. There's how many car manufacturers, and how many hundred different models? Yet when you sit down in one you don't worry about that huge degree of fragmentation. The controls will mostly be where they ought to be and the ones that aren't aren't safety-critical and aren't that hard to figure out, and while the shape of the fenders and design of the taillights may change the looks dramatically that doesn't really impact your ability to drive it.
True, but then your X-ray example is an example of someone else broadcasting things into your home. WiFi involves the opposite: you broadcasting things out of your home where anyone can pick them up. Your example involves things not done by you, broadcasting is something you do that's under your control.
Why should we be ignorant of everything beyond our own senses? Everyone knows radio exists. My grandparents knew about radio, there's no excuse for anyone today to not know about it. Everyone knows it involves broadcasting the signal for anyone with a receiver to pick up, that's why we call them radio broadcasts. And while 15 years ago you might have been excused for not knowing that WiFi worked over radio, today it's common knowledge. You're even told this on Page 1 of the booklet that came with your wireless router or access point.
My question would be this: if you're standing in your front yard using a bullhorn, do you really have any expectation of privacy about what you're saying? One of the first requirements for an expectation of privacy has to be taking at least some steps to insure what you're doing/saying isn't public.
These weren't low-speed collisions, though. The initiating car was going fast enough to shove 3-4 cars forward with the lead car ending up half a car-length forward of where it had been standing. The only reason my friend got out with just body damage was because there were 2 cars behind him with half a car-length between each and half a car-length between him and the car ahead of him. But the law was clear on the point: in a rear-end collision the car behind is at fault regardless. The initiating car was clearly at fault for his collision, but everyone else was deemed at fault for theirs. No, it's neither fair nor reasonable. The law cares about neither.
You wouldn't want write access. From my standpoint I want the legal presumption that the data's valid to be as unchallengeable as I can arrange it. If I don't have write access, I can't be accused of having altered the data. Note: the box doesn't have to be tamperproof, it merely has to be not immediately alterable by me. One of the advantages of these laws is that they grant the legal presumption of validity to the black box and the burden's on the cops or the insurance company to prove it was tampered with if they don't agree with what it's saying. And depending on the exact wording it may not even matter if they can prove it was tampered with (see first-class mail for legal documents for an example of an all-but-unrebuttable presumption).
Actually I wouldn't mind having a black box in the car recording everything... IF I have access to the data. I've contemplated wiring up cameras and building a small server to continuously record front and rear views, so if there's an accident or something and there's questions about what happened I can pull up the video and say "Here, watch what happened.". Having had friends who've been dinged for rear-ending someone because they got rear-ended and shoved forward, I think it'd be wonderful to be able to pull up the black box record and prove that I was stationary with the engine at idle and the brake fully applied when the collision occurred and could not have been the cause.
What I object to isn't the black box itself. It's having that black box there and not having any access to it or control over or even knowledge of who's pulling the data from it and when.
I'd think it'd already have been dealt with. Think about an author going bankrupt, and as part of the proceedings trying to cancel all the copyright licenses given to publishers for all the books sold over a 2-decade career. Or a musical group going bankrupt and breaking up, and cancelling the copyright licenses given to the labels for all the records that'd been released. That'd just be too big a mess to allow.
I'd argue that a license like the GPL or BSD license can't be executory contracts because there is no ongoing obligation on the licensor's part. The only obligation is on the licensee's part, to continue to comply with the terms of the license grant. The bankrupt party can cease offering the license, but as their obligations have been completely fulfilled already the license shouldn't be eligible for cancellation.
The ability to cancel contracts in bankruptcy is intended to deal with things like a bankrupt party's contract with the cleaning service for a building.
Not quite. Sure I could enable this on my router, it's got guest network capability. But it'd eat my bandwidth, and it'd point back to me as the subscriber responsible for the access point. With the ISP doing it, though, the guest network wouldn't count towards my bandwidth and it'd be the ISP, not me, responsible for any abuse of the guest network since it's them offering access through it, not me. That's all stuff I can't do myself for free.
Slashdot Mirror
The thing in question is a Web app. That means that the end user doesn't make or get a copy of the program. It runs on the server, the user accesses it but never actually copies it. Which left the possibility of someone taking a GPL'd program, adding their own extensions and setting it up as a Web application, offering access to it without having to give users the source code to it as they normally would.
The AGPL was the response. The end user may not be copying, but the operator of the Web app would've had to copy the AGPL'd software onto their server. They can't make that copy without a license. The AGPL license says that if you make a copy and run it on your own server, you have to give users a copy of the code if they ask as a condition of you being able to copy the software to use in the first place. The intent of the AGPL was that it'd be applied to entire applications or to Web services (which're isolated by a network interface, so the AGPL wouldn't extend to software that used those Web services). Oracle here is trying to use it on a small but important component to force Web app developers to choose between AGPLing their entire Web app or buying a proprietary license to BDB.
Personally I'd have no problem with using the AGPL this way from the start. I wouldn't use a component like that, but the author IMO has every right just like they have the right to use the GPL instead of the LGPL on a conventional library intended for use in other programs. But I have heartburn with Oracle changing the license rules in such a fundamental way now, after people have committed to use based on the original rules. NB: I have the same heartburn with an LGPL project going GPL after widespread adoption.
It's not that they have to provide source to BDB. It's that the AGPL changes the rules. Before usage as an embedded database in a Web app was considered internal use, not distribution, so BDB's license didn't impact the licensing of the Web app itself and didn't require release of the source code for the Web app. The AGPL means that if you use BDB in a Web app then the Web app itself has to be licensed under AGPL-compatible terms. That's... a huge change. And even though I normally use GPL terms, I don't really agree with it. If you were talking about an entire Web app framework, AGPL is appropriate. But for such a small component? That smacks to me of arm-twisting in a bad way, of trying to force users into buying proprietary licenses without coming out and saying that's what you're trying to do.
Similar things are why we have the LGPL, and why so many library components use it instead of the GPL. The GPL is suitable for entire programs, the LGPL is more suitable for libraries used by other programs. And while I don't have a problem with a library declaring itself licensed under the GPL, I do have a problem with a library starting out under the LGPL and then changing it's licensing to GPL. That changes a fundamental rule about what kinds of usage impact licensing, and it feels to me like I was suckered in.
Worse: where I work we're subject to regulatory requirements about data disclosure. Having an external entity (Microsoft) be made aware of what we're doing before it's officially disclosed is a violation of Federal securities regulations. Having an external entity be made aware of private consumer credit information (which I work with regularly) is a violation of Federal privacy, consumer-protection and banking laws. The day this goes in, there's going to be a directive from Legal come down: this feature must be disabled completely or we must cease using Windows.
My bet would be that Microsoft refuses to sign the loader, saying that they can only sign if the loader's coded to only load binaries signed by a trusted authority (ie. Microsoft) and that allowing a loader that can load untrusted (ie. unsigned or not signed by Microsoft) binaries compromises the security of the boot process.
It's going to fail for the same reason it failed last time: Windows 7 won't magically go away overnight. DirectX is something users don't care about, nor do they need to. They don't care which version of DirectX they're using so long as their games run. Developers care about DirectX because they need to know what version(s) to target. The problem here is that, as with XP in it's day, Windows 7 is going to be a large chunk (probably even the majority) of the market for at least a year after Windows 8.1 comes out. Console game makers will be able to target whatever's on the console, but PC game developers can't just write off the majority of their market and say "Sorry, can't run our game.". That makes base DX11 the latest version PC game makers can safely target, or DX9.0c if they feel they need to keep the XP market (obsolete it may be, but ~36% of the desktop market it still is).
And if your games all require base DX11, why as a user would you feel any pressure to upgrade to get 11.2?
The ones that go on rampages, though, aren't merely saying stupid things. They were doing lots of stuff in addition to what they were saying, stuff that should've raised the red flags. You're demonstrating the very problem that causes those massacres: people in a position to do something about them getting "target fixation", focusing so much on one single thing that they completely ignore all the other warnings blaring because those warnings aren't the one single thing they're concentrating on.
See the input ports on DVI-D-capable monitors, with contacts for both analog and digital signals. It should also be obvious, contacts can be used for anything so once you have contacts in a connector for one thing it's a simple and straightforward idea to add a few more contacts for another thing. And you have USB charging cables which separate the +5/GND power pins from the D+/D- data pins, hooking power up to provide for charging but ignoring data since it's irrelevant. So yeah, this patent ought to be smacked down based on at least the KSR v. Teleflex ruling.
The parents ought to submit a filing to the court with just one thing in it: a photocopy of the page from the dictionary with the definition of "sarcasm" highlighted, and the comment "Apparently the <SARCASM> tags in his post failed to render correctly.".
I think it's time to start pranking the authorities mercilessly and without respite. They want to be Dolores Umbridge, they need the same treatment.
I think the logic there is that sales over the counter aren't interstate commerce, so they're open to state regulation. Mail-order direct to consumers would be interstate and a Federal matter.
Of course that's the opposite of what the Feds claim when it comes to a lot of other regulation, where anything that crossed a state line at any point or involved any party in another state, no matter how peripherally, is "interstate commerce", but nobody said the government had to be consistent...
It's not that they'd be hiding, it's their normal non-deductible development expenses. They shove all their developers over under the non-profit. They provide a "contribution" to the non-profit that just coincidentally covers the costs of those developers. They can write that contribution off on taxes and it counts as a cost so they don't lose any of the salary-related deductions they could take against profits. The non-profit does all the development work and the company "buys" the results back off the non-profit. The cost of purchasing the software counts as a cost they can take on taxes and against profits. Over on the non-profit side the money from that goes into salary and bonuses for the management of the non-profit, who just coincidentally happen to be upper management or shareholders from the company. That gains them some write-offs they couldn't get otherwise, and allows them to pay upper management bonuses and additional salary without having to say so openly in the financial filings which makes the P&L statement look better (the bottom line's the same, but the big numbers are hidden in "Charitable contributions" rather than "Executive bonuses").
Real R&D is done in-house, and then the non-profit contributes to a double-whammy: the company can write off the R&D costs, then turn around and claim another deduction for the value when they "donate" the results of that R&D to the non-profit.
The software the non-profit produces would be technically open-source, but not under any of the standard licenses. They'd use a custom license that made it open-source for non-commercial use only, with any commercial use requiring a paid license. It'd also be open-source only for use. Modification and redistribution would not be permitted under the license. The only way third parties could get their own changes distributed would be by contributing them back to the non-profit and assigning copyright to them, hoping that the non-profit would include those changes in the mainline code.
That requirement sounds reasonable. Google used to work that way: you had highlighted boxes at the top and on the right that contained the paid placements, and the unhighlighted regular search results in the body of the page. There's no technical reason it can't be done that way now. Lots of business reasons maybe, but no technical ones which is all the FTC should be caring about.
That doesn't mean the FTC should be unreasonably interfering in a search engines' business. But saying the search engine has to clearly indicate which results it's being paid to show people is hardly unreasonable.
My guess is it's the fact that most of the membership in those open-source projects are developers for for-profit businesses. The IRS would be on the lookout for businesses hiding their normal development activity over in a tax-exempt organization. I note that the IRS position is "no particular advice, look it over and punt it higher up the food chain if you can't make a clear call on it". Which I think is the standard procedure for anything. I'd rather have that in place, when a Tier 1 bureaucrat makes a wrong call it's easier to argue "They admit it's not clear here and here, according to IRS procedures they should've sent it up to a higher level to decide." as opposed to "They made the wrong call.".
If there's several simultaneous valid complaints alleging something like a serious illness, the water system may have to be shut down while it's tested or risk spread of a contamination. We've had that happen several times where I live (and I live in a major metropolitan area) when initial tests have shown a possible bacterial problem and they've needed several days for comprehensive tests to tell whether there really is a problem or not. I'd be outraged if a single complaint would have them labeling the complainant a terrorist, but I suspect the missing context is that they're discussing concerted multiple reports filed with the intent of forcing a shutdown and possibly where the complainants are aware they don't have a reasonable basis for the complaints (think anti-fluoridation kooks wanting to "send a message").
Yep. But again, in your example the people inside are taking measures (opaque walls) to keep the activities private, and seeing them requires special equipment that a person wouldn't ordinarily have. The equivalent for WiFi would be putting a Faraday cage around your house to contain radio emissions and having them leak out anyway. I don't think you've posited a Faraday cage being involved, have you?
Most of that, though, is feature tests. You don't care about the API level, you test "What's this device's screen resolution?", "Does this device have NFC?" and so on. If the test is positive, you start using that feature. If the test was negative, you avoid using it. In terms of code, you set a minimum API level to the lowest common denomiator that you require, then target the minimum API level that supports the features you want to use and code to check feature support before trying to use features. There's a trick to testing when you don't know if the API level you're running on supports what you want to test, but if you're a serious Android developer you don't need me to hand-hold you through it. If you're a serious Java developer you probably already know it too, it's how you write code to take advantage of Java 7 API additions if you're in a J7 VM while still being able to run in a J6 VM.
Most of it's that the "fragmentation" in Android really isn't visible at the developer level. Sure you've got a lot of versions. But in general the API changes between versions don't break backwards compatibility: if you wrote code for API level 8 (Android 2.2), it's almost certainly going to run just fine on a device running API level 17 (Android 4.2.2). It mostly comes down to picking the minimum API level that supports all the features you need and writing to that. There's only a relatively few places where you need to explicitly handle differences, eg. coding for "If the device supports NFC then hook up the handlers for it, otherwise don't bother.". Most of those are just like that, simple feature tests: does this device have GPS, does it have a camera, and so on. Only a small minority are truly complicated to handle and need special coding based on the Android version.
It's a lot like cars. There's how many car manufacturers, and how many hundred different models? Yet when you sit down in one you don't worry about that huge degree of fragmentation. The controls will mostly be where they ought to be and the ones that aren't aren't safety-critical and aren't that hard to figure out, and while the shape of the fenders and design of the taillights may change the looks dramatically that doesn't really impact your ability to drive it.
True, but then your X-ray example is an example of someone else broadcasting things into your home. WiFi involves the opposite: you broadcasting things out of your home where anyone can pick them up. Your example involves things not done by you, broadcasting is something you do that's under your control.
Why should we be ignorant of everything beyond our own senses? Everyone knows radio exists. My grandparents knew about radio, there's no excuse for anyone today to not know about it. Everyone knows it involves broadcasting the signal for anyone with a receiver to pick up, that's why we call them radio broadcasts. And while 15 years ago you might have been excused for not knowing that WiFi worked over radio, today it's common knowledge. You're even told this on Page 1 of the booklet that came with your wireless router or access point.
This is the 21st century, not the 19th.
My question would be this: if you're standing in your front yard using a bullhorn, do you really have any expectation of privacy about what you're saying? One of the first requirements for an expectation of privacy has to be taking at least some steps to insure what you're doing/saying isn't public.
These weren't low-speed collisions, though. The initiating car was going fast enough to shove 3-4 cars forward with the lead car ending up half a car-length forward of where it had been standing. The only reason my friend got out with just body damage was because there were 2 cars behind him with half a car-length between each and half a car-length between him and the car ahead of him. But the law was clear on the point: in a rear-end collision the car behind is at fault regardless. The initiating car was clearly at fault for his collision, but everyone else was deemed at fault for theirs. No, it's neither fair nor reasonable. The law cares about neither.
You wouldn't want write access. From my standpoint I want the legal presumption that the data's valid to be as unchallengeable as I can arrange it. If I don't have write access, I can't be accused of having altered the data. Note: the box doesn't have to be tamperproof, it merely has to be not immediately alterable by me. One of the advantages of these laws is that they grant the legal presumption of validity to the black box and the burden's on the cops or the insurance company to prove it was tampered with if they don't agree with what it's saying. And depending on the exact wording it may not even matter if they can prove it was tampered with (see first-class mail for legal documents for an example of an all-but-unrebuttable presumption).
Actually I wouldn't mind having a black box in the car recording everything... IF I have access to the data. I've contemplated wiring up cameras and building a small server to continuously record front and rear views, so if there's an accident or something and there's questions about what happened I can pull up the video and say "Here, watch what happened.". Having had friends who've been dinged for rear-ending someone because they got rear-ended and shoved forward, I think it'd be wonderful to be able to pull up the black box record and prove that I was stationary with the engine at idle and the brake fully applied when the collision occurred and could not have been the cause.
What I object to isn't the black box itself. It's having that black box there and not having any access to it or control over or even knowledge of who's pulling the data from it and when.
I'd think it'd already have been dealt with. Think about an author going bankrupt, and as part of the proceedings trying to cancel all the copyright licenses given to publishers for all the books sold over a 2-decade career. Or a musical group going bankrupt and breaking up, and cancelling the copyright licenses given to the labels for all the records that'd been released. That'd just be too big a mess to allow.
I'd argue that a license like the GPL or BSD license can't be executory contracts because there is no ongoing obligation on the licensor's part. The only obligation is on the licensee's part, to continue to comply with the terms of the license grant. The bankrupt party can cease offering the license, but as their obligations have been completely fulfilled already the license shouldn't be eligible for cancellation.
The ability to cancel contracts in bankruptcy is intended to deal with things like a bankrupt party's contract with the cleaning service for a building.
Not quite. Sure I could enable this on my router, it's got guest network capability. But it'd eat my bandwidth, and it'd point back to me as the subscriber responsible for the access point. With the ISP doing it, though, the guest network wouldn't count towards my bandwidth and it'd be the ISP, not me, responsible for any abuse of the guest network since it's them offering access through it, not me. That's all stuff I can't do myself for free.