Where did you hear that there is no native support for PDF's?
You can easily load PDF's to the Kindle.
These are not equivalent. "Native" support means that you could put a .pdf file directly on the Kindle (via USB), and the Kindle would be able to open it. What the Kindle actually does is, you can email a .pdf document to firstname.lastname@example.org, and Amazon's software will attempt to reflow and convert the .pdf document into .azw format. The Kindle does NOT support .pdf natively.
This python script creates a hash to make the Kindle think that .mobi files (Secure Mobipocket books, a competitor of Amazon's for this market) are native Amazon books. After you get a hash from kindlepid.py, you run kindlefix.py on your .mobi file with your hash, and it produces a .azw file which the Kindle then thinks is one of its own book formats.
This is incorrect in several ways. First, the non-DRMed .azw format is almost exactly the same as the non-DRMed .mobi format. It simply has a different extension. The encryption used for DRM may be different, but the Kindle is certainly capable of opening DRMed .mobi files natively. You can bet that Amazon is paying a licensing fee to Mobipocket.
Now, here's how mobipocket DRM works. Your device (Kindle, Bookeen, etc.) has a unique ID number. When you buy an ebook from a site (ie. Fictionwise), you input this ID which is then incorporated into the encryption of the file. Thus, that device will be able to open that file. Any file can be viewed by up to 6 different devices. For most devices, the ID is known to the user. With the Kindle and Amazon, all of the above is handled automatically, so the user does not NEED to know the ID when buying from Amazon.
The script in question, kindlepid.py, simply reads the ID number of the Kindle in question and prints it out for the user. It's worth noting that the official Mobipocket Desktop software version 6.0 could also do this, at least for the Kindle v1.
Now, using the ID, it is possible to buy encrypted .mobi ebooks from other vendors (ie. Fictionwise) with the Kindle added as an "approved" device. The Kindle can read these files, but won't unless a "read-approval" bit is flipped in the file. This can be done by a second script, kindlefix.py.
What's curious and kind of ridiculous about this situation is that if either of these scripts is circumventing DRM, it would be the second script, kindlefix. However, the DMCA takedown notice apparently targeted the FIRST script, kindlepid, which only prints information that you could already get using official Mobipocket software. That's why Amazon's whole approach in this case seems ridiculous at best.
In any case, I think that from Mobileread's point of view this was probably the best response.