BitTorrent Closes Source Code 390
An anonymous reader writes ""There are two issues people need to come to grips with," BitTorrent CEO Ashwin Narvin told Slyck.com. "Developers who produce open source products will often have their product repackaged and redistributed by businesses with malicious intent. They repackage the software with spyware or charge for the product. We often receive phone calls from people who complain they have paid for the BitTorrent client."
As for the protocol itself, that too is closed, but is available by obtaining an SDK license."
Who cares? (Score:5, Interesting)
Note that they opposed the addition of encryption, and they were completely ignored. BitTorrent, the company, is entirely irrelevant.
Bittornado (Score:3, Interesting)
There, that should tide us over for a while.
Re:So.... (Score:5, Interesting)
Re:It was only a matter of time.. (Score:5, Interesting)
One difference. They don't operate any of the servers people actually use. Unless they can convice the server operators (most of whom they can't legally even admit exists, which will make negotiations somewhat awkward) to adopt their closed protocol, who will notice any optional dead protocols their 'official' but little used client supports?
At this point someone simply needs to write up a formal documentation of the protocol as it currently exists and submit it to the W3C, at which point the wire protocol is pretty much settled. And go ahead and pick a new anme because you can bet your last dollar they will pull the trademark crap the second they realize they are being written out of the picture.
Re:Not RTFA? Read this at least. (Score:5, Interesting)
Re:It was only a matter of time.. (Score:5, Interesting)
I can only hope... (Score:4, Interesting)
It's time we address it's critical failure... that you can see which IP's are trafficking in which files. There has to be an obscure way in which people can just exchange data blobs. Where the blobs are interleaved or multiplexed with data of other files and you don't know and can't know with all practicality what a particular blob contains until you finally collect enough blobs to reconstruct your data file. There are more blobs to be collected for a particular file for data redundancy but you only need to collect so many of them to recreate the data set. Meanwhile sure you downloaded more data then you needed to for that particular file but all the blobs you downloaded are still in demand from other people because of their relevance to other data sets. And you can safely continute to server those files because you don't necessarily know what multiplexed data they contain. Blobs also mutate and remix over time as to which combined data they contain.
Not Entirely Accurate and Not Entirely Catastophic (Score:3, Interesting)
From the article itself, it appears that, since acquiring uTorrent, a closed-source C++ BitTorrent client for Windows, Bittorrent, inc. has decided to keep it closed source, and also to make it the new "mainline" BitTorrent. The old "mainline" client, which is open-source, written in Python (with wx for the graphics) and is generally cross-platform, last I checked, will continue to be maintained as a "reference implementation", but might not always track the latest protocol updates to uTorrent. Full documentation on the protocol will apparently come with an "SDK license", which they claim is "easy to get".
Well, first of all they ARE doing a few things that contradict the spirit of free software. Their main client app will be closed source, and although the reference implementation will apparently continue to be free, protocol docs require you to acquire a special license. A few years ago, these moves would have tightened Bittorrent inc's grip on the world of bt clients in general.
Now, however, the landscape is different. I can't produce statistics for all torrent users in general, but when I take a look at my peers in my preferred client, KTorrent [ktorrent.org], there seems to be a near dead-heat for most popular client between uTorrent and Azureus [sourceforge.net] (also open source), with certain alternative clients like Transmission [m0k.org], Bitrocket [bitrocket.org], and KTorrent [ktorrent.org] making frequent appearances, as well (and all 3 of those examples? also open source). Although uTorrent certainly remains a big player, it doesn't confer upon BitTorrent, inc. the ability to dictate major compatibility-breaking protocol changes by fiat. The fact that the main implementation of BT was open source to start basically stops things from being ruined by more restrictive licensing now.
the protocol can't be reprotected (Score:1, Interesting)
is trade secret, which evaporates when published. I'm not sure they
can pull it back now.
It's similar to the reason you can't really protect the definition of a
programming language, even though lots of companies act like you can
and the industry largely plays along.
editors? don't forget taggers. (Score:4, Interesting)
While we're at it, let's point out how wonderful some of those tags are.
This story is tagged "lame" and "bastards" among other things. So yeah, if I'm interested in looking up info on OSS software being closed, I'll be sure to look for articles tagged "lame". That imediately makes so much sense to me, and you guys clearly know what good tagging's all about. Tagging's a great way of expressing opinions on entire stories without having to own up to them. You don't even have to have to LEAVE A FUCKING COMMENT WITH A USER NAME.
C'mon, at least post AC, dickheads.
Re:other open source clients? (Score:5, Interesting)
People use Bittorrent -- or more specifically, many people use uTorrent -- to connect to public BT trackers and to other people running similar client programs. Bittorrent (the company) doesn't control either. In fact, I don't think that Bittorrent-the-company's "reference implementation" is particularly popular for trackers, and they're really where the marketshare matters.
I don't think that the majority of bittorent (the protocol) users are just going to bend over and throw away the software that they've liked, just because Bittorrent (the company) decides it would be cool to produce a new, ad-laden, DRM-using, Hollywood-mogul-approved version of their software, that breaks compatibility with older versions. In fact, I strongly suspect that the trackers which drive the more popular torrent aggregation sites would refuse to recognize such a "broken" implementation, and would instead favor free implementations (old versions of uTorrent, Azureus, etc.).
What's happening here is that Bittorrent (the company) has become fully decoupled from bittorrent (the protocol). They have very little leverage over the latter; about all they have is the rights to the name "Bittorrent," and the 'reference implementation,' which won't be worth its weight in electrons once they start messing with it.
The comparisons to Microsoft and RTF aren't really apt, because Microsoft had a way they could easily control the format -- they just made future versions of Word produce output that was incompatible with other vendors' software. But Bittorrent can't really do that, because a bittorrent client is only useful insofar as it can communicate with the swarm. As long as the trackers that drive the most popular torrents (which, let's face it, are the illegal ones; warez and movies) don't start using the new/broken protocols, it seems unlikely that a broken protocol would gain traction.
This is so useless i want to cry. (Score:3, Interesting)
And that's only skimming your description.
Besides, not being able to preview files will pretty much make it useless for anything mainstream. Like pirating crap. So, if this protocol is never used for piracy, it will never need such insane protection from the MAFIAA because it will never blip on their radar. Oh, it can be used for other things, like downloading Linux ISOs? BT already does that. Secure file transfer? LOL Traffic analysis foiling? Tor. What else?
You are coming to a sad realization: Cancel or Allow?
Re:So.... (Score:4, Interesting)
I can easily picture the various motion picture and software copyright lawyers sending a few dark glasses wearing "lawyers" to explain "nice little business you got here, I'd hate to see anything happen to it" to encourage Bittorrent both to avoid providing encrypted transfers and to add "load monitoring" features that ease tracking. I'm not saying this is sure to happen, but with the source closed, it wouldn't take much to add hooks to report specific downloads to the mothership.
Re:Oxymoronic: thief cries thief !! (Score:5, Interesting)
Re:KTorrent too CPU hungry (Score:5, Interesting)
Re:Not RTFA? Read this at least. (Score:4, Interesting)
That's certainly all I use it for.
Re:In related news... (Score:4, Interesting)
Monetizing the SDK (Score:3, Interesting)
Correction -- their SDK can be *paid for*.
I beginning to think that the whole point of acquiring the most popular closed source client was to allow them to close and charge for the SDK. The counterpoint to this argument is that if any one open source P2P grits it teeth and pays whatever fee they're going to charge open source clients, then their implementation becomes the new reference.
A lot of people here are talking about how the Mainline client has once again aggressively pursued irrelevance, but uTorrent's marketshare is going to be nigh impossible to unseat unless they do something self-destructive like removing a popular feature they don't like (like encrpytion). They have a really good chance of dictating the development of the future of the protocol with that client in hand.
I think that this finally explains the reason for the buy-out and the lack of open source. I had previously thought it was due to uTorrent's original developer's dislike of open source, but it may have more to do with control and with monetizing the SDK.
Re:Oxymoronic: thief cries thief !! (Score:3, Interesting)
DC is also a popular P2P protocol and it started as a closed application whose protocol was reverse engineered. Later attempts to retake control were futile and nowadays there's no such thing as an "official" DC protocol, only several different client software making it on sheer popularity. Just like BT, some of them add new features and sometimes they're borrowed by the others and so on.
Think of IRC too. It also doesn't have an "official" specification, there are all these servers and clients and so on. At least there were some RFC's at some point, which is more than can be said of other P2P protocols.
So it seems to be a "normal" situation with P2P to not have a standard protocol and for it to evolve on server/client software popularity alone.
Re:In related news... (Score:4, Interesting)
Sorry to ruin it for you, but if you don't even know what that means, you're not in a position of judging *any* protocol.
Another hint for you: Just because it seems to work well for you on a small scale doesn't mean it is a good protocol (i.e. scaling well, little overhead, easily extendable, etc.).
Re:rtorrent pwnz (Score:3, Interesting)
What someone needs to do is set up an automated build system that uses "-fprofile-generate/-fprofile-use" -- especially for base system, multimedia, and compression libraries. I got something like a 12% speedup in using that for mplayer (or was that mpg123...) in benchmark mode, as opposed to stock ports compiler options under FreeBSD/amd64 (which, I believe, is "-O2 -fno-strict-aliasing", though many individual ports tweak those to the extreme). Granted, each program would need a decent corpus of representitive "work" to do for this method to be effective, but it could be done on port-by-port basis.
If someone wants to rock the world of Gentoo (and has more free time than sense), they should fork the project and incorporate the "profile" method I mentioned above *and* ACOVEA [coyotegulch.com] into an automated build system. Now *that* would be impressive. :)