Perhaps not creative, but wayyyyy back in the 80's, Atari games on floppy could be protected by a sector on the floppy that couldn't be read. If you tried to copy the disk, it'd fail at that one.
The Atari "dual density" disk drives (1050's) had a dial (maybe a potentiometer) to adjust the speed. A friend of mine sawed a door on the top of the case so he could get to it. With that and some custom software these could be copied.
The software would detect the bad sector, alert the user, the user could slow down the drive to "ridiculous (slow) speed", the software would write a "good" sector at later unreadable speeds, then alert the user again to speed the drive back up to normal speed. If memory serves, the software had a disk speed check with it, just for this purpose.
Typically, floppy disks and other magnetic media use some kind of encoding system, rather than write 1s and 0s directly to the physical media. This encoding system serves multiple purposes, but mostly clock synchronization and error detection. If you put garbage data on the actual track, you'll get an error when you try to read it because it has an invalid encoding.
Imagine that I handed you a piece of paper and asked you to tell me which letters were written on it, but the paper just had a bunch of squiggles on it. You'd tell me that there aren't any letters written on it, just squiggles. That's what it's like.
Yes, but there is no data on the deliberately bad sector that the game really needs - it just reads it to see if it can (and if it gets data back but no error it will assume it is a pirated copy on a "clean" disk. The bad sector has to be part of a particular file too, so you can't just corrupt track-60-sectors-2-through-4 without also making sure "checkf.ile" is using those sectors (not a given if you do a file based copy instead of a full volume copy) or doctoring the disk will corrupt data that the game does need.
As well as being a test, if the deliberately bad block/track is not at the end of the media it would defeat the simplest copying techniques (simply copying the disk) as most basic disk copy utilities would stop at the bad block.
Other ways to defeat naive copying exist too that don't need tweaks to the physical media, which were often used in conjunction with the physical method. Examples include having a "corrupt" directory entry that referred to itself or a file with an apparent size larger than the disk, both of which would breaking simple file based full disk copying and allow the game to test its environment - if it doesn't see the deliberately bad directory entries it knows the disk is not an original. Depending on the target system other filestytem tricks are possible like bad file allocation table entries on FAT12 formatted disks. You needed to be careful to not do anything that the OS would throw up as an error or try to fix (keeping the disk read-only protects this to an extent) but the OS was fairly dim back then so that wasn't a big issue.
None of these "soft" methods would stop anyone who knew what they were doing of course, but they would block the man-on-the-street from simply being able to copy that floppy with "COPY A:. B:" or "XCOPY A:. B: /S/E" or equivalents.
One way is to arrange things such that the read doesn't fail but is non-deterministic. The game reads the same dodgy disk sector multiple times, and checks that the results are not the same on every read. A normal disk copy will read that sector once from the target disk and write the result to the destination disk. Any reads from the destination disk will be deterministic, and trigger the copy protection.
I got hit by the batman one back in the day. I still don't know how they figured it out. I have a modified xbox with a k3y (hardware dvd drive emulator that is fixed inline behind the real dvd drive) and while I've never been banned from xbox live I was never able to complete that level.
Settlers III sort of worked when the copy protection check failed, but messed with production of some buildings and stuff like that. So you could start a game, just to be confused why your iron smelters suddenly produced pigs instead of iron bars.
I guess it would've been too big to put it in that post, but my favourite DRM approach has gotta be for Spyro 3 YOTD on PS1. The anti-reversing tricks the developers used had hackers stumped for over two months trying to crack it. There's a great writeup on Gamasutra:
This brings back happy memories of reading +fravia's reverse engineering pages, and cracking protection on PC-games myself, for educational purposes.
Some of my earliest programming was z80 disassembly and patching of games to get infinite lives on the ZX Spectrum, so it's a topic I've a reasonable history with.
If you're sued, I believe it would have to be for unauthorized distribution (as with BitTorrent), not just downloading a pirated copy. So you would have to somehow argue that your distribution was fair use, which probably won't fly.
The original physical release of the indie game Uplink came with old school copy protection codes printed in black on black paper (the text was glossy, the background matte). I think the hex matrix containing the codes doubled as a clue in a clever "hacker challenge" style easter egg.
The 1999 strategy game The Settlers 3 would appear to work fine, but the iron smelters would produce pigs rather than iron bars, so you couldn't make any new tools or weapons.
The Atari "dual density" disk drives (1050's) had a dial (maybe a potentiometer) to adjust the speed. A friend of mine sawed a door on the top of the case so he could get to it. With that and some custom software these could be copied.
The software would detect the bad sector, alert the user, the user could slow down the drive to "ridiculous (slow) speed", the software would write a "good" sector at later unreadable speeds, then alert the user again to speed the drive back up to normal speed. If memory serves, the software had a disk speed check with it, just for this purpose.