When you pay for Spotify etc., you aren't paying a musician for their work. You're paying to copy bits on their behalf. Anybody can copy bits without permission, which is why copyright infringement is so widespread.

Paying a musician for their work involves going to see them live, or alternative business models, such as ones based on the Street Performer Protocol. In those cases, you're actually paying a musician to create music.

Could you actually read my comment all the way through instead of stopping at the first few words and assuming I don't know what a web app is? I've been writing web apps for about 15 years. You don't have to explain to me how they work.

the operator of the Web app would've had to copy the AGPL'd software onto their server. They can't make that copy without a license.

As I stated in the comment you replied to, this is something that is explicitly excluded from copyright protection in the USA, so why do they need a license?

My question is not "hur dur, what's a web app?", it's "copyright in the USA doesn't provide them with enough power to enforce this as far as I can see, so what gives?"

Just because they make the data generally available doesn't mean you're allowed to have a copy of it.

Copyright doesn't cover having a copy. That's property law, not copyright law. For example: if you steal a book from a shop, at no point has the copyright holder given you permission to have that copy, yet you haven't committed copyright infringement.

Copyright covers making copies. The copies you make when using it in a web application - installing on the server, copying into RAM, etc. - are explicitly excluded from copyright protection by USA law.

treats web deployment as a trigger to license compliance

How does this work in the USA? If you obtain it from them directly, they are giving you a copy, you aren't copying it yourself - so that's not copyright infringement. Copying software as an essential step in using it does not count as copyright infringement in the USA - so installing it on your server doesn't count as copyright infringement. Responding to incoming web queries doesn't copy any of their work - so that's not copyright infringement. So if you aren't doing anything that is protected by copyright, why do you need a license?

Apple still has feature fragmentation. Airdrop is going to be Iphone 5 or above only.

That's not relevant to developers though. Airdrop is implemented behind an activity view. Any iOS application using activity views gets Airdrop support included automatically when it is available, and they get their current behaviour when it's unavailable. They don't have to do anything to support both cases, it all just works automatically.

Compare this to an experience we had with building an application for Android recently. The client came back and asked us when we were adding certain form fields. We were puzzled - the developer had told us they were already in there. We looked at it - they were in there, but their selected/deselected state was practically indistinguishable. We talked to the developer - it looked fine to him. These were standard form controls, and they looked different on every device we had, to the point where they were invisible or defective on some. We ended up having to use custom graphics instead.

You really can't compare iOS "fragmentation" with Android fragmentation. They really are two entirely different things.

That was the point of the Apple graphic, sure, but who cares? Developers, sure, but the evidence is that that doesn't matter, because developers will follow the users.

I'm one of those developers. Developers will follow the users that are willing to buy and use our applications. There are more Android users, sure, but the users that are willing to buy and use our applications are overwhelmingly iOS users. Add in the problem of having to support ancient versions of Android, and you'll find that the cost-benefit ratio is far better for iOS than Android.

We really don't see that changing. Google aren't fixing the fragmentation problem, and the source of Android's growth - the people who don't care if they have a smartphone or not but are being upgraded to cheap Android phones - aren't a source of profit for us. In fact they are actually making the version problem worse because they are less likely to upgrade.

Already some app developers (particular game makers) are seeing Android revenues surpass iOS revenues

By "some", you mean one company with two apps, and their first app didn't even compare like-for-like.

Most Apps built for iOS5 are often a few recompiles away from running on iOS6.

No, that's not true, it would be awful if that were the case. Virtually all applications built for iOS 5 will run unmodified on iOS 6, no recompile needed. If there's an app that runs on an earlier version of iOS but not a newer version, chances are, the developers have done something they shouldn't have.

That's one of the reasons behind some of Apple's rules - e.g. you can't use undocumented APIs because they might not be there in the same form in the next version of iOS, or you can't modify an Apple control's view hierarchy because they might decide to present something differently in the future.

