BitTorrent Closes Source Code

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."

Not RTFA? Read this at least.

[tonsofpcs]

So basically BitTorrent bought uTorrent and is staying closed source (as uTorrent is now). Q: How will this impact the BitTorrent open source development community as a whole? A: There will be no impact to the BitTorrent open source development community. We are committed to maintaining the preeminent reference implementation of BitTorrent under an open source license. Although the latest documentations won't be published for the world to see, an aspiring BitTorrent developer or a hardened coder can still obtain the specifications on the latest protocol extensions by obtaining a SDK [slyck.com] license.

Re:In related news...

[Anonymous Coward]

And uTorrent belongs to Bittorrent(company) and always has been closed source.

Re:In related news...

[compro01]

though utorrent was acquired by these guys and likely will now be following the same route.

Re:Not RTFA? Read this at least.

[PaintyThePirate]

Not exactly. The only mention of an SDK on the Bittorrent site is part of a "device certification program" [bittorrent.com], that would undoubtedly involve paying Bittorrent in exchange for licensing their now proprietary information and some offical seal of approval. There is no mention of open source projects being able to see/use any changes in the protocol. Luckily, I assume that most bittorrent trackers (public or private), will ban any incompatible official client if the protocol does change, rather than adopting the official client and abandoning all of the others.

Re:The argument doesn't scan..

[grcumb]

I'm a bit confused by this. Isn't this what licenses are for? Why not just sue the people selling and profiting from your open source product for breaking the license?

Because that's not enough to constitute infringement of the license. People are welcome to repackage and resell GPL software. But they also need to consider trademark issues. They can call the software almost anything they like, they can claim that their product is just like another, but if they claim that their product is the other one, then the original company can take them to court and sue their euphemisms off.

And that, of course, is why claiming that GPLed software is open to this kind of abuse is the reddest of red herrings. Trading on someone else's good name is well covered in the laws of most countries, and the GPL has exactly zero impact on such abusive practices.

Re:Not RTFA? Read this at least.

[tonsofpcs]

From the article:
However this will not be the case, Ashwin told Slyck.com. Although the latest documentations won't be published for the world to see, an aspiring BitTorrent developer or a hardened coder can still obtain the specifications on the latest protocol extensions by obtaining a SDK license.

"I don't think we've ever said no" to an aspiring BitTorrent programmer, Ashwin said.

Re:In related news...

[starwed]

But utorrent has always been closed source.

editors? more like lamers.

[hxnwix]

From TFA:

"Q: How will this impact the BitTorrent open source development community as a whole?

A: There will be no impact to the BitTorrent open source development community. We are committed to maintaining the preeminent reference implementation of BitTorrent under an open source license."

Slashdot editors, you are fucking retarded.

The Explaination Makes No Sense.

[twitter]

"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. ... As for the protocol itself, that too is closed, but is available by obtaining an SDK license."

The risks are great and I don't see a pay off.

As one person has already pointed out, too much of the wrong thing will isolate and destroy them [slashdot.org]

.

Going non free will also make their problems worse. The malice described is a problem that free software creates. The only reason crackers and MAFIAA can get away with charging people for spyware derivatives is because Windoze and the clients are not free to begin with. Real free software can be packaged by distributions like Debian, which assure the user the software has been checked for malware by an impartial third party. The further away from that model they get, the more problems they will have. The dirtbags will go right along with what they are doing and their life will be easier.

The difference

[Rinisari]

There is a difference, here. uTorrent has always been closed, so it's not the client that's being closed. What people are or should be worried about are changes to the protocol. Hopefully, we won't see BitTorrent 6.0+ clients being blocked from trackers other than BitTorrent.com's tracker because of a silly change in the protocol that disrupts clients using v5 and earlier. Unfortunately, this means that if Bram, Ludde, and company engineer some wicked addition to the protocol that drastically improves it, the open source community will either 1) not have access to it or 2) have to reverse engineer it.

Additionally, only the main BitTorrent.com tracker would have access to tracker-side protocol updates. So, this then means that the only benefit of using the mainline client is when downloading from the BitTorrent.com tracker!

Is BitTorrent pigeonholing itself; is it forming its own niche within its once-large niche?

rtorrent pwnz

[Anonymous Coward]

get rtorrent
http://libtorrent.rakshasa.no/ [rakshasa.no]

with adsl2+ i could get >1meg/s with hundreds of connections, totally stable and only used around ~1%cpu time on a p3 933.

