You always own your changes, unless you explicitly sell or give them to someone else (which is a requirement for contributing code to FSF projects, but not for distributing modified versions yourself). Nothing you create is GPL unless you put it under the GPL. That's the main idea of copyright law.
On the other hand, for a derived work, it's not going to be very useful by itself. If you want to distribute a work derived from a GPL work, you have to distribute the derived work under the GPL; you have no other permission to distribute the original which you modified.
If you create a derived work, you have to accept the terms of the GPL for the original, since you aren't allowed, under copyright law, to even modify a copyrighted work without distributing it. But you don't need to apply any license at all to the derived work, according to the GPL, unless you actually distribute it. You are merely required to license it to anyone who you distribute it to, not to the general public, or, in fact, to anyone at all.
So, in your example, even if you had integrated your work directly into Apache, even if Apache were actually GPL, you still would be able to keep all of the source secret, provided you didn't distribute your application, but rather ran it exclusively yourself (possibly allowing co-workers, paying customers, or the general public to use it online).
In any case, a database schema you create yourself is not a derived work; it's entirely your creation. Same for scripts you write from scratch. You can apply to these any license you'd like, including offering the same or different people multiple licenses.
I hear spoken English works pretty well, unless you're actually have some visual information, in which case you should use the real thing or a set of photos or PDFs or something like that.
If you have to have slides, show pictures of your pets or your vacation or something. It'll distract less from your talk.
SYN protection means that you don't keep any state for the SYN packets you receive, so that an attacker can't fill up your memory with half-open connections. You still have to respond to all of the SYNs.
I'm not entirely sure we should believe the analysts, however, since they're relying exclusively on packets that SCO sent out. Obviously, it would be trivial to forge these responses perfectly (either by SYN flooding the machine from itself, or simply by sending random responses). On the other hand, that would take a surprising amount of technical competance.
The only way to actually determine if they were actually attacked would be to find out if their upstream provider saw 700 million incoming SYNs during that period.
Using the environment to set up the initial configuration was a sensible choice; using the environment to set up some non-security-related configurations at other times was a sensible choice. On the other hand, having it automatically fetch the local network's root account along with the local network's printers was an oversight.
Given the number of people I know who have Mac laptops and use the wireless networks at conferences and cafes (and, sometimes, open wireless networks of companies near cafes), it makes a lot more sense to have an initial setup, where it trusts information from the environment (which is almost certainly your home network), but then doesn't let anything significant get overridden by other environments, unless you actually tell it to (like if you've given the laptop to someone else).
Actually, almost certainly all he'd need to do is type:
echo 1>/proc/sys/net/ipv4/tcp_syncookies
as root on the affected machine. Linux (which is what that server runs) has built-in support for ignoring SYN floods. It's actually easier to stop a SYN flood than it is to identify a SYN flood, these days.
Of course, it's possible that the machine did get taken down by something, and they have no idea what, and just picked an attack at random to call it (and they're obviously wrong about it being a SYN flood).
All of the current evidence points to a particular Linux user. But chances are they'll never be prosecuted, because SCO almost certainly didn't actually call any law enforcement, and it's not illegal, in any case, to shut down your own website.
According to Groklaw, not only is it implausible that this is a real attack, it's not even competently done. SCO blames a SYN flood, which is trivial to ignore. Their ISP hasn't had anything to do about it. While they say their email server was down, it actually wasn't. Their FTP server on the next IP over (and on the same block of addresses) had no problems. Their internal network almost certainly isn't anywhere near their Web server, network wise, and, if it was, it would almost certainly have a firewall that's not the web server.
It's clear that SCO's run out of technical people; not only are they faking technical problems, they can't even make up a technically sound attack on their own systems.
There's nothing really wrong with propping up SCO at this point. In fact, this is a good opportunity to have the GPL tested in court (in IBM's coutersuit), since it's pretty much a sure win for the GPL side. But in order for IBM to persue it, SCO needs to have enough money to cover IBM's expenses; otherwise SCO just goes bankrupt without creating any legal precedent. Furthermore, it's best for SCO to get money as an investment instead of a profit, so that Darl doesn't get profitable quarters and closer to vesting.
Digital is getting better rapidly, while film is staying about the same. This means that film is doomed, but it doesn't mean that you can get a better digital camera at the same price yet (for SLR, at least; the auto-everything digital cameras are better because they can work on the actual images).
Chances are that when you replace the camera you get, you'll replace it with a digital. But the technology isn't available or affordable for that digital today.
The scary thing is that NZ didn't have a legitimate way of shutting the project down. You'd think the NZ would actually have a law against building your own cruise missile, and they wouldn't give random individuals permission to build them based on thinking that they won't be able to do it.
I'm not entirely clear why he thought it was a good idea to design and build a cruise missile, but NZ really shouldn't have given him the go-ahead in the first place. It's not his job to prevent the profileration of missile technology, but it is the NZ government's, and they seem to have been dangerously lax.
The benefit of capitalism is that the different companies may choose different methods (in fact, with patents, they're forced to choose different methods), and so the obvious solution that turns out not to work won't hold up the industry for ages. If an industry is small enough that there's only one company in it, resources don't get split. If it's large enough that companies think that it will support multiple companies, these companies are required to use different methods.
Of course, there is a lot of cooperation between companies. The computer I'm sitting at uses parts from probably half a dozen companies, many of which were actually produced by a different company than the one they're branded by. But when a design flaw causes IBM hard drives to fail frequently, other manufacturer's hard drives are generally not affected, because they didn't use the same design.
Thanks; I think that was the reference I was remembering (although I also remember there being someone else who did a study on fooling a broad range of biometric sensors).
Right, the 2.6 is definitely better. So it's a good idea for a backport to 2.4, because it will allow people who try 2.6 but find it not to work with some of their devices to switch back and forth as needed.
Actually, people can steal your finger with a piece of tape and a bit of rubber. So far as I know, nobody's made a biometric system that actually manages to determine that what it's examining is actually flesh and blood, rather than a thin layer of some other material with somebody else's fingerprints on it (or something even less sophisticated).
Actually, that's a good reason for certain patches to be added and certain features to be backported. There are some things where the way you need to do things for 2.6 doesn't work for 2.4, and so it's not easy to switch back and forth. For example, the way that you need to configure XFree86 to enable both the built-in touchpad on a laptop and an external mouse if one is attached changes between 2.4 and 2.6. (The 2.4 way causes extra clicks on 2.6; the 2.6 way doesn't support the external mouse on 2.4)
So I used to use Java JDK 1.2, and it was fine. Then, whenever I used it, I'd get hit by waves of superheated gasses. Now it's really solid. And I've found out why: it's completed the Sun End of Life Process.
How do you know that the device isn't reading a non-FAT filesystem, and exporting to you a virtual FAT view of it? Just because the device has a HDD and the device looks like USB storage doesn't mean the USB storage actually shows the bit-for-bit contents of the hard drive.
I think it's more likely that crackers have noticed that OSS servers tend to be interesting to crack. There are a lot of services which might be vulnerable to a number of different exploits, and they might contain or have access to information that could be used to attack other servers.
Windows machines, by contrast, are pretty dull. It's evidently trivial to crack tons of them, and there's nothing interesting on them. Unless you want to do a DDoS attack, there's no point.
The telephony network gives you reliable, timely delivery. That is, you get a chunk of bandwidth on all of the segments between you and the other end, and this bandwidth carries your signal, whatever it is, as long as you're connected. This is why, if the system is overloaded, you may have a hard time getting a connection, but once you've got one, it's just like when the system isn't overloaded.
This is fundamentally different from an IP network, where routers along the path delay or drop packets as needed to be able to push data around, and the protocols are designed to manage the unreliability. Of course, they can only insure either that the stream never gets out of order or that the stream is never delayed too much, not the complete reliability of delivery that phone gives you.
So IP-to-telephone calls use both networks, and might get regulated that way. But pure VoIP calls aren't "telephone calls" at all; they're IP connections. It's no more "free telephone calls" than talking in person or talking by two-way radio. Of course, it's not free either; you'll have to pay somehow for your IP connection.
Incidentally, I suspect that traditional telephone may end up as a city service like water or sewer service. This is because it is in the government interest to provide 911 service, and to tax the public in the area accordingly, and IP, without dedicated bandwidth, may not be considered sufficient.
Actually, what I expect to see emerge is a bi-directional streaming audio protocol. Whether it has anything to do with the telephone or not is a matter of whether there is too much regulation there. For that matter, it may well not be limited to a single audio channel, but have support for video (if you have enough bandwidth), general file transfer, shared drawing space, etc.
On the other hand, the same people may well still use traditional telephony to call traditional phone numbers, because it could be too much of a hassle to provide the gateways if regulators don't like the idea. (Sure, you can go to a country where the regulators like the idea, but your friends will get annoyed if it's an international call to reach you, probably).
Slashdot Mirror
There's a model of the Flyer on the Great Dome (Pictures from the Boston Globe).
There's a model of the Flyer on the Great Dome (Pictures from the Boston Globe).
I remember when qtest came out, seeing how cool it was on my P90, and how unplayable it was on everybody else's 486s.
You always own your changes, unless you explicitly sell or give them to someone else (which is a requirement for contributing code to FSF projects, but not for distributing modified versions yourself). Nothing you create is GPL unless you put it under the GPL. That's the main idea of copyright law.
On the other hand, for a derived work, it's not going to be very useful by itself. If you want to distribute a work derived from a GPL work, you have to distribute the derived work under the GPL; you have no other permission to distribute the original which you modified.
If you create a derived work, you have to accept the terms of the GPL for the original, since you aren't allowed, under copyright law, to even modify a copyrighted work without distributing it. But you don't need to apply any license at all to the derived work, according to the GPL, unless you actually distribute it. You are merely required to license it to anyone who you distribute it to, not to the general public, or, in fact, to anyone at all.
So, in your example, even if you had integrated your work directly into Apache, even if Apache were actually GPL, you still would be able to keep all of the source secret, provided you didn't distribute your application, but rather ran it exclusively yourself (possibly allowing co-workers, paying customers, or the general public to use it online).
In any case, a database schema you create yourself is not a derived work; it's entirely your creation. Same for scripts you write from scratch. You can apply to these any license you'd like, including offering the same or different people multiple licenses.
I hear spoken English works pretty well, unless you're actually have some visual information, in which case you should use the real thing or a set of photos or PDFs or something like that.
If you have to have slides, show pictures of your pets or your vacation or something. It'll distract less from your talk.
SYN protection means that you don't keep any state for the SYN packets you receive, so that an attacker can't fill up your memory with half-open connections. You still have to respond to all of the SYNs.
I'm not entirely sure we should believe the analysts, however, since they're relying exclusively on packets that SCO sent out. Obviously, it would be trivial to forge these responses perfectly (either by SYN flooding the machine from itself, or simply by sending random responses). On the other hand, that would take a surprising amount of technical competance.
The only way to actually determine if they were actually attacked would be to find out if their upstream provider saw 700 million incoming SYNs during that period.
Using the environment to set up the initial configuration was a sensible choice; using the environment to set up some non-security-related configurations at other times was a sensible choice. On the other hand, having it automatically fetch the local network's root account along with the local network's printers was an oversight.
Given the number of people I know who have Mac laptops and use the wireless networks at conferences and cafes (and, sometimes, open wireless networks of companies near cafes), it makes a lot more sense to have an initial setup, where it trusts information from the environment (which is almost certainly your home network), but then doesn't let anything significant get overridden by other environments, unless you actually tell it to (like if you've given the laptop to someone else).
Actually, almost certainly all he'd need to do is type:
echo 1>/proc/sys/net/ipv4/tcp_syncookies
as root on the affected machine. Linux (which is what that server runs) has built-in support for ignoring SYN floods. It's actually easier to stop a SYN flood than it is to identify a SYN flood, these days.
Of course, it's possible that the machine did get taken down by something, and they have no idea what, and just picked an attack at random to call it (and they're obviously wrong about it being a SYN flood).
All of the current evidence points to a particular Linux user. But chances are they'll never be prosecuted, because SCO almost certainly didn't actually call any law enforcement, and it's not illegal, in any case, to shut down your own website.
According to Groklaw, not only is it implausible that this is a real attack, it's not even competently done. SCO blames a SYN flood, which is trivial to ignore. Their ISP hasn't had anything to do about it. While they say their email server was down, it actually wasn't. Their FTP server on the next IP over (and on the same block of addresses) had no problems. Their internal network almost certainly isn't anywhere near their Web server, network wise, and, if it was, it would almost certainly have a firewall that's not the web server.
It's clear that SCO's run out of technical people; not only are they faking technical problems, they can't even make up a technically sound attack on their own systems.
There's nothing really wrong with propping up SCO at this point. In fact, this is a good opportunity to have the GPL tested in court (in IBM's coutersuit), since it's pretty much a sure win for the GPL side. But in order for IBM to persue it, SCO needs to have enough money to cover IBM's expenses; otherwise SCO just goes bankrupt without creating any legal precedent. Furthermore, it's best for SCO to get money as an investment instead of a profit, so that Darl doesn't get profitable quarters and closer to vesting.
Digital is getting better rapidly, while film is staying about the same. This means that film is doomed, but it doesn't mean that you can get a better digital camera at the same price yet (for SLR, at least; the auto-everything digital cameras are better because they can work on the actual images).
Chances are that when you replace the camera you get, you'll replace it with a digital. But the technology isn't available or affordable for that digital today.
The scary thing is that NZ didn't have a legitimate way of shutting the project down. You'd think the NZ would actually have a law against building your own cruise missile, and they wouldn't give random individuals permission to build them based on thinking that they won't be able to do it.
I'm not entirely clear why he thought it was a good idea to design and build a cruise missile, but NZ really shouldn't have given him the go-ahead in the first place. It's not his job to prevent the profileration of missile technology, but it is the NZ government's, and they seem to have been dangerously lax.
The benefit of capitalism is that the different companies may choose different methods (in fact, with patents, they're forced to choose different methods), and so the obvious solution that turns out not to work won't hold up the industry for ages. If an industry is small enough that there's only one company in it, resources don't get split. If it's large enough that companies think that it will support multiple companies, these companies are required to use different methods.
Of course, there is a lot of cooperation between companies. The computer I'm sitting at uses parts from probably half a dozen companies, many of which were actually produced by a different company than the one they're branded by. But when a design flaw causes IBM hard drives to fail frequently, other manufacturer's hard drives are generally not affected, because they didn't use the same design.
Thanks; I think that was the reference I was remembering (although I also remember there being someone else who did a study on fooling a broad range of biometric sensors).
Right, the 2.6 is definitely better. So it's a good idea for a backport to 2.4, because it will allow people who try 2.6 but find it not to work with some of their devices to switch back and forth as needed.
Actually, people can steal your finger with a piece of tape and a bit of rubber. So far as I know, nobody's made a biometric system that actually manages to determine that what it's examining is actually flesh and blood, rather than a thin layer of some other material with somebody else's fingerprints on it (or something even less sophisticated).
Actually, that's a good reason for certain patches to be added and certain features to be backported. There are some things where the way you need to do things for 2.6 doesn't work for 2.4, and so it's not easy to switch back and forth. For example, the way that you need to configure XFree86 to enable both the built-in touchpad on a laptop and an external mouse if one is attached changes between 2.4 and 2.6. (The 2.4 way causes extra clicks on 2.6; the 2.6 way doesn't support the external mouse on 2.4)
I suspect he's an out-of-work comedian. But there's a reason they put him on the only train with a working PA.
You know you've been riding the green line too much when you hear "Uhh uhh uh uh uh uh. Uhh uh uh uh", and you think "Hynes".
So I used to use Java JDK 1.2, and it was fine. Then, whenever I used it, I'd get hit by waves of superheated gasses. Now it's really solid. And I've found out why: it's completed the Sun End of Life Process.
How many programmers does it take to change a light bulb? Can't be done. It's a hardware problem.
How many circuit designers does it take to change a light blub? Can't be done, either. It's a software problem.
How do you know that the device isn't reading a non-FAT filesystem, and exporting to you a virtual FAT view of it? Just because the device has a HDD and the device looks like USB storage doesn't mean the USB storage actually shows the bit-for-bit contents of the hard drive.
I think it's more likely that crackers have noticed that OSS servers tend to be interesting to crack. There are a lot of services which might be vulnerable to a number of different exploits, and they might contain or have access to information that could be used to attack other servers.
Windows machines, by contrast, are pretty dull. It's evidently trivial to crack tons of them, and there's nothing interesting on them. Unless you want to do a DDoS attack, there's no point.
The telephony network gives you reliable, timely delivery. That is, you get a chunk of bandwidth on all of the segments between you and the other end, and this bandwidth carries your signal, whatever it is, as long as you're connected. This is why, if the system is overloaded, you may have a hard time getting a connection, but once you've got one, it's just like when the system isn't overloaded.
This is fundamentally different from an IP network, where routers along the path delay or drop packets as needed to be able to push data around, and the protocols are designed to manage the unreliability. Of course, they can only insure either that the stream never gets out of order or that the stream is never delayed too much, not the complete reliability of delivery that phone gives you.
So IP-to-telephone calls use both networks, and might get regulated that way. But pure VoIP calls aren't "telephone calls" at all; they're IP connections. It's no more "free telephone calls" than talking in person or talking by two-way radio. Of course, it's not free either; you'll have to pay somehow for your IP connection.
Incidentally, I suspect that traditional telephone may end up as a city service like water or sewer service. This is because it is in the government interest to provide 911 service, and to tax the public in the area accordingly, and IP, without dedicated bandwidth, may not be considered sufficient.
Actually, what I expect to see emerge is a bi-directional streaming audio protocol. Whether it has anything to do with the telephone or not is a matter of whether there is too much regulation there. For that matter, it may well not be limited to a single audio channel, but have support for video (if you have enough bandwidth), general file transfer, shared drawing space, etc.
On the other hand, the same people may well still use traditional telephony to call traditional phone numbers, because it could be too much of a hassle to provide the gateways if regulators don't like the idea. (Sure, you can go to a country where the regulators like the idea, but your friends will get annoyed if it's an international call to reach you, probably).