In many ways this is not a new observation.
Bruce Perens noted, back in 1999,
"Do not write a new license if it is possible to use one of the ones
listed here. The propagation of many different and incompatible licenses
works to the detriment of Open Source software because fragments of one
program cannot be used in another program with an incompatible license."
Eric S. Raymond's
Software Release Practice HOWTO
strongly states (as a heading!)
"don't write your own license if you can possibly avoid it."
What's different is the increasingly strenuous tone calling for people to reign in the number of licenses.
In many ways, this basically demonstrates that OSS/FS has matured. Lots of people have created new licenses, essentially experimenting with different approaches. The marketplace of ideas has selected a few "winning" ideas, and it's getting increasingly hard for even a good new license idea to overcome the many problems of incompatibility with what already exists.
Commercial development and use of OSS/FS is now widespread;
a consolidation of common licensing approaches appears inevitable as the whole approach becomes common.
In many ways, this license winnowing is happening anyway.
My paper
More
than a Gigabuck found that
only a few licenses were used by nearly all
the code; at the time it was (in order)
GPL, MIT, LGPL, MPL, and BSD
(counting by lines of code).
You can look at
Freshmeat's
statistics, which counts the licenses per project. Today, 2005-02-16,
the OSS/FS licenses in order of popularity were
(from most popular) the
GNU General Public License (GPL) (67.99%)
GNU Lesser General Public License (LGPL) (5.89%),
BSD License (original) (3.54%),
BSD License (revised) (1.92%),
Artistic License (1.80%),
MIT/X Consortium License (1.26%),
Apache License (0.72%),
Mozilla Public License (MPL) (0.57%),
Perl License (0.39%), and
Apache License 2.0 (0.26%).
I see a short list here, and notice
that even in this list of the most popular
licenses, the dropoff between
the most-popular licenses and the next most
popular licenses are really steep.
Every project whose license is incompatible with all of these has a serious liability, and in fact, being only compatible with the lower-popularity licenses is a real problem. Few think Sun's CDDL code is going to go anywhere, solely because it's an odd license incompatible with the millions of lines of code already out there.
I wish he'd used proper terminology - I think he meant "proprietary" not "commercial". Last I checked, Red Hat, Novell, IBM, Sun, and many other distributors of OSS/FS programs (including those using the GPL) were commercial companies.
It's worth noting that a slightly older variation of this paper was already referenced in
Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! back
in 2004-09-30. Look at their results, the actual numbers give a rather positive story: "1. Using tools such as MI derived for measuring CSS quality, OSS code quality appears to be at least equal and sometimes better than the quality of CSS code implementing the same functionality."
OSS is no silver bullet. Their last point is
"OSS code quality seems to suffer from the very same problems that have been observed in CSS projects." Er, big surprise, they're all software.
Evolution is great, and a port to Windows sounds great too. But if Macs aren't included then that's unfortunate. Both Firefox and OpenOffice.org are available across Windows, Mac, Unix, and Linux. It'd be great if a good OSS/FS Email/Groupware combo were cross-platform too.
I think you misunderstood the OpenOffice.org announcement. The Aqua port is being done... just not by the OpenOffice.org people. The OpenOffice.org folks have decided to continue to maintain the X11 port for Mac, because they think they can get their results faster (and trying to do the Aqua port in-house was problematic). See the earlier story about this.
Yes, it'd be great if it were done faster. Volunteering?
Thankfully, most of these problems are easily countered by what you always have to do anyway: you MUST check and severely limit what you allow as input.
Letting users provide arbitrary-length data that's then used in realpath is a bug in the first place!
The unserialize() bug issue is rather serious, though.
It's true that all systems have vulnerabilities, but that does not mean that all systems are equally secure. What you want is a track record that shows good things.
Frankly, I'm not all that impressed with PHP's track record so far.
The good news is that the PHP developers have been willing to change critical pieces (like turning off globals) to deal with security issues, and it looks like at least some of them are taking security more seriously.
But I'd really like to see evidence of serious steps to not just provide a niftier OO model, but provide a programming language where programs are more likely to actually withstand attack.
PHP has a lot going for it, but an implementation that can't handle harsh attacks is simply not appropriate for today's network.
I'd like to see Hardened-PHP, or something like it, merged into the mainline PHP.
Why is it that only some users will get a PHP that tries to defend against attacks?
Does this mean that other PHP users never get attacked?
Does this mean that PHP programmers have stopped making common mistakes?
Nonsense.
There's no reason that there has to be a
separate project to modify PHP to be secure against attack; that should be part and parcel of PHP itself.
The performance impact is tiny, and much less important than keeping control over your own machine.
Why should anyone be impressed at the speed of a system that's about to be controlled by an attacker?
One of the best ways to get a secure setup is to find out what product has the better security track record with evidence of a secure design (modular parts, etc.), and switch to one of them.
That's true whether it's OSS or proprietary; OSS is no guarantee of security, it simply makes some kinds of worldwide review possible.
Using Internet Explorer or Outlook?
Switch to Firefox and Thunderbird.
Using Sendmail? Switch to Postfix.
That doesn't guarantee perfection, but you're generally better off in the long run.
I think you could make a very good case for switching from PHP to Perl or Python or Java.
If the PHP folks want to keep their large user base, they need to get on the stick.
For more information, see the
section on TCO in "Why OSS/FS? Look at the Numbers!".
Basically, TCO is very sensistive to the specific environment and requirements. It's clear, though, that there are many cases where OSS/FS does have a lower TCO.
Go see my Suggestions for Palm-based PDA Users, where I point out various useful utilities and programs for Palms. For viewing documents, I live on Plucker, in fact, that's my primary application -- I download documents in HTML (etc.) using Plucker, and then I can read them offline. For text editing, SiEd is great. For moving files around, use FileZ.
It's not free nor Free Software, but if you need a word processor / spreadsheet / presentation program, get Documents To Go if you have a Palm. It works well.
There's an even simpler solution: pregenerate your RSS feed.
Whenever info that you use to generate your RSS changes (e.g., you add a blog entry), regenerate a static file. This is no big deal; if anyone asked for the info, you'd have to generate this anyway.
Then serve the static file.
This gets a lot of caching behavior automatically.
The article seems to be really misleading. From reading the article, it appears this law isn't an anti-spam law; it's an anti-fraud law. It says you can't fraudulently claim to be someone else, etc., etc. As far as I can tell, spamming under a correct name (say, the company you just created 2 seconds ago and will throw away tomorrow) is still legal.
Let's talk about holes you can drive trucks through.
What we need is an anti-spam law, so that people who steal everyone's network access and email addresses can actually be prosecuted (including the people who fund them). Then the various technological techniques to counter and track the spammers down have a chance. It's still legal to spam in Ohio, and elsewhere. Why would we expect people to stop spamming when it's still legal to do so? Some people will stop doing things that are illegal, and for the rest, it's only possible to enforce laws that are actually passed.
Murder still happens, even though it's illegal. But many people won't murder for fear of punishment, and we have a whole infrastructure set up to catch and punish those who break the law. Time to bring the spamming thieves into that list.
Ben Hutchings has thought of a clever attack
(send a single spam message from one throwaway web-mail account to another on the same system, getting it signed on the way, then send copies of that out via other zombies).
But I think you're missing the point.
DomainKeys doesn't prevent spam; it just proves that the email really was sent from the given domain. So, if all the zombies are sending out copies of the email, then so what -- the recipient can correctly determine who the "real" sender's domain was, using the DomainKeys values to prove it.
Basically, things are working just how they're supposed to work - you can confirm that the email really was from a Yahoo! account, or whatever the domain said it was from.
So in some sense, this isn't a problem at all.
This attack does reveal an underlying assumption, though -- it's assumed that if a message is signed, then only the sender will be sending it, and a "good" sender will try to stop spam.
This attack ruins this assumption; an attacker can use a mail hosting service like Yahoo to create a valid signature, and copy that email to the entire world.
The problem isn't that it's not authenticated -- the problem is that it's hard to stop someone from sending those extra messages.
This approach would still work, if you could at least determine WHOSE email was being spammed. It does look like straight DomainKeys does have this as a weakness.
If there's one key per domain you might not be able to exactly determine who sent the message (by itself).
I guess a signer could record each hash it signs, and who sent it, so you could trace it back to the specific individual.
Alternatively, you could use per-user signatures, and then you'd be able to tell.
So, if a signer records the hashes it signs (along with who made the request), or uses individual user keys, I think it still works.
This is a nasty problem; ideally, MTAs shouldn't change the headers at all.
One solution would be to canonicalize the headers. Say, "remove all headers beginning with X-, then sort the headers alphabetically; identical header names use the pre-existing order". That would solve this.
Another solution would be to ignore all but certain headers. Ugh.
It's nonsense to think that something should be a standard if the implementors can't implement it. If the patent issues have been removed (say by dropping the absurd requirements, or by the patent office rejecting the patent), then great. But it's not reasonable to try to use a standards body to prevent alternative implementations. The whole purpose of a standards body is to define standard interfaces that everyone can implement. Since there are many important open source software implementations of these interfaces (in this case for MTAs), then the standards need to be implementable by open source software. If not, then the IETF should just send it right back; nothing important has changed. The problem is legal, not technical, and it requires a change in legal situation.
It'd be nice if they gave Theora a shot. It looks like a lot of work has to go into preparing Microsoft's codec -- why not work on one that has no licensing problems at all, if you have to do that? The code is available now, which is more than you can say for this alternative.
I agree with your statement that "there is not enough data to set a reasonable market price for the product", since obviously no sale of different Linux rights has been made.
However, your next statement is somewhat missing the point:
"Estimating based on what it would cost in a commercial environment is also flawed, because there are too many variables to consider."
Yes, salaries and overheads vary, and they'll certainly affect the answer. But I used a U.S.-nationwide average for salaries, and several sources for the overhead value. See "Gigabuck" for more info. So this is an "average" kind of development. If you don't like those assumptions, I gave enough information for you to recompute everything using different values.
But you have to make some assumptions, and I think these are quite reasonable ones; I
basically picked averages to represent an "average" development project's costs.
But then you say stuff that I think isn't right: "The bottom line is, since the developers have always been paid nothing for their work (except those that are being sponsored by commercial entities)... since in all likelihood if these guys weren't writing the code in their spare time, they would be doing some other hobby...
The bottom line here is, the only time that you can assign a value to is the time that someone actually received a wage for. This is a small minority of the overall code base, so by that method the code would not be worth much at all."
Two problems: first, I'm computing re-development cost, and presuming that the developers would be getting a wage. And second, most of the changes in the Linux kernel are from developers getting a wage to do so.
In fact, the move to wage-earning OSS/FS development has been one of the silent trends in the IT industry.
In 2004,
Government Computer News reported in July 2004 on a presentation by Andrew Morton, who leads maintenance of the the Linux kernel in its stable form, and confirmed the trend towards paid OSS/FS developers. Morton spoke at a meeting sponsored by the Forum on Technology and Innovation, to address technology-related issues, held by Sen. John Ensign (R-Nev.), Sen. Ron Wyden (D- Ore.) and the Council on Competitiveness. Morton noted that "People's stereotype [of the typical Linux developer] is of a male computer geek working in his basement writing code in his spare time, purely for the love of his craft. Such people were a significant force up until about five years ago..." but contributions from such enthusiasts, "is waning... Instead, most Linux kernel code is now generated by corporate programmers." Morton noted that "About 1,000 developers contribute changes to Linux on a regular basis... Of those 1,000 developers, about 100 are paid to work on Linux by their employers. And those 100 have contributed about 37,000 of the last 38,000 changes made to the operating system."
Time to ask the Public Patent Foundation to see if this patent can be overturned because of prior art and obviousness. Sounds like these patents are really good targets for both problems.
The author makes the process (from the user point of view) sound much worse than it really was. Was this a bad bug? Of course, all agree that dataloss is a terrible thing. But:
this was immediately marked as a blocker, so the official (initial) release of Firefox was NOT going to go out with this bug, anyway, no matter what.
once it was identified as a security issue, it was fixed within a half hour, even though it was an incredibly difficult bug to find (3 project developers had tried and failed).
Yes, ideally all bugs are fixed even more rapidly. But originally this wasn't marked as a security bug, and nonsecurity bugs often take more time to fix than you'd wish in any development process:
The bug appeared to be an extremely unlikely occurance, and thus while important to fix before release, it's not clear that the delays were in any way unusual for ANY development project.
Although it had bad ramifications, it's also clear that triggering this accidentally is extremely difficult. None of the millions of users using Firefox had reported it before, and previous versions have been out for a while. The priority of a bug doesn't just depend on the severity of the problem, but on the likelihood. If a dataloss can happen 1/day, that's much more serious than one that happens 1/millenium. For extremely unlikely triggers, it's not at all unusual for those to take longer to correct in either proprietary or open source software.
In part that's because of the difficulty of tracking down such uncommon problems to their source.
This was obviously a hard bug to fix. Three people tried to find the bug, and couldn't do so.
The author wishes that even more people would've worked on it in the early days, but all projects have a limited number of people and much to do. Heck, in most proprietary projects, you assign only one person to handle the bug, and that person has 100 other assignments too. He had three people directly working on it, with discussion by others... that's far more help than many projects get.
What changed everything was marking it as a security requirement. Here I agree with the author - the author should have identified this as a security problem in the first place. And I'm really sympathetic to his sitatuation; we all make mistakes, and at least he reported the bug in the first place. Thankfully, a later reader DID realize this, and raised it to a security issue. As a security issue, suddenly the "unlikely" problem becomes "near certainty" since an attacker WANTS to cause trouble, and will work to cause the unlikely to happen.
And once it was labelled as a security problem - look at the speedy response! It was fixed in less than a half hour - that's extraordinarily fast in any software development process, OSS/FS or proprietary. It's even more amazing because the problem was in a completely different place than 3 previous developers had thought... so this was clearly not an easy bug to find and fix (at least for most project developers).
And Firefox is still at the "previous release" level, it's not even officially released! I routinely use Mozilla and Netscape, not Firefox, because Firefox THEMSELVES state that the product's not ready. When they say it's ready, I'll let other people try it out first; version 1.0s are often a little wet behind the ears (remember Windows 1.0? Probably not, and there's a reason for that). But once Firefox 1.0 is out for a little while, I'll probably switch to it; it looks really nice. Obviously a lot of people
Getting ansy about taking a little extra time to find a non-security bug, when the product can't be released til it's fixed anyway, and it's hard to fix, seems a little excessive.
The process issues he raises are interesting issues, and they're certainly worth addressing. E.G., how do you "make secret" that which is already public? But I'm sure there are many possible answers; discuss, pick one, and move on.
You should use facts acquired over a period of time to discern something, which is why older facts and figures (like the ones you note) are mentioned.
One of the paragraphs in the opening says:
"This paper includes data over a series of years, not just the past year; all relevant data should be considered when making a decision, instead of arbitrarily ignoring older data. Note that the older data shows that OSS/FS has a history of many positive traits, as opposed to being a temporary phenomenon."
For market surveys, sure, more recent data are often more relevant. But those are in there, so it's not like they're missing. But older survey data can help you see that this isn't as "new" a phenominon as some people want to claim.
As far as the reliability experiment goes,
the end of the reliability section explains further: "One problem with reliability measures is that it takes a long time to gather data on reliability in real-life circumstances. Thus, there's more data comparing older Windows editions to older GNU/Linux editions. The key is that these comparisons are fair, because they compare contemporaneous products."
That shouldn't be surprising. If it takes 10 months to do a study, then it takes quite a commitment to keep re-doing them.
Increasingly, people are being paid to work on OSS/FS software. That's how X and Apache were developed, so this isn't new. The Linux kernel is almost entirely developed by people paid to do so (37,000 out of 38,000 changes a few months ago).
There are lots of articles about this trend, referenced in the paper.
Also, nearly all software is not developed for sale, but is custom-developed for a particular purpose (most estimates place this at 95%). For custom, you're paid to develop it anyway, and
having an OSS/FS program to base it on makes many things easier.
My site's up, but it's not handling Slashdotting as well as I'd hope. I'll see what I can do.
Nonsense. Many businesses want to talk to strangers (except they have the curious phrase "potential customers" for them). And don't you get email from long-lost friends/relations?
Sure, whitelisting alone helps SOME people. But for many people that's not enough.
If you don't like what Hotmail is doing, switch to an alternative. If you're willing to pay a little anyway, there are lots of good services available. One is Runbox. I make no money from them; I'm just a happy customer. Google mail is obviously a possibility (though they're only in beta testing right now).
I love it when customers say, "Nah, I'm going to switch." If they do that often enough, companies are forced to provide better service or better prices to all of us. Invisible hand, yadda yadda.
If by "failsafe" you mean "will chop off the hands of people who don't include that information", then no, their.doc or OOo format are failsafe.
Nor is anything else, for that matter.
But this OOo format does include a way to store metadata, in office:document-meta. See section 2.2 (and section 2.1) of
the OOo 1.0 committee draft specification.
You can even include arbitrary metadata (say from another metadata format specification, like the W3C's RDF).
There's some info in there about storing author names; nothing built-in for abstracts.
If you think they should predefine something, or recommend something as a starting point, please research what you think they should do, and then submit your recommendation and rationale to the OASIS office group. A well-reasoned proposal is going to get a serious look by this group, and if there's no serious challenge (or the challenges are well-rebuffed), you're likely to get it in.
No, standards don't need to prevent you from improving a product. For one thing, widely-used standards usually get updated periodically. And this particular specification includes lots of ways to include additional information that's ignored unless the program can handle it (that opens things up for embrace-and-extend, but at least it deals with the problem you mentioned).
I think you're looking at the wrong thing: the program. I don't want to care about the program. What's important to me is the data. If you create a word processor document, do you have all the details of its data format so that you could extract the data later if you needed to? Or must you depend on a particular version of a product? Already Microsoft Office cannot correctly read many files that previous versions of their product created only 10 or 15 years ago. But government records may have to be kept viewable for centuries or millenia.
And don't say, "It's popular, so it'll always be readable." WordStar was at one time the dominant word processor. Nowadays few programs can really read its format (which is luckily close enough to ASCII that the critical stuff is extractable). Apple ][ disks were once common; think you can easily read them now? How about in 500 years?
Users own their data, not vendors.
And thus users need to know exactly what the data format is, so that they can have access to their own data.
And in commonly-used formats (like office documents), these need to be standardized, so that vendors can compete on an equal footing with products that manipuate those formats.
The World Wide Web was so successful in part because the normal data format (HTML) was publicly specified -- anyone could write a program to acquire and process the data.
That's a key advantage of standards -- once the data format is standard, people can write programs to process the data in new and useful ways.
TCP/IP is a standard, but nobody complains that there "shouldn't be a standard." Why? Because we NEED standards to exchange data. Office data format standards are needed for exactly the same reasons: to let people exchange data.
Now it's true that
there's always a risk that standards are created "too soon" before their functionality needs are identified. That's not an issue with office suites; their basic functionality hasn't changed in a long, long time.
Another common risk is trying to invent a standard from whole cloth, without implementation first. Again, not a problem; OpenOffice.org implements this, and I believe both KOffice and AbiWord implement parts of it, so it has some real experience.
And the OASIS folks are doing a real review of the format so it can handle things in the long haul. Already they've made minor changes, since the format is now undergoing real scrutiny, and the minor changes are getting reflected in OpenOffice.org to ensure that the changes are helping instead of hurting.
In the end, they'll have a specification that has at least one full implementation directly (OpenOffice.org), plus filters to and from Microsofto Office and several other office suites. That sounds like pretty good vetting, actually. And if it'll be implemented in StarOffice and OpenOffice.org, people will be able to use it immediately, and without fee (if they wish), so that eliminates many barriers.
I actually think this is fairly common in standards-land. Various vendors develop formats. One is developed with liberal/no licensing requirements, so that it can be implemented by multiple vendors. That format, because it's supported by multiple vendors, is picked by major customers, becomes a standard, and then dominates the rest. In videotapes eventually VHS dominated over Betamax, in part because Sony wanted to "own everything" and the smaller vendors who were willing to go a less proprietary route ended up taking them to the cleaners (though I grant that other Betamax issues like 1 hour lengths were issues as well).
That doesn't mean that Microsoft's formats will be el
Slashdot Mirror
What's different is the increasingly strenuous tone calling for people to reign in the number of licenses. In many ways, this basically demonstrates that OSS/FS has matured. Lots of people have created new licenses, essentially experimenting with different approaches. The marketplace of ideas has selected a few "winning" ideas, and it's getting increasingly hard for even a good new license idea to overcome the many problems of incompatibility with what already exists. Commercial development and use of OSS/FS is now widespread; a consolidation of common licensing approaches appears inevitable as the whole approach becomes common.
There's at least one simple test: make sure your license is GPL-compatible. You can do this by using the GPL, using a different license that is known to be GPL-compatible (in particular the LGPL, MIT/X, or BSD-new (modified BSD) licenses), or by dual-licensing the program (and ensuring that one of the licenses is the GPL). See my essay for info on why GPL compatibility is so important.
In many ways, this license winnowing is happening anyway. My paper More than a Gigabuck found that only a few licenses were used by nearly all the code; at the time it was (in order) GPL, MIT, LGPL, MPL, and BSD (counting by lines of code). You can look at Freshmeat's statistics, which counts the licenses per project. Today, 2005-02-16, the OSS/FS licenses in order of popularity were (from most popular) the GNU General Public License (GPL) (67.99%) GNU Lesser General Public License (LGPL) (5.89%), BSD License (original) (3.54%), BSD License (revised) (1.92%), Artistic License (1.80%), MIT/X Consortium License (1.26%), Apache License (0.72%), Mozilla Public License (MPL) (0.57%), Perl License (0.39%), and Apache License 2.0 (0.26%). I see a short list here, and notice that even in this list of the most popular licenses, the dropoff between the most-popular licenses and the next most popular licenses are really steep. Every project whose license is incompatible with all of these has a serious liability, and in fact, being only compatible with the lower-popularity licenses is a real problem. Few think Sun's CDDL code is going to go anywhere, solely because it's an odd license incompatible with the millions of lines of code already out there.
I wish he'd used proper terminology - I think he meant "proprietary" not "commercial". Last I checked, Red Hat, Novell, IBM, Sun, and many other distributors of OSS/FS programs (including those using the GPL) were commercial companies.
OSS is no silver bullet. Their last point is "OSS code quality seems to suffer from the very same problems that have been observed in CSS projects." Er, big surprise, they're all software.
That's interesting info!
Evolution is great, and a port to Windows sounds great too. But if Macs aren't included then that's unfortunate. Both Firefox and OpenOffice.org are available across Windows, Mac, Unix, and Linux. It'd be great if a good OSS/FS Email/Groupware combo were cross-platform too.
Yes, it'd be great if it were done faster. Volunteering?
The unserialize() bug issue is rather serious, though.
It's true that all systems have vulnerabilities, but that does not mean that all systems are equally secure. What you want is a track record that shows good things. Frankly, I'm not all that impressed with PHP's track record so far. The good news is that the PHP developers have been willing to change critical pieces (like turning off globals) to deal with security issues, and it looks like at least some of them are taking security more seriously. But I'd really like to see evidence of serious steps to not just provide a niftier OO model, but provide a programming language where programs are more likely to actually withstand attack. PHP has a lot going for it, but an implementation that can't handle harsh attacks is simply not appropriate for today's network.
I'd like to see Hardened-PHP, or something like it, merged into the mainline PHP. Why is it that only some users will get a PHP that tries to defend against attacks? Does this mean that other PHP users never get attacked? Does this mean that PHP programmers have stopped making common mistakes? Nonsense. There's no reason that there has to be a separate project to modify PHP to be secure against attack; that should be part and parcel of PHP itself. The performance impact is tiny, and much less important than keeping control over your own machine. Why should anyone be impressed at the speed of a system that's about to be controlled by an attacker?
One of the best ways to get a secure setup is to find out what product has the better security track record with evidence of a secure design (modular parts, etc.), and switch to one of them. That's true whether it's OSS or proprietary; OSS is no guarantee of security, it simply makes some kinds of worldwide review possible. Using Internet Explorer or Outlook? Switch to Firefox and Thunderbird. Using Sendmail? Switch to Postfix. That doesn't guarantee perfection, but you're generally better off in the long run. I think you could make a very good case for switching from PHP to Perl or Python or Java. If the PHP folks want to keep their large user base, they need to get on the stick.
For more information, see the section on TCO in "Why OSS/FS? Look at the Numbers!". Basically, TCO is very sensistive to the specific environment and requirements. It's clear, though, that there are many cases where OSS/FS does have a lower TCO.
It's not free nor Free Software, but if you need a word processor / spreadsheet / presentation program, get Documents To Go if you have a Palm. It works well.
This gets a lot of caching behavior automatically.
It's worth noting that there are a number of open source software products that run on top of PalmOS. See my Suggestions for PalmOS PDA Users, freshmeat.net's list for the PalmOS Operating System category, and http://www.palmopensource.com.
Let's talk about holes you can drive trucks through.
What we need is an anti-spam law, so that people who steal everyone's network access and email addresses can actually be prosecuted (including the people who fund them). Then the various technological techniques to counter and track the spammers down have a chance. It's still legal to spam in Ohio, and elsewhere. Why would we expect people to stop spamming when it's still legal to do so? Some people will stop doing things that are illegal, and for the rest, it's only possible to enforce laws that are actually passed.
Murder still happens, even though it's illegal. But many people won't murder for fear of punishment, and we have a whole infrastructure set up to catch and punish those who break the law. Time to bring the spamming thieves into that list.
Basically, things are working just how they're supposed to work - you can confirm that the email really was from a Yahoo! account, or whatever the domain said it was from. So in some sense, this isn't a problem at all.
This attack does reveal an underlying assumption, though -- it's assumed that if a message is signed, then only the sender will be sending it, and a "good" sender will try to stop spam. This attack ruins this assumption; an attacker can use a mail hosting service like Yahoo to create a valid signature, and copy that email to the entire world. The problem isn't that it's not authenticated -- the problem is that it's hard to stop someone from sending those extra messages.
This approach would still work, if you could at least determine WHOSE email was being spammed. It does look like straight DomainKeys does have this as a weakness. If there's one key per domain you might not be able to exactly determine who sent the message (by itself). I guess a signer could record each hash it signs, and who sent it, so you could trace it back to the specific individual. Alternatively, you could use per-user signatures, and then you'd be able to tell.
So, if a signer records the hashes it signs (along with who made the request), or uses individual user keys, I think it still works.
This is a nasty problem; ideally, MTAs shouldn't change the headers at all. One solution would be to canonicalize the headers. Say, "remove all headers beginning with X-, then sort the headers alphabetically; identical header names use the pre-existing order". That would solve this. Another solution would be to ignore all but certain headers. Ugh.
It's nonsense to think that something should be a standard if the implementors can't implement it. If the patent issues have been removed (say by dropping the absurd requirements, or by the patent office rejecting the patent), then great. But it's not reasonable to try to use a standards body to prevent alternative implementations. The whole purpose of a standards body is to define standard interfaces that everyone can implement. Since there are many important open source software implementations of these interfaces (in this case for MTAs), then the standards need to be implementable by open source software. If not, then the IETF should just send it right back; nothing important has changed. The problem is legal, not technical, and it requires a change in legal situation.
It'd be nice if they gave Theora a shot. It looks like a lot of work has to go into preparing Microsoft's codec -- why not work on one that has no licensing problems at all, if you have to do that? The code is available now, which is more than you can say for this alternative.
However, your next statement is somewhat missing the point: "Estimating based on what it would cost in a commercial environment is also flawed, because there are too many variables to consider." Yes, salaries and overheads vary, and they'll certainly affect the answer. But I used a U.S.-nationwide average for salaries, and several sources for the overhead value. See "Gigabuck" for more info. So this is an "average" kind of development. If you don't like those assumptions, I gave enough information for you to recompute everything using different values. But you have to make some assumptions, and I think these are quite reasonable ones; I basically picked averages to represent an "average" development project's costs.
But then you say stuff that I think isn't right: "The bottom line is, since the developers have always been paid nothing for their work (except those that are being sponsored by commercial entities) ... since in all likelihood if these guys weren't writing the code in their spare time, they would be doing some other hobby...
The bottom line here is, the only time that you can assign a value to is the time that someone actually received a wage for. This is a small minority of the overall code base, so by that method the code would not be worth much at all."
Two problems: first, I'm computing re-development cost, and presuming that the developers would be getting a wage. And second, most of the changes in the Linux kernel are from developers getting a wage to do so.
In fact, the move to wage-earning OSS/FS development has been one of the silent trends in the IT industry. In 2004, Government Computer News reported in July 2004 on a presentation by Andrew Morton, who leads maintenance of the the Linux kernel in its stable form, and confirmed the trend towards paid OSS/FS developers. Morton spoke at a meeting sponsored by the Forum on Technology and Innovation, to address technology-related issues, held by Sen. John Ensign (R-Nev.), Sen. Ron Wyden (D- Ore.) and the Council on Competitiveness. Morton noted that "People's stereotype [of the typical Linux developer] is of a male computer geek working in his basement writing code in his spare time, purely for the love of his craft. Such people were a significant force up until about five years ago ..." but contributions from such enthusiasts, "is waning... Instead, most Linux kernel code is now generated by corporate programmers." Morton noted that "About 1,000 developers contribute changes to Linux on a regular basis... Of those 1,000 developers, about 100 are paid to work on Linux by their employers. And those 100 have contributed about 37,000 of the last 38,000 changes made to the operating system."
For more about the general trend of employed OSS/FS developers, see http://www.dwheeler.com/oss_fs_why.html#wont-destr oy-industry.
This isn't new in a sense; X Windows was started
this way, as was Apache. It's just become
more common.
Time to ask the Public Patent Foundation to see if this patent can be overturned because of prior art and obviousness. Sounds like these patents are really good targets for both problems.
Yes, ideally all bugs are fixed even more rapidly. But originally this wasn't marked as a security bug, and nonsecurity bugs often take more time to fix than you'd wish in any development process:
What changed everything was marking it as a security requirement. Here I agree with the author - the author should have identified this as a security problem in the first place. And I'm really sympathetic to his sitatuation; we all make mistakes, and at least he reported the bug in the first place. Thankfully, a later reader DID realize this, and raised it to a security issue. As a security issue, suddenly the "unlikely" problem becomes "near certainty" since an attacker WANTS to cause trouble, and will work to cause the unlikely to happen.
And once it was labelled as a security problem - look at the speedy response! It was fixed in less than a half hour - that's extraordinarily fast in any software development process, OSS/FS or proprietary. It's even more amazing because the problem was in a completely different place than 3 previous developers had thought... so this was clearly not an easy bug to find and fix (at least for most project developers).
And Firefox is still at the "previous release" level, it's not even officially released! I routinely use Mozilla and Netscape, not Firefox, because Firefox THEMSELVES state that the product's not ready. When they say it's ready, I'll let other people try it out first; version 1.0s are often a little wet behind the ears (remember Windows 1.0? Probably not, and there's a reason for that). But once Firefox 1.0 is out for a little while, I'll probably switch to it; it looks really nice. Obviously a lot of people
Getting ansy about taking a little extra time to find a non-security bug, when the product can't be released til it's fixed anyway, and it's hard to fix, seems a little excessive.
The process issues he raises are interesting issues, and they're certainly worth addressing. E.G., how do you "make secret" that which is already public? But I'm sure there are many possible answers; discuss, pick one, and move on.
Some helpful background on searching the net can be found on SearchLores.org.
One of the paragraphs in the opening says: "This paper includes data over a series of years, not just the past year; all relevant data should be considered when making a decision, instead of arbitrarily ignoring older data. Note that the older data shows that OSS/FS has a history of many positive traits, as opposed to being a temporary phenomenon."
For market surveys, sure, more recent data are often more relevant. But those are in there, so it's not like they're missing. But older survey data can help you see that this isn't as "new" a phenominon as some people want to claim.
As far as the reliability experiment goes, the end of the reliability section explains further: "One problem with reliability measures is that it takes a long time to gather data on reliability in real-life circumstances. Thus, there's more data comparing older Windows editions to older GNU/Linux editions. The key is that these comparisons are fair, because they compare contemporaneous products." That shouldn't be surprising. If it takes 10 months to do a study, then it takes quite a commitment to keep re-doing them.
Increasingly, people are being paid to work on OSS/FS software. That's how X and Apache were developed, so this isn't new. The Linux kernel is almost entirely developed by people paid to do so (37,000 out of 38,000 changes a few months ago). There are lots of articles about this trend, referenced in the paper. Also, nearly all software is not developed for sale, but is custom-developed for a particular purpose (most estimates place this at 95%). For custom, you're paid to develop it anyway, and having an OSS/FS program to base it on makes many things easier.
My site's up, but it's not handling Slashdotting as well as I'd hope. I'll see what I can do.
Sure, whitelisting alone helps SOME people. But for many people that's not enough.
I love it when customers say, "Nah, I'm going to switch." If they do that often enough, companies are forced to provide better service or better prices to all of us. Invisible hand, yadda yadda.
But this OOo format does include a way to store metadata, in office:document-meta. See section 2.2 (and section 2.1) of the OOo 1.0 committee draft specification. You can even include arbitrary metadata (say from another metadata format specification, like the W3C's RDF). There's some info in there about storing author names; nothing built-in for abstracts.
If you think they should predefine something, or recommend something as a starting point, please research what you think they should do, and then submit your recommendation and rationale to the OASIS office group. A well-reasoned proposal is going to get a serious look by this group, and if there's no serious challenge (or the challenges are well-rebuffed), you're likely to get it in.
I think you're looking at the wrong thing: the program. I don't want to care about the program. What's important to me is the data. If you create a word processor document, do you have all the details of its data format so that you could extract the data later if you needed to? Or must you depend on a particular version of a product? Already Microsoft Office cannot correctly read many files that previous versions of their product created only 10 or 15 years ago. But government records may have to be kept viewable for centuries or millenia.
And don't say, "It's popular, so it'll always be readable." WordStar was at one time the dominant word processor. Nowadays few programs can really read its format (which is luckily close enough to ASCII that the critical stuff is extractable). Apple ][ disks were once common; think you can easily read them now? How about in 500 years?
Users own their data, not vendors. And thus users need to know exactly what the data format is, so that they can have access to their own data. And in commonly-used formats (like office documents), these need to be standardized, so that vendors can compete on an equal footing with products that manipuate those formats.
The World Wide Web was so successful in part because the normal data format (HTML) was publicly specified -- anyone could write a program to acquire and process the data. That's a key advantage of standards -- once the data format is standard, people can write programs to process the data in new and useful ways.
TCP/IP is a standard, but nobody complains that there "shouldn't be a standard." Why? Because we NEED standards to exchange data. Office data format standards are needed for exactly the same reasons: to let people exchange data.
Now it's true that there's always a risk that standards are created "too soon" before their functionality needs are identified. That's not an issue with office suites; their basic functionality hasn't changed in a long, long time. Another common risk is trying to invent a standard from whole cloth, without implementation first. Again, not a problem; OpenOffice.org implements this, and I believe both KOffice and AbiWord implement parts of it, so it has some real experience.
And the OASIS folks are doing a real review of the format so it can handle things in the long haul. Already they've made minor changes, since the format is now undergoing real scrutiny, and the minor changes are getting reflected in OpenOffice.org to ensure that the changes are helping instead of hurting. In the end, they'll have a specification that has at least one full implementation directly (OpenOffice.org), plus filters to and from Microsofto Office and several other office suites. That sounds like pretty good vetting, actually. And if it'll be implemented in StarOffice and OpenOffice.org, people will be able to use it immediately, and without fee (if they wish), so that eliminates many barriers.
I actually think this is fairly common in standards-land. Various vendors develop formats. One is developed with liberal/no licensing requirements, so that it can be implemented by multiple vendors. That format, because it's supported by multiple vendors, is picked by major customers, becomes a standard, and then dominates the rest. In videotapes eventually VHS dominated over Betamax, in part because Sony wanted to "own everything" and the smaller vendors who were willing to go a less proprietary route ended up taking them to the cleaners (though I grant that other Betamax issues like 1 hour lengths were issues as well). That doesn't mean that Microsoft's formats will be el