Yeah, he was arrested for telling the truth, even after he was told he wasn't allowed to. That makes it sooooo much better.
To paraphrase Indiana Jones: "Science is not the search for truth; if you want that, theology is down the hall."
While the relative sizes of the Sun and Earth are fact, nothing more than offhand parsimony puts the Sun or the Earth at rest in relation to the other.
As per Einstein, all movement is relative. It's perfectly valid to say that the Sun moves around the Earth--and the other planets move around the Earth, but have their orbits (incredibly) skewed by the gravitational pull of the sun. (If you're doing something like, oh, making a chart of the sky, an earth-centric model is more useful than a sun-centric model.)
Apparantly, Gallielo was arrested for maligning the church, and then told to be quiet about the subjet wherein he maligned the chuch. His scientific merit, apparantly, had little to do with the gag order.
Darn, that would be spiffy. Wordperfect, back when it was the king of the PC, used to have a "function key reference" card, that neatly spelled out all of the commands; same thing, but eaiser on the hardware budget.
GUIs are good, but they could be done a LOT better--and CLIs tend to be limitd by their "ask a question, get an answer" model.
It really is true that if html is not allowed as a 'mail medium' the spammers will not be allowed to show their presentations and/or direct you to dangerous sites. It is really that simple and if Outlook is out of the picture, spam has the great setback that has been a long time coming. This is a serious note BTW.
You're wrong.
Outlook is just one mail client. So long as HTML mail can be sent, it will be sent, and it will be used for spam--and for other things as well. It doesn't matter if every installation of Outlook suddenly vanishes tomorrow--there will still be HTML/MHTML mail, and there will still be spam.
Of course, to remove HTML mail would require a level of effort such that a proper check on spam would be easier to implement.
Only as much as a priest of a false religion is lying.
Microsoft servers _do_ get hacked more than Linux servers, but this is because there are far more MS servers of an identical configuration than there are Linux servers. They also tend to crash more--especially IIS.
So, Linux does get hacked, and there have been viruses written for Linux--but there are far far more hackers and virus-writers aimed at MS Windows as opposed to Linux.
For somebody who was obviously distressed when somebody tried to teach you a "lesson", you seem very eager to assume the role of a lecturer. You might like to contemplate that I have nothing to learn about UNIX history from you.
Let's settle this before we go on.
I have absolutly no problem with you, me or a lurker using a historical reference to make a point. What i objected to was your "I'm telling you something, so you had better pay attention" remark--it struck me as a horribly condescending attitude, and added nothing to the conversation.
That said...
# Load Outlook. First tool. # Compose mail. Microsoft Word loads with a blank page. Second tool. # I decide I want a diagram. Insert Picture. Visio loads with a blank page. Third tool. # Picture looks OK. I need an attachment. I decide to ZIP it. Start WinZip. Fourth tool.
All of the programs you noted, with the exception of WinZip, violate the UNIX Tool Philosophy. They do many, many things, and they have grown exponentially in size since their first incarnation. They're great examples of my modified "Tool Philosophy", though: (fairly) stable and they do their job sufficiently completely. (And, with the exception of Winzip, you can use all of them by launching a single application, and then performing tasks from that single app to call the others.)
A better example of the classic "Tool Philosophy":
* Use "edit" to compose e-mail and save as text file. (first tool) * Run "spellcheck" on text file. (second tool) * Use "chartmaker" to create your diagram (third tool) * Open "gview" to check diagram. (fourth tool) * Run "zip" to compress graphic. (fifth tool) * Run PINE to send e-mail. (sixth tool.)
And this is assuming that all of your programs have a common format, and "chartmaker" can save as the right graphics file; if not, you might need to run "convert" to change the chart to an acceptable format for your audience.
If you would rather do the same task (send an e-mail with a chart), you can do it with one program (MS Word or Outlook) on a properly setup machine.
Sheesh. I'm disagreeing with you, not stubbornly refusing to learn your lesson. I stand by my original statement: the UNIX philosophy is out of date, and should be updated.
The UNIX philosophy was constructed at a time when all computers were (essentially) mainframes, all computer work was computing, and all users were experts. They were the computer-equivalent of early machine builders: if an early computer staff wanted to do something, they almost always had to create it in-house.
The world of today is vastly different, with varying file formats, (spoken) languages, and purposes. The computer is a notebook, reference tool, and communications medium far more than it is a computing device. (To continue the machinist analogy, most machine builders today don't work with the gears and pullies of one machine at a time--they create markets and assembly lines to make machines en masse.)
Given this shift in the use of computers, a shift in design philosophy is rather appropriate. It doesn't matter if it's small, so long as it's stable. It doesn't matter if each executable is focused, so long as the end product does its tasks well.
(Last analogy note: Yes, there are still prototypes created with maunal fabrication and assembly of components. But the average user of a computer isn't a kernel hacker, and so the tools of a computer shouldn't--and don't--assume that they are.)
(Also, note that I don't care if the end product is a single monolithic program or a bundled set of seperate programs, just so long as it does the task I want it to do 'completely.')
We have more-abstract languages, more-abstract machine design, and more-abstract computer usage today than we did thirty years ago. We should have a more-abstract program contsruction philosophy to match.
Actually, I'd prefer that pressing an alphanumeric key (silly me--Ctl Alt etc are QWERTY) brings up a "command window" rather than running a direct command.
And a few hundred real-word mappings to commands would be nice. If I type "quit" and the command is "exit", the darn thing can say "quit mapped to EXIT command; exiting." or something.
What I've just described is the Tool Philosophy and it's well emulated in traditional command line UNIX. You're right that most people prefer to be a button pusher. I prefer the freedom to adapt. That's why I prefer UNIX.
Stop.
You are not a carpenter. A carpenter works in the real world with physical goods. AND, a modern carpenter uses several tools that automate dozens of their steps--and I'm not just talking power tools here.
Furthermore, a carpenter has immediate feedback to how their tools are working, what their tools will do, and what the final product will look like. "Traditional command line UNIX" does not. It requires arcane (and somewhat archaic) knowledge, and the only real feedback you get is what you specfically ask for.
ure, this requires the carpenter to have skill with and knowledge of many tools. The carpenter's job is much harder than simply pushing the "Make Another Box" button on the gigantic Box Building Machine. However the carpenter is more flexible because he can quickly adapt his tools to make new and original products. The button pusher can only make more boxes.
You're wrong on two fronts.
Firstly, not all carpenters are able to quickly adapt their tools--and not all carpenters use guild-style contruction methods. Oh, there are a few holdouts, and a few who do extra work so they can charge more, but by and large carpentry work is automated today--and the real craftsmen work on figuring out better ways to build a table, rather than fancier ways to use their tools.
Secondly, not all "button pushers" want to make the same old, same old. For any task that can be done on a CLI, a GUI can do just as or nearly as well as... with the added bonus of a shorter learning curve.
Now, one _could_ argue that a CLI is a specific thing, and a GUI is "anything else that's graphical"--but that's missing the actual method of interaction.
In my ideal system, a computer would watch the QWERTY keys, and pressing a key would ALWAYS do something. Only when the focus is on a textarea would the keys equate to text; ANYWHERE else, pressing a key would bring up a "command window", into which commands would be ran.
An intelligent system would keep the command window small but distinct (I'm picturing a bright neon floating window, that pops to the center of the dispay when used and then slides off to the bottom left corner....) and have all the results open in new windows. We could even have the current "active" path always on the screen...
There's a lot of rather intersting bits that could be done, but they need to be done at the basic level, not as a nosebleed-level hack.
Sort of. The "UNIX philosophy" has some very good elements in it--but it's not without its flaws.
The biggest one, IMO, is getting a tool changed and automating multiple computer tasks to one human-task.
And if you need some functionality that the tools can't provide, you don't need to install a 100% beginning-to-end solution complete with duplicate functionality and learning curve, you install a new small, specialized tool (i.e. gphoto2 to fetch photos from a camera) to solve the 1% of the problem that needed a new tool and use the tools you already know and have for the other 99% of the problem.
Depends on the problem, what what your current state of learning is. (Don't toss around statistics that you don't have--we have perfectly good words for "majority" and "minority")
As I said, the problem is the advent of the GUI and the commonality of richly formatted documents--two major elements of modern computer usage that weren't really dealt with when the orignal UNIX system was created. For some modern applications, such as working with pictures, small apps added to the old apps can work. For other applications, such as 3D design, the current suite of small apps don't work.
Some people argue (as you have) that these come at the expense of ease of use, but that is only true for small (admittedly often consumer-oriented) problems.
A minority ("1%") of computers are used to solve problems. Most computers in service today are used to replace pen & paper, communicate, or play games. And most of these computers are used in a GUI environment, never (or almost-never) using the command line.
I would love to see a removal of the division between "command line" and "GUI", just as I would love to see a removal of the user-distinction between "programs" and "tasks" et al.
Why is it then that there are people out there who spend their entire lives with UNIX/Linux, and who ignore this?
Because it's old and out of date. The new ideals should be:
- Stable is beautiful
- Make each program do what it does completely.
Few folks enjoy puny programs that do one thing very well--when they want to do something slightly different, they wind up using a bunch of differenet tools.
Also, the advent of windowing, color, and richly formated files has made "small simple programs" too hard to use. A whole new set of "single-task, fast-running" programs would be nice--but they'd have to be designed from the ground up to (1) work together and (2) work with richly formatted (XHTML) files.
'course, the end-user wouldn't see distinct programs--they'd ideally just see their computer, and do what they want to without ever having to think about tasks, programs, or appellets ever again.
Worth noting LICENSES have been [upheld], software EULA's which extend the authority of the copyright holder beyond what copyright laws give them, have NOT.
Two points:
Firstly, the GPL has never been held up in court. Anywhere. At all. Yes, this is becuase the parties to infringmenet all settle out of court--but that could just be because the GPL is as likely to be tossed out wholesale (equaling "no license to make derivitive works at all") as modified to remove the copyleft.
Secondly, depending on where in the USA you live, EULAs either have been upheld, have been selectivly tossed out, or have not yet been tested in court. And to my knowledge, MS hasn't lost a single EULA case in the USA.
Most folk who use Ethernet use a hub or router, and have a home LAN. (Those who have cable modems and only 1 PC may very likely skip the hub and use USB.)
Ethernet has the great big advantage that almost every PC has it at a good enough speed to use to transfer 20 GB of MP3s. Not everyone has Firewire, and most of us who have USB don't have USB2.
If i say you can borrow my car, but i want it back by 6pm. i'm not giving you the right to use my car in perpetuity and then taking that right away.
That's a limited-use grant. The GPL could, I suppose, be seen by that--but what the GPL asks isn't exactly "blindingly obvious courtesy."
A good car analogy would be "you can borrow my car, but you need to fill up the tank with at least Octate 90 gasoline that isn't from [Cheap local store known for watered-down gas]."
While this is still well within the realm of courtesy and reasonableness, it is a specific action required as part of the grant--consideration sufficient (IMO) to form a contract.
(Of course, the odd part is how vhenement some/.ers are about this. You'd think that I was threatening the very nature of copyleft just by saying "it's a contract.")
Look for the part about the St. Petersburg Times use of commercial satelitte photos that don't show what our government claimed was there.
So... the newspaper of a major city in one of our on-again/off-again enemies is a surefire foil against the US military's lying?
Maybe if it was the BBC, or the NYT, or another close-ally's paper... or even Russian government... but a distant power's paper's interpretation of the US's actions is, really, just not convincing.
Ethically, morally, and really, I agree. Legally, I think a gift with strings is a contract.
My understanding is that, legally, we have not entered into an informal contract, because I recieve no consideration.
I think the same holds with the GPL.
I agree that the principle is the same, and that neither of us is in a position of sufficient authority to weight in on the legalities of the matter.
'course, I wager that we can both agree that "if you break the GPL, the lawyers will be able to toss all sorts of things at you." If "sorts of things" is breach of contract or just copyright infringement is, really, a moot point.
The problem here is that we're discussing a legal issue, using legal terminology, but neither of us really knows what we're talking about.
But that *is* consideration, because the father is doing something -- paying money, in exchange for an action the son is taking, giving up a vice. Which is a service, if you will. Distributing stuff via GPL isn't a service you are providing the author (or anyone else). The author is granting you PERMISSION to distribute. That's the difference.
The author is granting you permission to distribute (your consideration) in exchange for your agreement to only distribute under the terms of the GPL (HIS consideration).
If I have $100 and and give it you on the condition that you spend it on your rent, have I given you something and taken part of it back?
YES!
*sigh*
If you give me $100 on the condition that I have to spend it on my rent, you have offered me an informal contract. In taking the money, I then enter into a contract--I get the benefit of your money, provided that I spend it on my rent.
It only requires that you ensure that whoever you do give it to (if anyone) gets the same deal you got.
Yes, I know. Go back and read my original comment--"net gain of rights" and all.
But the GPL is still a contract, with each party getting legally valid consideration. The licensee gets to make derivitive works, and the licensor gets a promise that all derivitive works will be released under a license just like the GPL.
This is perfectly fair and good--but so is paying for music or paying for the gas you buy, and both of those are contracts too.
Name one right that the GPL revokes from those who have agreed to it.
I just did that!
The GPL lets you use the software for free (yay!), and then you can make your own software based on GPL'd software (again, yay!). BUT--if you do make any software based on GPL'd software, you have to release it in a near-identical license to the GPL--and here is where the right is taken away, and where the whole "BSD v GPL" shism comes from.
It's a matter of semantics for most purposes, but when you get to the legalities--like anyone who manages a GPL'd project should--the semantics are important.
(Oh, and as for copyright law--the law says "you need the author's permission to download, copy, use, or derive from a copywritten work. There is no Point 0, there is no Point 2.)
The thing is, though, that software under the GPL is copyrighted, it is not public domain software
ALL software covered by the GPL is copyrighted. If it isn't, it can't bring the weight of law to the arrangement, and the copyleft has no teeth.
If the meaty portions of the GPL are removed and the remainder left to stand, the GPL is left as essentially a declaration of public-domain software. (I must correct myself, btw--the first stage would be a BSD-style "soft copyleft.", not PD.)
A license isn't so much a contract as it is an extention of existing copyright law, extending or transfering some of the rights normally exclusively reserved to the copyright holder alone.
Talk to a lawyer, go take a business law class--do something.
A license is a type of contract. (I'm not pretending to know exactly what makes a license a license-but I know that it's a type of contract.) It's every bit as much a contract as a race car and a van are both "automobiles."
Slashdot Mirror
Yeah, he was arrested for telling the truth, even after he was told he wasn't allowed to. That makes it sooooo much better.
To paraphrase Indiana Jones: "Science is not the search for truth; if you want that, theology is down the hall."
While the relative sizes of the Sun and Earth are fact, nothing more than offhand parsimony puts the Sun or the Earth at rest in relation to the other.
As per Einstein, all movement is relative. It's perfectly valid to say that the Sun moves around the Earth--and the other planets move around the Earth, but have their orbits (incredibly) skewed by the gravitational pull of the sun. (If you're doing something like, oh, making a chart of the sky, an earth-centric model is more useful than a sun-centric model.)
Apparantly, Gallielo was arrested for maligning the church, and then told to be quiet about the subjet wherein he maligned the chuch. His scientific merit, apparantly, had little to do with the gag order.
Honestly, folks, isn't this why we moved to Linux in the first place?
God, I hope not.
Most folk moved to Linux either for Freedom (re: the FSF) or for Cost (it's free! Woot!) or for stability (it doesn't crash! Woot!)
I pity those who installed all of Linux just to use a command line. I mean, honestly, DOS still runs!
Darn, that would be spiffy. Wordperfect, back when it was the king of the PC, used to have a "function key reference" card, that neatly spelled out all of the commands; same thing, but eaiser on the hardware budget.
GUIs are good, but they could be done a LOT better--and CLIs tend to be limitd by their "ask a question, get an answer" model.
It really is true that if html is not allowed as a 'mail medium' the spammers will not be allowed to show their presentations and/or direct you to dangerous sites. It is really that simple and if Outlook is out of the picture, spam has the great setback that has been a long time coming. This is a serious note BTW.
You're wrong.
Outlook is just one mail client. So long as HTML mail can be sent, it will be sent, and it will be used for spam--and for other things as well. It doesn't matter if every installation of Outlook suddenly vanishes tomorrow--there will still be HTML/MHTML mail, and there will still be spam.
Of course, to remove HTML mail would require a level of effort such that a proper check on spam would be easier to implement.
Bzzt, Wrong. There are more Apache servers (by far) than IIS servers, and IIS gets more attacks - by over a four to one margin.
I said "of identical configuration."
How many Apachae instances are running exactly the same combination of modules?
Was he lying?
Only as much as a priest of a false religion is lying.
Microsoft servers _do_ get hacked more than Linux servers, but this is because there are far more MS servers of an identical configuration than there are Linux servers. They also tend to crash more--especially IIS.
So, Linux does get hacked, and there have been viruses written for Linux--but there are far far more hackers and virus-writers aimed at MS Windows as opposed to Linux.
For somebody who was obviously distressed when somebody tried to teach you a "lesson", you seem very eager to assume the role of a lecturer. You might like to contemplate that I have nothing to learn about UNIX history from you.
Let's settle this before we go on.
I have absolutly no problem with you, me or a lurker using a historical reference to make a point. What i objected to was your "I'm telling you something, so you had better pay attention" remark--it struck me as a horribly condescending attitude, and added nothing to the conversation.
That said...
# Load Outlook. First tool.
# Compose mail. Microsoft Word loads with a blank page. Second tool.
# I decide I want a diagram. Insert Picture. Visio loads with a blank page. Third tool.
# Picture looks OK. I need an attachment. I decide to ZIP it. Start WinZip. Fourth tool.
All of the programs you noted, with the exception of WinZip, violate the UNIX Tool Philosophy. They do many, many things, and they have grown exponentially in size since their first incarnation. They're great examples of my modified "Tool Philosophy", though: (fairly) stable and they do their job sufficiently completely. (And, with the exception of Winzip, you can use all of them by launching a single application, and then performing tasks from that single app to call the others.)
A better example of the classic "Tool Philosophy":
* Use "edit" to compose e-mail and save as text file. (first tool)
* Run "spellcheck" on text file. (second tool)
* Use "chartmaker" to create your diagram (third tool)
* Open "gview" to check diagram. (fourth tool)
* Run "zip" to compress graphic. (fifth tool)
* Run PINE to send e-mail. (sixth tool.)
And this is assuming that all of your programs have a common format, and "chartmaker" can save as the right graphics file; if not, you might need to run "convert" to change the chart to an acceptable format for your audience.
If you would rather do the same task (send an e-mail with a chart), you can do it with one program (MS Word or Outlook) on a properly setup machine.
Please pay attention.
Sheesh. I'm disagreeing with you, not stubbornly refusing to learn your lesson. I stand by my original statement: the UNIX philosophy is out of date, and should be updated.
The UNIX philosophy was constructed at a time when all computers were (essentially) mainframes, all computer work was computing, and all users were experts. They were the computer-equivalent of early machine builders: if an early computer staff wanted to do something, they almost always had to create it in-house.
The world of today is vastly different, with varying file formats, (spoken) languages, and purposes. The computer is a notebook, reference tool, and communications medium far more than it is a computing device. (To continue the machinist analogy, most machine builders today don't work with the gears and pullies of one machine at a time--they create markets and assembly lines to make machines en masse.)
Given this shift in the use of computers, a shift in design philosophy is rather appropriate. It doesn't matter if it's small, so long as it's stable. It doesn't matter if each executable is focused, so long as the end product does its tasks well.
(Last analogy note: Yes, there are still prototypes created with maunal fabrication and assembly of components. But the average user of a computer isn't a kernel hacker, and so the tools of a computer shouldn't--and don't--assume that they are.)
(Also, note that I don't care if the end product is a single monolithic program or a bundled set of seperate programs, just so long as it does the task I want it to do 'completely.')
We have more-abstract languages, more-abstract machine design, and more-abstract computer usage today than we did thirty years ago. We should have a more-abstract program contsruction philosophy to match.
Actually, I'd prefer that pressing an alphanumeric key (silly me--Ctl Alt etc are QWERTY) brings up a "command window" rather than running a direct command.
And a few hundred real-word mappings to commands would be nice. If I type "quit" and the command is "exit", the darn thing can say "quit mapped to EXIT command; exiting." or something.
What I've just described is the Tool Philosophy and it's well emulated in traditional command line UNIX. You're right that most people prefer to be a button pusher. I prefer the freedom to adapt. That's why I prefer UNIX.
Stop.
You are not a carpenter. A carpenter works in the real world with physical goods. AND, a modern carpenter uses several tools that automate dozens of their steps--and I'm not just talking power tools here.
Furthermore, a carpenter has immediate feedback to how their tools are working, what their tools will do, and what the final product will look like. "Traditional command line UNIX" does not. It requires arcane (and somewhat archaic) knowledge, and the only real feedback you get is what you specfically ask for.
ure, this requires the carpenter to have skill with and knowledge of many tools. The carpenter's job is much harder than simply pushing the "Make Another Box" button on the gigantic Box Building Machine. However the carpenter is more flexible because he can quickly adapt his tools to make new and original products. The button pusher can only make more boxes.
You're wrong on two fronts.
Firstly, not all carpenters are able to quickly adapt their tools--and not all carpenters use guild-style contruction methods. Oh, there are a few holdouts, and a few who do extra work so they can charge more, but by and large carpentry work is automated today--and the real craftsmen work on figuring out better ways to build a table, rather than fancier ways to use their tools.
Secondly, not all "button pushers" want to make the same old, same old. For any task that can be done on a CLI, a GUI can do just as or nearly as well as... with the added bonus of a shorter learning curve.
No. God, no. Not as currently concieved.
Now, one _could_ argue that a CLI is a specific thing, and a GUI is "anything else that's graphical"--but that's missing the actual method of interaction.
In my ideal system, a computer would watch the QWERTY keys, and pressing a key would ALWAYS do something. Only when the focus is on a textarea would the keys equate to text; ANYWHERE else, pressing a key would bring up a "command window", into which commands would be ran.
An intelligent system would keep the command window small but distinct (I'm picturing a bright neon floating window, that pops to the center of the dispay when used and then slides off to the bottom left corner....) and have all the results open in new windows. We could even have the current "active" path always on the screen...
There's a lot of rather intersting bits that could be done, but they need to be done at the basic level, not as a nosebleed-level hack.
That is [the] point of the Unix philosophy.
Sort of. The "UNIX philosophy" has some very good elements in it--but it's not without its flaws.
The biggest one, IMO, is getting a tool changed and automating multiple computer tasks to one human-task.
And if you need some functionality that the tools can't provide, you don't need to install a 100% beginning-to-end solution complete with duplicate functionality and learning curve, you install a new small, specialized tool (i.e. gphoto2 to fetch photos from a camera) to solve the 1% of the problem that needed a new tool and use the tools you already know and have for the other 99% of the problem.
Depends on the problem, what what your current state of learning is. (Don't toss around statistics that you don't have--we have perfectly good words for "majority" and "minority")
As I said, the problem is the advent of the GUI and the commonality of richly formatted documents--two major elements of modern computer usage that weren't really dealt with when the orignal UNIX system was created. For some modern applications, such as working with pictures, small apps added to the old apps can work. For other applications, such as 3D design, the current suite of small apps don't work.
Some people argue (as you have) that these come at the expense of ease of use, but that is only true for small (admittedly often consumer-oriented) problems.
A minority ("1%") of computers are used to solve problems. Most computers in service today are used to replace pen & paper, communicate, or play games. And most of these computers are used in a GUI environment, never (or almost-never) using the command line.
I would love to see a removal of the division between "command line" and "GUI", just as I would love to see a removal of the user-distinction between "programs" and "tasks" et al.
Why is it then that there are people out there who spend their entire lives with UNIX/Linux, and who ignore this?
Because it's old and out of date. The new ideals should be:
- Stable is beautiful
- Make each program do what it does completely.
Few folks enjoy puny programs that do one thing very well--when they want to do something slightly different, they wind up using a bunch of differenet tools.
Also, the advent of windowing, color, and richly formated files has made "small simple programs" too hard to use. A whole new set of "single-task, fast-running" programs would be nice--but they'd have to be designed from the ground up to (1) work together and (2) work with richly formatted (XHTML) files.
'course, the end-user wouldn't see distinct programs--they'd ideally just see their computer, and do what they want to without ever having to think about tasks, programs, or appellets ever again.
Some advice: this would be the time to gracefully admit you were wrong.
But I'm not wrong. The GPL is a contract, and agreeing to use the GPL on derivitive works is consideration.
Worth noting LICENSES have been [upheld], software EULA's which extend the authority of the copyright holder beyond what copyright laws give them, have NOT.
Two points:
Firstly, the GPL has never been held up in court. Anywhere. At all. Yes, this is becuase the parties to infringmenet all settle out of court--but that could just be because the GPL is as likely to be tossed out wholesale (equaling "no license to make derivitive works at all") as modified to remove the copyleft.
Secondly, depending on where in the USA you live, EULAs either have been upheld, have been selectivly tossed out, or have not yet been tested in court. And to my knowledge, MS hasn't lost a single EULA case in the USA.
I fear you may be an idiot.
Most folk who use Ethernet use a hub or router, and have a home LAN. (Those who have cable modems and only 1 PC may very likely skip the hub and use USB.)
Ethernet has the great big advantage that almost every PC has it at a good enough speed to use to transfer 20 GB of MP3s. Not everyone has Firewire, and most of us who have USB don't have USB2.
If i say you can borrow my car, but i want it back by 6pm. i'm not giving you the right to use my car in perpetuity and then taking that right away.
/.ers are about this. You'd think that I was threatening the very nature of copyleft just by saying "it's a contract.")
That's a limited-use grant. The GPL could, I suppose, be seen by that--but what the GPL asks isn't exactly "blindingly obvious courtesy."
A good car analogy would be "you can borrow my car, but you need to fill up the tank with at least Octate 90 gasoline that isn't from [Cheap local store known for watered-down gas]."
While this is still well within the realm of courtesy and reasonableness, it is a specific action required as part of the grant--consideration sufficient (IMO) to form a contract.
(Of course, the odd part is how vhenement some
Look for the part about the St. Petersburg Times use of commercial satelitte photos that don't show what our government claimed was there.
So... the newspaper of a major city in one of our on-again/off-again enemies is a surefire foil against the US military's lying?
Maybe if it was the BBC, or the NYT, or another close-ally's paper... or even Russian government... but a distant power's paper's interpretation of the US's actions is, really, just not convincing.
A gift with strings is just a smaller gift.
Ethically, morally, and really, I agree. Legally, I think a gift with strings is a contract.
My understanding is that, legally, we have not entered into an informal contract, because I recieve no consideration.
I think the same holds with the GPL.
I agree that the principle is the same, and that neither of us is in a position of sufficient authority to weight in on the legalities of the matter.
'course, I wager that we can both agree that "if you break the GPL, the lawyers will be able to toss all sorts of things at you." If "sorts of things" is breach of contract or just copyright infringement is, really, a moot point.
The problem here is that we're discussing a legal issue, using legal terminology, but neither of us really knows what we're talking about.
under copyright law, you do not have a right to make a derivative work and distribute it. The GPL is not taking away a right to do that.
The GPL grants that right, and then takes part of it away.
*sigh*
But that *is* consideration, because the father is doing something -- paying money, in exchange for an action the son is taking, giving up a vice. Which is a service, if you will. Distributing stuff via GPL isn't a service you are providing the author (or anyone else). The author is granting you PERMISSION to distribute. That's the difference.
The author is granting you permission to distribute (your consideration) in exchange for your agreement to only distribute under the terms of the GPL (HIS consideration).
If I have $100 and and give it you on the condition that you spend it on your rent, have I given you something and taken part of it back?
YES!
*sigh*
If you give me $100 on the condition that I have to spend it on my rent, you have offered me an informal contract. In taking the money, I then enter into a contract--I get the benefit of your money, provided that I spend it on my rent.
It only requires that you ensure that whoever you do give it to (if anyone) gets the same deal you got.
Yes, I know. Go back and read my original comment--"net gain of rights" and all.
But the GPL is still a contract, with each party getting legally valid consideration. The licensee gets to make derivitive works, and the licensor gets a promise that all derivitive works will be released under a license just like the GPL.
This is perfectly fair and good--but so is paying for music or paying for the gas you buy, and both of those are contracts too.
Name one right that the GPL revokes from those who have agreed to it.
I just did that!
The GPL lets you use the software for free (yay!), and then you can make your own software based on GPL'd software (again, yay!). BUT--if you do make any software based on GPL'd software, you have to release it in a near-identical license to the GPL--and here is where the right is taken away, and where the whole "BSD v GPL" shism comes from.
It's a matter of semantics for most purposes, but when you get to the legalities--like anyone who manages a GPL'd project should--the semantics are important.
(Oh, and as for copyright law--the law says "you need the author's permission to download, copy, use, or derive from a copywritten work. There is no Point 0, there is no Point 2.)
Go back and read what I said again.
The GPL gives a net benefit of rights, but to say "it only grants rights" is wrong, wrong, wrong.
The GPL gives rights, and then takes a little bit away. It's like "rights change" that you have to give back.
The thing is, though, that software under the GPL is copyrighted, it is not public domain software
ALL software covered by the GPL is copyrighted. If it isn't, it can't bring the weight of law to the arrangement, and the copyleft has no teeth.
If the meaty portions of the GPL are removed and the remainder left to stand, the GPL is left as essentially a declaration of public-domain software. (I must correct myself, btw--the first stage would be a BSD-style "soft copyleft.", not PD.)
A license isn't so much a contract as it is an extention of existing copyright law, extending or transfering some of the rights normally exclusively reserved to the copyright holder alone.
Talk to a lawyer, go take a business law class--do something.
A license is a type of contract. (I'm not pretending to know exactly what makes a license a license-but I know that it's a type of contract.) It's every bit as much a contract as a race car and a van are both "automobiles."