Comment Re:ssh (Score 1) 641
Agreed. ssh is the most important tool.
Agreed. ssh is the most important tool.
Similar in software, I have to pay $600 for Adobe CS4 as nobody can't produce similar tools because Adobe have their 'patent portfolio' there.
Very bad example: (1) Similar software exists; (2) The price is (most probably) not because of patent protection, but rather because of the availability, usability, and brand of the product.
If you copy it, they remind you that you only have a license. You can't do *everything* you want to do because you don't own it, you just have a license to listen to it.
You are wrong (at least for audio CDs and movie DVDs). If you bought a CD or DVD you own it. You can do with it whatever you want (note: this does NOT include violating the copyright - which is a distribution right); there is no EULA. Those licenses exist for software, though.
Actually, I think that this boycott helps. At least in the case of audio CDs (which have been often crippled as "enhanced CDs"), there is a trend to come back to the DRM free CD standard. I think that is mainly because enough people do not buy them. You also see it with DRM free music at Amazon and iTunes.
DVDs are different: they always included DRM and the so much hated region code. DVD buyers just live with the fact. BTW: I know nearly no person that is still buying DVDs (unless they have kids - because they tend to see a movie 100s of times); most people are either renting the DVD or directly use VoD. Clearly, a DRM on a rented DVD or on a VoD stream is less cumbersome for the consumer - after all you only have a day or so to use the media.
And, most importantly: I do not buy DVDs (with DRM) to have a better conscience. I do not buy them, because I do not want them.
Just because others do not care, does not mean that you should buy DRM crippled media.
I am convinced that at least some of those great DVD non-skipable trailers and annoucements "Copying of this DVD is prohibited..." and you-need-to-watch-this-for-at-least-30-seconds have decreased the number of people buying DVDs and increased the number of people getting cracked copies over the Internet. It's not just those who do not want to pay - it's also those who do not want to see every time that the publisher thinks that you need a reminder to not become a criminal.
Interestingly enough, your direct link to AnyDVD is illegal in Germany. Will we see STOP signs? Or will Gemany close
When I buy a DVD, I want to be able to create a backup that I use and store the DVD in safe keeping. If they don't want me to do this, distribute your films on a more robust media. This ruling is down right horrible for consumers.
I fully agree to your reasoning. But I think that the only real consequence is: Do not buy any movie, music, software that is distributed on DRM "protected" media.
This behavior, btw, may over time maybe also change the offer.
A general tool of almost any kind, used in a different way, is _not patentable_. It's using the tool for what it was designed for, it does not change the physical construction of the machine nor its number of parts nor its general capabilities.
This is not entirely accurate. Suppose there is a patent on Compound X and the patent discloses the use of Compound X as a floor wax. Now suppose someone discovers that Compound X makes an excellent treatment for baldness, which is entirely nonobvious given its previous use as a floor wax. It is true that the inventor cannot patent Compound X again just because a new use has been discovered. But what the inventor can patent is a method of use of Compound X as a baldness treatment, specifying the dose and treatment regimen. This is true in the US though not true in many other jurisdictions.
I hope that you are not right. First of all: Discoveries are not patentable (as far as I understand the patent system). Second, you cannot patent the "how-to-use" description of compound X, you may create a new product that contains compound X and maybe patent its composition. But then, I know much about patents for software (which should not exist, but practically exist), and nothing about patents used in pharmaceutical products. I am not sure whether they are comparable.
The "actually implemented algorithm" is protected in its specific implementation by copyright, and should not receive the double protection of patent law against writing similar algorithms.
The protection provided by copyright is very narrow: it extends only to the literal source and machine code, not to the algorithm generally. For example: suppose one discovers a new efficient algorithm for simulating fluids. This has many potential applications: special effects, computer games, weather simulation, etc. Now suppose one publishes the algorithm and implements it in a specific program: a computer game. Nothing in copyright law stops everyone in the world from implementing the published algorithm in their own games, weather simulators, special effects software, etc. So long as they don't directly rip off the inventor's code but instead create their own implementation of the idea, they are in the clear.
Yes. And you have built an application around this algorithm fully covered by the copyright. Or you have a library which markets the implementation - fully covered by the copyright. By publishing your new algorithm (e.g. on an international conference), you even get the merits and maketing that you need to establish yourself as an expert, so that's much easier to sell your implementation of this algorithm - compared to maybe other implementations. And, of course, you have a head start, since you may not publish the algorithm before your product is ready.
So what's a business to do? A common thing to do is keep the algorithm a secret and keep the source closed.
The public will never learn about the algorithm.
That is also a possibility: Use your algorithm as a trade secrete inside your application - instead of benefiting from the marketing by publishing it. However, you should not think that other researchers are so dumb to not make the same discovery, if the algorithm is really so much better than others. If your product outperforms all others, people will start looking closer to possible solutions and they will do the same discovery - and they will do it before the typical end of the patent period.
Software patents step in to fill the gap left by copyright.
There is only a perceived gap. You think that a discovery of some mathematics should be patentable. I think it should not. Oddly, you cannot patent mathematics, but somehow lobbyists could get the PTO to patent algorithms (if I write the words "embodied in an apparatus").
A patent on the fluid simulation algorithm protects any implementation of it in any domain. This allows the inventor to sell or license the rights to the highest bidder in each field. In the mean while, the public gets to see the algorithm published as a patent, and they are free to create and patent improvements as well as design around it. When the patent expires, the public is free to use the original idea. If the idea becomes outdated (e.g. because an open-source competitor designs a better alternative), then the patent will be worthless, the owner will stop paying the maintenance fees, and the invention will enter the public domain ahead of schedule.
The above very clearly summarizes why patents on algorithms are so powerful and harmful: Your example algorithm is required in many fields and anybody using it needs to get a license. You may sell me a license - or you may decide to not sell me a license. You may also sell me an exclusive license. You may also decide to give nobody a license. In any case: Either I have to license your algorithm - or I am blocked. Even if I would be capable to design the same algorithm (which is more often the case than otherwise with those patented algorithms that I have seen), I would be at your mercy to get a license. Even worse, I might have discovered the same algorithm independently and not even know about your patent - and you could stop me from using my own discovery.
So, I think a made my points against software patents.
But that someone should be distributed, i.e. a group instead of a single entity
Why?
And, more importantly, how?
Because self contained formats are easier to archive than a format that may include lots of external references.
That's another assertion, not a reason. Also, note that "easier to archive" is of much less importance than ease in searching and retrieval.
I think that being able to determine easily whether a document is complete or not, is very important for archival reasons. So, self-containment is much easier in this regard. And there are enough open document standards that allow self-containment (e.g. PDF).
Your argument "search and retrieval is more important than ease of format" is very valid.
But, most of those other formats can be easily indexed and searched.
Another issue is that HTML is complex; if you really want long-term archival, your archived documents must adhere 100% to the standard (which is in the HTML world rather the exception) and you need browser implementations that are 100% compatible.
Natural language is complex. HTML is the first widely deployed system that captures the semantics of natural language compositions in an overt way.
That's an interesting point. I would never had said that HTML is used to do semantic markups. Of course you could use HTML for semantic markups, but then XML would be the better choice (or LaTeX). But even then: A real semantic markup is e.g. something as discussed under the term Semantic Web.
That having said, I am not sure that semantic markup is a good thing for long-term archival. In, say 100 or 200 years from now, will a semantic markup still be useful? That's an open question, I do not have the answer.
Unlike XML and XHTML, HTML does support documents whose underlying semantics are broken, so it can be used to capture and archive documents that don't really make much sense. So the assertion that archival documents would need to be 100% compliant with HTML standards is false. It is simply a case that the archival process is not going to make a poorly written document magically better.
What do you want to archive, actually? If the content is produced by a machine (e.g. OCRed from a book scan) you could easily require XML or any other format. If the authors request an archive, you could request full HTML or also full XML compliance (or any other format that they can create). If it is about arbitrary existing HTML documents that you want to archive, then a Web spider is probably good enough.
But if we speak about long-term archiving, at least I speak about a kind of library with librarians. Content is not just added and indexed and retrieved, but also tagged. And the librarians are responsible to not only the technical long-term archival, but also (if required) a format change. At least they are required to ensure that for all stored formats can be decoded (before they accept to store the content). I really think that HTML is too complex for this, there are too many options. And you do not gain much from using HTML. HTML might be a choice, if you very much restrict its use.
As far as I know long term archival of digital artifacts is still an open research topic. But I am not involved.
Meaning that there is no existing method of archiving today's documents that meets your specifications. I, for one, think we need to work with the tools that are available rather than day dreaming about the wonders of vaporware.
Agreed. But this does not point me to HTML.
The main reason for the existence of HTML is its use via HTTP - the ability to fetch the documents with a browser from remote sites over the Internet. So, HTML should excel for this task and not include more requirements, such as for long-term archival.
No, this is false.
This describes the original purpose of HTML some 20 odd years ago.
No, this is still the case. HTML is dominant for documents on the Web; i.e. documents accessed via HTTP. It is not the dominant format for document creation; and other formats are better suited (e.g. LaTeX, Oasis).
This is proving to be one of the more useful
Thanks. I return the compliments.
Yeah, tell me about a solution that works out of the box on all systems. The only solutions I know are meta solutions that are the compiled differently for the different platform (such as GWT). Or the self-restriction to very basic HTML - i.e. to the content plus the hyper text markups.
Just because that is how things are now, does not mean that that is how it should be, or always will be. As far as I can tell, you're basically saying "we shouldn't try and standardise anything other than text layout, because existing proprietary solutions for things other than text have traditionally been difficult and fragile, and we can't possibly break with tradition." Your reason for thinking we shouldn't try and standardise the codecs is because nothing else is standardised?
No, I did not say this. I wanted to point out that currently HTML is not an out-of-the-box solution and that it is very improbable that HTML5 will be. So, the argument to require a specific codec to get an out-of-the-box solution is void.
It breaks when the web designer wants to do layout; unfortunately that's exactly what most web designer concentrate on.
The reason for that is because we are still in the grip of the "browser wars", no matter how much people try to claim otherwise. Why fight attempts to bring them to a close? I can only assume that you are so sure that HTML 5 is doomed to failure that you no longer think it is worth the time and effort trying, which is a wee bit cynical IMHO.
I do not think that the main problem comes from the "browser wars". The main problem stems from the idea that web pages now must be "designed" and "layouted". HTML was originally for content and links together with mark-up hints about how to display the content. If you want to create a Web page that looks the same on every device and in all browsers you're doomed (in HTML); you should use something like Flash. But this is not the fault of HTML, but about the wrong requirements of web page designers.
HTML should not be used for long term archival purpose.
Why not? It looks like the ideal archival format to me: fully searchable by umpteen different browsers, available to all, simple to reverse engineer if that someday becomes necessary.
Because self contained formats are easier to archive than a format that may include lots of external references.
Another issue is that HTML is complex; if you really want long-term archival, your archived documents must adhere 100% to the standard (which is in the HTML world rather the exception) and you need browser implementations that are 100% compatible.
So I'd love to hear your reasoned arguments about why any other format would be better than HTML.
As far as I know long term archival of digital artifacts is still an open research topic. But I am not involved.
Or at least, long term archival should not be taken as an argument whether or not to define a codec within the standard.
Again, please explain this. I don't understand.
The main reason for the existence of HTML is its use via HTTP - the ability to fetch the documents with a browser from remote sites over the Internet. So, HTML should excel for this task and not include more requirements, such as for long-term archival.
The plant where my dad works at has a 200 gallon pool where the waste is stored that what they have from 75 years of running the plant...
Bart Simpson, is this you? On a side note, as far as I am aware the world-oldest nuclear power plant became operational in 1956. Unless he is working in a military nuclear plant, but then they are actually using the waste for the bombs (or did I miss here something?).
Here's a crazy idea: how about nuclear power? Oh, that's right, the word "nuclear" is too super-scary for the science-based environmentalists. Never mind that they actually are better for the environment than anything else.
Nuclear energy is better for the environment than: Wind? Solar photovoltaics? Solar thermal? Hydroelectric?
Or do you mean: petrol and coal, when you said "anything else"?
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?
