Bottom line is this: If you're working mandatory overtime, there's a line where it'd be better to go sling burgers
Maybe there is a line somewhere, but it's not at $12 or $15/hr. I have to point out that 80 hours a week coding is a damn sight better than 80 hours a week slinging burgers. I did my share of 40 hour weeks at the local Wendy's back in high school, and it was not the ideal work environment - I guess I could do it for 80 hours a week if my life depended on it, but I was pretty tired after a 8 or 10 hour shift.
I know I could handle 80 hours of coding easier than 80 hours of standing. Which would I choose for the same pay? No contest.
the court didn't rule the case in the plaintiff's favor. The court just denied a motion to dismiss the complaint. I'd say that there's still a way to go before any precedent is set.
The fact is we have no idea what they meant. Proprietary research bugs me a bit because you can read press articles about it, but you can't actually read the report yourself to determine whether the reporter mangled the conclusions of the study or whether the study was worth the paper it was printed on in the first place. Forget about being able to detect any bias.
As far as I could tell, with the model we were dealing with there was no way to turn off DHCP or the routing features and make it just a hub. The laptop with a wireless card could ping the router but not the desktop, and the desktop with an ethernet connection to the hub could ping the router but not the laptop. The routing was all hosed up, and no apparent way to fix it. I did change the router's IP address.
I think this is a great addition to the current lineup of equipment out there. I don't know if you've ever tried to put together a wireless LAN with a desktop computer that's connected to the internet via dialup instead of broadband, but it's a PITA. As far as Linksys is concerned, it CANNOT be done. I did every trick I could think, flipped every configuration flag I could find, tried to fool the thing into thinking there was a broadband connection.
As far as I can tell, before this, there is no way to share a dialup connection over a wireless LAN. I know what Dad's getting for Christmas...
I'm in a situation where we have a few thousand retail locations that send data up at night. A few points of pain:
1. Use an extensible format for your batch uploads. What you think you want to upload today will be different (probably less than) what you want to upload tomorrow. Use an extensible format for your batch uploads (XML is awfully nice in this regard, it just eats up bandwidth). That way when you make upgrades to part of the chain, your server software can gracefully handle differences in the data being sent up from different locations. If you try to "bleed the turnip" in terms of bandwidth and go with something like a fixed width or comma separated file, you're going to pay for it in maintenance down the road.
2. Keep a backup of the data at the remote location until the remote location receives a well-formed acknowledgement form the central location. Just because the remote location sends up the data doesn't mean it's captured; a lot of things can go wrong, and it makes life much easier if you can recover the data at the remote location later. Furthermore, PLAN to miss some uploads; it's just going to happen sometimes, and if your system is designed to handle that fact, you'll be much better off.
3. Document your data formats - the format at the remote location and the central location (presumably those are relational databases and can be documented with detailed ER diagrams) and the format used for transmission. Troubleshooting is a pain in the ass if you are unsure about how to map a transmission field to a remote or central DB field. Seems like a no-brainer, but if you don't do it from the beginning you're not ever going to do it.
4. You might want to give your remote locations random upload times within the overall upload window so as not to "slashdot" yourself. If you want the remote locations to upload between 1 AM and 4 AM, write a script and schedule it in cron that will trigger the upload at some random time during that period. If all your remote locations start uploading at 01:00:00.00, you're going to have trouble scaling.
This kind of thing isn't rocket science, but once you start down the wrong path, it's easy to get entrenched to the point where it's easier to live with your mistakes than to take corrective action.
You might find it interesting to know that there are already physical -- that's right, as in not digital or content -- consumer products that attach this kind of IP bullshit. I'm a weekend woodworker when I'm not hacking, and one popular tool for make dovetail joints is the Stots TemplateMaster dovetail jig. (here's a good definition if you don't know what a dovetail joint is) You can think of this tool as a "meta jig" - it allows you to create dovetail joint jigs of many varieties, length, etc. You then use the jigs you create to make dovetail joints.
When you open the box, there's a neat little notice in there; they're kind enough to post it on the web - http://www.stots.com/agree.htm. It's even a shrink-wrap agreement:
"Removing the seal from the product indicates your agreement to be bound by the terms of the agreement."
Here's where they tell you that you didn't really "buy" the tool, you just bought the right to use it for a while:
"This is a license, not a sales agreement, between you, the end user, and Stots Corporation ("Stots"). Stots grants to you a non-exclusive, non-transferable (except as provided below) license to use the Make-It-RightTM Template Master TM ("Product") attached to the agreement seal and also to the manufacturing process ("Process") described in the accompanying documentation in accord with the terms set forth in this License Agreement."
Some of the assinine conditions:
Want to use it in your basement AND in your garage? Tough. OR - want to lend it to a friend? Tough.
"You may: a. use the Product (or any of the working templates produced using the Product or Process) in only one shop by the original purchaser only."
Want to lend, not the original tool, but a jig made using the tool with the wood you bought, to a friend? Tough.
"You may not: a. allow individuals that did not purchase the original Product use the Product or any templates produced using the Product or Process described"
Don't like stickers on your tools? Think you might use the box for another purpose and scribble over the original grahics on the box? Tough.
"You may not... d. remove any proprietary notices, labels, or marks on the Product, documentation, and containers"
Say you try using it for a week and decide it's not the tool for you. Think you could just put it up for sale on eBay? Get real. Remember...
"Stots grants to you a non-exclusive, non-transferable (except as provided below) license" (for what it's worth, the provision below says that you can transfer your rights with Stot's written permission and subject to the transferee's acceptance of the same terms and conditions you agreed to [by opening the box]).
Labelling O'Conner as the "Swing Vote Justice" is just media BS. O'Conner herself has commented on it:
"That's something the media has devised as a means of writing about the court, and I don't think that has a lot of validity." --Sandra Day O'Conner (as quoted by CNN)
Patent language is so damn rediculous it makes my head hurt. It's little wonder that patents are awarded for virtually anything (does anyone who files a patent in legalese actually get denied?). It would be a rare individual indeed who has the training both to decipher the patent lawyers' language AND who has the technical expertise to evaluate the claims on their merits. And we're supposed to believe that the USPTO has an entire staff of these M.S./J.D. geniuses evaluating every patent that comes through the door? Right...
How in the WORLD did SCO manage to sell 9 *million* dollars in software? That says to me you could have a monkey on the stree selling AOL CDs and rake in a couple million...
If it's made to run faster on old hardware, then why wouldn't I prefer this speedier system on my new hardware? Sounds like they could just take some of the bloat out of Windows XP and come up with an altogether better OS, rather than forking.
FTA: It may be that this is actually a deep Astroturf PR campaign orchestrated by Microsoft to discredit open source and Linux.
Yeeaaahhhh.....that's the ticket: PJ isn't a stooge for IBM as O'Gara would purport. She's a stooge for MICROSOFT! Yes! That's it! Microsoft pays...no, no, wait, Microsoft invents PJ and has this so called "journalist" post some seemingly insightful but in hindsight clearly superficial and superfulous pro-Linux articles to gain acceptance and credibility among the Linux wackos. Now they pay O'Gara to pretend to aggrevate "PJ" with real and veiled threats, which sends PJ -- and therefore all of the Linux wacko sheep -- spiraling into oblivian and the entire Linux community implodes under its own weight.
That, my friend, is some solid investigative reporting.
Should we be asking what specific rights we'll give the consumer, or should we be asking what specific rights we'll give the content owner? I would suggest the latter. The US Constitution, for example, takes that tack; all powers not explicitly reserved for the federal government are implicitly remanded to the states. I'd like to see the same thing in copyright law so we don't have to go change the law everytime someone thinks of something new to do with content - any rights not explicitly reserved for the content owner are implicitly remanded to the consumer.
In most IT shops, I'm sorry to say, test cases are a low priority and almost always come after the code is complete or nearly complete.
If you're looking for a "methodology" for creating unit test cases, I think you're overthinking the problem. You need to create a set of test caes that assure you that the unit is working in and of itself. There are a number of things you can do to accomplish that:
1. Look at the design document. See what the design document says the unit is supposed to do. Write test cases to test the various aspects of what the unit is supposed to do. If it transforms input, write test cases that test expected input, boundary cases, completely invalid input, no input, and as much damn input as you can generate. Do that for every function of the unit.
2. Look at the code. Because the design document may be outdate, incomplete, or just MIA, look at the code. Hopefully it's commented well and tells you what the unit should do. Write test cases that you are sufficient to exercise each function in the unit, and if possible each branch of code in the functions in the unit. Ideally every line of code gets executed at least once by your unit test case suide, though 100% coverage is not always possible or cost effective.
3. Look at other test cases If Integration or System test cases have been written, then you may be able to use those to school on. Integration test cases will in particular show you what you don't need to bother testing at the unit level. It will also show you where your stubs and drivers need to be built. The system test cases may give you more ideas for functionality that needs to be tested.
Sorry that you've been dumped in this situation, but it's the same situation that many, many of us face every day. It is the unfortunate reality of software engineering at a lot of IT shops.
I disagree. I think bringing in the topic of changing requirements over time muddies the issue. Yes, requirements do change over time and maintenance intended to implement new or changed requirements can cause defects and failures. However, at issue here is whether a piece of software, fully functioning at time "A" and not [significantly] modified in terms of its own code base, will decay and fail at some time "B" in the future.
Assuming for the moment that the software program itself remains static, can you characterize and measure decay of the program, and is it the result of anything besides a changing (system? operating?) environment in whose context the software program runs?
Unfortunately, you can't see a crew management system age the way you can see an airplane rust. But they do.
I find that an interesting if not slightly obvious insight. The interesting part is that you can know that software is decaying, but I don't know of any effective way to measure that decay. I don't even know of any particularly good ways to characterize the decay. It's not as if new defects are being introduced into code that's not changing. But the environment in which the software operates changes, and that change is analagous to weather corroding a pieces of physical equipment. Every time the OS gets a patch, the filesystem changes, a shared library is upgraded, the underlying hardware changes, there's a chance of triggering a failure in the software.
Can it be proven, or should we otherwise reasonably believe, that the probability of catastrophic system failure approaches 1 as the age of the system increases? Maybe a good topic for a research paper...
The thing that I always think about when I hear this argument for OSS, that there are thousands of developers who will find and fix the problem, is that the argument applies only to a very few of the "elite" OSS projects.
Sure, there are thousands of developers working on Linux or Apache in one way or another. But, if you look at sourceforge.net, for instance, while there are 100,000 projects, how many of those have more than, say, 5 active developers? How many have even more than 1 active developer?
The potential is there for thousands of developers to participate in any given OSS project, but the fact is that for probably 99.9% of OSS projects, it's still just one guy in his basement hacking away.
I saw several posts that say a HS diploma or GED isn't strictly required by many colleges, and I'm thinking that's a load of BS. Of course they require diplomas.
Well, after looking at a few institutions, it appears a diploma isn't always a must-have after all:
All in all, it looks like it's going to vary significantly from institution to institution. I suggest your friend find out where he/she wants to go to college and act accordingly.
Well, I do have software distributed under the GPL, so I want to talk specifics...
Here's the full section 9, a portion of which you quoted:
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
So my question becomes this: What determines whether or not you specified a specific version of the GPL? Most of my comments and the readme file say "Licensed under the GNU General Public License" (no version mentioned), but then included with the distribution is a copy of version 2 of the license. Does that imply strongly enough that version 2 is the specific license under which the software is distributed?
Or do I need to go make some changes and do a commit....
The thing that aggravated me about godaddy's letter (yeah, I got that email too) is that there is absolutely NO information directly from the NTIA about what the policy is, says, how it was arrived at, what the goal is, or when they believe the results will be. This petition drive has thus far been a completely one-sided story. As a result, I have to think that anyone who would sign the petition, save those that have managed to dig up more info that I have, are just drinking the koolaid.
I will fault NTIA for apparently having no mention of the policy on their website (at least last time I checked yesterday). There's no rational reason for them to either set new policy like this or start enforcing existing policy without hearings or public comment. It's even less excuable that after the fact they won't provide their side of the story. They refused comment in the couple of media stories I saw about this.
By the way, that's right, it's not a new policy, it's enforcement of a previously unenforced existing policy. So for that, I think some blame may lay on the registrars who allowed proxy registrations for.us domains. Shame on them if they failed to inform the registrants that a proxy registration of a.us domain was technically a violation of NTIA policy. If they did inform registrants, then the registrants should have seen this coming.
Well that seems to be a big middle finger to Yahoo!'s paying Mail Plus users. I wonder if they're not going to try to offer something extra to them as well. Right now is sounds like the only difference would be POP access and extra filters.
and in effect on the date of enactment of this Act
I read this clause as protecting any state or local law pertaining to taxation that is A) Otherwise permissible by or under the Constitution or other Federal Law AND B) In effect on the date of enactment of [the ITFA].
Ergo, new state and local laws taxing the internet are not necessarily protected.
Slashdot Mirror
Bottom line is this: If you're working mandatory overtime, there's a line where it'd be better to go sling burgers
Maybe there is a line somewhere, but it's not at $12 or $15/hr. I have to point out that 80 hours a week coding is a damn sight better than 80 hours a week slinging burgers. I did my share of 40 hour weeks at the local Wendy's back in high school, and it was not the ideal work environment - I guess I could do it for 80 hours a week if my life depended on it, but I was pretty tired after a 8 or 10 hour shift.
I know I could handle 80 hours of coding easier than 80 hours of standing. Which would I choose for the same pay? No contest.
the court didn't rule the case in the plaintiff's favor. The court just denied a motion to dismiss the complaint. I'd say that there's still a way to go before any precedent is set.
The fact is we have no idea what they meant. Proprietary research bugs me a bit because you can read press articles about it, but you can't actually read the report yourself to determine whether the reporter mangled the conclusions of the study or whether the study was worth the paper it was printed on in the first place. Forget about being able to detect any bias.
r eleases/), and on the analyst's page - well, the analyst quoted in the macworld article - there's no mention of the report at all (see http://www.jupiterresearch.com/bin/item.pl/company :analyst/jup/id=4569/).
What really suprises me is that although the Macworld article is dated July 21, there's no press release from JupiterResearch announcing the study (see http://www.jupiterresearch.com/bin/item.pl/press:
So, we have second hand information that is impossible to confirm in any way, shape, or form.
Nothing to see here, move along.
As far as I could tell, with the model we were dealing with there was no way to turn off DHCP or the routing features and make it just a hub. The laptop with a wireless card could ping the router but not the desktop, and the desktop with an ethernet connection to the hub could ping the router but not the laptop. The routing was all hosed up, and no apparent way to fix it. I did change the router's IP address.
I think this is a great addition to the current lineup of equipment out there. I don't know if you've ever tried to put together a wireless LAN with a desktop computer that's connected to the internet via dialup instead of broadband, but it's a PITA. As far as Linksys is concerned, it CANNOT be done. I did every trick I could think, flipped every configuration flag I could find, tried to fool the thing into thinking there was a broadband connection.
As far as I can tell, before this, there is no way to share a dialup connection over a wireless LAN. I know what Dad's getting for Christmas...
I'm in a situation where we have a few thousand retail locations that send data up at night. A few points of pain:
1. Use an extensible format for your batch uploads.
What you think you want to upload today will be different (probably less than) what you want to upload tomorrow. Use an extensible format for your batch uploads (XML is awfully nice in this regard, it just eats up bandwidth). That way when you make upgrades to part of the chain, your server software can gracefully handle differences in the data being sent up from different locations. If you try to "bleed the turnip" in terms of bandwidth and go with something like a fixed width or comma separated file, you're going to pay for it in maintenance down the road.
2. Keep a backup of the data at the remote location until the remote location receives a well-formed acknowledgement form the central location. Just because the remote location sends up the data doesn't mean it's captured; a lot of things can go wrong, and it makes life much easier if you can recover the data at the remote location later. Furthermore, PLAN to miss some uploads; it's just going to happen sometimes, and if your system is designed to handle that fact, you'll be much better off.
3. Document your data formats - the format at the remote location and the central location (presumably those are relational databases and can be documented with detailed ER diagrams) and the format used for transmission. Troubleshooting is a pain in the ass if you are unsure about how to map a transmission field to a remote or central DB field. Seems like a no-brainer, but if you don't do it from the beginning you're not ever going to do it.
4. You might want to give your remote locations random upload times within the overall upload window so as not to "slashdot" yourself. If you want the remote locations to upload between 1 AM and 4 AM, write a script and schedule it in cron that will trigger the upload at some random time during that period. If all your remote locations start uploading at 01:00:00.00, you're going to have trouble scaling.
This kind of thing isn't rocket science, but once you start down the wrong path, it's easy to get entrenched to the point where it's easier to live with your mistakes than to take corrective action.
You might find it interesting to know that there are already physical -- that's right, as in not digital or content -- consumer products that attach this kind of IP bullshit. I'm a weekend woodworker when I'm not hacking, and one popular tool for make dovetail joints is the Stots TemplateMaster dovetail jig. (here's a good definition if you don't know what a dovetail joint is) You can think of this tool as a "meta jig" - it allows you to create dovetail joint jigs of many varieties, length, etc. You then use the jigs you create to make dovetail joints.
When you open the box, there's a neat little notice in there; they're kind enough to post it on the web - http://www.stots.com/agree.htm. It's even a shrink-wrap agreement:
"Removing the seal from the product indicates your agreement to be bound by the terms of the agreement."
Here's where they tell you that you didn't really "buy" the tool, you just bought the right to use it for a while:
"This is a license, not a sales agreement, between you, the end user, and Stots Corporation ("Stots"). Stots grants to you a non-exclusive, non-transferable (except as provided below) license to use the Make-It-RightTM Template Master TM ("Product") attached to the agreement seal and also to the manufacturing process ("Process") described in the accompanying documentation in accord with the terms set forth in this License Agreement."
Some of the assinine conditions:
Want to use it in your basement AND in your garage? Tough. OR - want to lend it to a friend? Tough.
"You may: a. use the Product (or any of the working templates produced using the Product or Process) in only one shop by the original purchaser only."
Want to lend, not the original tool, but a jig made using the tool with the wood you bought, to a friend? Tough.
"You may not: a. allow individuals that did not purchase the original Product use the Product or any templates produced using the Product or Process described"
Don't like stickers on your tools? Think you might use the box for another purpose and scribble over the original grahics on the box? Tough.
"You may not... d. remove any proprietary notices, labels, or marks on the Product, documentation, and containers"
Say you try using it for a week and decide it's not the tool for you. Think you could just put it up for sale on eBay? Get real. Remember...
"Stots grants to you a non-exclusive, non-transferable (except as provided below) license" (for what it's worth, the provision below says that you can transfer your rights with Stot's written permission and subject to the transferee's acceptance of the same terms and conditions you agreed to [by opening the box]).
Labelling O'Conner as the "Swing Vote Justice" is just media BS. O'Conner herself has commented on it:
"That's something the media has devised as a means of writing about the court, and I don't think that has a lot of validity."
--Sandra Day O'Conner (as quoted by CNN)
I tend to agree with her.
Patent language is so damn rediculous it makes my head hurt. It's little wonder that patents are awarded for virtually anything (does anyone who files a patent in legalese actually get denied?). It would be a rare individual indeed who has the training both to decipher the patent lawyers' language AND who has the technical expertise to evaluate the claims on their merits. And we're supposed to believe that the USPTO has an entire staff of these M.S./J.D. geniuses evaluating every patent that comes through the door? Right...
I think you can attribute that to Gerald Weinberg.
How in the WORLD did SCO manage to sell 9 *million* dollars in software? That says to me you could have a monkey on the stree selling AOL CDs and rake in a couple million...
The question is simply where you'll spend it.
If it's made to run faster on old hardware, then why wouldn't I prefer this speedier system on my new hardware? Sounds like they could just take some of the bloat out of Windows XP and come up with an altogether better OS, rather than forking.
FTA:
It may be that this is actually a deep Astroturf PR campaign orchestrated by Microsoft to discredit open source and Linux.
Yeeaaahhhh.....that's the ticket: PJ isn't a stooge for IBM as O'Gara would purport. She's a stooge for MICROSOFT! Yes! That's it! Microsoft pays...no, no, wait, Microsoft invents PJ and has this so called "journalist" post some seemingly insightful but in hindsight clearly superficial and superfulous pro-Linux articles to gain acceptance and credibility among the Linux wackos. Now they pay O'Gara to pretend to aggrevate "PJ" with real and veiled threats, which sends PJ -- and therefore all of the Linux wacko sheep -- spiraling into oblivian and the entire Linux community implodes under its own weight.
That, my friend, is some solid investigative reporting.
Should we be asking what specific rights we'll give the consumer, or should we be asking what specific rights we'll give the content owner? I would suggest the latter. The US Constitution, for example, takes that tack; all powers not explicitly reserved for the federal government are implicitly remanded to the states. I'd like to see the same thing in copyright law so we don't have to go change the law everytime someone thinks of something new to do with content - any rights not explicitly reserved for the content owner are implicitly remanded to the consumer.
Welcome, to the world of the Real.
In most IT shops, I'm sorry to say, test cases are a low priority and almost always come after the code is complete or nearly complete.
If you're looking for a "methodology" for creating unit test cases, I think you're overthinking the problem. You need to create a set of test caes that assure you that the unit is working in and of itself. There are a number of things you can do to accomplish that:
1. Look at the design document.
See what the design document says the unit is supposed to do. Write test cases to test the various aspects of what the unit is supposed to do. If it transforms input, write test cases that test expected input, boundary cases, completely invalid input, no input, and as much damn input as you can generate. Do that for every function of the unit.
2. Look at the code.
Because the design document may be outdate, incomplete, or just MIA, look at the code. Hopefully it's commented well and tells you what the unit should do. Write test cases that you are sufficient to exercise each function in the unit, and if possible each branch of code in the functions in the unit. Ideally every line of code gets executed at least once by your unit test case suide, though 100% coverage is not always possible or cost effective.
3. Look at other test cases
If Integration or System test cases have been written, then you may be able to use those to school on. Integration test cases will in particular show you what you don't need to bother testing at the unit level. It will also show you where your stubs and drivers need to be built. The system test cases may give you more ideas for functionality that needs to be tested.
Sorry that you've been dumped in this situation, but it's the same situation that many, many of us face every day. It is the unfortunate reality of software engineering at a lot of IT shops.
I disagree. I think bringing in the topic of changing requirements over time muddies the issue. Yes, requirements do change over time and maintenance intended to implement new or changed requirements can cause defects and failures. However, at issue here is whether a piece of software, fully functioning at time "A" and not [significantly] modified in terms of its own code base, will decay and fail at some time "B" in the future.
Assuming for the moment that the software program itself remains static, can you characterize and measure decay of the program, and is it the result of anything besides a changing (system? operating?) environment in whose context the software program runs?
One of the interesting quotes from the article:
Unfortunately, you can't see a crew management system age the way you can see an airplane rust. But they do.
I find that an interesting if not slightly obvious insight. The interesting part is that you can know that software is decaying, but I don't know of any effective way to measure that decay. I don't even know of any particularly good ways to characterize the decay. It's not as if new defects are being introduced into code that's not changing. But the environment in which the software operates changes, and that change is analagous to weather corroding a pieces of physical equipment. Every time the OS gets a patch, the filesystem changes, a shared library is upgraded, the underlying hardware changes, there's a chance of triggering a failure in the software.
Can it be proven, or should we otherwise reasonably believe, that the probability of catastrophic system failure approaches 1 as the age of the system increases? Maybe a good topic for a research paper...
The thing that I always think about when I hear this argument for OSS, that there are thousands of developers who will find and fix the problem, is that the argument applies only to a very few of the "elite" OSS projects.
Sure, there are thousands of developers working on Linux or Apache in one way or another. But, if you look at sourceforge.net, for instance, while there are 100,000 projects, how many of those have more than, say, 5 active developers? How many have even more than 1 active developer?
The potential is there for thousands of developers to participate in any given OSS project, but the fact is that for probably 99.9% of OSS projects, it's still just one guy in his basement hacking away.
Well, after looking at a few institutions, it appears a diploma isn't always a must-have after all:
All in all, it looks like it's going to vary significantly from institution to institution. I suggest your friend find out where he/she wants to go to college and act accordingly.
Well, I do have software distributed under the GPL, so I want to talk specifics...
Here's the full section 9, a portion of which you quoted:
9. The Free Software Foundation may publish revised and/or new versions of the General
Public License from time to time. Such new versions will be similar in spirit to the
present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a
version number of this License which applies to it and "any later version", you have
the option of following the terms and conditions either of that version or of any
later version published by the Free Software Foundation. If the Program does not
specify a version number of this License, you may choose any version ever published by
the Free Software Foundation.
So my question becomes this: What determines whether or not you specified a specific version of the GPL? Most of my comments and the readme file say "Licensed under the GNU General Public License" (no version mentioned), but then included with the distribution is a copy of version 2 of the license. Does that imply strongly enough that version 2 is the specific license under which the software is distributed?
Or do I need to go make some changes and do a commit....
The photos of Memphis, TN, were taken in the first half of 2003. You can tell by the state of completion of the FedEx Forum.
The thing that aggravated me about godaddy's letter (yeah, I got that email too) is that there is absolutely NO information directly from the NTIA about what the policy is, says, how it was arrived at, what the goal is, or when they believe the results will be. This petition drive has thus far been a completely one-sided story. As a result, I have to think that anyone who would sign the petition, save those that have managed to dig up more info that I have, are just drinking the koolaid.
.us domains. Shame on them if they failed to inform the registrants that a proxy registration of a .us domain was technically a violation of NTIA policy. If they did inform registrants, then the registrants should have seen this coming.
I will fault NTIA for apparently having no mention of the policy on their website (at least last time I checked yesterday). There's no rational reason for them to either set new policy like this or start enforcing existing policy without hearings or public comment. It's even less excuable that after the fact they won't provide their side of the story. They refused comment in the couple of media stories I saw about this.
By the way, that's right, it's not a new policy, it's enforcement of a previously unenforced existing policy. So for that, I think some blame may lay on the registrars who allowed proxy registrations for
Well that seems to be a big middle finger to Yahoo!'s paying Mail Plus users. I wonder if they're not going to try to offer something extra to them as well. Right now is sounds like the only difference would be POP access and extra filters.
and in effect on the date of enactment of this Act
I read this clause as protecting any state or local law pertaining to taxation that is
A) Otherwise permissible by or under the Constitution or other Federal Law
AND
B) In effect on the date of enactment of [the ITFA].
Ergo, new state and local laws taxing the internet are not necessarily protected.
But, IANAL either (surprise surprise).