The first integrated circuit. That would deserve a patent. Since then?
Intel doesn't have any patents on the specific circuit designs of a CPU, just certain additions and implementations of it (such as redundant CPU cores and whatnot). When you get down to it, an Intel x86 chip isn't vastly different from an AMD x86 chip, which isn't much different from an ARM chip. They're all basically the same thing.
And you could say the same thing about algorithms. They're all basically the same thing.
Look at recent Intel patents. None of them have anything to do with the current build of their processors. I don't even think their tri-gate transistors, which is their most recent innovation, is patent pending. They're all about materials used, or manufacturing processes.
I don't deny the fact that Creative was a total douche about it, and if there was prior art surrounding their shadow algorithm the patent should never have been granted in the first place.
That said, as the article stated Carmack's algorithm was not their algorithm. They were different algorithm's that accomplished the same thing. As I said earlier, he wanted to use their algorithm not his, and if you implement someone else's design they deserve to be paid for their work.
First of all, if his algorithm wasn't their algorithm, then that means they had a patent for the end result, which, as a programmer, you should be greatly against.
Second, he had no other choice in the matter. It wasn't a choice between him preferring their implementation of depth fail stencils, they were the same thing, it was that he had two choices.
Use a different, not nearly as efficient method (which was eventually used for the source code release).
Or
Accept their offer to use EAX to avoid a lawsuit.
I don't know where you're getting that he preferred Creative's method over his.
I fail to see how someone can accidentally or unknowingly implement a complex algorithm. It's not like you can change 5 lines of code and have a new compression scheme. If you are working at that level you know that you're on the bleeding edge. If you plan on selling your invention, as with hardware you should ensure you aren't stepping on others toes before you bring it to market. That's just common sense.
An algorithm as complex as a data compression scheme is better protected by copyright, since...like you said...you can't go in and change 5 lines and get something entirely new.
Anyone who wants to do a better compression scheme will have to start from scratch, and write all the code themselves from the bottom up. So with that in mind...why patent it? Why not just rely on copyright protection, which keeps people from looking at your source code and copying it for their own use? That's exactly what you want, right?
Like I said, software patents ultimately confuse the issue. No matter how much effort you put into your due diligence, if you make something that even remotely looks like someone else's patent, they'll have you in court proving that it's not the moment they first lay eyes on it. That costs money. A lot of it. Money most freelancers don't have.
With your suggestion garage programmers will disappear. Since you'd have no protection legally how are you going to convince an investor to back you or sell it to a company that can make use of it? You can't tell them how it works or they (corporations) will take their staff, reverse engineer your algorithm and steal it. Why bother paying royalties for something you can rip off without any legal ramifications?
Software developers managed to get by just fine before software patents become a thing in the 90's, and the EU doesn't allow software patents at all. Your copyrighted material, from the code itself to the graphics you use in your program, is more than enough to protect yourself from moochers.
Plus, unless you're working on an FOSS project, what are the chances of someone seeing your source code and ripping it off? If you make a successful program, someone would have to reverse engineer your work to make something similar, and chances are good their final product will be a great deal different than yours while still performing the same function. Which is totally legal.
If their product ends up being better than yours, well...that's life. You'll have to do something better yourself to keep ahead of the Jonses. If it's not, you still have the better piece of software, and you'll still make money off your hard work because of that.
But in a software patented world, you could still sue them because their end result looks similar to your end result, which costs both parties a ton of money. If you're a big corporation, that's not a big deal. If you're a little guy with a great idea, you're kinda screwed.
To be frank I don't know what the right solution is. You can't throw away software patents without creating a host of other problems. Startup's cannot thrive with backing, no protection against theft from those with more resources, and it would breed a world of programmers who wouldn't talk to one another out of fear (bye bye Open Source).
Too much protection and you end up with the mess we have now. Obviously a lot of the software patents you see in these cases should never have been granted in the first place. It could be lack of knowledge, lack of technical resources, I'm not sure.
The answer must lie somewhere in the middle. Hopefully someone can figure out a solution that works for both sides!
There isn't an easy answer, no. I personally believe everyone should be compensated for their hard work, and programming is definitely not an easy thing to do. But I also believe that people should only own their very specific implementation, not a generalized process of something that produces a specific output. The latter is something the patent system in its current state allows to let happen. And that, more than anything, will kill innovation.
