Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: Re:I can't find the commercial speech section (Score 1) 239

It's a huge defense. The difference between commercial and hobby/recreational activity is whether the primary motivation is making money or relaxation/recreation. Showing that the amounts of money made are very, very small strengthens the argument that it's a hobby/recreational activity rather than a commercial activity.

Comment: Re:Additional background (Score 1) 293

by JoelKatz (#48664613) Attached to: Hotel Group Asks FCC For Permission To Block Some Outside Wi-Fi

It's not jamming. They're not transmitting at the same time as someone else or using more power than other people. They're sending data when the channel is idle and at the normal power level, but it has the consequence of breaking connections because those connections are so insecure that anyone can break them. This has no effect on secure networks.

Comment: Re:have they thought about the liability? (Score 1) 293

by JoelKatz (#48664601) Attached to: Hotel Group Asks FCC For Permission To Block Some Outside Wi-Fi

It's the reverse. They block outside hotspots because they are thinking about liability. Imagine if someone creates a hotspot with the same SSID as the hotel's, MITM's the login process, and steals credentials.

There's no shared secret between you and the hotel and no way to know the hotel's public key. Thus the only way the hotel can protect you from connecting to an attacker is to detect and block the attacker's signals.

Comment: Lies, damn lies, and (Score 3, Insightful) 144

by JoelKatz (#48628193) Attached to: Will Ripple Eclipse Bitcoin?

Jed McCaleb left. The original development team (myself, Arthur Britto, Stefan Thomas, Vahe Hovhannisyan, etc) is still here, and Chris Larsen, the first CEO, is still CEO. Ripple Labs currently has more than 80 full time employees working to develop and promote the protocol.

Ripple does not require a centrally administered list of trusted transaction processing servers. That's just like arguing that Bitcoin requires a centrally administered list of valid transaction formats. Substantial agreement does not require central administration.

Comment: That seems quite reasonable (Score 2) 282

by JoelKatz (#48343987) Attached to: When We Don't Like the Solution, We Deny the Problem

There's nothing inherently irrational about this. For example, if your daughter says to you, "My grades are bad and my teacher says I need to spend more time studying", you'd believe her. But if she says, "My grades are bad and my teacher says I need to stay up later", you might not. The incentive to exaggerate or misstate evidence depends on the consequences of accepting the evidence, and thus the reliability of evidence depends on its consequences as well.

Comment: Re:IRL (Score 1) 204

by JoelKatz (#48141869) Attached to: Netflix Video Speed On FiOS Doubles After Netflix-Verizon Deal

ISP customers generate very little traffic. The vast majority of the traffic "eyeball networks" like ISPs carry is generated by others. It's not the ISP, or their customer, that has control over the bandwidth usage. Companies like Google and Netflix design the products they offer and control how they use bandwidth. The end user just uses the service, generally not needing to particularly care how much bandwidth it uses. If you want rational resource consumption, the costs of the usage of the resource have to be borne by the party that can control the use of the resource.

Your benefit argument is not rational, it's just spin. Without ISPs, services like Amazon or Netflix would have nobody to serve. The assumption that traffic between service providers and end users benefits both parties roughly equally is a perfectly rational one, and it's the one Internet companies have been using to drive their peering decisions for decades.

It is perfectly rational to assume that when an AT&T customer accesses Netflix, the packets that flow between AT&T and Netflix benefit both parties equally and thus the costs to carry that traffic should be split evenly between AT&T and Netflix. AT&T cannot move their customers to make the traffic cheaper to deliver, but Netflix does place their servers precisely where it is cheapest to generate traffic. Similarly, it is a simple fact that it is cheaper to have a small number of large bandwidth endpoints than a large number of small bandwidth endpoints. Thus Netflix incurs costs on its network that are substantially lower than AT&T incurs on its network for the same traffic. This has always been the conditions that have triggered settlement-based peering.

Comment: Re:IRL (Score 1) 204

by JoelKatz (#48138477) Attached to: Netflix Video Speed On FiOS Doubles After Netflix-Verizon Deal

Right. Each party pays half the costs of the traffic. When the costs don't naturally split in half, settlement-based peering is used.

Amazon, by intentional design, places servers that generate huge amounts of traffic in places where it costs them the least possible to deliver that traffic to AT&T. Meanwhile, it is much more expensive for AT&T to deliver that traffic to their customers because they can't move just to bring traffic costs down. We presume the traffic benefits AT&T and Amazon equally, so they should each pay half the cost. So Amazon owes AT&T half the difference between what it costs Amazon to carry the outbound traffic over their network and what it costs AT&T to carry the inbound traffic over their network.

This is how the Internet has worked for decades.

Comment: Re:You can copyright maps and manuals (Score 1) 146

by JoelKatz (#48107049) Attached to: Google Takes the Fight With Oracle To the Supreme Court

This is precisely what copyright does *NOT* cover. There must be millions of equally good ways of doing the same thing, and you may protect the non-functional aspects of the one way that you creatively chose. Here, the name is purely functional -- play(soundname) is the only way to get the API to play a sound -- it is the one way to achieve a particular functional result, so it cannot be protected by copyright.

You can copyright a sentence you solely authored if it has sufficient creative expression. But you cannot enforce that copyright against someone who uses that sentence because it is the only practical way to achieve a particular functional result. If the sentence uses an API, then complying with the API is the only way to achieve the functional result desired. The purpose of APIs is to standardize the way to achieve particular results.

Comment: Re: Oracle (Score 1) 146

by JoelKatz (#48106979) Attached to: Google Takes the Fight With Oracle To the Supreme Court

Right, but the question is whether that copyright is enforceable against another implementation of that same API. For example, in Lexmark v. SCC, the Toner Loading Program was held to be copyrightable, but the copyright was not enforceable against SCC because SCC's use of the TLP was purely functional.

Something can be copyrightable but that copyright not enforceable if the use of the work is purely functional and used in a way where it is not practical to achieve the same result in any other way than using the covered work. Interoperating with implementations of the API is a functional goal, and if you *must* use the API to do that, then the API's copyright is not enforceable against those using it to achieve that functional purpose.

If you want to own every way to do achieve a particular functional result, you need a patent.

Comment: Re: Oracle (Score 1) 146

by JoelKatz (#48106941) Attached to: Google Takes the Fight With Oracle To the Supreme Court

All these things are purely functional though. Copyright doesn't protect functional aspects, you need patents for that.

Say you have two programs that work together. What you can change on each side are the creative implementation choices. What is required for them to work are the functional aspects. By "API", we specifically mean the functional parts needed for the two to work together and are specifically ignoring the implementation choices that each side can make however it wants.

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.