It doesn't matter whether the page had raw-coded the HTML or hand-coded HTML. Generated HTML can be copyrighted also.
No; human creativity (as in a literary work, which is what computer programs are considered) is required. (In the US, at least.) See Feist vs. Rural
It's not that adding advertising doesn't make changes, it's that those changes don't make a derived copy, because the ISP doesn't have to make any copy of the page in the first place. Any more than you make a derivative copy of water by sending it through a rusty pipe.
The phrase "derivative work" does not include the word "copy" for a reason. The right "to prepare derivative works" is granted exclusively to the copyright holder directly. (17 USC 106).
Irrelevant garble about rust and water removed.
If end users reloads the page, that ad will be gone. There is no change to the physical document, only the user's view.
Again; irrelevant. The exclusive right to prepare a derivative work has been violated.
It's as if you look at a piece of painting while you happen to be wearing red sunglasses with transparent advertising imposed in the upper-left-hand corner. That doesn't mean the sunglasses manufacturer made a derived copy of the painting. It means YOU, the VIEWER of the artwork observed the art as modified by YOUR choice to modify your vision by using the product which _automatically_ made the transformation.
No; that's wrong, because modifying an image through a filter like that doesn't create a derivative work. (It's not "sufficiently permanent or stable to permit it to be perceived, reproduced, or otherwise communicated for a period of more than transitory duration" (17 USC 101).)
Modifying a web page in transit, OTOH, does, because the destination of the page is (with extremely high probability) a user's screen for an extended period of time, and potentially permanent storage (HDD or hardcopy.)
Second of all, there's also the fact that all kinds of transformations already being made to data in transit just to deliver it. Within Tcp/Ip, and the path to your browser, pages are packetized and retransmitted in some manner, possibly the whole message, whenever it passes through a HTTP proxy.
Copies of a computer program necessary to use it are explicitly permitted. Slicing and dicing in the transmission is not relevant, just as the pagination of text [mostly], usage of different inks, and usage of differing radio transmission methods (AM/FM/...) aren't relevant.
It is more than common, particularly with HTML e-mail, for items to even be removed, or for scripting elements to be removed by a proxy, partly for enhanced security of end users. Essentially, by the time the HTML page is received, it's merely a "derived version" of what is physically stored in a.html file, already -- in that case, adding advertising is an additional change, but not the first change. Once you accepted one derivation, you don't have the luxury of rejecting other ones.
What happens elsewhere is irrelevant, and your argument essentially boils down to "But everybody else is doing it! It must be legal." In any case, removing of scripts and images by the browser would be irrelevant because those modifications would (almost certainly) occur in the rendering system, after the HTML has already been interpreted (and we're discussing the copyrightability of the HTML, not of the rendered web page; see below.)
Essentially, the only such thing as a "fixed" HTML document is one that's delivered over a system that provides for its integrity. HTTP does not.
Huh? You don't make sense. HTTP doesn't provide for integrity? There's a reasonable expectation HTTP payloads won't be modified in transit. HTTP doesn't guarantee integrity? Neither does the USPS, but if I write a poem and mail it, it's still
The JS could just do a HTTP request to the server for the URL that was loaded to get the source. The probability that the source the browser renders gets an add inserted is probably the same as the probability the source the script gets has an add inserted.
You still waste a lot of bandwidth, though, on the downside. On the plus side, if you're just using this script for your own site [1], you could shortcut things by having the server (post generation of the HTML) embed the checksum in the response, so the JS could do the verification (and then report mismatches to the server.) That would mean the server wouldn't have to store data except what you wanted to log about pages that did get modified.
Your argument (even if correct) also assumes that the rendered website is the only aspect of the work which is copyrightable and not the raw HTML. For a site created by a WYSIWIG editor, this wouldn't apply, but if the site was hand-coded (as all of mine are), merely modifying the HTML stream in transit *at all* would constitute creation of a derivative work.
JIT would be different. Assuming they decided to scrap it for v1.0, they'd still need to figure out the UI, which would be very hard, given that the iPhone UI doesn't look anything like a normal OSX UI. If they could port AWT and somehow hack Swing into working nicely, that'd be one route. Another would be to write their own libraries, but that's at least as difficult as a full SDK, since they've almost undoubtedly not written the original code in Java.
(On the other hand, it does occur to me now that they *may* have a JVM there already for applet support...)
Mod parent up. (He's pointed out, if you haven't noticed, that the more people start using things like iPhone for Skype, the less cell service they'll be using even though they'll still be paying monthly fees. Or, in Slashdot terms,
<perspective of="cell phone companies"> 1) Spend less on providing customers service. 2) Charge them the same amount 3) ??? 4) Profit! </perspective>
Re:Public DNS is corrupt, but Private DNS is subli
on
DNS Complexity
·
· Score: 1
You... don't really sound like you know what you're talking about. (Sorry to be blunt.)
One TLD != one server; on the contrary, TLDs tend to have many, many servers.
The likes of Verisign, for example, run no less than 13 servers (a.gtld-servers.net through m.gtld-servers.net) for com and net, and, in reality, they almost certainly run many more, since each of those names is probably a cluster of actual machines.
The GTLD is managed similarly, and I'd be surprised if any other TLDs have less than 6 obviously distinct servers.
Even second-level domains are often redundant; many (all?) registars in com/net/org require 2-3 nameservers per domain.
And so you will have very successfully taught him that, should he ever do something in the future that you might disagree with, he should do his level best to make sure you never find out about it. Instead of attempting to communicate with you and acting responsibly, he'll instead end up acting without your guidance doing irresponsible things. For example...
Well, you can't know for sure, but if you keep this up for a long time, you might even end up seeing him doing crazy things like driving your truck without your permission!
Take a look at the Massachusetts state-wide requirements for public schools-- if you were subject to them, you'd require at least one (maybe even two) full-time sysadmins per that many students (plus a few other people too). You could cite that as documentation for the validity of your proposal.
Am I the first to post Base64? "CfkRAp1041vYQVbFY1aIwA"
Or, an even better idea...
If you treat the hex string as a sequence of unsigned big-endian U16s, and then look up the sequence of corresponding words in OSX's password dictionary, you get "edit view phosphor beautified sorcerous crushed kneader deadline".
but, speaking of what AOL could do, what exactly did they do to make this a "settlement"? It sounds like it was basically, AOL saying: "Okay, let's make a deal here. You can give us exactly what we'll want and we'll go away. Good deal?"
Seriously, what did the IMFC (IIRC) get from this?
It provides plausible deniability, a lot more encryption options, is open source (which may actually matter to you for crypto), supports efficiently encrypting entire disks, an open disk format, and is probably faster.
OTOH, DiskImaging is more flexible w.r.t to image formats (e.g. sparse images), has identifiable images (which means you can open them without opening DU first), can therefore be integrated with the GUI, and is also usable in other nice places (e.g. asr).
I'm going to try to bring this discussion back to what we were actually saying at the beginning, if you don't mind [1]. I'm not going trying to argue that DHCP is God and solves every administration problem in existence. The only thing I am going to argue for right now is what I've actually asserted in my comments in this discussion. (Like the ancestor to this post, I think it's beneficial. Beneficial != solves all problems; beneficial == net gain. That's just full disclosure on my position.)
You said:
With enterprise-scale services, outages cost a lot of money. Quite a lot of time and planning goes into designing network topologies and architectures to minimize risk and minimize points of failure. Requiring that DHCP services be up and available and renewing leases in order for your mission-critical servers to discover the network is a HUGE liability. If you're an online retailer, a DHCP outage could translate to a significant revenue-impacting event that would easily outweigh the additional administrative costs of NOT having a DHCP-managed IP address scheme.
I said:
dhcp supports redundant modes of operation; furthermore, you could have a few servers (or pairs of servers) for different segments of the network, and they could easily share the database and only differ in which subnet they're on.
I was just pointing out that you don't have to rely on a single point of failure. A single DHCP point server is a single point of failure. A cluster isn't; DHCP services isn't, just like DNS isn't a single point of failure (if you're doing it right.)
A DHCP outage could translate to a horrible outage which would easily outweigh the administrative cost of a non-DHCP scheme. However, a mistake in configuring some server which could have been avoided with DHCP could also translate to a horrible outage which easily... (etc.) If one route had no disadvantages, we probably wouldn't be having this discussion. Both choices do have disadvantages, and pointing those out is logically irrelevant. What you should be doing is considering which is least disadvantageous.
(As an aside, your reference to "the additional administrative costs of NOT having a DHCP-managed IP address scheme." acknowledges that DCHP has a lower administrative cost.) That brings us to:
Except all of this costs a lot of money, and you're still never going to get to a 0.000% chance of failure. So you've cost the enterprise tens if not hundreds of thousands of dollars building this redundant, distributed DHCP infrastructure, and reduced the availability of your systems by some small (but non-zero) amount. What has that bought you? A slight reduction in the amount of hours worked by your administrators? Oops, we forgot about the administrators that we'd have to hire to maintain the dozens of DHCP clusters we'd have to deploy to make this work.
You're not going to get a 0% chance of failure no matter what you do (for a reasonably definition of "chance".) I think the administrative overhead for maintaining the DHCP clusters is significantly less than the overhead maintaining a heap of servers with static configurations. The increased chance of failure should be sufficiently small as to be negligible. (How negligible? If the two servers were run the neglect with which I admin my personal computers, there'd be about an 00.018% chance of failure, empirically. That's after a healthy margin of error for non-professional computers.)
That only leaves raw cost for the DHCP servers, which is why I brought up:
The maximum you'd need would be two servers per segment, where a "server" could be as simple as a WRT54G running OpenWRT. (Those work very well, in fact.)
WRT54G's are the archetypal "cheap but unexpectedly useful device" (in my mind, at least.) Suggesting them for serious use is somewhat tongue-in-cheek, merely to demonstrate with how little the infrastruc
The maximum you'd need would be two servers per segment, where a "server" could be as simple as a WRT54G running OpenWRT. (Those work very well, in fact.)
Maintenance is pretty darn trivial. Write a quick Perl script to generate and push the config files from a central database, and there basically isn't maintenance. (There is some, but nowhere near one administrator's work for a moderate- to medium-sized place.)
Furthermore, there are presumably routers somewhere holding the network together. You could use those to relay the DHCP to a single central cluster and drive administration even lower.
dhcp supports redundant modes of operation; furthermore, you could have a few servers (or pairs of servers) for different segments of the network, and they could easily share the database and only differ in which subnet they're on.
Just because things work now doesn't mean they'll work when the power / $hardware_component / kernel fails unpredictably in a few days and your computer has to reboot.
So, 242 days puts you well before the recent udev upgrade, right. Are you sure your router's NICs will keep the same names? (JSYN, "yes" is a perfectly valid answer, and the fact that you've considered that gotcha doesn't mean you've considered them all.)
BTW, Gentoo is my distribution of choice, but that doesn't prevent me from recognizing its shortcomings. "I mean it seriously."
No, you'll be running Vista, running some other "approved" OS (i.e. OSX), or just avoiding Trusted DRM protected content.
Chances are, IMO, if you're the kind of person who wouldn't be running Vista or OSX, you don't care about the content, and you probably wouldn't be able to use it (in a TC-free world) anyway.
If someone is trying to obtain the data on your hard drive, and "asking" you for your keys was an option, they presumably don't care about secrecy, and they're also presumably capable of getting the (encrypted) contents of the HDD. Why not just take the rest of the computer, TPM and all?
It's worth noting that much current hardware should be Vista-compatible, and is perfectly capable of running Linux. FOSS isn't fundamentally incompatible with Trusted Computing-- it's just incompatible with things which use Trusted Computing to secure against other things (e.g. using a Free OS with content which uses TC-based DRM. You'd have to pick either your ability to modify the OS or the content.)
Personally I don't believe they have this amount of clout, especially with the antitrust thing still hanging over their head.
Oh, come on! It's not exactly like the antitrust thing actually hurt them, or made them any less evil-empire-monopolistic. Remember that article about them probably having violated it a few days ago? Remember all the issues with the EU?
If they're capable of standing up to a multinational government, they're certainly capable of standing up to (probably buying out if necessary) the MAFIAA. (Even I wouldn't go so far as to say they have an obligation to do it, though.)
Slashdot Mirror
It doesn't matter whether the page had raw-coded the HTML or hand-coded HTML. Generated HTML can be copyrighted also.
No; human creativity (as in a literary work, which is what computer programs are considered) is required. (In the US, at least.) See Feist vs. Rural
It's not that adding advertising doesn't make changes, it's that those changes don't make a derived copy, because the ISP doesn't have to make any copy of the page in the first place. Any more than you make a derivative copy of water by sending it through a rusty pipe.
The phrase "derivative work" does not include the word "copy" for a reason. The right "to prepare derivative works" is granted exclusively to the copyright holder directly. (17 USC 106).
Irrelevant garble about rust and water removed.
If end users reloads the page, that ad will be gone. There is no change to the physical document, only the user's view.
Again; irrelevant. The exclusive right to prepare a derivative work has been violated.
It's as if you look at a piece of painting while you happen to be wearing red sunglasses with transparent advertising imposed in the upper-left-hand corner. That doesn't mean the sunglasses manufacturer made a derived copy of the painting. It means YOU, the VIEWER of the artwork observed the art as modified by YOUR choice to modify your vision by using the product which _automatically_ made the transformation.
No; that's wrong, because modifying an image through a filter like that doesn't create a derivative work. (It's not "sufficiently permanent or stable to permit it to be perceived, reproduced, or otherwise communicated for a period of more than transitory duration" (17 USC 101).)
Modifying a web page in transit, OTOH, does, because the destination of the page is (with extremely high probability) a user's screen for an extended period of time, and potentially permanent storage (HDD or hardcopy.)
Second of all, there's also the fact that all kinds of transformations already being made to data in transit just to deliver it. Within Tcp/Ip, and the path to your browser, pages are packetized and retransmitted in some manner, possibly the whole message, whenever it passes through a HTTP proxy.
Copies of a computer program necessary to use it are explicitly permitted. Slicing and dicing in the transmission is not relevant, just as the pagination of text [mostly], usage of different inks, and usage of differing radio transmission methods (AM/FM/...) aren't relevant.
It is more than common, particularly with HTML e-mail, for items to even be removed, or for scripting elements to be removed by a proxy, partly for enhanced security of end users. Essentially, by the time the HTML page is received, it's merely a "derived version" of what is physically stored in a .html file, already -- in that case, adding advertising is an additional change, but not the first change. Once you accepted one derivation, you don't have the luxury of rejecting other ones.
What happens elsewhere is irrelevant, and your argument essentially boils down to "But everybody else is doing it! It must be legal." In any case, removing of scripts and images by the browser would be irrelevant because those modifications would (almost certainly) occur in the rendering system, after the HTML has already been interpreted (and we're discussing the copyrightability of the HTML, not of the rendered web page; see below.)
Essentially, the only such thing as a "fixed" HTML document is one that's delivered over a system that provides for its integrity. HTTP does not.
Huh? You don't make sense. HTTP doesn't provide for integrity? There's a reasonable expectation HTTP payloads won't be modified in transit. HTTP doesn't guarantee integrity? Neither does the USPS, but if I write a poem and mail it, it's still
The JS could just do a HTTP request to the server for the URL that was loaded to get the source. The probability that the source the browser renders gets an add inserted is probably the same as the probability the source the script gets has an add inserted.
You still waste a lot of bandwidth, though, on the downside. On the plus side, if you're just using this script for your own site [1], you could shortcut things by having the server (post generation of the HTML) embed the checksum in the response, so the JS could do the verification (and then report mismatches to the server.) That would mean the server wouldn't have to store data except what you wanted to log about pages that did get modified.
Then just run a traceroute/whois/DNS lookup on the server when the script that checks the table notices the page has been corrupted.
Your argument (even if correct) also assumes that the rendered website is the only aspect of the work which is copyrightable and not the raw HTML. For a site created by a WYSIWIG editor, this wouldn't apply, but if the site was hand-coded (as all of mine are), merely modifying the HTML stream in transit *at all* would constitute creation of a derivative work.
Quite possibly....
JIT would be different. Assuming they decided to scrap it for v1.0, they'd still need to figure out the UI, which would be very hard, given that the iPhone UI doesn't look anything like a normal OSX UI. If they could port AWT and somehow hack Swing into working nicely, that'd be one route. Another would be to write their own libraries, but that's at least as difficult as a full SDK, since they've almost undoubtedly not written the original code in Java.
(On the other hand, it does occur to me now that they *may* have a JVM there already for applet support...)
Mod parent up. (He's pointed out, if you haven't noticed, that the more people start using things like iPhone for Skype, the less cell service they'll be using even though they'll still be paying monthly fees. Or, in Slashdot terms,
<perspective of="cell phone companies">
1) Spend less on providing customers service.
2) Charge them the same amount
3) ???
4) Profit!
</perspective>
)
Who here's written a JRE? Anyone?
You... don't really sound like you know what you're talking about. (Sorry to be blunt.)
One TLD != one server; on the contrary, TLDs tend to have many, many servers.
The likes of Verisign, for example, run no less than 13 servers (a.gtld-servers.net through m.gtld-servers.net) for com and net, and, in reality, they almost certainly run many more, since each of those names is probably a cluster of actual machines.
The GTLD is managed similarly, and I'd be surprised if any other TLDs have less than 6 obviously distinct servers.
Even second-level domains are often redundant; many (all?) registars in com/net/org require 2-3 nameservers per domain.
And so you will have very successfully taught him that, should he ever do something in the future that you might disagree with, he should do his level best to make sure you never find out about it. Instead of attempting to communicate with you and acting responsibly, he'll instead end up acting without your guidance doing irresponsible things. For example...
Well, you can't know for sure, but if you keep this up for a long time, you might even end up seeing him doing crazy things like driving your truck without your permission!
Very nice. I also like this one.
I think what I was thinking of was here at 4.B.3.
(First post, or am I slow?)
Take a look at the Massachusetts state-wide requirements for public schools-- if you were subject to them, you'd require at least one (maybe even two) full-time sysadmins per that many students (plus a few other people too). You could cite that as documentation for the validity of your proposal.
Am I the first to post Base64? "CfkRAp1041vYQVbFY1aIwA"
Or, an even better idea...
If you treat the hex string as a sequence of unsigned big-endian U16s, and then look up the sequence of corresponding words in OSX's password dictionary, you get "edit view phosphor beautified sorcerous crushed kneader deadline".
You're wrong. It's because she was damn good at her job, and, frankly, it'll be a loss to MIT that she resigned.
Yeah...
but, speaking of what AOL could do, what exactly did they do to make this a "settlement"? It sounds like it was basically, AOL saying: "Okay, let's make a deal here. You can give us exactly what we'll want and we'll go away. Good deal?"
Seriously, what did the IMFC (IIRC) get from this?
It provides plausible deniability, a lot more encryption options, is open source (which may actually matter to you for crypto), supports efficiently encrypting entire disks, an open disk format, and is probably faster.
OTOH, DiskImaging is more flexible w.r.t to image formats (e.g. sparse images), has identifiable images (which means you can open them without opening DU first), can therefore be integrated with the GUI, and is also usable in other nice places (e.g. asr).
You said:
I said:
I was just pointing out that you don't have to rely on a single point of failure. A single DHCP point server is a single point of failure. A cluster isn't; DHCP services isn't, just like DNS isn't a single point of failure (if you're doing it right.)
... (etc.) If one route had no disadvantages, we probably wouldn't be having this discussion. Both choices do have disadvantages, and pointing those out is logically irrelevant. What you should be doing is considering which is least disadvantageous.
A DHCP outage could translate to a horrible outage which would easily outweigh the administrative cost of a non-DHCP scheme. However, a mistake in configuring some server which could have been avoided with DHCP could also translate to a horrible outage which easily
(As an aside, your reference to "the additional administrative costs of NOT having a DHCP-managed IP address scheme." acknowledges that DCHP has a lower administrative cost.) That brings us to:
You're not going to get a 0% chance of failure no matter what you do (for a reasonably definition of "chance".) I think the administrative overhead for maintaining the DHCP clusters is significantly less than the overhead maintaining a heap of servers with static configurations. The increased chance of failure should be sufficiently small as to be negligible. (How negligible? If the two servers were run the neglect with which I admin my personal computers, there'd be about an 00.018% chance of failure, empirically. That's after a healthy margin of error for non-professional computers.)
That only leaves raw cost for the DHCP servers, which is why I brought up:
WRT54G's are the archetypal "cheap but unexpectedly useful device" (in my mind, at least.) Suggesting them for serious use is somewhat tongue-in-cheek, merely to demonstrate with how little the infrastruc
The maximum you'd need would be two servers per segment, where a "server" could be as simple as a WRT54G running OpenWRT. (Those work very well, in fact.)
Maintenance is pretty darn trivial. Write a quick Perl script to generate and push the config files from a central database, and there basically isn't maintenance. (There is some, but nowhere near one administrator's work for a moderate- to medium-sized place.)
Furthermore, there are presumably routers somewhere holding the network together. You could use those to relay the DHCP to a single central cluster and drive administration even lower.
dhcp supports redundant modes of operation; furthermore, you could have a few servers (or pairs of servers) for different segments of the network, and they could easily share the database and only differ in which subnet they're on.
No, but you do lose the ability to change your default web browser if you're running 10.4.
Just because things work now doesn't mean they'll work when the power / $hardware_component / kernel fails unpredictably in a few days and your computer has to reboot.
So, 242 days puts you well before the recent udev upgrade, right. Are you sure your router's NICs will keep the same names? (JSYN, "yes" is a perfectly valid answer, and the fact that you've considered that gotcha doesn't mean you've considered them all.)
BTW, Gentoo is my distribution of choice, but that doesn't prevent me from recognizing its shortcomings. "I mean it seriously."
No, you'll be running Vista, running some other "approved" OS (i.e. OSX), or just avoiding Trusted DRM protected content.
Chances are, IMO, if you're the kind of person who wouldn't be running Vista or OSX, you don't care about the content, and you probably wouldn't be able to use it (in a TC-free world) anyway.
Wait, how does that really help?
If someone is trying to obtain the data on your hard drive, and "asking" you for your keys was an option, they presumably don't care about secrecy, and they're also presumably capable of getting the (encrypted) contents of the HDD. Why not just take the rest of the computer, TPM and all?
See [[Wikipedia:Trusted Computing]].
It's worth noting that much current hardware should be Vista-compatible, and is perfectly capable of running Linux. FOSS isn't fundamentally incompatible with Trusted Computing-- it's just incompatible with things which use Trusted Computing to secure against other things (e.g. using a Free OS with content which uses TC-based DRM. You'd have to pick either your ability to modify the OS or the content.)
Personally I don't believe they have this amount of clout, especially with the antitrust thing still hanging over their head.
Oh, come on! It's not exactly like the antitrust thing actually hurt them, or made them any less evil-empire-monopolistic. Remember that article about them probably having violated it a few days ago? Remember all the issues with the EU?
If they're capable of standing up to a multinational government, they're certainly capable of standing up to (probably buying out if necessary) the MAFIAA. (Even I wouldn't go so far as to say they have an obligation to do it, though.)