In 802.11b circles, WEP stands for Wired Equivalent Privacy. It provides an encryption mechanism for wireless ethernet which, if its name were to be believed, would provide security equivalent to what you would get with traditional ethernet cable.
Now, first off, it's important to remember that a regular cat5 ethernet cable doesn't exactly give you stellar security. Anyone hooked up to your LAN over regular ethernet (assuming nothing complicated like switches or routers are in the way) can, by operating a packet sniffer see all the traffic going to or from your system, and if that traffic happens to be in plaintext, well, sucks to be you. But what cat5 DOES guarantee you is that some random Joe in the parking lot probably can't get anything useful out of your LAN, since random Joe probably doesn't have a great big ethernet cable running from your LAN to his SUV. The idea behind WEP is that you get that level of security - other people on the network can probably see your traffic, but Joe cannot. Sounds fair enough right? At least it's not a gargantuan step backwards, right?
Wrong. In practice, WEP is a horrible little protocol with glaring errors all over the place. The first problem is that it's often not even turned on. A lot of 802.11b setups will just let anyone in broadcast range have access because it's easier that way. WEP cannot be blamed for this though. What WEP can be blamed for is using RC4, with plaintext Initialization Vectors, and in almost all cases long key periods.
See, RC4 is an encryption protocol that, for better or for worse, works by taking a key you give it, generating a stream of pseudo-random bits from it, and XORing that with the plaintext. That's not so bad in principle, especially with rapidly changing keys, but guess what WEP doesn't have? That's right kiddies, many WEP setups, in actuality, have manually entered keys (which, knowing humanity, are never going to get updated) and worse, many use a single key for all users on the system. This, as any cryptographer will tell you, means that an eavesdropper doesn't have to wait long to build up enough data on these pseudo-random bits to read all the traffic going across the ether, but it gets worse.
Because of how RC4 works, it is possible to interfere with legitimate, encrypted packets and make predictable changes once they are decrypted. In essence, I can take an encrypted packet you sent and flip certain bits - when that packet is decrypted, the corresponding plaintext bits will be flipped - if you can't think of something fun to do, given the ability to flip arbitrary bits of outgoing packets (say... the bits that store the destination IP of some email or password data) then you're not thinking hard enough.
The clever WEP people anticipated this attack actually, and included a checksum to verify that the packet hadn't been tampered with. They used CRC-32 - a very well known checksum algorithm, with just one little problem - if you flip a bit of the input text, predictable bits of the checksum flip. Argh! This means that I can tamper with your packet, and then ALSO tamper with the checksum, to make the tamperings look legitimate.
The clever WEP people also anticipated the problem of the stagnant key mentioned above, believe it or not. They solved it by taking the key, which they pretty much admit is going to just sit and get stale, and glueing on a 24-bit Initialization Vector (IV). The practice of taking a stable thing, and gluing on a random number, in order to make key guessing harder, is pretty standard. But 24-bits is a relatively small piece to glue on, and what's terribly, terribly worse: they broadcast the IV in *plaintext*. Imagine you and a friend agree to a secret passphrase but, fearing that it may be comprimised, you and your friend agree to an additional secondary passphrase which you shout out to everyone listening. Your friend would be right to ridicule you and beat you with his shoe. It means that, in what experts estimate at about 5 hours, you could capture enough encrypted data to build up a dictionary of every possible bitstream (that is, the bitstream generated by secret + EVERY 24-bit IV), and thereby, without knowing the key, still read every packet that passed your antenna.
I have glossed heinously over important cryptographic details here to an extent that should make any cypherpunk twitch and froth at the mouth. This is partly because the entry was getting too long, partly because I didn't want to give a more precise rendering and then get something wrong, but mostly because there is already an excellent site with more detailed information. It's at http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html and was the source for some of what was said here.