I enthusiastically support your interest in applied mathematics. You'd probably be much happier in the math department, though, rather than struggling to justify yourself as a "computer scientist" to the rest of the academic community.
I also agree that we need to find a better name for the course of study under which we've been handing out Engineering degrees for the last 35 years.
I guess I was thinking about college coursework, not motivating a youngster. Your high school experience sounds similar to mine, although mine began in 1970 with a 110 baud teletype and paper tapes.
There is nothing more fascinating than learning how computers really work. And this background is essential when designing algorithms and memory structures that must be efficient. It is merely a question of teaching this in an interesting way, and of relating it to real-world problems, such as "why is this pretty reasonable-looking high level language code so fucking slow?"
On our benchmarks we can't get 4 cores' worth of performance out of an Intel CPU, but we can get nearly 8 cores' worth out of AMD. AMD's memory bus architecture is simply better.
I agree, speeding tickets are a bullshit money maker 90% of the time. But think about it -- how stupid are they, using these old fashioned methods? Why not get serious and raise some real money?
I live in Massachusetts. The Mass Pike (I90) is a limited access highway with toll stations on all on/off ramps. Your time on is clocked. Your time off is clocked. By DeMoivre's Theorem, if your average speed is greater than the speed limit, you must have exceeded said speed limit at some point. So, just hand everyone a ticket as they leave the highway, if their average speed was X% higher than the posted speed limit (65) (or mail them one if they use EasyPass).
Here's a related revenue generation idea: triple the rent for all the McDonald's etc. on the I90 service plazas. Hell, open a bunch of new service plazas. People who want to speed will stop (they'll have to, unless they want a ticket). Here's another idea: for a buck, they can feed their turnpike ticket into a machine and it will tell them when it's safe to continue at the posted speed limit without getting a speeding ticket. Idiots who can't do arithmetic will be feeding dollar bills into these machines day in and day out.
I feel your pain, having "taught" hashing to every new hire for 25 years. However, I'm equally concerned with whether they can write a coherent English sentence, construct a memorandum that other people can understand, or communicate with a non-technical person to gain an understanding of what that person thinks he needs.
I suspect you'd agree that there's nothing wrong with using a stable OS. There's everything wrong with trying to "re-invent the OS" every few years using some wet-behind-the-ears college grads, and still -- after 25 years -- not being able to ship a dispatcher that can handle a spinning process without roaching the whole box. Yes, I'm looking at you, Windows. OS/MFT could handle a spinning process. Even CTSS could handle a spinning process, and that was written in 1960.
As far as the old saw that Unix/Linux/BSD/whatever "can't support a real graphical shell," have a peek at OS X. The academics who pronounced that a microkernel was the way to go (where are you now, QNX? Hurd? CMU?) found out that idea wasn't all-she-wrote either. OK, I enjoyed watching the file system crash on QNX without crashing the kernel, but there isn't much you can do without a file system (unless you're running a nuculer power plant, which was QNX's favorite example), so who cares?
Age is good. Stability is good. These are good things.
In Virginia, especially closer to D.C., the drivers are more ruthless, more vicious...
In the Boston area, we practice the "I don't see you" game when merging. The driver with the shittiest car wins. I bet that's what you're running into on the Beltway. I recall driving a '75 Chrysler New Yorker around Cambridge (dents everywhere, front bumper wired together, tape on the tail lights), and it was amazing how smoothly I was able to merge into traffic. Then when I got a job and bought a new car -- suddenly I was totally unable to merge at all.
That's certainly true. But since we all believe that we are magnificent drivers, we can make some important generalizations. First, let's erase all the driver deaths in single-car accidents, because we wouldn't get into that accident in the first place. Then let's erase all the driver deaths in multi-car accidents where the driver did something really dumb, like run a red light, because we would never do that. Then let's erase all the driver deaths that occur after midnight (because we don't drive after midnight, when statistics show that as many as 1 of 3 drivers are drunk). Then let's erase all the driver deaths where the driver was impaired by drugs or alcohol, because we don't drive under the influence. Finally, since we are slashdot geeks and we care about how things work so we maintain our equipment properly, let's erase all the driver deaths due to equipment failure.
Now show us that our risk of being killed on the road -- by SOMEBODY ELSE when WE ARE DRIVING COMPETENTLY and where OUR DEATH WAS NOT AVOIDABLE -- is higher than on a mileage basis than climbing on an airplane.
I run a successful software company and I have to deal with large-company IT departments all the time. I can state with authority that:
1) No two IT departments are the same. Some are great, some suck. 2) IT departments often get in the way of business progress. It isn't necessarily their fault, because they've been nailed with security mandates, "thou shalt not crash my PC" mandates, "thou shalt cut your datacenter support team by 50%" mandates, and so on, that cause them to have to resist (or at least point out potential problems with) almost every new initiative. So IT gets cast in the role of obstructionist, whether they are actually obstructionist or not. 3) IT departments often think they know "what's best" for the business, and they really don't. This can prevent the business from acquiring technology (like ours) that would help them deeply. I've been in many meetings where IT stands up and says, "we already own [this generic product from some large vendor], so why do we need this new thing?" That's the kiss of death for the business, for me, and for everyone else -- because the business people will NEVER use [the generic product], not in a million years, not ever, yet the CFO (always looking to save money) sees an opportunity not to spend. End of initiative.
You were a repeat offender. You were a pain in the ass. You admit that you were mostly guilty of whatever they charged you. Sounds like the system was working pretty well in your case.
Look at it from the cops' standpoint. Everyone they arrest is innocent, or so they claim. Some of the most obvious murderers in history claimed they were innocent. Pamela Smart claims she's innocent (http://en.wikipedia.org/wiki/Pamela_Smart).
Do you think the cops would have been so convinced that you were the guy, had they not had a long history of dealing with you? If you were some first-time offender, do you think they would have pushed it this hard?
If a large mass impacts a small mass, the small mass accelerates more than the large mass. Roll a big marble at a little marble. What happens? The little marble takes off at high speed, the big marble deflects slightly.
What kills passengers is delta-a, i.e. change in acceleration, as well as the acceleration itself. You can't live after your organs have been turned into scrambled eggs, like Lady Di's.
If you are riding in the big marble, you get accelerated (and delta-a'd) slightly. You live. If you are riding in the little marble, you get accelerated (and delta a'd) a lot. You die.
Yes, one can create work-arounds with GPL'd library code, like compiling the library separately and building a socket or messaging interface to it (which interface of course has to be GPL'd as well), but this can be a PITA as you point out. And, as I'm sure you'd agree, workarounds like that are not always possible for performance and other reasons.
Yes, authors who use the GPL have decided that we can use their code in a certain way, and that's their privilege. However, it can be a dumb choice, because as the grandparent poster points out, those of us who do rely on proprietary licensing models for our revenue (and that would be the majority of us) are often unable to give anything back to the community as a result. I'd love to be able to use some GPL'd libraries in our stuff, and I'd love to be able to piss in those libraries to contribute bug fixes and help out in general. But the GPL forces me in another direction, usually to reinvent the wheel or to use something that's closed source and potentially less capable.
If you author a library, think hard about the licensing model. The GPL may not be the best choice -- unless, of course, you have a religious belief that all software should be GPL, which is your decision to make. I don't get into religious arguments, so that would be the end of the discussion.
Let me tell you a story. So, a number of years ago I'm running a UI project for a small company, a team of hackers churning out lots of good stuff relatively quickly. After a couple months of work we show what we have to a customer. He's not impressed. He shows us a similar UI that his jokebag loser accounting programmer has cooked up in about a day using Powerbuilder. It's got some rough edges, it's not that pretty, but my blood turns to ice. It blows our doors off functionally.
My guys spend 3 hours on the ride back criticizing what the accounting guy has built in order to make themselves feel better. It doesn't matter, we can't change our approach this late in the game anyway, so we forge on. We end up selling $30M worth of product, which was pretty good for that vertical. So we were successful.
But I never forgot that moment. I had guys working with me who were spectacular coders, and this doofus cleans our clock -- makes us look like idiots, quite frankly -- using a productivity tool that a junior high school kid can pick up in about 5 minutes.
This is a hard lesson to internalize when you think you're a big programming stud -- hell, after 30 years in the business I've forgotten more languages than I remember -- but if you ignore VB and its ilk, you do so at your peril.
1) Only noobs and losers use VB. 2) It's not object-oriented and I took an OO class and they said everything should be OO or it sucks, so VB sucks. 3) I have to create global variables sometimes and I was taught that I should never use global variables for anything because they're bad. 4) Only noobs and losers use VB. 5) VB lets me create classes but they don't work the way classes are supposed to so I hate them. 6) I don't like VB controls, they're ugly, I like to make little hexagonal corners and stuff and piss away weeks of development on cute little clickable thingies. 7) Only noobs and losers use VB. 8) I don't like VB because writing Windows applications should be really hard. 9) "Hello, world" only takes one line, and that can't be right, because I learned in Java class that it should take pages and pages of setup code and stuff. 10) Only noobs and losers use VB. 11) Some idiot can build a simple windows app in about 30 seconds and it's not fair, that same app took me two weeks in C++ class. 12) The dweebs in Accounting are building VB apps and they shouldn't be programming, they don't know what they're doing. 13) Only noobs and losers use VB. 14) I heard Ruby is where it's at, I only want Ruby jobs now because it's kewl. 15) I heard that VB is wicked slow, but then I found out it compiles and stuff which totally isn't fair. 16) Only noobs and losers use VB.
I suspect that the reason legal doesn't let you download GPL'd source is because legal is afraid you'll copy the source and violate the copyright. Bluntly: you are in a large company and they don't trust you. Which is part of the problem of working for large companies -- they don't trust you, and you don't trust them. Not that small companies are necessarily trustworthy either, but at least maybe you get to meet the CEO and the senior managers and have a chance to make your own decision as to whether they are sleazeballs or reasonable human beings.
I'm actually pretty sure that there is no danger whatsoever in looking at GPL'd code, as long as you ensure that you don't copy it. Implementing the same idea with different code is not covered by copyright. It is not possible to copyright an idea (as opposed to patents, where it is).
Too bad we can't ask Pamela Jones -- she'd settle this quickly!
IANAL, but I believe you are confusing copyright with IP infringement. The GPL is copyright-based. Copyright doesn't cover ideas, it only covers the form of the implementation of the idea. So you can read GPL code all you want. You mustn't copy it or use it verbatim (unless you GPL the result), but you can use its ideas freely.
If you are a large entity, revealing your source via restricted license has become one of the best ways to cause your ideas to be protected, since you can argue that anyone else who had access to your source code, and then subsequently wrote something competitive, has "stolen your intellectual property." Even if you don't win the case, or the case is weak to begin with (as was SCO's), at the very least you can make a lot of trouble for a competitor, mire them in an expensive multi-year court case, and cause Casper Milquetoast prospects to avoid a "possibly infringing" solution.
This could very well be Microsoft duplicity at its finest. It is built-in protection for Windows 7. Let's assume that software patents are overthrown by the SCOTUS, Microsoft's SCO friends die the zombie death they so richly deserve, and that Microsoft is forced, kicking and screaming, to obey standards by the EU and others -- in other words, all of Microsoft's existing weapons to maintain its monopoly position are defused. This strategy becomes a key defensive position.
Do not look at this code. You must be able to answer, "I never saw it," under oath, if you ever expect to build something competitive.
I said, "as I approach my seat." So as to be clear to self-righteous assholes like you, I should have said, "as I get close to my seat," which is what I meant. The point is, I'm not throwing the dice that I'll have room when I actually get there. When the bins start to get crowded, I commit.
I always obey the carry-on luggage rules, but I often transport delicate and valuable stuff. As a result, I need my overhead space.
In my experience, the number one problem with boarding and de-planing is the fact that all us business drones have long since been trained to carry on our luggage -- or else we'll never see it again, or (worse) we'll have to wait around for hours trying to collect it and miss our meeting.
If the airlines and airports could solve the luggage loading/unloading/distribution problem, they'd solve the boarding/de-planing problem as well, because a larger percentage of people (me, included) would stop the stupid overhead luggage bin shuffle and leave more room for people like you who legitimately must carry on sensitive and/or delicate equipment.
In my case, I book a seat at the back, but as I approach my seat I shove my bag in the first available bin, memorizing the seat where it's stored. That fscks up later arrivals, but I can't take the chance that by the time I get to the back, there will be no room for my bag. It's them or me.
Despite speeding laws, people still get killed while speeding. So let's abolish speeding laws altogether and just allow anyone to go as fast as he pleases. After all, you cannot stop people dying in traffic, so why even try?
One of my New York-based co-workers was pulled over in Connecticut, on the southernmost section of I-95, the favorite playground of the maniacally efficient Connecticut State Troopers (motto: "why not cite New Yorkers?"). They are the inventors of the "mass speed trap," where one Trooper stands on the side of the road with a radar gun (usually at the bottom of a hill, of course, where almost every car is going faster than normal). He radios make/model/speed to a colleague who is parked about 1/4 mile down the road. Since everyone hits the brakes when they see the radar guy (as well as the second Trooper in the distance), the second Trooper can safely stand in the middle of the road and point at the vehicles identified by his buddy (by now everybody is going about 20 mph) and gesture to them to pull over. Eventually there are about 150 cars parked in the breakdown lane waiting for two or three other Troopers to get around to licking the stubs of their dull pencils and writing a ticket. By that time they've probably forgotten the speed reading, but that doesn't matter, they just make something up, like "81" or "79", never an even number that might seem suspicious.
My colleague fought the ticket and argued in court that there was no speed limit on the Autobahn, and that they have fewer accidents/fatalities than we do, and therefore that speed limits are actually not an effective way to prevent people from dying on highways. He also pointed out that hitting something at any speed in excess of 35mph is likely to kill you anyway. He supported his argument with citations, flip charts, and so on. He was careful to point out that residential and secondary-road speed limits weren't part of his argument. The judge was so intrigued by his presentation that he let him off, basically saying that my colleague had spent so much time preparing and researching his defense that "obviously he had learned something from the experience and would not wish to repeat it."
This is precisely the problem with such ideas. As you said, if a program is sufficiently rigorously specified that an automated proof-of-correctness can be generated, then the specification of the program is obviously complex enough to require that it, too, must undergo testing to ensure that it is correct, and so on. We might end up with 2 = 2, but that doesn't help much if we wanted 3.
The DoD has funded these efforts heavily since the 1970's, and computer science graduate students have been all over them for as long as I can remember. I've read way too many dull papers on the topic, as one amateur modern algebraist after another discovers the wonders of Hoare and rushes into print with his or her "unique" twist, all to the end of starting yet another unremarkable academic career.
Of course, the illusion of "perfect" software never fails to amuse me, since I remember an Interdata 32 overheating in the lab and making serious fixed point arithmetic errors. Sort of grounds one in reality, doesn't it, when the machine can't add. Sure glad the program was declared "correct," though.
Slashdot Mirror
I enthusiastically support your interest in applied mathematics. You'd probably be much happier in the math department, though, rather than struggling to justify yourself as a "computer scientist" to the rest of the academic community.
I also agree that we need to find a better name for the course of study under which we've been handing out Engineering degrees for the last 35 years.
I guess I was thinking about college coursework, not motivating a youngster. Your high school experience sounds similar to mine, although mine began in 1970 with a 110 baud teletype and paper tapes.
Maybe they should choose a different line of work?
I'm afraid I'll have to differ.
There is nothing more fascinating than learning how computers really work. And this background is essential when designing algorithms and memory structures that must be efficient. It is merely a question of teaching this in an interesting way, and of relating it to real-world problems, such as "why is this pretty reasonable-looking high level language code so fucking slow?"
On our benchmarks we can't get 4 cores' worth of performance out of an Intel CPU, but we can get nearly 8 cores' worth out of AMD. AMD's memory bus architecture is simply better.
I stand corrected.
I agree, speeding tickets are a bullshit money maker 90% of the time. But think about it -- how stupid are they, using these old fashioned methods? Why not get serious and raise some real money?
I live in Massachusetts. The Mass Pike (I90) is a limited access highway with toll stations on all on/off ramps. Your time on is clocked. Your time off is clocked. By DeMoivre's Theorem, if your average speed is greater than the speed limit, you must have exceeded said speed limit at some point. So, just hand everyone a ticket as they leave the highway, if their average speed was X% higher than the posted speed limit (65) (or mail them one if they use EasyPass).
Here's a related revenue generation idea: triple the rent for all the McDonald's etc. on the I90 service plazas. Hell, open a bunch of new service plazas. People who want to speed will stop (they'll have to, unless they want a ticket). Here's another idea: for a buck, they can feed their turnpike ticket into a machine and it will tell them when it's safe to continue at the posted speed limit without getting a speeding ticket. Idiots who can't do arithmetic will be feeding dollar bills into these machines day in and day out.
I feel your pain, having "taught" hashing to every new hire for 25 years. However, I'm equally concerned with whether they can write a coherent English sentence, construct a memorandum that other people can understand, or communicate with a non-technical person to gain an understanding of what that person thinks he needs.
At least a top 5 graduate tends to be literate.
I suspect you'd agree that there's nothing wrong with using a stable OS. There's everything wrong with trying to "re-invent the OS" every few years using some wet-behind-the-ears college grads, and still -- after 25 years -- not being able to ship a dispatcher that can handle a spinning process without roaching the whole box. Yes, I'm looking at you, Windows. OS/MFT could handle a spinning process. Even CTSS could handle a spinning process, and that was written in 1960.
As far as the old saw that Unix/Linux/BSD/whatever "can't support a real graphical shell," have a peek at OS X. The academics who pronounced that a microkernel was the way to go (where are you now, QNX? Hurd? CMU?) found out that idea wasn't all-she-wrote either. OK, I enjoyed watching the file system crash on QNX without crashing the kernel, but there isn't much you can do without a file system (unless you're running a nuculer power plant, which was QNX's favorite example), so who cares?
Age is good. Stability is good. These are good things.
In Virginia, especially closer to D.C., the drivers are more ruthless, more vicious...
In the Boston area, we practice the "I don't see you" game when merging. The driver with the shittiest car wins. I bet that's what you're running into on the Beltway. I recall driving a '75 Chrysler New Yorker around Cambridge (dents everywhere, front bumper wired together, tape on the tail lights), and it was amazing how smoothly I was able to merge into traffic. Then when I got a job and bought a new car -- suddenly I was totally unable to merge at all.
...not everyone around you is [a good driver]...
That's certainly true. But since we all believe that we are magnificent drivers, we can make some important generalizations. First, let's erase all the driver deaths in single-car accidents, because we wouldn't get into that accident in the first place. Then let's erase all the driver deaths in multi-car accidents where the driver did something really dumb, like run a red light, because we would never do that. Then let's erase all the driver deaths that occur after midnight (because we don't drive after midnight, when statistics show that as many as 1 of 3 drivers are drunk). Then let's erase all the driver deaths where the driver was impaired by drugs or alcohol, because we don't drive under the influence. Finally, since we are slashdot geeks and we care about how things work so we maintain our equipment properly, let's erase all the driver deaths due to equipment failure.
Now show us that our risk of being killed on the road -- by SOMEBODY ELSE when WE ARE DRIVING COMPETENTLY and where OUR DEATH WAS NOT AVOIDABLE -- is higher than on a mileage basis than climbing on an airplane.
For many studies, 40 people is plenty. That's probably the case here. It seems counter-intuitive, but the math works.
I run a successful software company and I have to deal with large-company IT departments all the time. I can state with authority that:
1) No two IT departments are the same. Some are great, some suck.
2) IT departments often get in the way of business progress. It isn't necessarily their fault, because they've been nailed with security mandates, "thou shalt not crash my PC" mandates, "thou shalt cut your datacenter support team by 50%" mandates, and so on, that cause them to have to resist (or at least point out potential problems with) almost every new initiative. So IT gets cast in the role of obstructionist, whether they are actually obstructionist or not.
3) IT departments often think they know "what's best" for the business, and they really don't. This can prevent the business from acquiring technology (like ours) that would help them deeply. I've been in many meetings where IT stands up and says, "we already own [this generic product from some large vendor], so why do we need this new thing?" That's the kiss of death for the business, for me, and for everyone else -- because the business people will NEVER use [the generic product], not in a million years, not ever, yet the CFO (always looking to save money) sees an opportunity not to spend. End of initiative.
You were a repeat offender. You were a pain in the ass. You admit that you were mostly guilty of whatever they charged you. Sounds like the system was working pretty well in your case.
Look at it from the cops' standpoint. Everyone they arrest is innocent, or so they claim. Some of the most obvious murderers in history claimed they were innocent. Pamela Smart claims she's innocent (http://en.wikipedia.org/wiki/Pamela_Smart).
Do you think the cops would have been so convinced that you were the guy, had they not had a long history of dealing with you? If you were some first-time offender, do you think they would have pushed it this hard?
If a large mass impacts a small mass, the small mass accelerates more than the large mass. Roll a big marble at a little marble. What happens? The little marble takes off at high speed, the big marble deflects slightly.
What kills passengers is delta-a, i.e. change in acceleration, as well as the acceleration itself. You can't live after your organs have been turned into scrambled eggs, like Lady Di's.
If you are riding in the big marble, you get accelerated (and delta-a'd) slightly. You live. If you are riding in the little marble, you get accelerated (and delta a'd) a lot. You die.
Yes, one can create work-arounds with GPL'd library code, like compiling the library separately and building a socket or messaging interface to it (which interface of course has to be GPL'd as well), but this can be a PITA as you point out. And, as I'm sure you'd agree, workarounds like that are not always possible for performance and other reasons.
Yes, authors who use the GPL have decided that we can use their code in a certain way, and that's their privilege. However, it can be a dumb choice, because as the grandparent poster points out, those of us who do rely on proprietary licensing models for our revenue (and that would be the majority of us) are often unable to give anything back to the community as a result. I'd love to be able to use some GPL'd libraries in our stuff, and I'd love to be able to piss in those libraries to contribute bug fixes and help out in general. But the GPL forces me in another direction, usually to reinvent the wheel or to use something that's closed source and potentially less capable.
If you author a library, think hard about the licensing model. The GPL may not be the best choice -- unless, of course, you have a religious belief that all software should be GPL, which is your decision to make. I don't get into religious arguments, so that would be the end of the discussion.
Let me tell you a story. So, a number of years ago I'm running a UI project for a small company, a team of hackers churning out lots of good stuff relatively quickly. After a couple months of work we show what we have to a customer. He's not impressed. He shows us a similar UI that his jokebag loser accounting programmer has cooked up in about a day using Powerbuilder. It's got some rough edges, it's not that pretty, but my blood turns to ice. It blows our doors off functionally.
My guys spend 3 hours on the ride back criticizing what the accounting guy has built in order to make themselves feel better. It doesn't matter, we can't change our approach this late in the game anyway, so we forge on. We end up selling $30M worth of product, which was pretty good for that vertical. So we were successful.
But I never forgot that moment. I had guys working with me who were spectacular coders, and this doofus cleans our clock -- makes us look like idiots, quite frankly -- using a productivity tool that a junior high school kid can pick up in about 5 minutes.
This is a hard lesson to internalize when you think you're a big programming stud -- hell, after 30 years in the business I've forgotten more languages than I remember -- but if you ignore VB and its ilk, you do so at your peril.
VB not a programming language?
Yes, because:
1) Only noobs and losers use VB.
2) It's not object-oriented and I took an OO class and they said everything should be OO or it sucks, so VB sucks.
3) I have to create global variables sometimes and I was taught that I should never use global variables for anything because they're bad.
4) Only noobs and losers use VB.
5) VB lets me create classes but they don't work the way classes are supposed to so I hate them.
6) I don't like VB controls, they're ugly, I like to make little hexagonal corners and stuff and piss away weeks of development on cute little clickable thingies.
7) Only noobs and losers use VB.
8) I don't like VB because writing Windows applications should be really hard.
9) "Hello, world" only takes one line, and that can't be right, because I learned in Java class that it should take pages and pages of setup code and stuff.
10) Only noobs and losers use VB.
11) Some idiot can build a simple windows app in about 30 seconds and it's not fair, that same app took me two weeks in C++ class.
12) The dweebs in Accounting are building VB apps and they shouldn't be programming, they don't know what they're doing.
13) Only noobs and losers use VB.
14) I heard Ruby is where it's at, I only want Ruby jobs now because it's kewl.
15) I heard that VB is wicked slow, but then I found out it compiles and stuff which totally isn't fair.
16) Only noobs and losers use VB.
I suspect that the reason legal doesn't let you download GPL'd source is because legal is afraid you'll copy the source and violate the copyright. Bluntly: you are in a large company and they don't trust you. Which is part of the problem of working for large companies -- they don't trust you, and you don't trust them. Not that small companies are necessarily trustworthy either, but at least maybe you get to meet the CEO and the senior managers and have a chance to make your own decision as to whether they are sleazeballs or reasonable human beings.
I'm actually pretty sure that there is no danger whatsoever in looking at GPL'd code, as long as you ensure that you don't copy it. Implementing the same idea with different code is not covered by copyright. It is not possible to copyright an idea (as opposed to patents, where it is).
Too bad we can't ask Pamela Jones -- she'd settle this quickly!
IANAL, but I believe you are confusing copyright with IP infringement. The GPL is copyright-based. Copyright doesn't cover ideas, it only covers the form of the implementation of the idea. So you can read GPL code all you want. You mustn't copy it or use it verbatim (unless you GPL the result), but you can use its ideas freely.
the fact remains that this could be a trap
If you are a large entity, revealing your source via restricted license has become one of the best ways to cause your ideas to be protected, since you can argue that anyone else who had access to your source code, and then subsequently wrote something competitive, has "stolen your intellectual property." Even if you don't win the case, or the case is weak to begin with (as was SCO's), at the very least you can make a lot of trouble for a competitor, mire them in an expensive multi-year court case, and cause Casper Milquetoast prospects to avoid a "possibly infringing" solution.
This could very well be Microsoft duplicity at its finest. It is built-in protection for Windows 7. Let's assume that software patents are overthrown by the SCOTUS, Microsoft's SCO friends die the zombie death they so richly deserve, and that Microsoft is forced, kicking and screaming, to obey standards by the EU and others -- in other words, all of Microsoft's existing weapons to maintain its monopoly position are defused. This strategy becomes a key defensive position.
Do not look at this code. You must be able to answer, "I never saw it," under oath, if you ever expect to build something competitive.
I said, "as I approach my seat." So as to be clear to self-righteous assholes like you, I should have said, "as I get close to my seat," which is what I meant. The point is, I'm not throwing the dice that I'll have room when I actually get there. When the bins start to get crowded, I commit.
I always obey the carry-on luggage rules, but I often transport delicate and valuable stuff. As a result, I need my overhead space.
In my experience, the number one problem with boarding and de-planing is the fact that all us business drones have long since been trained to carry on our luggage -- or else we'll never see it again, or (worse) we'll have to wait around for hours trying to collect it and miss our meeting.
If the airlines and airports could solve the luggage loading/unloading/distribution problem, they'd solve the boarding/de-planing problem as well, because a larger percentage of people (me, included) would stop the stupid overhead luggage bin shuffle and leave more room for people like you who legitimately must carry on sensitive and/or delicate equipment.
In my case, I book a seat at the back, but as I approach my seat I shove my bag in the first available bin, memorizing the seat where it's stored. That fscks up later arrivals, but I can't take the chance that by the time I get to the back, there will be no room for my bag. It's them or me.
Despite speeding laws, people still get killed while speeding. So let's abolish speeding laws altogether and just allow anyone to go as fast as he pleases. After all, you cannot stop people dying in traffic, so why even try?
One of my New York-based co-workers was pulled over in Connecticut, on the southernmost section of I-95, the favorite playground of the maniacally efficient Connecticut State Troopers (motto: "why not cite New Yorkers?"). They are the inventors of the "mass speed trap," where one Trooper stands on the side of the road with a radar gun (usually at the bottom of a hill, of course, where almost every car is going faster than normal). He radios make/model/speed to a colleague who is parked about 1/4 mile down the road. Since everyone hits the brakes when they see the radar guy (as well as the second Trooper in the distance), the second Trooper can safely stand in the middle of the road and point at the vehicles identified by his buddy (by now everybody is going about 20 mph) and gesture to them to pull over. Eventually there are about 150 cars parked in the breakdown lane waiting for two or three other Troopers to get around to licking the stubs of their dull pencils and writing a ticket. By that time they've probably forgotten the speed reading, but that doesn't matter, they just make something up, like "81" or "79", never an even number that might seem suspicious.
My colleague fought the ticket and argued in court that there was no speed limit on the Autobahn, and that they have fewer accidents/fatalities than we do, and therefore that speed limits are actually not an effective way to prevent people from dying on highways. He also pointed out that hitting something at any speed in excess of 35mph is likely to kill you anyway. He supported his argument with citations, flip charts, and so on. He was careful to point out that residential and secondary-road speed limits weren't part of his argument. The judge was so intrigued by his presentation that he let him off, basically saying that my colleague had spent so much time preparing and researching his defense that "obviously he had learned something from the experience and would not wish to repeat it."
This is precisely the problem with such ideas. As you said, if a program is sufficiently rigorously specified that an automated proof-of-correctness can be generated, then the specification of the program is obviously complex enough to require that it, too, must undergo testing to ensure that it is correct, and so on. We might end up with 2 = 2, but that doesn't help much if we wanted 3.
The DoD has funded these efforts heavily since the 1970's, and computer science graduate students have been all over them for as long as I can remember. I've read way too many dull papers on the topic, as one amateur modern algebraist after another discovers the wonders of Hoare and rushes into print with his or her "unique" twist, all to the end of starting yet another unremarkable academic career.
Of course, the illusion of "perfect" software never fails to amuse me, since I remember an Interdata 32 overheating in the lab and making serious fixed point arithmetic errors. Sort of grounds one in reality, doesn't it, when the machine can't add. Sure glad the program was declared "correct," though.