Exactly. Another case study of this would be the NTFS filesystem drivers for Linux. Unlike the Windows API, both the NTFS binary specification and the NTFS filesystem algorithms do not have official public documentation. Yet there are multiple NTFS drivers for Linux. The developers of these drivers had to observe an NTFS partition, and even profile and trace the actions of programs on the binary state of the filesystem, and developed their own specs of what they thought NTFS did. This is a rather remarkable feat of reverse engineering that Microsoft cannot legally do anything about.
The PC BIOS case is probably the textbook example of reverse engineering done correctly. The main place where reverse engineering can fail is in copyright violations of the implementations. Developing and publishing the specification - which is the hardest part! - is completely legal. However, if you take anything from the original implementation and use it in the new implementation, the new implementation is considered a derived work and cannot legally be distributed without violating copyright. There are some gray areas where things can be problematic, particularly if source code was visible to anyone doing the reverse engineering, so the safest route is to follow "clean room" procedures as described by the parent. Strictly speaking, that shouldn't be necessary, but it is used to ensure that there can be no question that your implementation is legal.
As I mentioned in my previous post, patents can throw a monkey wrench into things though. Patented algorithms are still patented even if you develop your own completely independent implementation. This is why the GIF image format, despite having a well-known specification, could not legally be reverse engineered until recently because it depended on a patented algorithm.
Uh, dude. Reverse engineering is not illegal, at least in the United States. What's illegal is copying and distributing nontrivial parts of the source or binary of a program, hence "copy"right. Reverse engineering is figuring out how a program (or any other technology) works and doing something with that information. Including writing your own implementation that does the exact same thing. Companies don't like others reverse engineering their stuff, and many EULAs forbid it. Legality of EULAs aside, I'm pretty sure that can't be enforced in the USA due to laws that expressly permit reverse engineering.
The DMCA does introduce some issues since circumvention of a copy protection device becomes a crime, but that didn't happen here. Patents can also create huge problems for reverse engineering, but that doesn't apply here.
It's almost impossible to write some kinds of applications WITHOUT using open source software. I'm particularly thinking of geospatial applications, 90% of which depend on the same four libraries: GDAL, OGR, Proj4, and Xerces-C. Similarly, things like Bzip2 and Zlib are a godsend. My company is very decentralized, so I don't know about our open source policy as a whole, but my own group is very open source friendly - we can't compete with the big boys in the industry without it!
The basic policy we follow is: No GPL code unless you can execute it as a separate process. LGPL, BSD, and MPL are fine. Anything else, we need to have multiple people check.
The main thing I hate is when people make library code GPL for no good reason, like the MySQL driver. Royal pain in the ass for people like us who do government contracting. Which is why we use PostgreSQL as our database backend instead.
Anyone who's done some work on a real-world simulation of any kind will recognize just how hard they are to do at all, much less realistically. Even simple tasks like "Can person A see person B" have funded 6 months of work by themselves, to use my current project as an example. Other tasks - like determining the course of a bullet, or where the kill zone of an explosion is when a bomb is detonated in a building - are harder. If you go for ultimate realism by allowing deformable terrain and destroyable buildings that operate according to physical laws, it just gets insane. Reuse is pretty much nonexistent, too, because everyone does such a craptastic job of their algorithms or their interface.
Military simulations are especially fun because most large military contractors don't give a damn about research or improving their technology, but rather just milking the cash cow that is the U.S. government. Projects go on for YEARS longer than they should because the contractor doesn't bother to do what they promised, but the military project leaders can't afford to admit to their superiors that the project was a failure, and their superiors aren't technically savvy enough to figure it out. The smaller contractors are better in terms of their commitment to research and actually improving the technology, but they don't have the resources or the marketing to actually have any real influence.
U.S. Army: "Hey, this simulation doesn't do X and Y correctly, and doesn't do Z at all, despite what you promised, and it's already two years late."
Contractor: "Oh, it's not a big deal, just give us more money and we'll take care of it."
U.S. Army: "It's alright, we understand, here you go. Make us proud!"
When the military actually gets ANY simulation into production that actually does what it was supposed to do, that's pretty impressive by itself. If the technology isn't over four years old or does something that's not found in commercial games, that's almost unheard of.
The punchline is that it would be a miracle for this game to offer anything above and beyond existing FPS games.
You might be surprised about interoperability. I work for a government contractor and we have a geographic information system that communicates geospatial data over CORBA between Java / JacORB, Java / Sun ORB, and C++ / TAO - mix and match Linux and Windows however you like. Say what you want about it, it does in fact work correctly.
Of course, there's a lot of other problems with CORBA. Tossing raw data across the sockets or using and extending some existing geospatial protocol would have saved us all the time that the CORBA learning curve cost us. Developing against CORBA was a nightmare, and only two members of our team even understand what we implemented. We STILL don't have an idea of the most efficient ways to cache and represent the data from our CORBA objects, and our software's memory footprint on both the Java and C++ side suffers from it. Yes, I know the network is supposed to be transparent in CORBA, but when you're working with millions of points, lines, and polygons with full data model attribution, along with high-resolution elevation maps and visual satellite imagery, you actually DO care where the data is. And that's probably the biggest problem with things like CORBA in our line of work. It's impossible to ignore the network: the physical location of the object is important.
Beyond that, there are also a host of smaller annoyances - for example, as much as I hate the STL (another lovely example of a design-by-committee standard, sigh), the CORBA C++ binding's lack of STL integration for its sequences and strings is extremely frustrating for interoperability with existing C++ code.
The implementations are also not that great. In fact, Sun's implementation is downright terrible. JacORB isn't quite so bad, but is ridiculously annoying to install and configure. When TAO works, it's great. But good luck even compiling the latest TAO on multiple platforms - that took me over two days to get right. It also issues about 50 bajillion compiler warnings when compiling IDL-generated C++ files and confuses the hell out of our memory leak checker. And at one point, the version we used had known memory leaks involving sequences and strings - not sure if that's been fixed since then.
I keep on hoping we can abstract out the CORBA layer so that someday I can justify replacing it with something easier to understand, maintain, and cache. We actually tried SOAP before CORBA, but if you've used SOAP before, you can imagine how quickly it fell apart under our data loads. Extremely large volumes of floating-point data is not your friend in XML.:-)
While I agree with most of the rest what you pointed out, the last bit about some of the institutions might not be quite the way you think it is... try talking with someone from MIT or CalTech, for example. The professors there are extremely brilliant researchers, but I'm told that a significant number of them are either unwilling or unable to pass that on to their students.
I've heard CalTech's physics department is in trouble because of it - the professors are starting to get old, and they're having trouble finding good enough people to replace them. MIT's recent drive to be more "diverse" has hurt them a lot. My school, the University of Central Florida, often beats them in CS competitions, for example. NASA, of course, has its own share of problems that have been thoroughly addressed elsewhere.
And if you look at international math and science competitions, US universities almost never place in the top 10. It's usually either some academies in China, the University of Kyoto in Japan, or somewhere Russian. So I'd be careful before putting too much faith in institutions. Doesn't mean everything scientific is going to hell, but those are not necessarily good examples.
Just my $0.02
I've lived in Orlando my entire life, just graduated from the local university, and even like to think I'm pretty familiar with local politics... and I've never heard of this before. Neither has anyone I know. If they wanted the people to actually use this service, it might help if the people knew about it.
The PC BIOS case is probably the textbook example of reverse engineering done correctly. The main place where reverse engineering can fail is in copyright violations of the implementations. Developing and publishing the specification - which is the hardest part! - is completely legal. However, if you take anything from the original implementation and use it in the new implementation, the new implementation is considered a derived work and cannot legally be distributed without violating copyright. There are some gray areas where things can be problematic, particularly if source code was visible to anyone doing the reverse engineering, so the safest route is to follow "clean room" procedures as described by the parent. Strictly speaking, that shouldn't be necessary, but it is used to ensure that there can be no question that your implementation is legal.
As I mentioned in my previous post, patents can throw a monkey wrench into things though. Patented algorithms are still patented even if you develop your own completely independent implementation. This is why the GIF image format, despite having a well-known specification, could not legally be reverse engineered until recently because it depended on a patented algorithm.
The DMCA does introduce some issues since circumvention of a copy protection device becomes a crime, but that didn't happen here. Patents can also create huge problems for reverse engineering, but that doesn't apply here.
Case study: http://www.winehq.com/
If reverse engineering were illegal, don't you think Microsoft would come down on them like a ton of bricks?
It's almost impossible to write some kinds of applications WITHOUT using open source software. I'm particularly thinking of geospatial applications, 90% of which depend on the same four libraries: GDAL, OGR, Proj4, and Xerces-C. Similarly, things like Bzip2 and Zlib are a godsend. My company is very decentralized, so I don't know about our open source policy as a whole, but my own group is very open source friendly - we can't compete with the big boys in the industry without it! The basic policy we follow is: No GPL code unless you can execute it as a separate process. LGPL, BSD, and MPL are fine. Anything else, we need to have multiple people check. The main thing I hate is when people make library code GPL for no good reason, like the MySQL driver. Royal pain in the ass for people like us who do government contracting. Which is why we use PostgreSQL as our database backend instead.
Anyone who's done some work on a real-world simulation of any kind will recognize just how hard they are to do at all, much less realistically. Even simple tasks like "Can person A see person B" have funded 6 months of work by themselves, to use my current project as an example. Other tasks - like determining the course of a bullet, or where the kill zone of an explosion is when a bomb is detonated in a building - are harder. If you go for ultimate realism by allowing deformable terrain and destroyable buildings that operate according to physical laws, it just gets insane. Reuse is pretty much nonexistent, too, because everyone does such a craptastic job of their algorithms or their interface. Military simulations are especially fun because most large military contractors don't give a damn about research or improving their technology, but rather just milking the cash cow that is the U.S. government. Projects go on for YEARS longer than they should because the contractor doesn't bother to do what they promised, but the military project leaders can't afford to admit to their superiors that the project was a failure, and their superiors aren't technically savvy enough to figure it out. The smaller contractors are better in terms of their commitment to research and actually improving the technology, but they don't have the resources or the marketing to actually have any real influence. U.S. Army: "Hey, this simulation doesn't do X and Y correctly, and doesn't do Z at all, despite what you promised, and it's already two years late." Contractor: "Oh, it's not a big deal, just give us more money and we'll take care of it." U.S. Army: "It's alright, we understand, here you go. Make us proud!" When the military actually gets ANY simulation into production that actually does what it was supposed to do, that's pretty impressive by itself. If the technology isn't over four years old or does something that's not found in commercial games, that's almost unheard of. The punchline is that it would be a miracle for this game to offer anything above and beyond existing FPS games.
You might be surprised about interoperability. I work for a government contractor and we have a geographic information system that communicates geospatial data over CORBA between Java / JacORB, Java / Sun ORB, and C++ / TAO - mix and match Linux and Windows however you like. Say what you want about it, it does in fact work correctly.
Of course, there's a lot of other problems with CORBA. Tossing raw data across the sockets or using and extending some existing geospatial protocol would have saved us all the time that the CORBA learning curve cost us. Developing against CORBA was a nightmare, and only two members of our team even understand what we implemented. We STILL don't have an idea of the most efficient ways to cache and represent the data from our CORBA objects, and our software's memory footprint on both the Java and C++ side suffers from it. Yes, I know the network is supposed to be transparent in CORBA, but when you're working with millions of points, lines, and polygons with full data model attribution, along with high-resolution elevation maps and visual satellite imagery, you actually DO care where the data is. And that's probably the biggest problem with things like CORBA in our line of work. It's impossible to ignore the network: the physical location of the object is important.
Beyond that, there are also a host of smaller annoyances - for example, as much as I hate the STL (another lovely example of a design-by-committee standard, sigh), the CORBA C++ binding's lack of STL integration for its sequences and strings is extremely frustrating for interoperability with existing C++ code.
The implementations are also not that great. In fact, Sun's implementation is downright terrible. JacORB isn't quite so bad, but is ridiculously annoying to install and configure. When TAO works, it's great. But good luck even compiling the latest TAO on multiple platforms - that took me over two days to get right. It also issues about 50 bajillion compiler warnings when compiling IDL-generated C++ files and confuses the hell out of our memory leak checker. And at one point, the version we used had known memory leaks involving sequences and strings - not sure if that's been fixed since then.
I keep on hoping we can abstract out the CORBA layer so that someday I can justify replacing it with something easier to understand, maintain, and cache. We actually tried SOAP before CORBA, but if you've used SOAP before, you can imagine how quickly it fell apart under our data loads. Extremely large volumes of floating-point data is not your friend in XML. :-)
While I agree with most of the rest what you pointed out, the last bit about some of the institutions might not be quite the way you think it is... try talking with someone from MIT or CalTech, for example. The professors there are extremely brilliant researchers, but I'm told that a significant number of them are either unwilling or unable to pass that on to their students. I've heard CalTech's physics department is in trouble because of it - the professors are starting to get old, and they're having trouble finding good enough people to replace them. MIT's recent drive to be more "diverse" has hurt them a lot. My school, the University of Central Florida, often beats them in CS competitions, for example. NASA, of course, has its own share of problems that have been thoroughly addressed elsewhere. And if you look at international math and science competitions, US universities almost never place in the top 10. It's usually either some academies in China, the University of Kyoto in Japan, or somewhere Russian. So I'd be careful before putting too much faith in institutions. Doesn't mean everything scientific is going to hell, but those are not necessarily good examples. Just my $0.02
I've lived in Orlando my entire life, just graduated from the local university, and even like to think I'm pretty familiar with local politics... and I've never heard of this before. Neither has anyone I know. If they wanted the people to actually use this service, it might help if the people knew about it.