> On a LAN environment free of switches, this has potential, but that's about it.
And how often would you expect to be on a switch-free LAN? Aren't most (ethernet) networks (even two host home networks) done with switches? The only exception I can think of is WiFi, and I'd say the odds of those having public routable IPs are low.
I know, but one a number of the cars, that was not enough! Several engineblocks were split down the middle. And the conditions meant that others could not be inspected before the cars had been driven out of the hold (probably causing some minor damage from runnig without coolant). That's the story as I've been told it by my late uncle who was there (though not in charge of the circus).
I actually once heard about a bunch of cars with frozen pipes. Granted, it was japanese cars bound for California, and they were frozen by mistake (they were transported as bulk cargo on a ship with refrigiated cargoholds) during a cooling plant test. But the end result was a lot of cars with pipes (and in a few cases engines) split open by the water freezing and expanding.
Maybe because we don't just "want to give away our work"? We want to share it with the world, on the (IMHO) small condition that the world is willing to share what additions they do to it with us. Is that really so bad? Releasing software into the public domain makes it free of cost, as long as someone is willing to distribute it to me free of cost. But what else does that give me?
The point is not to grant total freedom to anyone, since that would imply taking away freedom from others (i.e. if I'm free to take all your money, you cannot at the same time be free to keep your money), but to try to maximize the total amount of freedom - within the limits of the greater system.
...a major firewall between the application and the kernal....
Are you a bit confused, or would you like to explain what you mean by firewall between the kernel and the application? Are you thinking of virtual servers? Then how about I just become root in the virtual server? I still have root on a machine in your network, although it might not be running more than one service I can fool around with (until I start my own services).
SSH accounts should ALWAYS be on a different box than a major server- NEVER on the same box. And preferably, not at all.
Maybe users do not need shell access to all servers, but how would you administer a colocated/remote/headless/etc. machine without having (secure) remote shell access for relevant staff? How about users with legitimate need for shell access to the machine (remote working, checking mail (yes, I prefer ssh mailhost mutt over any webmail, anyday - and I and many others would be vastly less effective with webmail (until someone builds a webmail system of similar strength (but then it would need to include most of a terminal emulator/shell anyway)), local preprocessing of big datasets (say you need to do a simple search on a few GB of data - you want me to transfer that over the network (perhaps even to a remote location), or run the search locally and transfer a few bytes of result))?
By taking telnet and SSH off of it and requiring passwords on FTP.
You want to remove telnet, fine go ahead (might want to leave the telnet executable though (but do delete telnetd), it is very handy for diagnostics). But you want to delete ssh and leave ftp? You do know that ssh can be used for more secure filetransfer/remote filemanagement than ftp (scp/sftp)? You know that ssh allows you to setup remote accesses, that can only run the apps needed for that particulary purpose?
...require an administrator with LOCAL (as in hardware keyboard) access. It's called being paranoid...
If you are that paranoid, then your server is not connected to the Internet. If there is a codeinjection exploit in that ftpd you wanted to leave running, I don't need a shell to use a local root exploit (shells are not the only deamons that can exec() you know).
The one thing lacking in slashdot, compared to good mail/news readers, is thread/user killfiles. I would love to be able to kill offtopic threads, or eliminate posts by specific users (I know friends/foes can do this, but it is not what it is for). I want three buttons on each posting (when logged in): Kill thread (making it disappear from my worldview forever), kill user (never see another posts by this user), and semi-kill user (never show posts by user, unless they have highly rated followups).
Note: I'm not picking on you in particular, your posting is just the start of a massive, off-topic, thread, which I would rather have been without. You can speak your mind all you want, but I'm just bitching about the fact that I have no easy way to stop listening.
Subsection 3 a and c (paraphrasing from memory because I'm lasy and this is/.) allow you to avoid 3.b resposibility by either _always_ giving out source with binaries (3.a) or distributing unchanged binaries uncomercially along with an offer (obtained under 3.b) from an upstream distributor (3.c).
And yes, you are probably allowed charge for your trouble (within reason... and 3.b source distribution must be available to anyone with a copy of your binary (since it must include the offer to be legally distributed)).
As far as relicensing goes, you have no problems until the first patch from a third party is committed. So in your example, the code up until 2005-11-30 is yours to do whatever you want with. And it remains so until copyright runs out (in Disneys dreamworld: forever). The code from 2005-12-01 and on is the only thing you do not have complete control over. But even then you might be able to keep a clean branch if you wish (use a good revision control system). Divide your own changes into two piles: ones that work without changes you do not hold the copyright to, and those which needs (including recursively) the contributions of others. I definetely ANAL, but I think that you could resonably easily argue that pile one is yours to license as you see fit (assuming that you are careful (rewrites of outside patches, and stuff directly inspired from them, needs to go in pile two as well. Basicly anything you are not absolutely sure is not derived)). Question is if pile one will be big or small, and that depends on lots of things, but first and foremost what patches you accept.
One way to do what you want is to GPL, but only allow patches assigned to you (like GNU does). That might spawn a fork, or lessen the number of patches, but if you do good work and announce your intentions up front (e.g: Explain that you intend to sell licenses to finance development of the Free side, promise to keep the code Free (only if you can live up to the promise!), provide good service to GPL users, and so on) there might still be some sucke^H^H^H^H^H helpful hackers out there (I hope that time will show the "suckers" part to be fun (as intended), and not a prediction).
Another option would be to carefully (and in the open, documented) setup your project as several seperate pieces, licensed differently. This might need a lot of thinking (perhaps even someone with legal expertise) to hack together, but but if you are careful, and _upfront_, about what is Free and what is not (and perhaps even why!), you might be able to create a good setup. One example could be to release content for a game seperate from the code (like Id with Quake).
The GPL is just a copyright license. You (or the forker, or anyone else) can apply it to exactly the code they hold the copyright to, and they are free to apply any other license to that code. What makes the GPL work (in the long run) is that what's out under the GPL cannot be retracted (unless it was released without authority, but then we are usually heading into corporate issues (or the SCO case...)), and that any contribution not explicitly assigned to the main copyrightholder remains the copyright of the contributor.
Assuming that the forker initiated the project, he would still need to purge any contributions made by third parties (or get their ok to a relicensing), and get rid of any code that derives from those contributions, before a release could legally be made under another license.
And as you (and I) pointed out, the code, at the point of forking (and until relicensing is in place), is available under the GPL (and will be as long as someone willing has a copy).
For a bigger example look at the discussion a while back, when someone offered to "buy" a relicensed linux-tree. Linux has enough copyrightholders that even if Linus was ok with (of cause he was not), there could never be any meaningful relicensed version (not GPL to BSD anyway).
The executable is only for the target OS/architecture anyway. Adding a signature on some executables should not change that.
The same person who generates the detached openpgp signature for each mozilla/firefox release, could put a signature in the binary for all OS' supporting that (before detached sinatures are made, wouln't want to spoil those). The signatures do not imply additional checks of the code, only that the code, as signed, represents what mozilla.org _intends_ to distribute.
I happen to trust mozilla.org more than MS, but I fail to see how that is relevant (it is a personal question, and only my perception of the two organisations behaviour is going to influence that). Assuming that you trust MS enough to do the signature checking right, a signature would connect the binary with someone, claiming to be mozilla.org, who paid verisign some money and signed some documents (I would assume (background checks/investigation/whatever I think is beyond verisign)), no more but also no less. All in all not a totally bad idea.
All that a digital signature is, is a hash (usually md5 or sha1 or similar) of the signed object (the binary in this case), encrypted _to_ a public key (the reverse of a public key encrypted file). Encrypting to the public key is only possible using the private key, proving that what is decrypted was what the holder of the private key encrypted. Basically, signature = encrypt(hash(data),private_key), and to check, hash(data) == decrypt(signature,public_key).
So the diference between signatures and md5 hashes (besides the strength of the hash algorithm used (md5 is aging, but I can't recall the attack you mention, link?)) is that signatures are a secure way of distributing hashes, while simply publishing a list of md5/sha1 hashes just allows you to compare files from other sources/what you downloaded with what is on the (main) site.
In the case of hashes used by package managers, it is not uncommon for the hashes to come from a totally seperate entity than the sources. So if say Gentoo and mozilla.org is hacked at the same time, trojaned mozilla source might be downloaded by gentoo users, but if only one is hacked, hashes are enough to stop a trojan.
Oh yeah, as others have mentioned, mozilla.org does sign releases. Just get ${RELEASED_FILE}.asc, it's an openpgp detached signature, matching the published (and presumably signed by lots of other keys) key for mozilla.org. Only difference is that it is not MS-style, verisign certified (I don't trust verisign all that much), centralised, embeded signatures. But you mention pgp, so I'll assume you know enough to decide if the key can be trusted.
And to make it even better, there are detached openpgp signatures. So the package is in fact digitally signed, just not the way microsoft likes it to be. I wonder if an openpgp sig could be attached to the binary in the same fasion as the sigs ie likes? Maybe enigmail could be extended to support that on mozilla and firefox. And maybe mozilla.org should get a certificate, just to stop this kind of FUD. wouldn't really hurt, IMHO.
An easy mistake (since the info you were looking for is not on the english page), but the may 2004 date is the start of the 2004 season. The project has been in operation since 1995, so while "standing the test of time" might not have been achieved yet, it is far from a brand new thing. If you happen to know danish (or wish to try with automated translation) this is the history of the "Bycykel" project. The project was concieved in the late eighties, and started on may 31st of 1995.
Wrong: Assume population of 10 persons. 6 with IQ 110, 3 with IQ 90, and one with IQ 70. The average IQ is (6*110+3*90+70)/10 = 100. There are however 6 persons with above avarage IQ. So half the population is not "by definition" of below average intelligence. The word you are looking for is median.
That would not do what you expect. Unless abc is a valid command on 123.123.123.123. And you still have to enter the password (with openssh at least (it must be accessing the tty directly)).
dossen@leela:~$ echo 'this is neither a command, nor a password' | SSH_AUTH_SOCK='' ssh dossen@hermes Pseudo-terminal will not be allocated because stdin is not a terminal. Enter passphrase for key '/home/dossen/.ssh/id_rsa': -sh: line 1: this: command not found
Good question. It would require the SMB protocol to support a serverside local copy operation. And then the userspace software (KDE) needs to know about this option. Samba can't distinguish between a copy and a read/write unless it is told about it.
The "stealing" might refer to SCO's varied statements about the validity, while they are also shipping (and advertising (e.g. mozilla was mentioned on the defaced page the other day)) software under the GPL (yes I know mozilla is under more than the GPL, but it is just what I remember spotting. They use other Free stuff too.)
The purpose of copyright (US law anyway), is to encourage the publishing of materials, with the intent of creating a rich public domain, right?
This is accomplished by giving a legal monopoly to the author/publisher for a "limited time".
Once this limited time is up, the work enters the public domain.
How should that system react to materials with DRM protection?
These materials will forever remain under technical protection (assuming that no cracks are found). Why should they then recieve legal protection?
Would it not be reasonable to require a little quid pro quo? Perhaps require unprotected (full quality, whatever this means) copies to be filed with libraries?
That way you could get it in 70 years (if Mickey hasn't needed another extension). Maybe you should even be allowed access if you could document a fair use reason (or perhaps you could get a fresh copy when your cd/dvd/whatever is broken)?
First a disclaimer: I'm danish and know little about the US tax system.
While I'm not going to dispute your argument about the "proverbial single parent", there is an easy way to do progressive taxation without that problem: Say you have three rates, X, Y, and Z, and two limits, A and B. If your income is I, your tax would be:
T = I*X + max(0,(I-A)*Y) + max(0,(I-B)*Z)
That way you are never worse off for earning more.
If you earn say $21,000 and the limit (A) is $21,000, then you get
(1-X)*$21,000
Get a raise to $22,000, you get
(1-X)*$21,000 + (1-X-Y)*$1,000
which is more. You still get progressivly less each time your pay goes up, but silly stuff like having less money after a raise doesn't happen.
To the best of my knowledge this is how we do it (adding in stuff like deductables, interest, back-taxes, etc.).
The second problem could be worked around by downloading a reasonable amount of data that you might need in the not too distant future as encrypted chunks to a cache directory (I don't think we need to take steps to avoid trafficanalysis, but noop chunks could be included if need be). Then when the server wants you to have access to some picture/sound/video/other rich content, it just needs to send you some sort of UID of the piece and a decryption key. That should work fast enough, without violating the principle of not giving the client unneeded information (unless you consider strongly encrypted information accessable). Once you have had access to a chunk, you might be able to catch the decrypt, but since the server might never call for that piece again that doesn't matter much (as far as I can figure).
Slashdot Mirror
> On a LAN environment free of switches, this has potential, but that's about it.
And how often would you expect to be on a switch-free LAN? Aren't most (ethernet) networks (even two host home networks) done with switches? The only exception I can think of is WiFi, and I'd say the odds of those having public routable IPs are low.
Cue the apples and oranges comparison: http://www.improb.com/airchives/paperair/volume1/v 1i3/air-1-3-apples.html
I know, but one a number of the cars, that was not enough! Several engineblocks were split down the middle. And the conditions meant that others could not be inspected before the cars had been driven out of the hold (probably causing some minor damage from runnig without coolant). That's the story as I've been told it by my late uncle who was there (though not in charge of the circus).
I actually once heard about a bunch of cars with frozen pipes. Granted, it was japanese cars bound for California, and they were frozen by mistake (they were transported as bulk cargo on a ship with refrigiated cargoholds) during a cooling plant test. But the end result was a lot of cars with pipes (and in a few cases engines) split open by the water freezing and expanding.
Maybe because we don't just "want to give away our work"? We want to share it with the world, on the (IMHO) small condition that the world is willing to share what additions they do to it with us. Is that really so bad? Releasing software into the public domain makes it free of cost, as long as someone is willing to distribute it to me free of cost. But what else does that give me?
The point is not to grant total freedom to anyone, since that would imply taking away freedom from others (i.e. if I'm free to take all your money, you cannot at the same time be free to keep your money), but to try to maximize the total amount of freedom - within the limits of the greater system.
In this case it would be rather hard to go old enough to avoid the system call. It is the original shared library implementation, from 0.12 (yes _0_ dot _12_). Source: http://groups-beta.google.com/group/comp.os.linux/ msg/648f904b7e22ea21
Are you a bit confused, or would you like to explain what you mean by firewall between the kernel and the application? Are you thinking of virtual servers? Then how about I just become root in the virtual server? I still have root on a machine in your network, although it might not be running more than one service I can fool around with (until I start my own services).
Maybe users do not need shell access to all servers, but how would you administer a colocated/remote/headless/etc. machine without having (secure) remote shell access for relevant staff? How about users with legitimate need for shell access to the machine (remote working, checking mail (yes, I prefer ssh mailhost mutt over any webmail, anyday - and I and many others would be vastly less effective with webmail (until someone builds a webmail system of similar strength (but then it would need to include most of a terminal emulator/shell anyway)), local preprocessing of big datasets (say you need to do a simple search on a few GB of data - you want me to transfer that over the network (perhaps even to a remote location), or run the search locally and transfer a few bytes of result))?
You want to remove telnet, fine go ahead (might want to leave the telnet executable though (but do delete telnetd), it is very handy for diagnostics). But you want to delete ssh and leave ftp? You do know that ssh can be used for more secure filetransfer/remote filemanagement than ftp (scp/sftp)? You know that ssh allows you to setup remote accesses, that can only run the apps needed for that particulary purpose?
If you are that paranoid, then your server is not connected to the Internet. If there is a codeinjection exploit in that ftpd you wanted to leave running, I don't need a shell to use a local root exploit (shells are not the only deamons that can exec() you know).
The one thing lacking in slashdot, compared to good mail/news readers, is thread/user killfiles. I would love to be able to kill offtopic threads, or eliminate posts by specific users (I know friends/foes can do this, but it is not what it is for). I want three buttons on each posting (when logged in): Kill thread (making it disappear from my worldview forever), kill user (never see another posts by this user), and semi-kill user (never show posts by user, unless they have highly rated followups).
Note: I'm not picking on you in particular, your posting is just the start of a massive, off-topic, thread, which I would rather have been without. You can speak your mind all you want, but I'm just bitching about the fact that I have no easy way to stop listening.
Subsection 3 a and c (paraphrasing from memory because I'm lasy and this is /.) allow you to avoid 3.b resposibility by either _always_ giving out source with binaries (3.a) or distributing unchanged binaries uncomercially along with an offer (obtained under 3.b) from an upstream distributor (3.c).
And yes, you are probably allowed charge for your trouble (within reason... and 3.b source distribution must be available to anyone with a copy of your binary (since it must include the offer to be legally distributed)).
As far as relicensing goes, you have no problems until the first patch from a third party is committed. So in your example, the code up until 2005-11-30 is yours to do whatever you want with. And it remains so until copyright runs out (in Disneys dreamworld: forever). The code from 2005-12-01 and on is the only thing you do not have complete control over. But even then you might be able to keep a clean branch if you wish (use a good revision control system). Divide your own changes into two piles: ones that work without changes you do not hold the copyright to, and those which needs (including recursively) the contributions of others. I definetely ANAL, but I think that you could resonably easily argue that pile one is yours to license as you see fit (assuming that you are careful (rewrites of outside patches, and stuff directly inspired from them, needs to go in pile two as well. Basicly anything you are not absolutely sure is not derived)). Question is if pile one will be big or small, and that depends on lots of things, but first and foremost what patches you accept.
One way to do what you want is to GPL, but only allow patches assigned to you (like GNU does). That might spawn a fork, or lessen the number of patches, but if you do good work and announce your intentions up front (e.g: Explain that you intend to sell licenses to finance development of the Free side, promise to keep the code Free (only if you can live up to the promise!), provide good service to GPL users, and so on) there might still be some sucke^H^H^H^H^H helpful hackers out there (I hope that time will show the "suckers" part to be fun (as intended), and not a prediction).
Another option would be to carefully (and in the open, documented) setup your project as several seperate pieces, licensed differently. This might need a lot of thinking (perhaps even someone with legal expertise) to hack together, but but if you are careful, and _upfront_, about what is Free and what is not (and perhaps even why!), you might be able to create a good setup. One example could be to release content for a game seperate from the code (like Id with Quake).
The GPL is just a copyright license. You (or the forker, or anyone else) can apply it to exactly the code they hold the copyright to, and they are free to apply any other license to that code. What makes the GPL work (in the long run) is that what's out under the GPL cannot be retracted (unless it was released without authority, but then we are usually heading into corporate issues (or the SCO case...)), and that any contribution not explicitly assigned to the main copyrightholder remains the copyright of the contributor.
Assuming that the forker initiated the project, he would still need to purge any contributions made by third parties (or get their ok to a relicensing), and get rid of any code that derives from those contributions, before a release could legally be made under another license.
And as you (and I) pointed out, the code, at the point of forking (and until relicensing is in place), is available under the GPL (and will be as long as someone willing has a copy).
For a bigger example look at the discussion a while back, when someone offered to "buy" a relicensed linux-tree. Linux has enough copyrightholders that even if Linus was ok with (of cause he was not), there could never be any meaningful relicensed version (not GPL to BSD anyway).
Is it supposed to be funny, or do you believe in this incoherent kookery (http://en.wikipedia.org/wiki/Time_cube is at least readable)?
The executable is only for the target OS/architecture anyway. Adding a signature on some executables should not change that.
The same person who generates the detached openpgp signature for each mozilla/firefox release, could put a signature in the binary for all OS' supporting that (before detached sinatures are made, wouln't want to spoil those). The signatures do not imply additional checks of the code, only that the code, as signed, represents what mozilla.org _intends_ to distribute.
I happen to trust mozilla.org more than MS, but I fail to see how that is relevant (it is a personal question, and only my perception of the two organisations behaviour is going to influence that). Assuming that you trust MS enough to do the signature checking right, a signature would connect the binary with someone, claiming to be mozilla.org, who paid verisign some money and signed some documents (I would assume (background checks/investigation/whatever I think is beyond verisign)), no more but also no less. All in all not a totally bad idea.
Code signing is based on hashing.
All that a digital signature is, is a hash (usually md5 or sha1 or similar) of the signed object (the binary in this case), encrypted _to_ a public key (the reverse of a public key encrypted file). Encrypting to the public key is only possible using the private key, proving that what is decrypted was what the holder of the private key encrypted. Basically, signature = encrypt(hash(data),private_key), and to check, hash(data) == decrypt(signature,public_key).
So the diference between signatures and md5 hashes (besides the strength of the hash algorithm used (md5 is aging, but I can't recall the attack you mention, link?)) is that signatures are a secure way of distributing hashes, while simply publishing a list of md5/sha1 hashes just allows you to compare files from other sources/what you downloaded with what is on the (main) site.
In the case of hashes used by package managers, it is not uncommon for the hashes to come from a totally seperate entity than the sources. So if say Gentoo and mozilla.org is hacked at the same time, trojaned mozilla source might be downloaded by gentoo users, but if only one is hacked, hashes are enough to stop a trojan.
Oh yeah, as others have mentioned, mozilla.org does sign releases. Just get ${RELEASED_FILE}.asc, it's an openpgp detached signature, matching the published (and presumably signed by lots of other keys) key for mozilla.org. Only difference is that it is not MS-style, verisign certified (I don't trust verisign all that much), centralised, embeded signatures. But you mention pgp, so I'll assume you know enough to decide if the key can be trusted.
And to make it even better, there are detached openpgp signatures. So the package is in fact digitally signed, just not the way microsoft likes it to be. I wonder if an openpgp sig could be attached to the binary in the same fasion as the sigs ie likes? Maybe enigmail could be extended to support that on mozilla and firefox. And maybe mozilla.org should get a certificate, just to stop this kind of FUD. wouldn't really hurt, IMHO.
An easy mistake (since the info you were looking for is not on the english page), but the may 2004 date is the start of the 2004 season. The project has been in operation since 1995, so while "standing the test of time" might not have been achieved yet, it is far from a brand new thing. If you happen to know danish (or wish to try with automated translation) this is the history of the "Bycykel" project. The project was concieved in the late eighties, and started on may 31st of 1995.
Wrong: Assume population of 10 persons. 6 with IQ 110, 3 with IQ 90, and one with IQ 70. The average IQ is (6*110+3*90+70)/10 = 100. There are however 6 persons with above avarage IQ. So half the population is not "by definition" of below average intelligence. The word you are looking for is median.
Good question. It would require the SMB protocol to support a serverside local copy operation. And then the userspace software (KDE) needs to know about this option. Samba can't distinguish between a copy and a read/write unless it is told about it.
The "stealing" might refer to SCO's varied statements about the validity, while they are also shipping (and advertising (e.g. mozilla was mentioned on the defaced page the other day)) software under the GPL (yes I know mozilla is under more than the GPL, but it is just what I remember spotting. They use other Free stuff too.)
The purpose of copyright (US law anyway), is to encourage the publishing of materials, with the intent of creating a rich public domain, right?
This is accomplished by giving a legal monopoly to the author/publisher for a "limited time".
Once this limited time is up, the work enters the public domain.
How should that system react to materials with DRM protection?
These materials will forever remain under technical protection (assuming that no cracks are found). Why should they then recieve legal protection?
Would it not be reasonable to require a little quid pro quo? Perhaps require unprotected (full quality, whatever this means) copies to be filed with libraries?
That way you could get it in 70 years (if Mickey hasn't needed another extension). Maybe you should even be allowed access if you could document a fair use reason (or perhaps you could get a fresh copy when your cd/dvd/whatever is broken)?
While I'm not going to dispute your argument about the "proverbial single parent", there is an easy way to do progressive taxation without that problem: Say you have three rates, X, Y, and Z, and two limits, A and B. If your income is I, your tax would be:That way you are never worse off for earning more. If you earn say $21,000 and the limit (A) is $21,000, then you get Get a raise to $22,000, you getwhich is more. You still get progressivly less each time your pay goes up, but silly stuff like having less money after a raise doesn't happen.
To the best of my knowledge this is how we do it (adding in stuff like deductables, interest, back-taxes, etc.).
The second problem could be worked around by downloading a reasonable amount of data that you might need in the not too distant future as encrypted chunks to a cache directory (I don't think we need to take steps to avoid trafficanalysis, but noop chunks could be included if need be). Then when the server wants you to have access to some picture/sound/video/other rich content, it just needs to send you some sort of UID of the piece and a decryption key. That should work fast enough, without violating the principle of not giving the client unneeded information (unless you consider strongly encrypted information accessable). Once you have had access to a chunk, you might be able to catch the decrypt, but since the server might never call for that piece again that doesn't matter much (as far as I can figure).