This is perpetuating a common myth, namely that connecting to multiple networks translates into access to more files. It's a myth that makes sense on the face of it. It breaks down on the level of the searching protocols, however, and it's a myth that programs like Shareaza and Morpheus use as a marketing gimmick to get users to try their programs.
Why is it a myth? It's a myth because all p2p networks have physical limits that prevent searches from reaching beyond certain numbers of computers without overloading the bandwidth capacity of every node on the network. "Gnutella2 (aka Mike's Protocol)", Gnutella, eDonkey, FastTrack, etc all face these physical limits. All of these networks are highly advanced at this point. The eDonkey and Gnutella search architectures in particular are extremely efficient. The MP architecture seems pretty good, but it's not specified very well and will require someone plugging through the source code to really have a look at how good it is. FastTrack is probably trailing all of the other networks at this point in terms of search efficiency. That said, none of these network are able to search beyond a million or so nodes for a given (rare) file simply because there's only so much bandwidth to go around, and we've already extracted most of the big efficiencies to be tweaked out of these architectures.
The only way connecting to more networks can result in more files is if a client acts as a leech, if it connects to a network and sucks resources from it and contributes no resources back. This is precisely what Shareaza does with Gnutella and eDonkey. It connects as "leaves" to both networks to ensure that it does not have to contribute any resources while leeching off the other users of those networks to get files. Yick! Same thing the Morpheus folks do.
Don't get me wrong, Mike is clearly a talented programmer and Shareaza has lots of great features, and Mike's generally a nice guy. These kinds of behaviors are just a little obnoxious though, and doesn't tend to make Shareaza any friends. I don't work for LimeWire any more, by the way. These are my own, completely independent views.
This study is based on extremely old data and is not particularly relevant for today's Gnutella. The Gnutella crawl data is from 2001, a time when Gnutella was a vastly different network with a completely different searching architecture. Gnutella at the time was a very young protocol. Since then, the search architecture has moved beyond the flooding model, now using a combination of distributed indexing and "dynamic querying." These techniques are specified in detail here.
The data on average number of shared files and uptime is interesting, but there's really not a lot in here that is actually useful for peer to peer development. There's a lot of active, very useful research being done elsewhere. The folks at Stanford have done a great deal of work in this area, much of it very applicable. Their work is here.
The Tiger Tree specification was worked on and agreed by all of the members of the Gnutella community. The implementation itself is relatively trivial -- agreeing on the spec is the hard part. Even in this case, where there's a very strong, open specification for Tiger Tree exchange in the Tree Hash Exchange (THEX) protocol, Shareaza implements it slightly differently, breaking compatibility with other clients and flying in the face of the specification. You can find THEX at:
This is a scary conversation to get into, but here goes. We're probably both a bit overly fanatical in our viewpoints. MP offers interesting ideas, and it does work well. I think that the underlying technology of Gnutella is significantly more sound, as I've outlined in other threads. To say that "MP works and Gnutella doesn't" is clearly ridiculous. I definitely don't own Gnutella, but many people have put a great deal of effort into the Gnutella network, most of their time volunteered. Those people don't deserve to have their work swept under the umbrella of "Gnutella 2" just so Shareaza can get Slashdotted.
MP was a separate entity from the beginning -- it hasn't changed significantly since it was first introduced, and the Gnutella world did not embrace it because it made no attempt to have anything to do with Gnutella other than taking it's name so we'd all be talking about it right now.
I went into the details of why we haven't released GUESS on another thread. In a nutshell, we think that TCP approaches are more robust and can achieve the same efficiency and scalability. MP had nothing to do with increasing the outdegree -- that's an idea that has been around Gnutella for years, and the most rigorous discussion I've seen for why high outdegrees are important is the following paper from the Stanford Peers folks at:
It's true that LimeWire has no right to the Gnutella name or to "Gnutella 2." We would never dream of taking that name without careful consultation with other people who have invested countless hours of their time in this network.
At the same time, sure, maybe anyone can name anything Gnutella 2. The technology is the important thing, and it's helpful to have multiple protocols out there to see what works. I'd just prefer to work cooperatively with everyone to make the best technology possible, and that spirit of open collaboration simply isn't what it once was.
Good point. I was a little worked up when I wrote that message -- I usually get overly worked up when this topic comes up =). Basically, I see Gnutella 2 as an fine protocol that has been proprietary for most of its history. I applaud Mike for getting the specs out there, but I still don't appreciate his decision to coopt the Gnutella name without any consultation with anyone who actually wrote clients for the Gnutella network. I don't like it when I and the volunteer work of thousands of people in the rest of the Gnutella community see their work taken advantage of by an opportunist.
I believe the first p2p client to implement remote queueing was something called "Napster."
When I talk about Mike's Protocol slapping the Gnutella 2 name on protocols people in the Gnutella world came up with (again, without their consent), I'm referring to ideas like partial file sharing, HUGE, Tiger Tree, Ultrapeers, XML queries, etc.
I am sorry to hear that you have been disappointed with your experiences with LimeWire. We are working hard to create the best technology possible, and we have a road map that we feel will soon make LimeWire the best performing p2p application available.
You are clearly an informed user, so I will go into the details of LimeWire/Gnutella development as well as more detailed reasons for my above comments. I and Susheel Daswani wrote the original GUESS protocol, and we very openly shared our ideas regarding GUESS with Mike in particular, having no idea that there would be consequences for our openness. GUESS is fully implemented in LimeWire and has been for some time. We have not released that implementation for reasons that are vital to this conversion, including:
1) After extensive *collaboration* with the rest of the Gnutella community, we came to the realization that any UDP-based protocol would almost surely require a custom flow control layer to be written on top at some point down the road. Without this layer, congestion will simply starve all TCP connections of any available bandwidth, as TCP will continually backoff as UDP indiscriminately consumes the released bandwidth. This is bad for the use. Developing a flow control layer is a significant burden to the developer. Mike's Protocol does not do this, and it will cause congestion on the Internet as a result. It will also be one of the primary reasons that few developers will code for it.
2) We came to the realization that we could achieve the same efficiency gains with a far safer TCP implementation. This implementation relys on selective querying (dynamically adjusting the reach of a query based on the popularity of the content being searched for), as well as the exchanging of file indexes between Ultrapeers to limit traffic. This implementation is also significantly simpler than UDP-based architectures, and does not pose the same security concerns. We may at some point use GUESS for specific purposes, but we will likely not make GUESS the primary search architecture because we are able to achieve the same efficiency gains by better and more responsible means.
In short, we did not rush our client out the door using GUESS because our open collaboration with other developers led us to realize that better solutions were available and that a raw UDP solution was, in fact, dangerous in terms of network congestion, and even irresposible to network administrator everywhere attempting to cope with bursts of UDP traffic. Becuase Mike did not develop his protocol openly, he was unable to do this.
Mike's Protocol is able to use this architecture in large part because it's network is so small. It's possible that it scales better than I think it does, but I doubt it. The search architecture story tells much about why open protocols make sense -- because everyone collaborates to develop the best protocol possible.
An interesting parody. The big difference? Linux represented a huge leap forward because it was open source. Gnutella 2 is not a leap forward. It does things like arbitrarily create a new, completely unstandardized messaging system. As any Gnutella developer knows, the problems facing Gnutella, as with most p2p systems, have little to do with the underlying messages. They have to do with topology and the intelligence of the algorithms. Changing every Gnutella message does nothing to address these issues.
Linux also didn't hijack the Unix name (don't try to make the case that "Linux" is a varient of "Minix"). Everyone was using the Unix name for all sorts of Unix variants. Gnutella 2 is a marketting stunt, and you are furthering that stunt right now. Honestly, if you knew more about what you were doing, I think you'd be embarrassed about your above comment.
Gnutella2, or "Mike's Protocol," has some interesting properties. It has nothing whatsoever to do with Gnutella, however. It's a separate protocol that is bootstrapping off of the Gnutella name to do things like get on Slashdot, and everyone here is falling for it.
Characterizations of Gnutella as a simple, old protocol reflect a woeful ignorance of the many innovations that have emerged from Gnutella. In fact, much of Mike's Protocol calls "Gnutella 2" are innovations developed on Gnutella itself. These aren't simply close copies -- the protocols he cites are, in fact, Gnutella protocols. There are many more innovations happening on Gnutella as we speak, and the highjacking of the Gnutella name by Mike has weakened the fabric of an otherwise strong and open development community.
We should all support open networks by supporting Gnutella. Gnutella2 offers interesting alternatives, but is no better than the work currently occurring on Gnutella. What's more, few if any Gnutella developers will ever support Gnutella2 because of the divisive way that it was introduced, permanently fracturing the Gnutella community, with almost all of the Gnutella community still working on Gnutella because they were never told of the so-called Gnutella2 until it was slashdotted, much as we're seeing today.
If you support open protocols, support the original Gnutella. Gnutella2 does not solve any problems not currently solved by the original Gnutella clients. It simply creates division.
In any project that is centrally controlled, where a set of individuals keeps close track of any new code (and where limited numbers of people are able to add code directly without submitting patches), it's quite easy to know precisely who did what. This is the case with LimeWire just as it's the case with Linux (our job is orders of magnitude smaller and easier, of course).
That issue aside, however, even if you only know that a specific person wrote a specific piece of code that you liked (whether or not you know exactly who wrote every line in the program), that person has a much better chance of getting hired if and when a position opens up.
That's an interesting point regarding liability in general, and about the IRS. In terms of suite regarding any copyright issues in particular, however, it's unlikely that employees of companies would be held personally liable in any way. The assets of company officers could potentially be fair game in a suit, but even that is unlikely and not really what the plaintiffs would be after (except perhaps as a scare tactic). Given that open source coders could never be considered officers, there's really no legal threat in terms of personal assets.
As far as the IRS goes, any open source programmers that get paid are required to file their earnings, just as any freelance employee would be. If they're not getting paid, it's off course not an issue.
We see this issue from a slightly different angle -- open source coders for LimeWire offer us an extended "interview" period where we can truly judge the value of their code. This lets us make hiring decisions easily. There's no interview that can substitute for months of open source code. Interestingly, we've seen that one of the primary attributes of people who write good code is also one of the primary attributes that involves them in open source to begin with -- passion for the project. The best coders often don't have the most impressive degrees. Rather, the best coders are the ones who care enough about the project to write good code for it. Experience and training help, but it's passion for the project that makes average code good, or good code great.
What everyone seems to be missing is that ant is far more than simply a build tool. Sure, ant does conditional compilation. But it also allows you to do things like automated JUnit testing, automatic formatting of test output, fixing of issues in source such as tabs, spacing, and end of lines, etc, etc.
A well put-together automated ant build process can checkout and compile all of your sources, run all of your tests, package them in the necessary jars, build your installers, upload them to your servers, and e-mail all you developers the results of the process. That's ant leveraging off of other tools (like whatever installer you use), but that's what it's capable of.
Anyone know if this release includes the 1.4.1 implementation of Java that's been in beta for about a month?
Re:Gnutella2 - The real story!
on
Gnutella2?
·
· Score: 1
The LimeWire/TopMoxie affiliates are listed on the LimeWire web site
here.
Linking to these through the LimeWire web site goes directly to our affiliate links just like they would with any other web site. Those links are also listed directly on our home page.
Re:How exactly does TopMoxie work?
on
Gnutella2?
·
· Score: 1
Me too!
Re:How exactly does TopMoxie work?
on
Gnutella2?
·
· Score: 4, Informative
The difference is in the link. In your example, the user links to Amazon from another web site. In this case, TopMoxie does nothing. If the user goes directly to Amazon by typing it in a web browser, though, TopMoxie does prompt the user for whether or not he or she would like the commission to go to LimeWire.
Re:How exactly does TopMoxie work?
on
Gnutella2?
·
· Score: 1
In the scenario you described, TopMoxie would not come into play at all. It will not redirect links from other web sites, so it won't affect the affiliate revenue of other web sites at all.
I really don't want credit. The issue is more that these standards were developed almost entirely by members of the Gnutella community other than Shareaza -- including Ultrapeers, compression (GTK-Gnutella and Swapper), UDP-based searching, etc, and most of them are not particularly new.
That's what marketting seems to be all about, though, so maybe it's fine.
Re:How exactly does TopMoxie work?
on
Gnutella2?
·
· Score: 1
The first versions of TopMoxie worked that way. The newer versions, however, will not overwrite links from other web pages.
Re:Gnutella2 - The real story!
on
Gnutella2?
·
· Score: 2, Interesting
We also don't mean to imply that Mike "took" GUESS in any way. I fully understand that he was working on a separate protocol when GUESS was being developed -- I understand because I'm the one who had those conversations with him.
The point is that GUESS is a public specification for searching on Gnutella. Hopefully, whatever Mike is doing will soon be public as well. Then again, if it's not GUESS but is very similar to GUESS, then it'll create a standardization nightmare that we've worked very hard to avoid -- the type of incompatibility that wastes everyone's time. We need to have an open network that evolves and innovates rapidly. Perhaps Gnutella 2 will be a positive part of that, but it's not off to a great start.
Re:Gnutella2 - The real story!
on
Gnutella2?
·
· Score: 5, Informative
On the spyware topic, we originally started bundling software purely out of the need to survive -- we needed to bring in money, or we would have closed down. Since then, we came out with LimeWire Pro and now only bundle TopMoxie with LimeWire, and it's an optional install. TopMoxie really is not spyware in the way people typically use that word. It basically does one thing -- it has affiliate programs with multiple web sites, and when you visit those sites, it pops up a really innocuous window (that times out and disappears) asking you if you would like your purchase to support LimeWire. If you click yes, we get the affiliate revenue. If you ignore it or don't notice it, nothing happens. TopMoxie is primarily used by schools and charities to raise money for them.
So, the short answer is that we would prefer not to bundle anything. As a result, we now only bundle one program that we feel is really innocuous to the user and that they have the option not to install. On all operating systems other than Windows, LimeWire has no bundled software.
Slashdot Mirror
This is perpetuating a common myth, namely that connecting to multiple networks translates into access to more files. It's a myth that makes sense on the face of it. It breaks down on the level of the searching protocols, however, and it's a myth that programs like Shareaza and Morpheus use as a marketing gimmick to get users to try their programs. Why is it a myth? It's a myth because all p2p networks have physical limits that prevent searches from reaching beyond certain numbers of computers without overloading the bandwidth capacity of every node on the network. "Gnutella2 (aka Mike's Protocol)", Gnutella, eDonkey, FastTrack, etc all face these physical limits. All of these networks are highly advanced at this point. The eDonkey and Gnutella search architectures in particular are extremely efficient. The MP architecture seems pretty good, but it's not specified very well and will require someone plugging through the source code to really have a look at how good it is. FastTrack is probably trailing all of the other networks at this point in terms of search efficiency. That said, none of these network are able to search beyond a million or so nodes for a given (rare) file simply because there's only so much bandwidth to go around, and we've already extracted most of the big efficiencies to be tweaked out of these architectures. The only way connecting to more networks can result in more files is if a client acts as a leech, if it connects to a network and sucks resources from it and contributes no resources back. This is precisely what Shareaza does with Gnutella and eDonkey. It connects as "leaves" to both networks to ensure that it does not have to contribute any resources while leeching off the other users of those networks to get files. Yick! Same thing the Morpheus folks do. Don't get me wrong, Mike is clearly a talented programmer and Shareaza has lots of great features, and Mike's generally a nice guy. These kinds of behaviors are just a little obnoxious though, and doesn't tend to make Shareaza any friends. I don't work for LimeWire any more, by the way. These are my own, completely independent views.
This study is based on extremely old data and is not particularly relevant for today's Gnutella. The Gnutella crawl data is from 2001, a time when Gnutella was a vastly different network with a completely different searching architecture. Gnutella at the time was a very young protocol. Since then, the search architecture has moved beyond the flooding model, now using a combination of distributed indexing and "dynamic querying." These techniques are specified in detail here.
The data on average number of shared files and uptime is interesting, but there's really not a lot in here that is actually useful for peer to peer development. There's a lot of active, very useful research being done elsewhere. The folks at Stanford have done a great deal of work in this area, much of it very applicable. Their work is here.
Open Content Network
THEX is an open specification developed by Gordon Mohr and Justin Chapweske. It's not Gnutella-specific, but it certainly isn't Gnutella 2.
MP was a separate entity from the beginning -- it hasn't changed significantly since it was first introduced, and the Gnutella world did not embrace it because it made no attempt to have anything to do with Gnutella other than taking it's name so we'd all be talking about it right now.
I went into the details of why we haven't released GUESS on another thread. In a nutshell, we think that TCP approaches are more robust and can achieve the same efficiency and scalability. MP had nothing to do with increasing the outdegree -- that's an idea that has been around Gnutella for years, and the most rigorous discussion I've seen for why high outdegrees are important is the following paper from the Stanford Peers folks at:
Beverly Yang and Hector Garcia-Molina. Designing a Super-Peer Network
That link doesn't seem to be working at the moment, but you can reach it from:
Stanford Peers Page
All that said, I wish MP the best. I wish it had chosen a different name, but oh well.
At the same time, sure, maybe anyone can name anything Gnutella 2. The technology is the important thing, and it's helpful to have multiple protocols out there to see what works. I'd just prefer to work cooperatively with everyone to make the best technology possible, and that spirit of open collaboration simply isn't what it once was.
When I talk about Mike's Protocol slapping the Gnutella 2 name on protocols people in the Gnutella world came up with (again, without their consent), I'm referring to ideas like partial file sharing, HUGE, Tiger Tree, Ultrapeers, XML queries, etc.
You are clearly an informed user, so I will go into the details of LimeWire/Gnutella development as well as more detailed reasons for my above comments. I and Susheel Daswani wrote the original GUESS protocol, and we very openly shared our ideas regarding GUESS with Mike in particular, having no idea that there would be consequences for our openness. GUESS is fully implemented in LimeWire and has been for some time. We have not released that implementation for reasons that are vital to this conversion, including:
1) After extensive *collaboration* with the rest of the Gnutella community, we came to the realization that any UDP-based protocol would almost surely require a custom flow control layer to be written on top at some point down the road. Without this layer, congestion will simply starve all TCP connections of any available bandwidth, as TCP will continually backoff as UDP indiscriminately consumes the released bandwidth. This is bad for the use. Developing a flow control layer is a significant burden to the developer. Mike's Protocol does not do this, and it will cause congestion on the Internet as a result. It will also be one of the primary reasons that few developers will code for it.
2) We came to the realization that we could achieve the same efficiency gains with a far safer TCP implementation. This implementation relys on selective querying (dynamically adjusting the reach of a query based on the popularity of the content being searched for), as well as the exchanging of file indexes between Ultrapeers to limit traffic. This implementation is also significantly simpler than UDP-based architectures, and does not pose the same security concerns. We may at some point use GUESS for specific purposes, but we will likely not make GUESS the primary search architecture because we are able to achieve the same efficiency gains by better and more responsible means.
In short, we did not rush our client out the door using GUESS because our open collaboration with other developers led us to realize that better solutions were available and that a raw UDP solution was, in fact, dangerous in terms of network congestion, and even irresposible to network administrator everywhere attempting to cope with bursts of UDP traffic. Becuase Mike did not develop his protocol openly, he was unable to do this.
Mike's Protocol is able to use this architecture in large part because it's network is so small. It's possible that it scales better than I think it does, but I doubt it. The search architecture story tells much about why open protocols make sense -- because everyone collaborates to develop the best protocol possible.
Best,
Linux also didn't hijack the Unix name (don't try to make the case that "Linux" is a varient of "Minix"). Everyone was using the Unix name for all sorts of Unix variants. Gnutella 2 is a marketting stunt, and you are furthering that stunt right now. Honestly, if you knew more about what you were doing, I think you'd be embarrassed about your above comment.
Characterizations of Gnutella as a simple, old protocol reflect a woeful ignorance of the many innovations that have emerged from Gnutella. In fact, much of Mike's Protocol calls "Gnutella 2" are innovations developed on Gnutella itself. These aren't simply close copies -- the protocols he cites are, in fact, Gnutella protocols. There are many more innovations happening on Gnutella as we speak, and the highjacking of the Gnutella name by Mike has weakened the fabric of an otherwise strong and open development community.
We should all support open networks by supporting Gnutella. Gnutella2 offers interesting alternatives, but is no better than the work currently occurring on Gnutella. What's more, few if any Gnutella developers will ever support Gnutella2 because of the divisive way that it was introduced, permanently fracturing the Gnutella community, with almost all of the Gnutella community still working on Gnutella because they were never told of the so-called Gnutella2 until it was slashdotted, much as we're seeing today.
If you support open protocols, support the original Gnutella. Gnutella2 does not solve any problems not currently solved by the original Gnutella clients. It simply creates division.
In any project that is centrally controlled, where a set of individuals keeps close track of any new code (and where limited numbers of people are able to add code directly without submitting patches), it's quite easy to know precisely who did what. This is the case with LimeWire just as it's the case with Linux (our job is orders of magnitude smaller and easier, of course).
That issue aside, however, even if you only know that a specific person wrote a specific piece of code that you liked (whether or not you know exactly who wrote every line in the program), that person has a much better chance of getting hired if and when a position opens up.
That's an interesting point regarding liability in general, and about the IRS. In terms of suite regarding any copyright issues in particular, however, it's unlikely that employees of companies would be held personally liable in any way. The assets of company officers could potentially be fair game in a suit, but even that is unlikely and not really what the plaintiffs would be after (except perhaps as a scare tactic). Given that open source coders could never be considered officers, there's really no legal threat in terms of personal assets.
As far as the IRS goes, any open source programmers that get paid are required to file their earnings, just as any freelance employee would be. If they're not getting paid, it's off course not an issue.
We see this issue from a slightly different angle -- open source coders for LimeWire offer us an extended "interview" period where we can truly judge the value of their code. This lets us make hiring decisions easily. There's no interview that can substitute for months of open source code. Interestingly, we've seen that one of the primary attributes of people who write good code is also one of the primary attributes that involves them in open source to begin with -- passion for the project. The best coders often don't have the most impressive degrees. Rather, the best coders are the ones who care enough about the project to write good code for it. Experience and training help, but it's passion for the project that makes average code good, or good code great.
What everyone seems to be missing is that ant is far more than simply a build tool. Sure, ant does conditional compilation. But it also allows you to do things like automated JUnit testing, automatic formatting of test output, fixing of issues in source such as tabs, spacing, and end of lines, etc, etc. A well put-together automated ant build process can checkout and compile all of your sources, run all of your tests, package them in the necessary jars, build your installers, upload them to your servers, and e-mail all you developers the results of the process. That's ant leveraging off of other tools (like whatever installer you use), but that's what it's capable of.
Anyone know if this release includes the 1.4.1 implementation of Java that's been in beta for about a month?
The LimeWire/TopMoxie affiliates are listed on the LimeWire web site here.
Linking to these through the LimeWire web site goes directly to our affiliate links just like they would with any other web site. Those links are also listed directly on our home page.
Me too!
The difference is in the link. In your example, the user links to Amazon from another web site. In this case, TopMoxie does nothing. If the user goes directly to Amazon by typing it in a web browser, though, TopMoxie does prompt the user for whether or not he or she would like the commission to go to LimeWire.
In the scenario you described, TopMoxie would not come into play at all. It will not redirect links from other web sites, so it won't affect the affiliate revenue of other web sites at all.
I really don't want credit. The issue is more that these standards were developed almost entirely by members of the Gnutella community other than Shareaza -- including Ultrapeers, compression (GTK-Gnutella and Swapper), UDP-based searching, etc, and most of them are not particularly new. That's what marketting seems to be all about, though, so maybe it's fine.
The first versions of TopMoxie worked that way. The newer versions, however, will not overwrite links from other web pages.
We also don't mean to imply that Mike "took" GUESS in any way. I fully understand that he was working on a separate protocol when GUESS was being developed -- I understand because I'm the one who had those conversations with him.
The point is that GUESS is a public specification for searching on Gnutella. Hopefully, whatever Mike is doing will soon be public as well. Then again, if it's not GUESS but is very similar to GUESS, then it'll create a standardization nightmare that we've worked very hard to avoid -- the type of incompatibility that wastes everyone's time. We need to have an open network that evolves and innovates rapidly. Perhaps Gnutella 2 will be a positive part of that, but it's not off to a great start.
On the spyware topic, we originally started bundling software purely out of the need to survive -- we needed to bring in money, or we would have closed down. Since then, we came out with LimeWire Pro and now only bundle TopMoxie with LimeWire, and it's an optional install. TopMoxie really is not spyware in the way people typically use that word. It basically does one thing -- it has affiliate programs with multiple web sites, and when you visit those sites, it pops up a really innocuous window (that times out and disappears) asking you if you would like your purchase to support LimeWire. If you click yes, we get the affiliate revenue. If you ignore it or don't notice it, nothing happens. TopMoxie is primarily used by schools and charities to raise money for them.
So, the short answer is that we would prefer not to bundle anything. As a result, we now only bundle one program that we feel is really innocuous to the user and that they have the option not to install. On all operating systems other than Windows, LimeWire has no bundled software.