Actually Cisco outsourced the old linksys Linux stuff to a taiwanese company after the first lawsuit, washed their hands of Linux, and switched the Linksys router line to using some other embedded OS. (PNX? I forget.)
They had just taken Linux development back in-house for new routers (like the WRT610n) that had the capability to do a lot more in software. The guys in taiwan had monkey-patched the old broadcom build system into a horrible mess, all the package versions were 5 years old, and they were creating a while new build system (code-names "Bruschetta" and "Prosciutto" for minor variants of the same thing), and the new one came with a whole open source methodology they were setting up with public websites and participation on public lists and engagement in the community and a dedicated code auditing period between GM and actual production where the developers did NOTHING but confirm source versions and license info and ship the _source_ before shipping the _product_.
And then the FSF came in sock-puppeted the SFLC to go "you know that thing you outsourced to Taiwan after the first lawsuit, and haven't touched in 5 years, which the entire new development effort is aimed at obsoleting and replacing with current vanilla versions of everything? We're suing you over it AGAIN!"
And senior management went "Open Source is Not To Be Trusted", killed off the new in-house Linux effort, and outsourced support of existing WRT610n units to... Red Hat, I think.
The toolchain the FSF was suing over was A) from 2003 or so (gcc 3.2.3, binutils 184.108.40.206, linux-2.4.20, glibc-2.2.5. In 2008), B) from broadcom (cisco never had the source), C) a generic mips toolchain for a 5 year old hardware architecture. I'm fairly certain a toolchain built from all the vanilla sources would have happily worked as a drop-in replacement, but it was so old old nobody could build it on modern distros (and linux-2.4.20 wouldn't compile with gcc 4.x):
But by all means, consider the FSF's actions _useful_. After all, the end result was that all the guys working on getting vanilla Linux working well on the WRT610n were transferred off of Linux development to do Windows and IOS...
By the way, the only reason I know _this_ story in such detail is I was (purely coincidentally) on the other side of it. I expect the other enforcement actions were often equally pointless and/or counter productve, I just didn't get inside details from the engineers impacted by them. I just heard from lawyers and managers, and got code drops through intermediaries (which never had anything in them we would want, but I had to trawl through anyway to confirm that it did in fact reproduce the binary and identify random source control snapshot X plus backports of these 15 random commits out of the same source control system, plus debug printfs that really shouldn't have shipped, and they hardwired in these constants instead of learning how to use the config system...) All I really know about those _other_ actions is they were a complete waste of time from the perspective of BusyBox development.
(P.S. When I told the SFLC/SFC to stop representing me, they raised the fact I was giving up settlement money to try to convince me to stay. But money was _never_ why I did it, and it's not why I stopped either. I started the busybox enforcement actions because I thought it was the right thing to do and would help BusyBox and embedded Linux development and adoption, and I stopped when I figured out it was at _best_ useless, and most likely doing real harm to the goal of getting the most people to use the best software, harming _both_ the "most" and "best" parts of that goal.)