I suppose someone will chime in suggesting they mean the Apple TV which could be a valid point, except the market penetration of those are MUCH smaller, and the fact that they do not have any AAA titles that rival the competitors.

The market penetration is low because, right now, it's just a vehicle to play iTunes content on your television. They do not have any AAA titles because Apple hasn't opened up the SDK yet. Apple TVs run iOS internally and are roughly as powerful as their mobile devices.

Now that officially-blessed game controllers are coming to iOS 7, all Apple really have to do is open up the SDK, which will be very similar to the current iOS SDK, add internal storage, and put an App Store application on the Apple TV. Suddenly there's a ~$199 console on the market with a horde of iOS developers able to port their existing games very easily. The App Store is far easier to publish on than traditional games consoles and there's a lot of iOS developers who are champing at the bit to put their games on Apple's new game console.

Is it as powerful as the next-gen consoles? No. Can it play lots of enjoyable, cheap games with decent graphics? Yes. It doesn't have to be the most powerful console to be the most profitable console.

I assumed developers would be thinking about security first with e-commerce.

These are developers who, when faced with the problem of how to build an e-commerce site, think "I know, I'll use my favourite blogging software". Assuming they can tie their shoelaces is a stretch, let alone thinking about security.

Right about now, somebody is champing at the bit to reply saying that Wordpress has outgrown its blogging roots and is now a proper CMS. I invite anybody tempted to believe that nonsense to look at Wordpress' database schema and make their own mind up.

JS JIT in apps

I think this one is likely to happen now. The reason it is currently unavailable is due to security restrictions on application processes. Apple make an exception for Safari, but they don't want to do it for all applications due to the possibility for abuse. However Apple have recently been moving parts of their system (e.g. mail composer window) over to a new internal API that lets them embed view controllers from other processes. Once they move the web views over to this system, they'll be able to grant the exception for the process that handles web views without granting the exception for all applications.

I'm personally hoping that this new architecture will be made public and provide support for greater collaboration between apps, but that might be something we don't see until iOS 8.

I have never understood why so many people are so keen on putting a clock onto a website. Everyone has a clock.

If you aren't talking agile with the customer, you aren't doing agile. Agile isn't a way of producing code, it's a way of producing what the customer wants. It involves them intrinsically.

When we build an app for a client, they often start off with a long list of features they want. I've seen companies take their money, go off and build what they asked for, then watch the client discover that once their users are actually using it, it becomes apparent that half the features they asked for are unnecessary and half the features they need they didn't include. A lot of the information that makes this apparent is information that is unavailable to you at the start of a project.

Instead, we focus on building the minimum feature set necessary for the client to start getting value, then see how it is used in practice, and plan the following features using this information. The client ends up getting what they really needed after all and ends up much happier.

The difference between the two approaches is that the first is traditional and the second is agile. It is also something that you cannot do on your own as an internal practice - the client needs to be involved in these decisions at each step along the way. Whether you call it agile in front of them or not doesn't really matter - you are talking agile with the customer one way or the other if you are doing it properly.

talk about outcome, not process

Talking about outcome not process only makes sense if you assume the client is not involved in the process, and that's a recipe for building something that is ill-suited for the client's needs. Agile development assumes the client is an integral part of the development process for a reason.

This leaves only the iPhone 4 and 4S as devices Apple sell without the taller screen. If there's any hint at an upcoming product strategy, it would be that they might drop those models to streamline production.

No, profiting does not inherently make something not fair use. For example, if I write a game review for a magazine and take screenshots, that magazine can be sold for a profit regardless of the fact that the screenshots are derivative works of something I don't hold the copyright to. The fact that the magazine is sold for profit doesn't stop the use of those screenshots from being fair use.

There's absolutely no way anyone can realistically claim an LP isn't a 'derivative work' under copyright

He didn't say that it wasn't a derivative work, he said it was fair use. The two are not mutually exclusive, in fact most instances of fair use are derivative works. Fair use means that you can copy a copyrighted work legally, not that it isn't copyrighted.