FWIW, I wrote up a somewhat in-depth analysis of this SFLC / Conservancy dispute here: http://www.rants.org/2017/11/c...

TL;DR: Software Freedom Conservancy is behaving appropriately, and SFLC is not.

Your business shouldn't care if the user is running a server or just a client. You should be charging based on transit alone. Sure servers use more outbound transit and clients use more inbound transit. But you're free to price inbound and outbound traffic differently if they have different costs. The Internet wasn't built around the idea that some machines would have some special attribute that allowed them to serve traffic and everyone else was just a client. Any attempt to apply that to the Internet will ultimately fail. ISPs have been able to get away with this thinking because most of the popular protocols were client/server. Welcome to the 21st century. There are legitimate reasons to operate distributed services. For instance it makes sense to have voice chat applications that don't use a central server.

As far as P2P for YouTube. I don't think you know what you're talking about. The only thing I can find about P2P with YouTube is some Singapore company that tried to enable that and Google didn't like it. Given that Google is pushing for browser standards that don't require Flash at all you'd think they'd also be pushing for these standards to include P2P components. But as far as I can tell they aren't doing that either. Flash does support a P2P feature called RTMFP (Real Time Media Flow Protocol) which is primarily made for collaboration applications. As far as I can tell Google isn't using this even for things like Google Hangouts. If you have some proof otherwise I'd sure like to see the source.

Where did I give the impression that content providers aren't paying for bandwidth?

The way this should be working is that end users and content providers buy bandwidth from their ISPs and then the ISPs negotiate contracts over how to peer. If peering arrangements are titled towards one side or the other then maybe one side will end up paying for the peering. However, in many cases the peerage is mutually beneficial and they simply share the costs in supporting the peerage.

Hosted for free? No. Your user is paying you for the transit in both directions.

If your users aren't aware of how much bandwidth they are using perhaps you as an ISP should so something to educate them.

Quite frankly, if ISPs want to limit bandwidth usage then they should be required to show the bandwidth usage that has been used and should be required to provide exact limits as to what customers are provided. This shouldn't be any different than how cell phone companies have to show minutes used.

Instead they've been getting away with marketing burst speeds and creating the appearance of unlimited bandwidth usage (when in reality most of the big ones will start threatening to turn you off if you're using too much).

You keep brining up Google. What service does Google have that turns a users system into a server in order to access the service?

In my particular case I know exactly how much bandwidth I'm using. I actually have Cacti graphs. The only major thing that I can think of that I use that turns my system into a server without being obvious is the downloader for some game updates that uses bittorrent. As an ISP I'd think you'd be thrilled because these clients typically prefer to talk to IPs that are in the same blocks and often save a lot of transit across your peers.

I can't fathom what you mean by content providers wasting bandwidth.

I pay for a pipe, I expect to be able to send and receive packets to whomever I want. It's up to me as the user to decide if I'm wasting bandwidth. If I don't want to pay as much and save money then I should consider how to use less bandwidth.

The problem is that ISPs have been getting away with overprovisioning, underdelivering on bandwidth promises and pocketing the massive profits. If you can't make money with people using the bandwidth you sold them then perhaps you should price your product accordingly. If you're selling burst speeds and not explaining to customers your limits then it's your own fault.

There's two basic responses to this.

1) If there are competitors but their service isn't as good by switching you're helping put more resources in the hands of those competitors. Yes you might have to make some compromises in the short term but if enough other people do the same the competitor will be able to spend the money to provide the same service that Verizon is.

2) You may be able to gain herd immunity. Other areas do have competition. The areas with viable competition typically have it because they are very profitable. If people leave a carrier in areas where they are very profitable but the people without alternatives stay it hurts their profit margins. The misbehaving carrier is left with low profit of possibly even customers they lose money serving.

Seems like there's a simple solution. Verizon's only choice is to try and degrade service for sites that don't pay. If all sites refuse to pay then customers will complain about the degraded service and possibly choose other ISPs. Customers that want to prevent this sort of behavior can simply refuse to visit or given business to sites that do work these sorts of deals. Thus discouraging both sides from doing this. Vote with your wallets people.

+1 on "The Future Does Not Compute". One of my favorite books on this topic; IMHO it didn't get enough notice when it was new -- would be nice to see it get some now.

And Chris Daw, if you're out there: I still have your copy! I bought my own long ago; I've been trying to track you down ever since to return yours.

Those aren't iPhone model numbers. Those are Export Commodity Classification Control Numbers, which is how the government refers to categories of products. See http://www.bis.doc.gov/encryption/nlr.htm The poster above you is saying that the iPhone falls into a category that does not require an export license. However, not all encryption technology falls into that category.

I use SVN daily too. Sometimes SVN is the right tool for the job, sometimes Git is.

-Karl

They fixed it fast! (I'd delete the original comment now if I could.)

Odd typo (or transcript-o) -- the word "privatizations" should be "prioritizations" in this sentence:

"Given the huge topic space the authors had to choose from, their privatizations [should be 'priorizations'] are intelligently made and obviously reflective of long experience using Git."

I don't know how that happened. It was "prioritizations" in my submission at http://slashdot.org/submission/2368485/book-review-version-control-with-git-2nd-edition .

-Karl Fogel

It is not possible to compete with Git on its own terms without being open source. Being zero-charge for small teams is not going to cut it, IMHO.

Nope, no coordination nor conspiracy.

I reviewed the book at my own schedule, and as far as I know O'Reilly Media planned their Cyber Monday without any connection to when this review would be posted. Slashdot didn't promise me a posting schedule anyway, although a few days ago an editor wrote to say he'd probably run it on Monday. I forwarded that fact to a couple of people at O'Reilly (see below), but that was on Thursday, which was the Thanksgiving holiday in the U.S. Suffice it to say it is highly doubtful that O'Reilly Media planned their whole Cyber Monday thing starting a mere three days before the event and over a long holiday weekend!

However, I should have added a couple of disclaimers to the review:

O'Reilly sent me the copy to review, and, more importantly, the editor on the book, Andy Oram, is also my editor. The free review copy is not really worth a disclaimer, though; I'm just trying to be thorough. First of all, the amount of time it takes to read a book and write a review far outweighs the cost of purchasing a copy, and second of all, as an O'Reilly author I'm pretty sure I could have just emailed them asking for a copy anyway, regardless of whether I were reviewing it :-). As for sharing an editor: while Andy's a friend, I know he wouldn't want me to write a review differently just because he were the editor, he knows I wouldn't do so anyway, and he knows that I know that he knows I know he wouldn't want that. (The two people at O'Reilly whom I emailed about the probable Monday posting were Andy and the person who had sent me the review copy.)

So, this was not a slashvertisement -- just a coincidence, to the best of my knowledge.

Best,
-Karl Fogel