"If the "Or later clause" is present, then the embedded developers are SOL, because their own fork must also include the "Or later" clause"
No. You're missing the point of multiple licenses. If you distribute software to me that says GPL2 or later, it means that I can redistribute with any of GPL2, GPL3, or any future version. What I can't do is add "or later" to software that was licensed strictly GPL2.
It's the same as if you distributed software to me with a BSD or GPL clause. I can redistribute the software in something with a BSD license that is not GPLed.
Basically, the idea is that you tell the OS to always keep at least such and such an amount of the application in RAM. I'm fairly certain that MS apps (e.g. IE and Outlook) already do this for you. It's part of what makes them so spiffy compared to non-Microsoft alternatives.
"Remember that he changed a budget surplus of almost US$ 480 billion into the greatest deficit America has ever faced."
I suspect that the collapse of the stock bubble had as much of an effect on that as has Bush. Further, there was never any $480 billion surplus. When Clinton left office, there was a surplus of $86.4 billion which they characterized as a surplus of $236.2 billion (by counting the social security surplus, etc. with general receipts).
However, 1999 and 2000 were the only years that the government ran an actual surplus. Not coincidentally, those were also the two years when Enron, et.al. were reporting non-existent profits (and presumably paying taxes on them) instead of what turned out to be large losses.
This is not to say that Bush has been a great economic president. He hasn't. He's managed to change things to the point that the rich (like himself and the Kerrys) actually pay a lower tax rate than the average (I'm still waiting for a democrat to notice this and run on a flat tax platform as a soak the rich program). Further, he eliminated the inheritance tax which had previously served to reduce the cross generational persistence of wealth. Finally, he has expanded spending in all areas (although he is now backing off on this a bit).
"How about just adding a million lines of bug-free but totally bogus code to your project"
If it were that easy to write a million lines of bug-free code, we'd all be doing it. Bogus code is *MORE* bug prone than application code. Why? Because it's never tested.
Sure, in theory, people could just add a bunch of lines with just semi-colons. However, in practice, the testing agency would notice this and come up with a screen. Anything more complicated than empty statements is prone to error.
osCommerce is great for developers. While dense (there's a lot of code), it's easy to understand for someone willing to spend time working with it.
osCommerce is also fine for non-developers who don't mind using the base install/look or paying someone to make changes.
Where osCommerce sucks is for people who code HTML for a living and want to just change some HTML templates to change the design. Or for people who want to turn functionality on and off at whim. Or for people who can code, but don't want to spend any time actually reading code. However, it wasn't written for those people. It's an open source project. It's primarily aimed at developers who want to code ecommerce sites on a regular basis and can afford the time to learn how it works.
There are certainly things that could be easier in osCommerce. In particular, the non-modularity of the layout made anything other than a small set of changes (e.g. stylesheet, header, footer, and left and right columns) frustratingly repetitive. However, once I spent some time with it, I found it easy to modify.
"But I last used osCommerce back in it's [sic] 2.2 days "
Considering that 2.2 hasn't been released yet, that's quite an accomplishment. The most recent release was a patch on milestone 2 (of 4) of the 2.2 project: http://www.oscommerce.com/about/news,121
"the qb getting tackled on the 1 yard line and them calling it a TD comes to mind"
Dude, if you watch the play, it's obvious that his arm crossed the goal plane (it's not a line, since it sticks up into space). He was no where near the 1 yard line. If the ball was short of the goal, it was short by less than an inch.
Part of the problem is that the refs were actually bending over backwards trying to *avoid* penalizing Seattle. For example, Locklear was called for two holds, but actually committed ten. Why was he only called twice? Because most of his holds didn't affect the play, so they warned him instead. Seattle happened to get a big play on one of the times they called him for holding, but at the time of the call that wasn't known. Further, if he hadn't pulled Haggans down from behind, Haggans would have sacked Hasselback before the pass, which would have negated the big play anyway.
The refs really didn't call this game any differently than they call any other game. They don't like calling holding, as it happens on most plays and can devastate an offense when called on third down. They warned Locklear on the third downs (except for the first one) and evened up by calling him on first down.
I have the same problem with "loose." It's now gotten so bad that when I see the word used correctly, I try to translate it to "lose." I find myself stopping and rereading sentences with "loose" in them all the time to figure out what the author was saying.
For my advanced developmental economics class in college, I did a report on Burkina Faso. Two articles that really stuck out:
1. One advocated developing an efficient rental market for... donkeys.
2. The other talked about a UN program that dug wells. The problem was that the pump they used was not repairable by local technology. The Mennonites' charitable wing helped them by developing a pump that could be produced locally.
Not a Burkina Faso example, but I've also read about a road project in another poor country. The people used the dirt *berms* rather than the road's asphalt, as they were softer and cooler. Easier to use with bare feet.
It's amazing how low tech improvements can be and still be big wins locally.
I want to make restaurant tables out of it. In table menu displays with full customization. Out of water? Click the refill icon and someone scoots over to fill it for you. Freed from order taking duties and using the same kind of software places like Amazon use to manage their inventory picking.
"The fact that these purchases are raising doubts as to MySQL's future is already enough to make Suits (who are already skeptical of OSS) nervous & less likely to send their business to MySQL."
It's easy to spin it the other way. MySQL's future is now guaranteed. They can go with the cheap version now and the Oracle supported version later.
"Customers generally don't dissemble. They're not trying to get something for nothing."
Hmm...you've been *really* lucky in your customers then.
I would agree that most customers are not trying to get something for nothing, but it's not at all uncommon for them to do so. This is why companies like Best Buy and Pizza Hut have specific programs in place to "fire" customers. Essentially they decide that some customers are not worth supporting.
"Pursuing usability took them further from the path you identified as good design."
Only in that they didn't follow through with it. What this really means is that something like Access should be included with Excel by default. Microsoft wants to avoid doing this, as Access is an upgrade product (they sell office both with and without Access). The net result is that people use Excel to store data, since it requires some minimal ability to do that.
Proper design (rather than the after the fact fix that they actually applied) would have had the data always being stored separate from the calculations. In fact, you can use Excel this way. However, it does very little to push you to use it this way.
I.e. what they should have done was created a single interface (Excel?) that allows both data entry (stored in data files) and formula entry (stored in calculation files). Of course, the history of spreadsheets makes that counter intuitive for existing users.
Usability testing is essential to good design, but it does not supply good design automatically. Many of the holes in the Microsoft security model exist for the same reason. Usability says to maximize features. Security restricts them. Sometimes good compromises exist, and a feature can be offered securely.
Other times no compromise is possible, e.g. allowing only white hats to auto install software without your explicit permission. The Popcap games problem of being listed as a virus by some AV software is a perfect example. For most of the people to whom this happens, this is purely annoying.
It is the job of designers to sometimes deny usability. However, it can be difficult to argue a theoretic position against the evident desires of customers.
"I can appreciate the actual technical workers who ultimatly may review resumes do not use Word on a daily basis, but to be sure, the HR department does - and they have little incentive to cater to other formats when the next applicant "plays by the rules.""
I think that you're missing the GP's point. It's not that Word documents are inappropriate for sending to the hiring company; it's that asking the potential hiree for a word document is useless in evaluating the quality of a unix sysadmin.
The recruiter should be the one making the translation from information (from the potential recruit) into pretty word document (to send to the potential employer). If the recruiter isn't doing things like that, then what's the point of having the recruiter in the middle?
You're giving advice to people trying to get jobs. The thread is about giving advice to people trying to link employers with potential hires. Your advice is absolutely correct in dealing with corporations. It's not so correct when dealing with recruits.
Outlook with Exchange is arguably the best groupware system out there. However, it's still horrible.
Unfortunately, I'm not convinced that Google will really try to solve that space. Really, how is GMail better now than it was when it was released? They've made a couple tweaks, but the basic system is the same. Scheduling is a much harder space.
For example, say I have a weekly meeting that is normally in room 202 but gets preempted by a more important meeting on 2/28. How do you store that and notify people? How do you schedule a room for an hour and a half and a meeting for only the last hour? How do you maintain both generality and full customization.
By contrast, email is based on standards. You don't have to work out a lot of workflow, because it's already in the standard. It's just details. With scheduling, there is no standard, so you have to work out the overall architecture *and* the details.
The difference check from a foreclosure is based on the auction price. Since the house was only worth a $121,000 or therabouts and had an annual tax liability of $8 million, I suspect that it wouldn't have sold at auction. Even if it did, the money would go to the tax liability first, so you'd still just lose your house.
Too bad this didn't happen in West Virginia. Apparently they implemented something like Heinlein's suggestion: if you think that the assessment is too high, the assessor has to buy the house from you at that price. Unfortunately, I think that the assessor can also accept your assessment. Pity.
It's also worth pointing out that SBC was one of the baby bells. I.e. they used to be part of AT&T. This is more like Exxon merging with Chevron and calling itself Standard Oil.
I'm not exactly sure why AT&T owns this patent rather than Lucent. Elsewhere, people say that this was a Bell Labs discovery. Why didn't the patent go to Lucent?
Talking about pharmaceutical patents in the same breath with software patents is somewhat misleading. Yes, pharmaceutical patents do encourage companies to develop new drugs. However, very little of this is because they spend more on R&D. The main reason that pharmaceutical patents help is that they encourage companies to go through the FDA's drug approval process. In the end, most drug companies only have a few years to actually use the patent. Most of the patent period is spent in testing.
By contrast, software testing is only a fraction of the overall process. It took Edison's lab 10,000 tries to make a light bulb. Software's not like that. There's much less try and guess. Yes, there are multiple ways to do things and some are better than others. However, the process of choosing is much less exhaustive.
It's also worth noting that reverse engineering a pharmaceutical product is trivial. Reverse engineering software is difficult. Frankly, it's almost always simpler to write the software fresh. If reverse engineering were trivial, you could run all your Windows apps on your Linspire box.
Pharmaceuticals and software are the two endpoints of the discussion. It's not at all obvious to me that either tells us much about the other. They're very different products.
Also, I'm willing to spot you huge advances in medicine recently. I would still point out that we are woefully lacking in understanding still. This is one of the reasons why medicine is different from software. In software, you start with a system whose entire behavior can be known and build complexity from it. In medicine, you take huge swathes of the unknown and try to extract tiny pieces of knowledge.
It's interesting that both penicillin and Viagra were accidents. Penicillin kept killing the bacteria that was being studied, which Hess and Bumstead finally realized was a good thing. Pfizer was studying Viagra for a possible effect on lowering blood pressure when they realized it caused a Priapic effect. Perhaps we are close to being able to do constructive work (designing drugs rather than trying random experimentation); however, we aren't there yet.
It's quite possible that we are making great gains and still in the infancy of medical science. Note that people learn the most impressive things as an infant: how to walk; how to talk. These are incredibly complex tasks; yet, infants accomplish them with very little assistance. However, infants appear ineffectual, because they don't do these tasks well at first. Since we are ahead of them in the curve, they seem clumsy and slow.
I think that the real answer is that prior use doesn't matter in trademarks. It's current use. Daimler Chrysler currently uses Jeep to refer to their vehicle, and people no longer call other small 4WDs "Jeep." I.e. it's not generic *now*, which is what's important.
It's also worth noting that even in the '40s, Jeeps were mostly made by Willy's, which is now part of Daimler Chrysler: http://www.hrja.org/jeep.htm
It's also not clear from that article whether just the Willy's vehicles were called Jeeps or if the Ford vehicles were as well. However, even if the Ford vehicles were called Jeeps during WWII, that wouldn't necessarily make it so in 1950, much less now. Perhaps Ford could have fought it in 1950, but they didn't.
This is also something that could definitely be open sourced. The patent office wouldn't even need to do a prior art search. They could just publish it. It would be the patent holder's responsibility to say "Hey, I've patented that." Since patent holders now have an incentive to pay attention (which they don't have for patents), this means that it actually encourages knowledge sharing. Unlike patents, where researching patent implications only endangers you.
That would also be great for open source algorithms in general. It does for patents what BSD licenses do for copyright.
The result of this is very unlikely to be validation where they pass with flying colors. The more likely result is that some number of areas will fail and be improved in response.
There's no perfect system. Initiatives like this are simply aimed at making existing systems better. It's quite possible that the initiative itself could be better as well. However, rather than waiting for the perfect initiative, it's better to go with what one has now and repeat (better) later.
Slashdot Mirror
"If the "Or later clause" is present, then the embedded developers are SOL, because their own fork must also include the "Or later" clause"
3 .html
No. You're missing the point of multiple licenses. If you distribute software to me that says GPL2 or later, it means that I can redistribute with any of GPL2, GPL3, or any future version. What I can't do is add "or later" to software that was licensed strictly GPL2.
It's the same as if you distributed software to me with a BSD or GPL clause. I can redistribute the software in something with a BSD license that is not GPLed.
Stallman talked about this at the bottom of http://www.onlamp.com/pub/a/onlamp/2005/09/22/gpl
"The only way I know to really change Window's behavior is to disable the pagefile"
l
App specific, but look at http://suif.stanford.edu/pub/keepresident/faq.htm
Basically, the idea is that you tell the OS to always keep at least such and such an amount of the application in RAM. I'm fairly certain that MS apps (e.g. IE and Outlook) already do this for you. It's part of what makes them so spiffy compared to non-Microsoft alternatives.
"Remember that he changed a budget surplus of almost US$ 480 billion into the greatest deficit America has ever faced."
i st.pdf
I suspect that the collapse of the stock bubble had as much of an effect on that as has Bush. Further, there was never any $480 billion surplus. When Clinton left office, there was a surplus of $86.4 billion which they characterized as a surplus of $236.2 billion (by counting the social security surplus, etc. with general receipts).
Source: p. 317 of http://www.whitehouse.gov/omb/budget/fy2007/pdf/h
However, 1999 and 2000 were the only years that the government ran an actual surplus. Not coincidentally, those were also the two years when Enron, et.al. were reporting non-existent profits (and presumably paying taxes on them) instead of what turned out to be large losses.
This is not to say that Bush has been a great economic president. He hasn't. He's managed to change things to the point that the rich (like himself and the Kerrys) actually pay a lower tax rate than the average (I'm still waiting for a democrat to notice this and run on a flat tax platform as a soak the rich program). Further, he eliminated the inheritance tax which had previously served to reduce the cross generational persistence of wealth. Finally, he has expanded spending in all areas (although he is now backing off on this a bit).
"How about just adding a million lines of bug-free but totally bogus code to your project"
If it were that easy to write a million lines of bug-free code, we'd all be doing it. Bogus code is *MORE* bug prone than application code. Why? Because it's never tested.
Sure, in theory, people could just add a bunch of lines with just semi-colons. However, in practice, the testing agency would notice this and come up with a screen. Anything more complicated than empty statements is prone to error.
osCommerce is great for developers. While dense (there's a lot of code), it's easy to understand for someone willing to spend time working with it.
osCommerce is also fine for non-developers who don't mind using the base install/look or paying someone to make changes.
Where osCommerce sucks is for people who code HTML for a living and want to just change some HTML templates to change the design. Or for people who want to turn functionality on and off at whim. Or for people who can code, but don't want to spend any time actually reading code. However, it wasn't written for those people. It's an open source project. It's primarily aimed at developers who want to code ecommerce sites on a regular basis and can afford the time to learn how it works.
There are certainly things that could be easier in osCommerce. In particular, the non-modularity of the layout made anything other than a small set of changes (e.g. stylesheet, header, footer, and left and right columns) frustratingly repetitive. However, once I spent some time with it, I found it easy to modify.
"But I last used osCommerce back in it's [sic] 2.2 days "
Considering that 2.2 hasn't been released yet, that's quite an accomplishment. The most recent release was a patch on milestone 2 (of 4) of the 2.2 project: http://www.oscommerce.com/about/news,121
"every single page on the Dell website (other than, as you spotted, the homepage itself)"
Not on http://www.dell.com/linux either. Nor http://support.dell.com/ nor the Medium/Large Business page.
"the qb getting tackled on the 1 yard line and them calling it a TD comes to mind"
i ngs/every-play-counts/3640/
Dude, if you watch the play, it's obvious that his arm crossed the goal plane (it's not a line, since it sticks up into space). He was no where near the 1 yard line. If the ball was short of the goal, it was short by less than an inch.
Part of the problem is that the refs were actually bending over backwards trying to *avoid* penalizing Seattle. For example, Locklear was called for two holds, but actually committed ten. Why was he only called twice? Because most of his holds didn't affect the play, so they warned him instead. Seattle happened to get a big play on one of the times they called him for holding, but at the time of the call that wasn't known. Further, if he hadn't pulled Haggans down from behind, Haggans would have sacked Hasselback before the pass, which would have negated the big play anyway.
There was a pretty complete discussion of this at http://www.footballoutsiders.com/2006/02/09/rambl
The refs really didn't call this game any differently than they call any other game. They don't like calling holding, as it happens on most plays and can devastate an offense when called on third down. They warned Locklear on the third downs (except for the first one) and evened up by calling him on first down.
I have the same problem with "loose." It's now gotten so bad that when I see the word used correctly, I try to translate it to "lose." I find myself stopping and rereading sentences with "loose" in them all the time to figure out what the author was saying.
"According to the BLS"
Link?
For my advanced developmental economics class in college, I did a report on Burkina Faso. Two articles that really stuck out:
... donkeys.
1. One advocated developing an efficient rental market for
2. The other talked about a UN program that dug wells. The problem was that the pump they used was not repairable by local technology. The Mennonites' charitable wing helped them by developing a pump that could be produced locally.
Not a Burkina Faso example, but I've also read about a road project in another poor country. The people used the dirt *berms* rather than the road's asphalt, as they were softer and cooler. Easier to use with bare feet.
It's amazing how low tech improvements can be and still be big wins locally.
I want to make restaurant tables out of it. In table menu displays with full customization. Out of water? Click the refill icon and someone scoots over to fill it for you. Freed from order taking duties and using the same kind of software places like Amazon use to manage their inventory picking.
The answer to your question was posted here: http://yro.slashdot.org/comments.pl?sid=178066&cid =14767588
"The fact that these purchases are raising doubts as to MySQL's future is already enough to make Suits (who are already skeptical of OSS) nervous & less likely to send their business to MySQL."
It's easy to spin it the other way. MySQL's future is now guaranteed. They can go with the cheap version now and the Oracle supported version later.
"Customers generally don't dissemble. They're not trying to get something for nothing."
Hmm...you've been *really* lucky in your customers then.
I would agree that most customers are not trying to get something for nothing, but it's not at all uncommon for them to do so. This is why companies like Best Buy and Pizza Hut have specific programs in place to "fire" customers. Essentially they decide that some customers are not worth supporting.
"Pursuing usability took them further from the path you identified as good design."
Only in that they didn't follow through with it. What this really means is that something like Access should be included with Excel by default. Microsoft wants to avoid doing this, as Access is an upgrade product (they sell office both with and without Access). The net result is that people use Excel to store data, since it requires some minimal ability to do that.
Proper design (rather than the after the fact fix that they actually applied) would have had the data always being stored separate from the calculations. In fact, you can use Excel this way. However, it does very little to push you to use it this way.
I.e. what they should have done was created a single interface (Excel?) that allows both data entry (stored in data files) and formula entry (stored in calculation files). Of course, the history of spreadsheets makes that counter intuitive for existing users.
Usability testing is essential to good design, but it does not supply good design automatically. Many of the holes in the Microsoft security model exist for the same reason. Usability says to maximize features. Security restricts them. Sometimes good compromises exist, and a feature can be offered securely.
Other times no compromise is possible, e.g. allowing only white hats to auto install software without your explicit permission. The Popcap games problem of being listed as a virus by some AV software is a perfect example. For most of the people to whom this happens, this is purely annoying.
It is the job of designers to sometimes deny usability. However, it can be difficult to argue a theoretic position against the evident desires of customers.
"I can appreciate the actual technical workers who ultimatly may review resumes do not use Word on a daily basis, but to be sure, the HR department does - and they have little incentive to cater to other formats when the next applicant "plays by the rules.""
I think that you're missing the GP's point. It's not that Word documents are inappropriate for sending to the hiring company; it's that asking the potential hiree for a word document is useless in evaluating the quality of a unix sysadmin.
The recruiter should be the one making the translation from information (from the potential recruit) into pretty word document (to send to the potential employer). If the recruiter isn't doing things like that, then what's the point of having the recruiter in the middle?
You're giving advice to people trying to get jobs. The thread is about giving advice to people trying to link employers with potential hires. Your advice is absolutely correct in dealing with corporations. It's not so correct when dealing with recruits.
"all they need is a shared calendar"
I've been asking for that since gmail came out.
Outlook with Exchange is arguably the best groupware system out there. However, it's still horrible.
Unfortunately, I'm not convinced that Google will really try to solve that space. Really, how is GMail better now than it was when it was released? They've made a couple tweaks, but the basic system is the same. Scheduling is a much harder space.
For example, say I have a weekly meeting that is normally in room 202 but gets preempted by a more important meeting on 2/28. How do you store that and notify people? How do you schedule a room for an hour and a half and a meeting for only the last hour? How do you maintain both generality and full customization.
By contrast, email is based on standards. You don't have to work out a lot of workflow, because it's already in the standard. It's just details. With scheduling, there is no standard, so you have to work out the overall architecture *and* the details.
"then pocket the difference check"
The difference check from a foreclosure is based on the auction price. Since the house was only worth a $121,000 or therabouts and had an annual tax liability of $8 million, I suspect that it wouldn't have sold at auction. Even if it did, the money would go to the tax liability first, so you'd still just lose your house.
Too bad this didn't happen in West Virginia. Apparently they implemented something like Heinlein's suggestion: if you think that the assessment is too high, the assessor has to buy the house from you at that price. Unfortunately, I think that the assessor can also accept your assessment. Pity.
"the primary rationale for using a VC disappears."
Yeah, but you still have to deal with customers. The GP's point was that customers are worse than VCs and there are more of them.
It's also worth pointing out that SBC was one of the baby bells. I.e. they used to be part of AT&T. This is more like Exxon merging with Chevron and calling itself Standard Oil.
I'm not exactly sure why AT&T owns this patent rather than Lucent. Elsewhere, people say that this was a Bell Labs discovery. Why didn't the patent go to Lucent?
Talking about pharmaceutical patents in the same breath with software patents is somewhat misleading. Yes, pharmaceutical patents do encourage companies to develop new drugs. However, very little of this is because they spend more on R&D. The main reason that pharmaceutical patents help is that they encourage companies to go through the FDA's drug approval process. In the end, most drug companies only have a few years to actually use the patent. Most of the patent period is spent in testing.
By contrast, software testing is only a fraction of the overall process. It took Edison's lab 10,000 tries to make a light bulb. Software's not like that. There's much less try and guess. Yes, there are multiple ways to do things and some are better than others. However, the process of choosing is much less exhaustive.
It's also worth noting that reverse engineering a pharmaceutical product is trivial. Reverse engineering software is difficult. Frankly, it's almost always simpler to write the software fresh. If reverse engineering were trivial, you could run all your Windows apps on your Linspire box.
Pharmaceuticals and software are the two endpoints of the discussion. It's not at all obvious to me that either tells us much about the other. They're very different products.
Also, I'm willing to spot you huge advances in medicine recently. I would still point out that we are woefully lacking in understanding still. This is one of the reasons why medicine is different from software. In software, you start with a system whose entire behavior can be known and build complexity from it. In medicine, you take huge swathes of the unknown and try to extract tiny pieces of knowledge.
It's interesting that both penicillin and Viagra were accidents. Penicillin kept killing the bacteria that was being studied, which Hess and Bumstead finally realized was a good thing. Pfizer was studying Viagra for a possible effect on lowering blood pressure when they realized it caused a Priapic effect. Perhaps we are close to being able to do constructive work (designing drugs rather than trying random experimentation); however, we aren't there yet.
It's quite possible that we are making great gains and still in the infancy of medical science. Note that people learn the most impressive things as an infant: how to walk; how to talk. These are incredibly complex tasks; yet, infants accomplish them with very little assistance. However, infants appear ineffectual, because they don't do these tasks well at first. Since we are ahead of them in the curve, they seem clumsy and slow.
I think that the real answer is that prior use doesn't matter in trademarks. It's current use. Daimler Chrysler currently uses Jeep to refer to their vehicle, and people no longer call other small 4WDs "Jeep." I.e. it's not generic *now*, which is what's important.
It's also worth noting that even in the '40s, Jeeps were mostly made by Willy's, which is now part of Daimler Chrysler: http://www.hrja.org/jeep.htm
It's also not clear from that article whether just the Willy's vehicles were called Jeeps or if the Ford vehicles were as well. However, even if the Ford vehicles were called Jeeps during WWII, that wouldn't necessarily make it so in 1950, much less now. Perhaps Ford could have fought it in 1950, but they didn't.
This is also something that could definitely be open sourced. The patent office wouldn't even need to do a prior art search. They could just publish it. It would be the patent holder's responsibility to say "Hey, I've patented that." Since patent holders now have an incentive to pay attention (which they don't have for patents), this means that it actually encourages knowledge sharing. Unlike patents, where researching patent implications only endangers you.
That would also be great for open source algorithms in general. It does for patents what BSD licenses do for copyright.
The result of this is very unlikely to be validation where they pass with flying colors. The more likely result is that some number of areas will fail and be improved in response.
There's no perfect system. Initiatives like this are simply aimed at making existing systems better. It's quite possible that the initiative itself could be better as well. However, rather than waiting for the perfect initiative, it's better to go with what one has now and repeat (better) later.