Some fundamentalists are certainly intelligent in many respects. However, one common trait for all of them is the lack of critical thinking and/or imparired jugement. So while not all of them are unintelligent, all of them do have some 'blind spots' to their intelligence, since most of us would include critical capabilities and sound judgement to be important parts of what we call 'intelligence'.
Studying theology (or mythology) requires genuine scholarship (which in turn requires intelligence), regardless of the validity of the religion being studied or if the person believes in the tenants of the religion they are studying
While I don't disagree with this, the implication that fundamentalists are scholars is wrong. Genuine scholarship implies a critical distance and deep understanding of one's subject, not just a lot of knowledge. Indeed, if you look around at religious fanatics around the world, most of them are laymen, and have not studied theology at an academic level. (Whereas most of those preists who have do not advocate literal interpretations)
but the systems are far too large for analytical solutions of their wavefunctions.
The only system which can be solved analytically is the hydrogen atom. After that, it turns into a multi-body problem (and a rather nasty one at that, since the electron-electron interaction is not only governed by coulomb repulsion, but also the Pauli exclusion principle) and and there are only approximate solutions.
The big problem is that chemistry, in essence, is a very subtle effect. The effect of chemical bonding on an electron is several orders of magnitude smaller than its total energy. This means that any approximate solution must be very accurate. And the methods of approximation don't scale well.
Quantum chemistry is my field, and we are some of the few who actually study biochemical systems with it.
Unfortunately, I can't really say much about long-range effects myself; The number of atoms which can practically be modelled at the same time is about 100. (that's one-hundred! Not much!)
I'd say possibly the most important QM effect strucurally in enzymes is pi-stacking and pi-cation interactions. It's not something which can be modelled well by a point charge. (And what is worse, not all QM methods can model it either; DFT is infamous for not predicting pi-stacking or VdW effects)
Another significant thing which only QM can really model is transition-metal complexes. The coordination is very difficult to predict offhand. (Field splitting, spin states, spin interactions, Jahn-Teller effect, etc, etc..)
Just the other month, Science had some interesting results, including a completeley unprecedented mode of binding for nitric oxide to copper in nitrite reductase.
Our area is the study of the catalytic functions of metalloenzyme active sites. Again, this is not something which is easily predictable.
(Like, look at Cytochrome c Oxidase.. The function was determined in 1977, X-ray crystal structures have been known for over a decade. The mechanism of proton-pumping is still unknown. (And there's lotsofnotablepeople studying it.)
The creation of tools to make bio-machines similar to verilog/VHDL would indeed potentially have grave consequences, but I can't see it going any other way.
If all you have is a hammer..
Sorry, but this analogy is weird. Biology does NOT follow any simple rules of logic. In fact, we don't even know the rules.
A DNA sequence maps to an amino acid sequence, we've got that part pretty well figured out. The AA sequence maps to a protein or peptide. Right there, we're screwed. There is no ab initio method which accurately predicts protein folding. There are no reliable empirical methods either.
You can't really rely on existing structures for predicting new ones either; Even a single mutation can give you a completely different structure. (Compare an ordinary hemoglobin to a sickle-cell mutated one)
Ok, but just assume we can find out the structure, how do you determine the function of that protein? Again, there is no method of doing that. There is an entire world of chemistry which can go on. And in the enzymes for which we know the structure and function, there are a huge number in which we still do not know the mechanism. If chemistry was easily predictable, there would be far less for chemists to do!
Given you know the function of a single enzyme, can you predict how it will interact in a complex biological system with millions of other proteins, organic substances and whatnot?
There is no room for making the kind of abstractions which are done in the world of computers and engineering. Things are far more complex, and what is worse, they are not self-contained.
Intelligence is not knowledge, but there is are relations between the two. An important part of what most of us regard as 'intelligence' is the ability to 'see' how things relate to one another and form conclusions about them.
One way to do that is to form an abstraction in your head. Another way is to form an analogy and relate it to something which you do know.
For example the conclusion: "Fighting a war on two fronts is bad", could be reached either by abstract reasoning along the lines of how a two front war would divide one's resources and increase the chance of loosing the war. Or you could form an analogy to Germany loss in WWI.
The way I see it, they compliment eachother. But naturally, knowledge in itself is not intelligence, because you need a certain amount of abstract skills to be able to recognize an analogy.
No, you cited an example, not the actual definition.
The "writing your own program" part is not part of the definition.
And no, it does not neccesarily mean decompiling. Decompiling is only one method of reverse-engineering. Examining the program by comparing input/output is another one. Perhaps you'd never use a decompiler to reverse-engineer anything, but I'm guessing that you haven't either. There are many cases in which you can't use that method, or that method is simply to difficult.
But the actual code-writing is not part of the reverse-engineering process. Writing code is engineering. You're not reversing anything!
It's called 'reverse-engineering' because engineering is the process of going from an idea to a concrete thing, like an actual program or a bridge or a car. Reverse-engineering is the study of the engineering product in order to figure out which ideas were behind it, reversing the process. Hence the name.
Some real-life examples: Samba is an implementation of the Windows SMB protocl based on reverse-engineering. This was done through packet analysis, not through decompilation. It is therefore also 'clean room', because they haven't seen any actual code.
Hatari, an Atari ST emulator I've contributed to, has emulation of the Atari hard drive hardware which I coded after reverse-engineering the hard-drive interface protocol. Not having an actual Atari hard-drive to test on, or a full protocol spec, I did this through disassembling and studying the driver software. It is not clean-room, since I saw the other guy's code.
(However this is not a legal problem, because A) I didn't implement a driver, rather I implemented the 'hardware' part in software. and B) I didn't use any of their code and C) Nobody cares anymore anyway.)
Classpath, an reimplementation of the Java class libraries, is 'clean room'. Sun distributes its sources to these, but noone is allowed to contribute to Classpath if they have seen them, or if they've decompiled them. The Classpath project itself is not reverse-engineering. Although some reverse-engineering is probably done by means of writing small test programs to clarify omissions from Suns Java Specification.
Decompiling is not in itself cracking. "Cracking" depending on what meaning you chose, can mean many things, among others the removal of copy protection from software. I've did so myself back in my Atari years. Cracking is a form of reverse-engineering, and usually (but not always) entails using a disassembler. The only difference between cracking and traditional reverse-engineering is the intent.
And in the USA this is also a legal difference: The DMCA prohibits reverse-engineering with the intent to circumvent a copyright-protection device. It expressly allows it in order to achieve interoperability.
If you're European, you can look at directive 91-250-EEC of the EEC (now EU), Article 6. This legislation has been implemented in laws of all member states, and it expressly allows decompilation for interoperability purposes.
That's exactly the situation the EU seems to have worked themselves into here. They've ended up with "unfaithful" representatives who didn't do as they were expected to, and the EU hasn't exactly pondered what to do in such a situation yet.
Not quite. The EU Council, which took this decision, is not intended to represent the people. It represents the governments of the respective member states'. The governments, in turn, are supposed to represent the people.
(The EU parliament is the direct representative of the people.).
So it's more of a going-back-on-a-campaign-promise kind of betrayal than the analogy you made to the Electoral College.
Adding yet another patent to their (Note:)counter-claims doesn't qualify as 'going after someone' in my books. I think IBM put everything they could possibly bring up into their counterclaims.
That does not necessarily mean IBM themselves think this patent is valuable. It just means that they think it was 'worth a shot'; It's still better than anything SCO has.
It wouldn't look good for SCO to fail to contrive any Copyright infringement respective to Linux, when SCO own product UnixWare does infringe on IBM Patents.
You don't seem to know what you're hoping for. If the IBM patent is valid, Linux could be threatened too because gzip can read LZW compressed files.
AFAIK the conclusion that LZW compressed files could be decompressed legally was based on analysis of the Unisys patent, not the IBM one.
If the IBM patent is valid, then Linux could also be infringing.
I for one, will certainly be hoping IBM loses this counterclaim.
I agree that that sucks, and I've tried to do my part in trying to stop software patents (writing letters to my MP:s and so on).
What I meant to say isn't that we shouldn't be concerned about bogus and software patents, just that one shouldn't be on the lookout for them when programming.
Interesting point. Looking at Photoshop (and a couple other image-processing programs I had on my machines), it appears they all license the Unisys GIF patent (4,558,302) but none of them are licensees of the IBM patent (4,814,746).
Just further indication that the IBM patent isn't really relevant.
Well, that is simply bullshit. (see my other post in this thread on exactly what I'm doing)
Sure, there's a lot of overuse of stupid animations going on with powerpoint. There are a lot of people putting unnecessary and distracting animations into their presentations. But saying that that would mean that ALL animations are bad is simply throwing out the baby with the bath-water.
What is the best way to present:
Complex 3d objects? A still shot of a 3d object is difficult to interpret. An animation of the thing going through a full rotation immediately gives much better visualisation.
Time-dependent processes? Say you're showing the results of a fluid dynamics simulation, or temperature map or whatever. The alternatives are still maps with time indices in the caption, or an animated plot of the time evolution? Which is easier to understand? Which provides more detail? The animation.
Multivariate data A static image is 2d. An animation gives you a third axis of time to use, making for simpler plots.
I for one am the first to admit I don't quite get all this 'patents are evil' that seems to come from Slashdot articles.
It's not all patents, just software patents. It's debatable, but most programmers and OSS advocates are against software patents. Lots of info is available if you want to see where they're coming from.
A quick cursory overview of the patent link on IBM's patent doesn't say one thing about the GIF format, just the compression algorithm
No it doesn't. It covers the LZW algorithm. The most significant use of that algorithm today is in the GIF image format. It has been supplanted by better algorithms for general compression use.
Just seems silly to 'call out' a company to release a patent.
Not so silly, the patent is likely worthless since the same algorithm had already been patented by Unisys, and IBM probably knows it. (Although, as noted, it didn't stop them from throwing it into the mix against SCO, but then, why not? Additional counterclaims are cheap)
but client-server apps are not the same thing. i am sure that downloading pirate-sw has increased very very much when p2p came around.
And the Internet is not the same thing as the US Postal Service. I am sure that people sending kiddie-porn to eachother has increased very very much since the internet came around.
when was the last time you saw an useful gif animation?
The last time I gave a presentation.
I can't bet on which platform (linux/windows/mac) the lecture hall computer has, or if it has flash or whatever codec installed, and I need the animation to 'just work'.
With gif animations, any machine with a browser will do. If you can tell me which format I can use which will work on stock Linux, Windows and Mac systems without downloading or installing anything, I'm all ears.
There ARE other things being produced on computers than just web pages.
If want to know exactly: Animations of calculated molecular vibrational modes. It is simply far more effective to show someone an animation of a vibration than to try to illustrate it with 'motion arrows' and such.
Unisys was collecting money on GIF licenses for years, if IBM wanted to capitalize on this, they would've sued Unisys back then.
Besides that, there is good reason: It is, by all accounts I've read, the same algorithm. The Unisys LZW patent had even been granted before the IBM patent had been applied. It had priority by a mile. The IBM patent is simply worthless.
Developers shouldn't concern themselves with bogus patents. I for one have written programs which save GIF files, and although I respect(ed) the Unisys patent, I'm not at all worried about the IBM one.
How about: Because some of us need a format for simple animations which can be viewed on any machine without the hassle of installing software or codecs to use?
Trade secrets have no protection at all except by explicit contract. None.
Right. But Microsoft and most others put explicit trade-secret clauses in their employment contracts.
APIs are inherently nothing more than a logical framework. One does not reverse engineer them. One discovers them.
That wouldn't really be in tune with the more common definition of reverse-engineering. Reverse-engineering would typically entail using a decompiler/disassembler/debugger to figure out the inner workings of a program, and then writing a specification from that.
Yes, the actual implementation is the clean-room part, but that's ordinary forward-engineering from a specification, not reverse-engineering. H
owever, the person who did the reverse-engineering has seen the other guy's code, and is therefore not clean anymore.
It's simpler than that. You don't even need a clean room to simply describe something, even patented and licensed somethings.
No you don't, but you need to know what it is you are describing. I was thinking along the lines of (say) of undocumented Windows APIs. Leaving anti-trust issues aside, and just assuming that these undocumented APIs had trade-secret status, a Microsoft employee could not publish them without consent from MS. And everyone else couldn't 'just know' what they were.
So you'd then have to reverse-engineer them, and to do so legally, not use any priviliged information. And indeed, it's been done, without MS being able to do anything about it.
Auto parts is no problem, they're protected by patents as you noted, and patents are a stronger form of protection: There is no economic threat in having all information public (indeed patent applications are public), because noone else is allowed to make or use the part (for the given purpose) without license.
Popular misconception on Slashdot. I don't like the DMCA, but you should read exactly what it prohibits.
The DMCA prohibits "circumvention of copyright protection systems". No matter how you look at it, that's a very different thing from a general ban on reverse-engineering.
The most draconian interpretation possible is to assume that it prohibits reverse-engineering of copyright protection measures. But that's it. And it explicitly allows circumvention for interoperability purposes.
Without getting farther into the issue, an API cannot reasonably be interpreted as a copyright protection measure. And reverse-engineering isn't necessarily circumvention.
How did this seriously strange view of IP law get modded up?
You don't need permission from anybody to publish an API. There is no special copyright law covering API specifications.
Perhaps you are thinking of trade-secret status? Well, if something has been publicly published, it doesn't doesn't get trade-secret status. And that goes even if they put some silly 'license' on their documentation. (See for instance the BSDi case, where the Unix sources were found not to have trade-secret status without even being public, but simply because they had been seen by so many people. And that is despite the fact that they even had written agreements with all of them.)
You don't have to get a license to publish an original book on anything, ever.
Do you know what a license is? A license is permission from a rights-holder to exercise an otherwise exclusive right.
For copyright, that means performing, reproducing and creating derivatives of copyrighted material.
For patents, that means the right to manufacture and use the invention.
For trade-secrets, that means the right to divulge and use commercially the trade secret.
Now, if I chose not to publish my API secret, then it may be a trade-secret, in which case you may not have the right to publish it if you happen to be 'in' on it. APIs can however be reverse-engineered. You can reverse-engineer an API without any trade-secret knowledge (i.e. 'clean-room') and publish that, that is perfectly legal.
Perhaps you think that the API itself can be copyrighted, and that a description of the API is a derivative work? Well, that's a theory, but very dubious legally.
Under copyright law, code is separated into the "expressional" and "functional" parts, and APIs reasonably always fall into the latter part, and are therefore not copyrightable. In case law, good room is generally given for compatibility code, being functional. (Again, you can see the BSDi case, where it was found that header files describing the same Unix API were not infringing)
If the API itself is not copyrighted, something which has yet to be seen, the description of the API cannot be a derivative work. Naturally, the description itself can be copyrighted, including the official description, (e.g. the API specification) but anyone can write their own description.
so what it boils down to is some security firm pumping once again money from the gov(and paving the way for future pumping)...
Excuse me, you're not talking about "some security firm" here, you're talking about The RAND Corporation.
RAND was formed by the Air Force back during the cold war. Did a lot of development of game theory. John Nash ('A beautiful mind') worked there.
Infamous back in the 60's for their game-theoretical approach to nuclear war scenarios. Giving rise to the following satirical ditty by Malvina Reynolds:
The RAND Corporation's the hope of the world, They think all day long for a fee. They sit and play games about about going up in flames; For counters they use you and me.
I suppose you get the picture. Like them or not, RAND is and has been the most influential defense think-tank in the world, and shaped a large part of US defense policy.
Calling them "some security firm" is a bit of an understatement in that light.
Slashdot Mirror
Some fundamentalists are certainly intelligent in many respects. However, one common trait for all of them is the lack of critical thinking and/or imparired jugement.
So while not all of them are unintelligent, all of them do have some 'blind spots' to their intelligence, since most of us would include critical capabilities and sound judgement to be important parts of what we call 'intelligence'.
Studying theology (or mythology) requires genuine scholarship (which in turn requires intelligence), regardless of the validity of the religion being studied or if the person believes in the tenants of the religion they are studying
While I don't disagree with this, the implication that fundamentalists are scholars is wrong. Genuine scholarship implies a critical distance and deep understanding of one's subject, not just a lot of knowledge. Indeed, if you look around at religious fanatics around the world, most of them are laymen, and have not studied theology at an academic level.
(Whereas most of those preists who have do not advocate literal interpretations)
but the systems are far too large for analytical solutions of their wavefunctions.
The only system which can be solved analytically is the hydrogen atom. After that, it turns into a multi-body problem (and a rather nasty one at that, since the electron-electron interaction is not only governed by coulomb repulsion, but also the Pauli exclusion principle) and and there are only approximate solutions.
The big problem is that chemistry, in essence, is a very subtle effect. The effect of chemical bonding on an electron is several orders of magnitude smaller than its total energy. This means that any approximate solution must be very accurate. And the methods of approximation don't scale well.
Quantum chemistry is my field, and we are some of the few who actually study biochemical systems with it.
Unfortunately, I can't really say much about long-range effects myself; The number of atoms which can practically be modelled at the same time is about 100. (that's one-hundred! Not much!)
I'd say possibly the most important QM effect strucurally in enzymes is pi-stacking and pi-cation interactions. It's not something which can be modelled well by a point charge.
(And what is worse, not all QM methods can model it either; DFT is infamous for not predicting pi-stacking or VdW effects)
Another significant thing which only QM can really model is transition-metal complexes. The coordination is very difficult to predict offhand. (Field splitting, spin states, spin interactions, Jahn-Teller effect, etc, etc..)
Just the other month, Science had some interesting results, including a completeley unprecedented mode of binding for nitric oxide to copper in nitrite reductase.
Our area is the study of the catalytic functions of metalloenzyme active sites. Again, this is not something which is easily predictable.
(Like, look at Cytochrome c Oxidase.. The function was determined in 1977, X-ray crystal structures have been known for over a decade. The mechanism of proton-pumping is still unknown. (And there's lots of notable people studying it.)
The creation of tools to make bio-machines similar to verilog/VHDL would indeed potentially have grave consequences, but I can't see it going any other way.
If all you have is a hammer..
Sorry, but this analogy is weird. Biology does NOT follow any simple rules of logic. In fact, we don't even know the rules.
A DNA sequence maps to an amino acid sequence, we've got that part pretty well figured out.
The AA sequence maps to a protein or peptide. Right there, we're screwed. There is no ab initio method which accurately predicts protein folding. There are no reliable empirical methods either.
You can't really rely on existing structures for predicting new ones either; Even a single mutation can give you a completely different structure. (Compare an ordinary hemoglobin to a sickle-cell mutated one)
Ok, but just assume we can find out the structure, how do you determine the function of that protein?
Again, there is no method of doing that. There is an entire world of chemistry which can go on. And in the enzymes for which we know the structure and function, there are a huge number in which we still do not know the mechanism. If chemistry was easily predictable, there would be far less for chemists to do!
Given you know the function of a single enzyme, can you predict how it will interact in a complex biological system with millions of other proteins, organic substances and whatnot?
There is no room for making the kind of abstractions which are done in the world of computers and engineering. Things are far more complex, and what is worse, they are not self-contained.
Intelligence is not knowledge, but there is are relations between the two.
An important part of what most of us regard as 'intelligence' is the ability to 'see' how things relate to one another and form conclusions about them.
One way to do that is to form an abstraction in your head.
Another way is to form an analogy and relate it to something which you do know.
For example the conclusion: "Fighting a war on two fronts is bad", could be reached either by abstract reasoning along the lines of how a two front war would divide one's resources and increase the chance of loosing the war. Or you could form an analogy to Germany loss in WWI.
The way I see it, they compliment eachother. But naturally, knowledge in itself is not intelligence, because you need a certain amount of abstract skills to be able to recognize an analogy.
I Am Not A Cognitive Psychologist, however.
No, you cited an example, not the actual definition.
The "writing your own program" part is not part of the definition.
And no, it does not neccesarily mean decompiling. Decompiling is only one method of reverse-engineering. Examining the program by comparing input/output is another one.
Perhaps you'd never use a decompiler to reverse-engineer anything, but I'm guessing that you haven't either. There are many cases in which you can't use that method, or that method is simply to difficult.
But the actual code-writing is not part of the reverse-engineering process. Writing code is engineering. You're not reversing anything!
It's called 'reverse-engineering' because engineering is the process of going from an idea to a concrete thing, like an actual program or a bridge or a car.
Reverse-engineering is the study of the engineering product in order to figure out which ideas were behind it, reversing the process. Hence the name.
Some real-life examples:
Samba is an implementation of the Windows SMB protocl based on reverse-engineering. This was done through packet analysis, not through decompilation. It is therefore also 'clean room', because they haven't seen any actual code.
Hatari, an Atari ST emulator I've contributed to, has emulation of the Atari hard drive hardware which I coded after reverse-engineering the hard-drive interface protocol. Not having an actual Atari hard-drive to test on, or a full protocol spec, I did this through disassembling and studying the driver software. It is not clean-room, since I saw the other guy's code.
(However this is not a legal problem, because A) I didn't implement a driver, rather I implemented the 'hardware' part in software. and B) I didn't use any of their code and C) Nobody cares anymore anyway.)
Classpath, an reimplementation of the Java class libraries, is 'clean room'. Sun distributes its sources to these, but noone is allowed to contribute to Classpath if they have seen them, or if they've decompiled them. The Classpath project itself is not reverse-engineering. Although some reverse-engineering is probably done by means of writing small test programs to clarify omissions from Suns Java Specification.
Decompiling is not in itself cracking. "Cracking" depending on what meaning you chose, can mean many things, among others the removal of copy protection from software.
I've did so myself back in my Atari years. Cracking is a form of reverse-engineering, and usually (but not always) entails using a disassembler. The only difference between cracking and traditional reverse-engineering is the intent.
And in the USA this is also a legal difference: The DMCA prohibits reverse-engineering with the intent to circumvent a copyright-protection device. It expressly allows it in order to achieve interoperability.
If you're European, you can look at directive 91-250-EEC of the EEC (now EU), Article 6. This legislation has been implemented in laws of all member states, and it expressly allows decompilation for interoperability purposes.
Not that it's not possible to write palindromic code with curly-braces! (the one I did was in C)
It's just more of a challenge.
Why in the world would any programmer care about whether they write "if { }" or "if ... fi", etc?
Because we're geeks, and as such we want to be able to write palindromic code!
(And I'm saying that as someone who actually has..)
That's exactly the situation the EU seems to have worked themselves into here. They've ended up with "unfaithful" representatives who didn't do as they were expected to, and the EU hasn't exactly pondered what to do in such a situation yet.
Not quite. The EU Council, which took this decision, is not intended to represent the people. It represents the governments of the respective member states'. The governments, in turn, are supposed to represent the people.
(The EU parliament is the direct representative of the people.).
So it's more of a going-back-on-a-campaign-promise kind of betrayal than the analogy you made to the Electoral College.
I didn't bet anything.
Adding yet another patent to their (Note:)counter-claims doesn't qualify as 'going after someone' in my books. I think IBM put everything they could possibly bring up into their counterclaims.
That does not necessarily mean IBM themselves think this patent is valuable. It just means that they think it was 'worth a shot'; It's still better than anything SCO has.
It wouldn't look good for SCO to fail to contrive any Copyright infringement respective to Linux, when SCO own product UnixWare does infringe on IBM Patents.
You don't seem to know what you're hoping for. If the IBM patent is valid, Linux could be threatened too because gzip can read LZW compressed files.
AFAIK the conclusion that LZW compressed files could be decompressed legally was based on analysis of the Unisys patent, not the IBM one.
If the IBM patent is valid, then Linux could also be infringing.
I for one, will certainly be hoping IBM loses this counterclaim.
I agree that that sucks, and I've tried to do my part in trying to stop software patents (writing letters to my MP:s and so on).
What I meant to say isn't that we shouldn't be concerned about bogus and software patents, just that one shouldn't be on the lookout for them when programming.
Call it the Torvalds doctrine if you like..
Adobe is a licensee of all the relevant patents
Interesting point. Looking at Photoshop (and a couple other image-processing programs I had on my machines), it appears they all license the Unisys GIF patent (4,558,302) but none of them are licensees of the IBM patent (4,814,746).
Just further indication that the IBM patent isn't really relevant.
Well, that is simply bullshit.
(see my other post in this thread on exactly what I'm doing)
Sure, there's a lot of overuse of stupid animations going on with powerpoint. There are a lot of people putting unnecessary and distracting animations into their presentations. But saying that that would mean that ALL animations are bad is simply throwing out the baby with the bath-water.
What is the best way to present:
Complex 3d objects?
A still shot of a 3d object is difficult to interpret.
An animation of the thing going through a full rotation immediately gives much better visualisation.
Time-dependent processes?
Say you're showing the results of a fluid dynamics simulation, or temperature map or whatever. The alternatives are still maps with time indices in the caption, or an animated plot of the time evolution?
Which is easier to understand? Which provides more detail? The animation.
Multivariate data
A static image is 2d. An animation gives you a third axis of time to use, making for simpler plots.
And so on and so on..
I for one am the first to admit I don't quite get all this 'patents are evil' that seems to come from Slashdot articles.
It's not all patents, just software patents. It's debatable, but most programmers and OSS advocates are against software patents. Lots of info is available if you want to see where they're coming from.
A quick cursory overview of the patent link on IBM's patent doesn't say one thing about the GIF format, just the compression algorithm
No it doesn't. It covers the LZW algorithm. The most significant use of that algorithm today is in the GIF image format. It has been supplanted by better algorithms for general compression use.
Just seems silly to 'call out' a company to release a patent.
Not so silly, the patent is likely worthless since the same algorithm had already been patented by Unisys, and IBM probably knows it.
(Although, as noted, it didn't stop them from throwing it into the mix against SCO, but then, why not? Additional counterclaims are cheap)
but client-server apps are not the same thing. i am sure that downloading pirate-sw has increased very very much when p2p came around.
And the Internet is not the same thing as the US Postal Service.
I am sure that people sending kiddie-porn to eachother has increased very very much since the internet came around.
Ergo: Ban the Internet?
when was the last time you saw an useful gif animation?
The last time I gave a presentation.
I can't bet on which platform (linux/windows/mac) the lecture hall computer has, or if it has flash or whatever codec installed, and I need the animation to 'just work'.
With gif animations, any machine with a browser will do.
If you can tell me which format I can use which will work on stock Linux, Windows and Mac systems without downloading or installing anything, I'm all ears.
I didn't write I needed them for web design.
There ARE other things being produced on computers than just web pages.
If want to know exactly: Animations of calculated molecular vibrational modes.
It is simply far more effective to show someone an animation of a vibration than to try to illustrate it with 'motion arrows' and such.
I really doubt IBM is going to go after anybody.
Unisys was collecting money on GIF licenses for years, if IBM wanted to capitalize on this, they would've sued Unisys back then.
Besides that, there is good reason: It is, by all accounts I've read, the same algorithm.
The Unisys LZW patent had even been granted before the IBM patent had been applied. It had priority by a mile. The IBM patent is simply worthless.
Developers shouldn't concern themselves with bogus patents. I for one have written programs which save GIF files, and although I respect(ed) the Unisys patent, I'm not at all worried about the IBM one.
How about:
Because some of us need a format for simple animations which can be viewed on any machine without the hassle of installing software or codecs to use?
There is simply no other option in that niche.
Trade secrets have no protection at all except by explicit contract. None.
Right. But Microsoft and most others put explicit trade-secret clauses in their employment contracts.
APIs are inherently nothing more than a logical framework. One does not reverse engineer them. One discovers them.
That wouldn't really be in tune with the more common definition of reverse-engineering. Reverse-engineering would typically entail using a decompiler/disassembler/debugger to figure out the inner workings of a program, and then writing a specification from that.
Yes, the actual implementation is the clean-room part, but that's ordinary forward-engineering from a specification, not reverse-engineering. H
owever, the person who did the reverse-engineering has seen the other guy's code, and is therefore not clean anymore.
It's simpler than that. You don't even need a clean room to simply describe something, even patented and licensed somethings.
No you don't, but you need to know what it is you are describing.
I was thinking along the lines of (say) of undocumented Windows APIs.
Leaving anti-trust issues aside, and just assuming that these undocumented APIs had trade-secret status, a Microsoft employee could not publish them without consent from MS. And everyone else couldn't 'just know' what they were.
So you'd then have to reverse-engineer them, and to do so legally, not use any priviliged information. And indeed, it's been done, without MS being able to do anything about it.
Auto parts is no problem, they're protected by patents as you noted, and patents are a stronger form of protection:
There is no economic threat in having all information public (indeed patent applications are public), because noone else is allowed to make or use the part (for the given purpose) without license.
Popular misconception on Slashdot.
I don't like the DMCA, but you should read exactly what it prohibits.
The DMCA prohibits "circumvention of copyright protection systems". No matter how you look at it, that's a very different thing from a general ban on reverse-engineering.
The most draconian interpretation possible is to assume that it prohibits reverse-engineering of copyright protection measures. But that's it. And it explicitly allows circumvention for interoperability purposes.
Without getting farther into the issue, an API cannot reasonably be interpreted as a copyright protection measure. And reverse-engineering isn't necessarily circumvention.
So it's really not an issue at all in this case.
How did this seriously strange view of IP law get modded up?
You don't need permission from anybody to publish an API. There is no special copyright law covering API specifications.
Perhaps you are thinking of trade-secret status?
Well, if something has been publicly published, it doesn't doesn't get trade-secret status. And that goes even if they put some silly 'license' on their documentation.
(See for instance the BSDi case, where the Unix sources were found not to have trade-secret status without even being public, but simply because they had been seen by so many people. And that is despite the fact that they even had written agreements with all of them.)
You don't have to get a license to publish an original book on anything, ever.
Do you know what a license is? A license is permission from a rights-holder to exercise an otherwise exclusive right.
For copyright, that means performing, reproducing and creating derivatives of copyrighted material.
For patents, that means the right to manufacture and use the invention.
For trade-secrets, that means the right to divulge and use commercially the trade secret.
Now, if I chose not to publish my API secret, then it may be a trade-secret, in which case you may not have the right to publish it if you happen to be 'in' on it. APIs can however be reverse-engineered. You can reverse-engineer an API without any trade-secret knowledge (i.e. 'clean-room') and publish that, that is perfectly legal.
Perhaps you think that the API itself can be copyrighted, and that a description of the API is a derivative work? Well, that's a theory, but very dubious legally.
Under copyright law, code is separated into the "expressional" and "functional" parts, and APIs reasonably always fall into the latter part, and are therefore not copyrightable. In case law, good room is generally given for compatibility code, being functional. (Again, you can see the BSDi case, where it was found that header files describing the same Unix API were not infringing)
If the API itself is not copyrighted, something which has yet to be seen, the description of the API cannot be a derivative work.
Naturally, the description itself can be copyrighted, including the official description, (e.g. the API specification) but anyone can write their own description.
Excuse me, you're not talking about "some security firm" here, you're talking about The RAND Corporation.
RAND was formed by the Air Force back during the cold war. Did a lot of development of game theory. John Nash ('A beautiful mind') worked there.
Infamous back in the 60's for their game-theoretical approach to nuclear war scenarios.
Giving rise to the following satirical ditty by Malvina Reynolds:
More on RAND.
I suppose you get the picture. Like them or not, RAND is and has been the most influential defense think-tank in the world, and shaped a large part of US defense policy.
Calling them "some security firm" is a bit of an understatement in that light.
Yup.. people need GUIs nowadays. On the other hand, you don't have to be a grad student to use them.
(Figuratively and literally)
So?