RC2 is a 64-bit block cipher developed by Ron Rivest. It was originally a trade secret of RSA Data Security, Inc, but code was leaked on Usenet in the mid-90s. It was thought that this code was reverse-engineered from one of RSA's commercial crypto libraries, meaning the person(s) who did it were probably not under NDA (ie, it was legally done). For a while, RSA refused to either confirm or deny that this source code was an implementation of their RC2 algorithm, but several people with access to RSA's libraries confirmed that it did act exactly like the official RC2 code. Around 1998, RSA finally admitted that this code was RC2, ending completely RC2's trade secret status.
RC2 is an interesting algorithm, and does several things completely unlike most modern block ciphers. For one thing, it was described in RSA's documentation as a "mix and mash" cipher (which is of course not a particularly clear description), and that it did not use S-boxes (making it, they claimed, immune to differential cryptanalysis).
The 64-bit input is split into 4 16 bit words, R0, R1, R2, and R3, and is then run through a number of rounds of mixing, with the occasional bit of mash thrown in. Seriously, there are 16 rounds of mix, and an application of mash after the 5th and 11th rounds.
The mix operation adds to each word a combination of the other data words and a single sub-key word. The mash operation chooses 4 "random" sub-keys based on the value of the current data words, and adds them to the data words. The dependence on the data words for choosing the sub-key is why the mash operation is only used after a number of the encryption rounds have passed - if they were used any earlier in the encryption process, an attacker could guess bits of the data words, and thus which key word would be used in the mash round.
The actual operations are as follows. The round_no variable represents the round number, indexed from 0, and K is the array of 64 sub-keys.
mix(R0,R1,R2,R3,round_no)
R0 += (R1 & ~R3) + (R2 & R3) + K[4*round_no]
R0 = rotate_left(R0, 1);
R1 += (R2 & ~R0) + (R3 & R0) + K[4*round_no+1]
R1 = rotate_left(R1, 2);
R2 += (R3 & ~R1) + (R0 & R1) + K[4*round_no+2]
R2 = rotate_left(R2, 3);
R3 += (R0 & ~R2) + (R1 & R2) + K[4*round_no+3]
R3 = rotate_left(R3, 5);
mash(R0,R1,R2,R3)
R0 += K[R3 % 64]
R1 += K[R0 % 64]
R2 += K[R1 % 64]
R3 += K[R2 % 64]
RC2's key schedule has an odd ability to limit the strength of the input key. For example, it might accept a 128-bit key, but limit the actual entropy to only 40 bits. This was to make it easier to export the cipher under the (then-existing) U.S. export laws regarding crypto. This is quite unique - no other cipher I've ever seen supports this ability. In particular, there are some well-accepted techniques for doing this that don't require any special help from the key schedule, and it's unclear why Dr. Rivest felt RC2 should have the ability built-in.
RC2 really isn't terribly popular, primarily because by the time the specification of RC2 was public, several better ciphers (Blowfish, CAST-128, 3DES, SAFER, and Square, among others) were already available for public use. There is support for using it in SSL/TLS and in S/MIME (generally in the form of 40-bit keys), and that's about it. This is mostly because the SSL and S/MIME groups were influenced by RSA DSI, either directly (S/MIME is an PKCS standard) or indirectly (Netscape used RSA's crypto libraries in their initial SSL implementations).