The point that "monopolies are not illegal" has been raised many times throughout this discussion.
Achieving a monopoly through legal business practices may not be illegal in the US. But simply having a a monopoly, no matter how it was achieved, may stifle innovation, present insurmountable barriers to entry to competitors, and allow companies to charge for their products amounts that are undesirably high.
Regulating these falls outside the purview of the legal system, but it is legitimate business for legislators. Many behaviors that used to be legal were found undesirable and subsequently made illegal or regulated.
If monopolies exist on essential services and infrastructure, no matter how they were achieved, that is sufficient by itself to consider government intervention and/or regulation. And while many people seem to believe that the US has a laissez faire system where anything that's legal goes without government intervention, even the US (like any other democracy) has a long history of regulating essential services and infrastructure. For example, the communications infrastructure, media companies and utilities all fall under ownership restrictions and government regulations, even though they could (and would) otherwise achieve monopolies through legal means.
Maintaining a competitive, open market is one of the key functions of a democratic government that has chosen a free market approach. Government regulations and ownership restrictions are an essential part of that.
Of course, the question before the court is narrower. The court cannot create new government regulations, only enforce existing law. It is in that sense that the court has limited options for enforcement, and it is in that sense that "monopolies are not illegal".
While the court's options are limited, during an out-of-court settlement, everything is on the table, including remedies that the court could not legally require if the case went to trial.
And Microsoft has an interest in considering consenting to such remedies because if the legal system does not provide relief, lawmakers will take up the issue. That is a much bigger gamble for them and a much harder case to negotiate than settling this quietly with some government legal representatives.
It was a research project, used widely internally. I wasn't at PARC then, but I suspect that managers didn't see a mass market at the time, and I think they were right. A device that required users to learn a new alphabet, that was much slower for inputting text than even a small keyboard, and that cost several hundred dollars seemed doomed from the start. The Sharp organizers were nearly the same size and weight, cheaper, and much easier to input text into.
I think the biggest reason for the PalmPilot success was because it was the first to have excellent desktop synchronization. Also, I think its built-in apps were and still are the best in the business, much better than WinCE and somewhat better than Sharp. And, cumbersome and nonsensical as the handwriting input on the PalmPilot may be, it looks less geeky than typing at a tiny keyboard and is likely socially much more acceptable. And the PalmPilot creators were also lucky that they were just at the point in the technology curve where hardware had gotten cheap and powerful enough to design what they wanted to design; if they had started a year or two earlier, and they wouldn't have been able to deliver something useful at an acceptable price.
potential problems for high speed access
on
AOL Nation
·
· Score: 2
We have to see how AOL manages high-speed access via cable. If you are a Time-Warner cable customer, will you have to get Internet access from AOL? Will you have to use Windows and Internet Explorer in order to do so? Will you be forced to watch ads?
AOL claims they will continue to fight for open access for ISPs to cable. Let's hope they will. But maybe that stance is just temporary to avoid anti-trust complaints.
In fact, even the aggregation of cable and traditional content providers is worrisome and has led to a restricted menu of cable content already. Altogether, I'd feel more comfortable if regulatory agencies prohibited these kinds of deals outright.
I don't know the history first hand, but I believe the press has reported that there were negotiations between Xerox and the creators of the PalmPilot about licensing the unistroke technology and that those broke down. Apparently, the PalmPilot creators made a conscious decision to test the patent in court.
I think it's actually good to get these kinds of patents tested in court rather than licensed for some undisclosed amount or settled out of court.
Xerox made a handheld device, called the PARC TAB, roughly the size of the PalmPilot several years before the PalmPilot came out. That's what the patent grew out of.
The PARC TAB let you perform many of the functions of the PalmPilot. For quick access, it had a bunch of buttons, and for text entry, you'd use a unistroke alphabet (more efficient than the PalmPilot's alphabet). It was also networked through IR links (networked links were, and still are, installed in the ceilings around Xerox PARC).
If Palm were to come up with REAL handwriting, Apple could sue. Even IF the new version was 'clean' of Apple code, the legal bills would go on for some time.
I don't see why. Apple neither invented on-line handwriting recognition nor was their technology particularly distinguished. They may have a few patents in the area, but so do lots of other people. The basic ideas should be coming into the public domain by now, since they were worked out in the 70's and early 80's.
Of course, I don't see handwriting recognition as particularly important for PDAs anyway. It's a nice marketing gimmick, but when it comes down to it, something like a Sharp Wizard is much more efficient for data entry. To me, what makes the PalmPilot a good organizer is the well-designed software; unfortunately, none of the other hand-held organizers get close (e.g., on the Sharp Wizard, you cannot delete repeating appointments and the desktop software is a pain to install). I view the pen input as a liability, not an asset.
The term "open source" really doesn't mean much anymore, other than that you get the sources in one way or another. I don't necessarily fault companies for that. The common sense meaning of "open source" is that you easily get the sources somehow, nothing more. I think the term is not well chosen, and we should abandon it. Many licenses that can be reasonably called "open source" do nothing to encourage sharing and joint development; in fact, they may outright prohibit it.
The "official" Open Source Definition tries to define "open source" more tightly. But since the term isn't trademarked and since it has a different common sense meaning, it fails. Furthermore, even the "Open Source Definition" has some holes in it.
In the short term, I suggest people stop getting excited just because a company announces releasing something "open source". We should wait until the sources and the license are available for everybody to look at.
In the long term, I think we need to replace the term "open source" with something more self-descriptive.
Several people have asked what the big deal is if the video delivery technology is proprietary: it's cheap and people can still use it to publish whatever they want to.
While proprietary streaming video technology is a lot cheaper than a television station, it can nevertheless exclude a lot of voices from participating in the media. How?
First, proprietary technology, adopted as a standard and protected by patents, still ends up being a lot more expensive than equivalent free technology, and the price alone keeps people from using it.
Think not only of the cost of the encoder or a small streaming server, but of the cost of putting up a large streaming server that can reach a lot of people. Companies developing the streaming technology are going to charge for the use of their proprietary server technology based on commercial uses; maybe that ends up being only a fractional cent per connection, but that quickly adds up and becomes out of reach for non-commercial content providers.
A second problem is that the technology will likely be licensed selectively when it comes to large service providers. The heavy duty streaming video servers may end up only being available from a few large hosting companies, and those may have restrictions on content similar to those of large television companies. That hasn't happened yet, but it is another way in which proprietary distribution technology can limit available content. And the analogy to the broadcast networks and their bland, low-quality content is quite close--in the case of the broadcast networks, it wasn't patents but broadcast licenses that were exclusionary and led to the dumbing down of America.
And lastly, proprietary technology is self-perpetuating. If you leave the development of standards and technology to a few companies, they are going to develop and patent all the "innovations" and perpetuate their hold on the market. Many of those "innovations" may only be simple tweaks, ideas that would easily and naturally occur to any open source developer, but they will nevertheless be protected for decades to come. By playing the patent game right, companies can keep content in proprietary formats in perpetuity.
Have you looked at the prices for decent video publishing software (not the home video stuff)?
Granted, it's still cheaper to buy a Mac with lots of add-on software than to buy a television transmitter ans license. And right now, hardware and bandwidth are still as expensive as the software.
But in the long run, the price of video publishing software is going to dominate the cost of creating and distributing video content, and free software can play an important role in making video publishing more widely available.
Another consideration is that if we don't start developing more free video software, future "inventions" in that area will automatically be made by commercial companies and become patented. Useful little features that a free software author might spend 10 minutes on thinking up and implementing will be patented and locked up for the next 20 years if the field is left to the commercial software developers.
Creating algorithms isn't any more difficult than implementing a large sofwtare system. Even if you want to argue that basic video encoding ideas (motion compensation, etc.) at one point were patentable, the basic ideas are so old that they are in the public domain by now (or should be soon). Most of what protects MPEG-2 and similar standards are tweaks, tweaks that have alternative workarounds.
But even if it were, standards bodies should insist that methods that are adopted into standards are available royalty free to anybody, or at the very least royalty free for open source implementations.
In fact, they often do, and many standards have and will have free implementations as a consequence (JBIG and JPEG2000 being two of them). I suspect that with MPEG-2 and MPEG-4, it's the influence of the greed and money of the media industry and Hollywood that causes them to be governed by "patent pools". At the very least, corporate lawyers look at the money those companies are making and wondering: how can we get a slice of that.
I have no problem with taking a cut from big media companies. The problem I have is that we still need a free format for free content, for socially important content, etc., something that allows people who don't have a lot of money to get their content across the Internet, using a free infrastructure.
Once decrypted into plain-text, the key is vulnerable to the "key-finding" attack. But since a key is only a few hundred bytes long and the storage space of the server may be tens of gigabytes, conventional reasoning argues that an intruder is unlikely to ever find the key.
I know of noone that relies on the difficulty of finding a key within a few gigabytes of memory to protect their server. Doing so would be silly: there are a lot simpler attacks than looking for keys by their randomness. For example, most server software is standardized, and it's easy to figure out what locations hold pointers to the keys (you can find out by analyzing the source or by experimenting with your own copy). And there are many other ways to attack.
If you want your keys to be secure, the system that keeps them has to be physically secure and secure against unauthorized logins because at some point, the system will have the plain text keys in memory somewhere.
Of course, the whole thing is an attempt by nCipher to drum up business--they want to sell their "nCipher hardware". If you use a cryptographic accelerator that also performs the key management, you are a bit safer, because most of the time, the keys are available only inside the accelerator, a device that is probably harder to "break into" than the whole server. But nCipher's solution is still vulnerable because you communicate with the encryption box over the web and the web client you use could be attacked.
The best security for your keys is likely to be achieved by using a crypto accelerator for which the key is entered physically at the box (e.g., via a SmartCard or keyboard), or for which you physically connect the box to another, non-networked computer while performing key management functions. Lots of products besides nCipher's are capable of that.
I think your observation that these are issues of time scales is very important, and it's at the heart of why I believe that the computer virus/biological virus analogy is flawed.
The immune system was successful initially because it could very quickly generate new defense mechanisms that pathogens would take some time to adapt to through evolutionary mechanisms.
Even so, after many millions of years of evolution, there are now numerous pathogens that simply aren't touched by the immune system at all; the only reason why those pathogens haven't wiped us out is because natural pathogens don't have malicious intent, and most of them have co-evolved to co-exist with us.
When it comes to computer viruses, the insight to be concerned about is the insight of the virus writer. Unlike the biological world, where pathogens need to spend millions of years of evolution to figure out general mechanisms for avoiding the immune system, a virus writer can come up with a general purpose strategy for evading a "computer immune system" within days.
If you want secure systems, in a world of human adversaries, the only way to build them is so that they are structurally secure or cryptographically secure, and those are engineering problems that are very different from what biological systems have faced until now.
(As an aside, the next step of evolution of biological pathogens may be interesting. The immune system got us quite far, but it is growing old as a defense mechanism as pathogens have found general purpose ways of evading it. Perhaps its successor is our brain, as we design drugs and treatments rationally. It will be interesting to see how the pathogens will respond.)
There are some broad analogies between biology, ecology, and computer systems. For example, "monocultures" are susceptible to "viruses". And many "viruses" can be detected effectively by tracking the appearance of "fragments" (of code or proteins) and correlating that with computer system damage. But, biology or not, those are ideas that any good engineer should come up with anyway.
Perhaps the biggest point of departure is that biological systems are evolutionary, while computer systems are designed by humans, with knowledge of the possible countermeasures. That means that many immune system strategies just won't translate.
But even more important is perhaps the observation that most biological systems (even plants and most animals) don't even have immune systems. They rely on other mechanisms for their defense, mechanisms that many engineers would probably consider "good engineering": make it hard for the viruses to get in, destroy viruses that do get in, minimize the effects of infection if it does occur, stop the spread of infection with various barriers, and have lots of redundancy. The evolutionary pressures for some animals to develop immune systems probably simply don't exist for computer systems.
So, if you want to push the biology analogy, it may well be better to do without an immune system and to simply design good, strong systems.
The patent claims are actually quite broad; you can find the claims here.
If their implementation works well, GraphOn has done a nice programming job. However, as far as patents go, I think this one is of low quality even relative to the already low standards of today; dynamically translating between two window system APIs is a straightforward engineering solution to a common problem. If GraphOn's engineers think that this is something new, they didn't pay attention in their college CS classes.
The patent is on the IBM patent server. The press release is a fairly accurate summary, but if you care, read the patent yourself.
You don't need to go to lawschool to read this stuff; a decent command of English and logical reasoning is sufficient, and as an engineer, you better learn how to read and write patent claims.
Read the FAQ on Macromedia's site: the player is not being released "open source", it's released "free source". You can't sublicense, the license is non-transferable, and the field of application of the code is limited.
This is clearly an attempt by Macromedia to kill truly free implementations of the Flash format. Should another implementation of the Flash format become the de-facto standard, Macromedia would lose a lot of their strength and control of this market.
I suspect, in particular, that this may be related to the next release of Netscape this year: it will almost certainly need to include some kind of Flash player, and if they didn't make some kind of source code available, it would be the free implementation, giving an alternative implementation of the Flash format an instant big market share.
I think Macromedia's meddling and their implementation are best disregarded. If vector graphics is to become a web standard, we need truly free implementations, not the proprietary "free source" mess that Macromedia is offering.
I didn't see much information in the release about what kind of "open source" license the software would be released under.
Sadly, the term "open source" has become so overused that I think it is pretty much meaningless. Even the official open source definition is not sufficiently specific to be useful to me.
So, until we see the specific license, do you really care whether something is "open source"? I don't.
The problem with such discussions is that they are often couched in emotional or philosophical terms. But software licenses are primarily tools for getting people to do things. From a free software point of view, I'm particularly interested in encouraging open standards and contributions of new free software.
For end user applications, I think GPL is a great license: it makes companies share their modifications while allowing commercial distribution.
For libraries, I think GPL is not very good. The reason is the following. Development and research labs often start software development without making an up-front commitment to building open source software. Their projects are released as open source as an afterthought, when plans for commercialization fail, when there is no market for the software, or if a competitor became number one in the market and there is no profitable business in being second. Some companies may also release successful products in open source after a few years on the market, as they figure out that the money is in support, consulting, and add-ons.
Getting free software that way is not perfect, but much (if not most) free software was created that way (even a lot of software we may not think of like that--remember that many universities and basic research labs also have intellectual property rights to the works of their students, professors, and researchers).
Many of those institutions will not want to make an early commitment to making their software free. But with GPL libraries, they would have to.
LGPL and BSD both allow development and research labs to write software that will fit in smoothly with the free software infrastructure while allowing those institutions to keep their options open. If those institutions can't build their software on LGPL or BSD licenses, the software is going to be built on proprietary licenses and isn't going to make it out.
So, I think the GPL/LGPL approach for applications/libraries is a good one. GPL/BSD is also good. Both GPL and BSD have their uses.
As for a more temporary copyright, I think scaling back copyright to its original duration (or even shorter for software), possibly with an open source requirement, would be good public policy and serve the purposes of the copyright act.
But it's unlikely to happen: too many media companies have too large a stake in the current system. As people put it: every time the Mickey Mouse copyright is about to expire, Disney lobbies to get copyright protection extended for another 20 years.
If it were only as simple as some evil master plan by a few giant corporations.
But increasing interdependence is woven into our social and evolutionary fabric. Most of us wouldn't have made it to adulthood without modern medicine. We have become dependent on numerous agricultural techniques and species. We rely on electricity, water, and other "everyday technologies".
On the whole, this isn't bad. While people from an agrarian society 500 years ago might be shocked if they heard about and understood our dependence on just-in-time grocery delivery, we don't mind. Future generations won't mind the additional dependencies created.
However, the web of patents, ethical questions, ecological uncertainties, and policies surrounding biotechnology and bioengineered crops should make us tread cautiously. Do we really want to create dependencies on a few large agribusinesses? Are we certain that the current GM foods are really safe for the long term? Do we understand the social and economic consequences? Much simpler agricultural techniques (damming, irrigation, etc.) have turned out to be harmful and unsustainable, and it seems almost certain that we don't yet understand well enough the consequences of genetically modified foods.
In the long run, biotechnology will be beneficial in agriculture and it will create interdependencies that people will live with happily, just like with live happily with our current interdependencies. In the short run, however, I think we need to tread more cautiously.
Internet companies pick names all the time, and most of them try to make sure that there are no objectionable, pre-existing, confusable names.
Many Internet companies, in fact, buy confusable domains outright. eToys should have tried to acquire the etoy.com domain name before they got started.
Either eToys didn't do their homework, or they decided early on that they didn't care about the confusability issue. Either way, it's the responsibility of eToys, not etoy.com, no matter what etoy.com content is.
Besides, the etoy.com content doesn't seem "adult" by European standards. Why should US hangups and prudishness dictate what the rest of the world can see on the Internet?
In the software world, it appears that often only the commercial leader is really profitable. For all the also-rans, open sourcing is a good alternative for the creator of the software and benefits everybody (except the frontrunner).
Another, similar route to open source software is through research projects that, for one reason or another, aren't commercialized; the research code is released and often becomes an important open source/free software system.
We should be happy about that: much (if not most) open source and free software started out that way.
Because so much free software starts out as commercial or research projects that, I think it's important to think about how to encourage development and research organizations to build it in such a way that the transition to free software will be easy. That means that such organizations should find it easy to use existing free software libraries, build on open APIs with free implementations, and should not feel the need to rely on proprietary libraries (which would make freeing the software later much harder).
One thing that I think is very important is to use licenses like LGPL or BSD (as opposed to GPL or QPL) for important libraries. Research and development organizations will not use software if that means making a strong commitment early on to open sourcing their software later or face uncertain expenses later. Both GPL and QPL, unfortunately, impose such uncertainties and limit options. If there is no unencumbered free or open source software, they will pick the best and most affordable proprietary libraries to build on.
The LGPL and BSD licenses, on the other hand, allow development and research organizations to keep their options open for what to do with their code. When infrastructure libraries (standard libraries, networking, gui, etc.) are released under those licenses, research and development organizations can use them, and when they decide to release their software as "free software", it will be so much more useful to the free software community than if it had been based on proprietary libraries or APIs.
For similar considerations, I think it's also important to get as much free software infrastructure on Windows. If companies start programming to free software APIs on Windows (and they have to cover the Windows market), when they go open source, their software will be much more useful to the free software community. So, the more unencumbered networking, database, and GUI libraries we can get onto Windows, the better.
So, keep that in mind when thinking about policies and licenses. While the idea that all free software is created by altruistic volunteers is appealing (and a significant amount of free software is), the reality is that a lot of free software is created by companies and donated if the software turned out not to be a winner in the market or is otherwise not commercializable. Making the life of those companies easier and allowing them to develop code that interoperates well with other free software is a win for everybody.
DVD is affordable because the audio and video markets make it a mass market product. And that's the markets the RIA is interested in and that drives their designs.
The problem is that the computer industry found it expedient to latch onto that format. That pretty much precludes any other format from becoming a mass market product because DVD does do what many people want, even on computers.
Even if the computer industry had their own, open format, unencumbered by RIA designs, they would likely still try to influence things and might succeed. MP3 is a format unencumbered by RIA designs, and look what the RIA is trying to do to it.
While I don't like what the DVD industry is doing, what I don't understand is why the DVD standard isn't simply being implemented in hardware. Then, the issue of software keys and software decoders would simply go away.
How would this work? BTTV cards ($80?) receive television signals, rescale them, and stuff them into a window in real time with little intervention by the CPU. A DVD decoder card could do the exact same thing.
The idea of using links/citation for ranking the importance of search results predates the web, and other groups had built search engines based on rankings using links/citations before Google (but didn't go the startup route). It seems to me that, up to some tweaks, PageRank is one of the more straightforward implementations for the web.
It's really hard to tell without seeing the patent how broad its claims are. On the whole, this patent doesn't seem any worse than a lot of other software patents. Depending on its claims, however, I think there may be some published prior art.
Incidentally, take a look at NorthernLight (www.nlsearch.com); they have a patent on their search folders, again something that is very close to widely used techniques.
On the whole, startups don't have a choice: VCs want patents. Those patents are needed for defense and negotiation with other companies in cross-licensing deals. Almost everybody (other than the lawyers) would be better off if these software patents didn't exist, but as long as the patent office will grant them and courts will enforce them, everybody has to get them.
Being able to write information (through ftp or otherwise) on a public server in some form or another is often an essential part of its function, and the rule "don't have publically writable directories" simply doesn't make sense.
In this case, it appears that the ftp daemon was buggy, and in this particular case did the wrong thing with a writable/incoming directory. The solution is to run a different FTP daemon or to fix the bug.
In part, the responsibility for this lies with the ubiquitous use of C for Linux system programming. Guarding against buffer overflows in C is a lot of work, and it is humanly impossible to catch all the possible problems in a large program. C++ helps a lot with its string class. Writing servers in Java, Perl, Python, Eiffel, Ada, SML, or many of the other languages with runtime checking is even better.
Slashdot Mirror
Achieving a monopoly through legal business practices may not be illegal in the US. But simply having a a monopoly, no matter how it was achieved, may stifle innovation, present insurmountable barriers to entry to competitors, and allow companies to charge for their products amounts that are undesirably high.
Regulating these falls outside the purview of the legal system, but it is legitimate business for legislators. Many behaviors that used to be legal were found undesirable and subsequently made illegal or regulated.
If monopolies exist on essential services and infrastructure, no matter how they were achieved, that is sufficient by itself to consider government intervention and/or regulation. And while many people seem to believe that the US has a laissez faire system where anything that's legal goes without government intervention, even the US (like any other democracy) has a long history of regulating essential services and infrastructure. For example, the communications infrastructure, media companies and utilities all fall under ownership restrictions and government regulations, even though they could (and would) otherwise achieve monopolies through legal means.
Maintaining a competitive, open market is one of the key functions of a democratic government that has chosen a free market approach. Government regulations and ownership restrictions are an essential part of that.
Of course, the question before the court is narrower. The court cannot create new government regulations, only enforce existing law. It is in that sense that the court has limited options for enforcement, and it is in that sense that "monopolies are not illegal".
While the court's options are limited, during an out-of-court settlement, everything is on the table, including remedies that the court could not legally require if the case went to trial.
And Microsoft has an interest in considering consenting to such remedies because if the legal system does not provide relief, lawmakers will take up the issue. That is a much bigger gamble for them and a much harder case to negotiate than settling this quietly with some government legal representatives.
I think the biggest reason for the PalmPilot success was because it was the first to have excellent desktop synchronization. Also, I think its built-in apps were and still are the best in the business, much better than WinCE and somewhat better than Sharp. And, cumbersome and nonsensical as the handwriting input on the PalmPilot may be, it looks less geeky than typing at a tiny keyboard and is likely socially much more acceptable. And the PalmPilot creators were also lucky that they were just at the point in the technology curve where hardware had gotten cheap and powerful enough to design what they wanted to design; if they had started a year or two earlier, and they wouldn't have been able to deliver something useful at an acceptable price.
AOL claims they will continue to fight for open access for ISPs to cable. Let's hope they will. But maybe that stance is just temporary to avoid anti-trust complaints.
In fact, even the aggregation of cable and traditional content providers is worrisome and has led to a restricted menu of cable content already. Altogether, I'd feel more comfortable if regulatory agencies prohibited these kinds of deals outright.
I think it's actually good to get these kinds of patents tested in court rather than licensed for some undisclosed amount or settled out of court.
The PARC TAB let you perform many of the functions of the PalmPilot. For quick access, it had a bunch of buttons, and for text entry, you'd use a unistroke alphabet (more efficient than the PalmPilot's alphabet). It was also networked through IR links (networked links were, and still are, installed in the ceilings around Xerox PARC).
I don't see why. Apple neither invented on-line handwriting recognition nor was their technology particularly distinguished. They may have a few patents in the area, but so do lots of other people. The basic ideas should be coming into the public domain by now, since they were worked out in the 70's and early 80's.
Of course, I don't see handwriting recognition as particularly important for PDAs anyway. It's a nice marketing gimmick, but when it comes down to it, something like a Sharp Wizard is much more efficient for data entry. To me, what makes the PalmPilot a good organizer is the well-designed software; unfortunately, none of the other hand-held organizers get close (e.g., on the Sharp Wizard, you cannot delete repeating appointments and the desktop software is a pain to install). I view the pen input as a liability, not an asset.
The "official" Open Source Definition tries to define "open source" more tightly. But since the term isn't trademarked and since it has a different common sense meaning, it fails. Furthermore, even the "Open Source Definition" has some holes in it.
In the short term, I suggest people stop getting excited just because a company announces releasing something "open source". We should wait until the sources and the license are available for everybody to look at.
In the long term, I think we need to replace the term "open source" with something more self-descriptive.
While proprietary streaming video technology is a lot cheaper than a television station, it can nevertheless exclude a lot of voices from participating in the media. How?
First, proprietary technology, adopted as a standard and protected by patents, still ends up being a lot more expensive than equivalent free technology, and the price alone keeps people from using it.
Think not only of the cost of the encoder or a small streaming server, but of the cost of putting up a large streaming server that can reach a lot of people. Companies developing the streaming technology are going to charge for the use of their proprietary server technology based on commercial uses; maybe that ends up being only a fractional cent per connection, but that quickly adds up and becomes out of reach for non-commercial content providers.
A second problem is that the technology will likely be licensed selectively when it comes to large service providers. The heavy duty streaming video servers may end up only being available from a few large hosting companies, and those may have restrictions on content similar to those of large television companies. That hasn't happened yet, but it is another way in which proprietary distribution technology can limit available content. And the analogy to the broadcast networks and their bland, low-quality content is quite close--in the case of the broadcast networks, it wasn't patents but broadcast licenses that were exclusionary and led to the dumbing down of America.
And lastly, proprietary technology is self-perpetuating. If you leave the development of standards and technology to a few companies, they are going to develop and patent all the "innovations" and perpetuate their hold on the market. Many of those "innovations" may only be simple tweaks, ideas that would easily and naturally occur to any open source developer, but they will nevertheless be protected for decades to come. By playing the patent game right, companies can keep content in proprietary formats in perpetuity.
Granted, it's still cheaper to buy a Mac with lots of add-on software than to buy a television transmitter ans license. And right now, hardware and bandwidth are still as expensive as the software.
But in the long run, the price of video publishing software is going to dominate the cost of creating and distributing video content, and free software can play an important role in making video publishing more widely available.
Another consideration is that if we don't start developing more free video software, future "inventions" in that area will automatically be made by commercial companies and become patented. Useful little features that a free software author might spend 10 minutes on thinking up and implementing will be patented and locked up for the next 20 years if the field is left to the commercial software developers.
But even if it were, standards bodies should insist that methods that are adopted into standards are available royalty free to anybody, or at the very least royalty free for open source implementations.
In fact, they often do, and many standards have and will have free implementations as a consequence (JBIG and JPEG2000 being two of them). I suspect that with MPEG-2 and MPEG-4, it's the influence of the greed and money of the media industry and Hollywood that causes them to be governed by "patent pools". At the very least, corporate lawyers look at the money those companies are making and wondering: how can we get a slice of that.
I have no problem with taking a cut from big media companies. The problem I have is that we still need a free format for free content, for socially important content, etc., something that allows people who don't have a lot of money to get their content across the Internet, using a free infrastructure.
If you want your keys to be secure, the system that keeps them has to be physically secure and secure against unauthorized logins because at some point, the system will have the plain text keys in memory somewhere.
Of course, the whole thing is an attempt by nCipher to drum up business--they want to sell their "nCipher hardware". If you use a cryptographic accelerator that also performs the key management, you are a bit safer, because most of the time, the keys are available only inside the accelerator, a device that is probably harder to "break into" than the whole server. But nCipher's solution is still vulnerable because you communicate with the encryption box over the web and the web client you use could be attacked.
The best security for your keys is likely to be achieved by using a crypto accelerator for which the key is entered physically at the box (e.g., via a SmartCard or keyboard), or for which you physically connect the box to another, non-networked computer while performing key management functions. Lots of products besides nCipher's are capable of that.
The immune system was successful initially because it could very quickly generate new defense mechanisms that pathogens would take some time to adapt to through evolutionary mechanisms.
Even so, after many millions of years of evolution, there are now numerous pathogens that simply aren't touched by the immune system at all; the only reason why those pathogens haven't wiped us out is because natural pathogens don't have malicious intent, and most of them have co-evolved to co-exist with us.
When it comes to computer viruses, the insight to be concerned about is the insight of the virus writer. Unlike the biological world, where pathogens need to spend millions of years of evolution to figure out general mechanisms for avoiding the immune system, a virus writer can come up with a general purpose strategy for evading a "computer immune system" within days.
If you want secure systems, in a world of human adversaries, the only way to build them is so that they are structurally secure or cryptographically secure, and those are engineering problems that are very different from what biological systems have faced until now.
(As an aside, the next step of evolution of biological pathogens may be interesting. The immune system got us quite far, but it is growing old as a defense mechanism as pathogens have found general purpose ways of evading it. Perhaps its successor is our brain, as we design drugs and treatments rationally. It will be interesting to see how the pathogens will respond.)
Perhaps the biggest point of departure is that biological systems are evolutionary, while computer systems are designed by humans, with knowledge of the possible countermeasures. That means that many immune system strategies just won't translate.
But even more important is perhaps the observation that most biological systems (even plants and most animals) don't even have immune systems. They rely on other mechanisms for their defense, mechanisms that many engineers would probably consider "good engineering": make it hard for the viruses to get in, destroy viruses that do get in, minimize the effects of infection if it does occur, stop the spread of infection with various barriers, and have lots of redundancy. The evolutionary pressures for some animals to develop immune systems probably simply don't exist for computer systems.
So, if you want to push the biology analogy, it may well be better to do without an immune system and to simply design good, strong systems.
If their implementation works well, GraphOn has done a nice programming job. However, as far as patents go, I think this one is of low quality even relative to the already low standards of today; dynamically translating between two window system APIs is a straightforward engineering solution to a common problem. If GraphOn's engineers think that this is something new, they didn't pay attention in their college CS classes.
You don't need to go to lawschool to read this stuff; a decent command of English and logical reasoning is sufficient, and as an engineer, you better learn how to read and write patent claims.
This is clearly an attempt by Macromedia to kill truly free implementations of the Flash format. Should another implementation of the Flash format become the de-facto standard, Macromedia would lose a lot of their strength and control of this market.
I suspect, in particular, that this may be related to the next release of Netscape this year: it will almost certainly need to include some kind of Flash player, and if they didn't make some kind of source code available, it would be the free implementation, giving an alternative implementation of the Flash format an instant big market share.
I think Macromedia's meddling and their implementation are best disregarded. If vector graphics is to become a web standard, we need truly free implementations, not the proprietary "free source" mess that Macromedia is offering.
Sadly, the term "open source" has become so overused that I think it is pretty much meaningless. Even the official open source definition is not sufficiently specific to be useful to me.
So, until we see the specific license, do you really care whether something is "open source"? I don't.
For end user applications, I think GPL is a great license: it makes companies share their modifications while allowing commercial distribution.
For libraries, I think GPL is not very good. The reason is the following. Development and research labs often start software development without making an up-front commitment to building open source software. Their projects are released as open source as an afterthought, when plans for commercialization fail, when there is no market for the software, or if a competitor became number one in the market and there is no profitable business in being second. Some companies may also release successful products in open source after a few years on the market, as they figure out that the money is in support, consulting, and add-ons.
Getting free software that way is not perfect, but much (if not most) free software was created that way (even a lot of software we may not think of like that--remember that many universities and basic research labs also have intellectual property rights to the works of their students, professors, and researchers).
Many of those institutions will not want to make an early commitment to making their software free. But with GPL libraries, they would have to.
LGPL and BSD both allow development and research labs to write software that will fit in smoothly with the free software infrastructure while allowing those institutions to keep their options open. If those institutions can't build their software on LGPL or BSD licenses, the software is going to be built on proprietary licenses and isn't going to make it out.
So, I think the GPL/LGPL approach for applications/libraries is a good one. GPL/BSD is also good. Both GPL and BSD have their uses.
As for a more temporary copyright, I think scaling back copyright to its original duration (or even shorter for software), possibly with an open source requirement, would be good public policy and serve the purposes of the copyright act.
But it's unlikely to happen: too many media companies have too large a stake in the current system. As people put it: every time the Mickey Mouse copyright is about to expire, Disney lobbies to get copyright protection extended for another 20 years.
But increasing interdependence is woven into our social and evolutionary fabric. Most of us wouldn't have made it to adulthood without modern medicine. We have become dependent on numerous agricultural techniques and species. We rely on electricity, water, and other "everyday technologies".
On the whole, this isn't bad. While people from an agrarian society 500 years ago might be shocked if they heard about and understood our dependence on just-in-time grocery delivery, we don't mind. Future generations won't mind the additional dependencies created.
However, the web of patents, ethical questions, ecological uncertainties, and policies surrounding biotechnology and bioengineered crops should make us tread cautiously. Do we really want to create dependencies on a few large agribusinesses? Are we certain that the current GM foods are really safe for the long term? Do we understand the social and economic consequences? Much simpler agricultural techniques (damming, irrigation, etc.) have turned out to be harmful and unsustainable, and it seems almost certain that we don't yet understand well enough the consequences of genetically modified foods.
In the long run, biotechnology will be beneficial in agriculture and it will create interdependencies that people will live with happily, just like with live happily with our current interdependencies. In the short run, however, I think we need to tread more cautiously.
Many Internet companies, in fact, buy confusable domains outright. eToys should have tried to acquire the etoy.com domain name before they got started.
Either eToys didn't do their homework, or they decided early on that they didn't care about the confusability issue. Either way, it's the responsibility of eToys, not etoy.com, no matter what etoy.com content is.
Besides, the etoy.com content doesn't seem "adult" by European standards. Why should US hangups and prudishness dictate what the rest of the world can see on the Internet?
Another, similar route to open source software is through research projects that, for one reason or another, aren't commercialized; the research code is released and often becomes an important open source/free software system.
We should be happy about that: much (if not most) open source and free software started out that way.
Because so much free software starts out as commercial or research projects that, I think it's important to think about how to encourage development and research organizations to build it in such a way that the transition to free software will be easy. That means that such organizations should find it easy to use existing free software libraries, build on open APIs with free implementations, and should not feel the need to rely on proprietary libraries (which would make freeing the software later much harder).
One thing that I think is very important is to use licenses like LGPL or BSD (as opposed to GPL or QPL) for important libraries. Research and development organizations will not use software if that means making a strong commitment early on to open sourcing their software later or face uncertain expenses later. Both GPL and QPL, unfortunately, impose such uncertainties and limit options. If there is no unencumbered free or open source software, they will pick the best and most affordable proprietary libraries to build on.
The LGPL and BSD licenses, on the other hand, allow development and research organizations to keep their options open for what to do with their code. When infrastructure libraries (standard libraries, networking, gui, etc.) are released under those licenses, research and development organizations can use them, and when they decide to release their software as "free software", it will be so much more useful to the free software community than if it had been based on proprietary libraries or APIs.
For similar considerations, I think it's also important to get as much free software infrastructure on Windows. If companies start programming to free software APIs on Windows (and they have to cover the Windows market), when they go open source, their software will be much more useful to the free software community. So, the more unencumbered networking, database, and GUI libraries we can get onto Windows, the better.
So, keep that in mind when thinking about policies and licenses. While the idea that all free software is created by altruistic volunteers is appealing (and a significant amount of free software is), the reality is that a lot of free software is created by companies and donated if the software turned out not to be a winner in the market or is otherwise not commercializable. Making the life of those companies easier and allowing them to develop code that interoperates well with other free software is a win for everybody.
The problem is that the computer industry found it expedient to latch onto that format. That pretty much precludes any other format from becoming a mass market product because DVD does do what many people want, even on computers.
Even if the computer industry had their own, open format, unencumbered by RIA designs, they would likely still try to influence things and might succeed. MP3 is a format unencumbered by RIA designs, and look what the RIA is trying to do to it.
How would this work? BTTV cards ($80?) receive television signals, rescale them, and stuff them into a window in real time with little intervention by the CPU. A DVD decoder card could do the exact same thing.
It's really hard to tell without seeing the patent how broad its claims are. On the whole, this patent doesn't seem any worse than a lot of other software patents. Depending on its claims, however, I think there may be some published prior art.
Incidentally, take a look at NorthernLight (www.nlsearch.com); they have a patent on their search folders, again something that is very close to widely used techniques.
On the whole, startups don't have a choice: VCs want patents. Those patents are needed for defense and negotiation with other companies in cross-licensing deals. Almost everybody (other than the lawyers) would be better off if these software patents didn't exist, but as long as the patent office will grant them and courts will enforce them, everybody has to get them.
In this case, it appears that the ftp daemon was buggy, and in this particular case did the wrong thing with a writable /incoming directory. The solution is to run a different FTP daemon or to fix the bug.
In part, the responsibility for this lies with the ubiquitous use of C for Linux system programming. Guarding against buffer overflows in C is a lot of work, and it is humanly impossible to catch all the possible problems in a large program. C++ helps a lot with its string class. Writing servers in Java, Perl, Python, Eiffel, Ada, SML, or many of the other languages with runtime checking is even better.