use gentoo and -O3 it too.

Re:GPL

[Secret Rabbit]

The GPL cannot keep the original author from changing the license and closing the source nor can it prevent the protocol from being closed either.

The only thing it can do is keep that source (the version that was under the GPL) available to the open-source community. Which, btw, can be accomplished by any other open-source license. Btw, they have already done this.

Basically, we're in the exact same situation now that we would have been if it was GPL'd.

Re:uTorrent, BitTorrent...

[set]

probably. bitcomet [bitcomet.com] is the same client without the ad-crap.

Re:Oxymoronic: thief cries thief !!

[SL Baur]

Torrents are for stealing !! Get use to it !!

Blizzard uses an early version of the bittorrent code for their "Blizzard Downloader", I am told. Anything that reduces the download time of something I've paid for, like the online BC upgrade or update patches seems like a win to me.

It's a pity they're going closed source, but it wouldn't be unfair for Blizzard to toss a few gold pieces back their way given all the money Blizzard is making.

KTorrent

[Enderandrew]

KTorrent is my favorite pure torrent app on any platform, with utorrent running a close second. Both are very fast, light-weight clients.

I've also dabbled with mldonkey and shareaza as more multi-purpose p2p apps that also support torrents.

Re:It was only a matter of time..

[kripkenstein]

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?

No, that isn't quite true.

First, Bittorrent is a peer-to-peer protocol. Only a minor part of it is communication with the server (aka tracker). They might keep the tracker protocol exactly the same, and alter the important p2p part.

Second, this has already been done, and successfully. For example, utorrent came out with a 'PEX' (Peer Exchange) protocol that wasn't in the spec. So it was only used between peers that were both using the utorrent client. This provided a nicer bittorrent experience for utorrent users, especially as utorrent's marketshare rose. Later on, because of utorrent's dominant position, other clients started to implement utorrent PEX (KTorrent, libtorrent-based clients), with varying degrees of success.

A similar issue is Azureus's DHT protocol, which is not in the standard. Although at least Azureus is open source, so you can read the actual code to help in understanding what nonstandard protocols they have invented (but then they also have a very nice wiki).

The point is, it is easy to 'embrace and extend' the bittorrent protocol, even if you don't have control of the servers. Is 'extinguish' next? Probably not, but I for one won't be using the official Bittorrent client.

Re:Not RTFA? Read this at least.

[1000Monkeys]

You mean like the open source reference version that they've promised to continue to maintain?

Re:In related news...

[Barny]

And further reading would have shown that not only was utorrent closed source (and still is), but since this version it is also the "official" client, so...

Bit torrent have made a closed source client their mainline client, and have decided to fortify their rights to the protocol too (its closed, but an SDK can be requested).

Not only is this a non-issue, but its the type of sensationalism I would expect from a lot lower class of blog than /.

Re:Heh heh.

[frogger3d]

Not much chance they will merge a Python project (bittorrent 5.0) with a C++ project (uTorrent) if you ask me..

Re:In related news...

[kryptkpr]

I think he's referring to the initial peerid exchange. The requirement to establish a torrent session is that both parties must send out their peerids to establish the connection. This poses a problem for multicast where 1 party is sending but lots of parties are attempting to receive (ie, the link is one-way, with the receiver having no way to send back to the sender their peerids). This can probably be worked around, since peerid isn't really that necessary anyway (IIRC, it's just used as kind of a GUID).

What he says about using game theory to trick other clients into sending to you may or may not actually be true, since there are lots of clients out there and he only knows how the reference client's tit-for-tat/peer-picking algorithm works (although he's right in that it's weak). One MAY be able to use game theory to trick a specific implementation, but I don't think you could make some kind of uberclient that can trick the entire swarm into unloading their bits in your direction.

DISCLAIMER: It's been almost 2 years since I've done any torrent hacking, this information may be outdated.

Re:In related news...

[jsight]

You are definitely right about the spec. The "official" spec from Bram Cohen was somewhat of a joke. The best that is available is:
http://wiki.theory.org/BitTorrentSpecification [theory.org]

Re:KTorrent

[Zach978]

All of the Bittorrent clients eat up too much CPU, especially when downloading very fast (400 kB/s hogs hard drive and CPU )...so I finally threw TorrentFlux [torrentflux.com] on my fileserver and will never go back! It's a PHP client that actually uses the standard bittorrent client (can be modded to use other command line clients), but I can have 20 torrents going now without slowing down my desktop.