Stand Back, I'm About to Do Some Posting....

Apologies for the silence, I've been a bit busy, what with TTIP, ISDS, UK open standards, data retention, EU copyright review and much else.  But at least we had some great results, as the backlog of links to my posts elsewhere will show....

Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+

Interview: Eben Moglen - "surveillance becomes the hidden service wrapped inside everything"

(This was original published in The H Open in March 2010.)

Free software has won: practically all of the biggest and most exciting Web companies like Google, Facebook and Twitter run on it.  But it is also in danger of losing, because those same services now represent a huge threat to our freedom as a result of the vast stores of information they hold about us, and the in-depth surveillance that implies.

Better than almost anyone, Eben Moglen knows what's at stake.  He was General Counsel of the Free Software Foundation for 13 years, and helped draft several versions of the GNU GPL.  As well as being Professor of Law at Columbia Law School, he is the Founding Director of Software Freedom Law Center.  And he has an ambitious plan to save us from those seductive but freedom-threatening Web service companies.  He explained what the problem is, and how we can fix it.

GM: So what's the threat you are trying to deal with?

EM:  We have a kind of social dilemma which comes from architectural creep.  We had an Internet that was designed around the notion of peerage -  machines with no hierarchical relationship to one another, and no guarantee about their internal architectures or behaviours, communicating through a series of rules which allowed disparate, heterogeneous networks to be networked together around the assumption that everybody's equal. 

In the Web the social harm done by the client-server model arises from the fact that logs of Web servers become the trails left by all of the activities of human beings, and the logs can be centralised in servers under hierarchical control.  Web logs become power.  With the exception of search, which is a service that nobody knows how to decentralise efficiently, most of these services do not actually rely upon a hierarchical model.  They really rely upon the Web  - that is, the non-hierachical peerage model created by Tim Berners-Lee, and which is now the dominant data structure in our world.

The services are centralised for commercial purposes.  The power that the Web log holds is monetisable, because it provides a form of surveillance which is attractive to both commercial and governmental social control.  So the Web with services equipped in a basically client-server architecture becomes a device for surveilling as well as providing additional services.  And surveillance becomes the hidden service wrapped inside everything we get for free.

The cloud is a vernacular name which we give to a significant improvement in the server-side of the web side - the server, decentralised.  It becomes instead of a lump of iron a digital appliance which can be running anywhere.  This means that for all practical purposes servers cease to be subject to significant legal control.  They no longer operate in a policy-directed manner, because they are no longer iron subject to territorial orientation of law. In a world of virtualised service provision, the server which provides the service, and therefore the log which is the result of the hidden service of surveillance, can be projected into any domain at any moment and can be stripped of any legal obligation pretty much equally freely.

This is a pessimal result.

GM:  Was perhaps another major factor in this the commercialisation of the Internet, which saw power being vested in a company that provided services to the consumer?

EM:  That's exactly right.  Capitalism also has its architectural Bauplan, which it is reluctant to abandon.  In fact, much of what the network is doing to capitalism is forcing it to reconsider its Bauplan via a social process which we call by the crappy name of disintermediation.  Which is really a description of the Net forcing capitalism to change the way it takes.  But there's lots of resistance to that, and what's interesting to all of us I suspect, as we watch the rise of Google to pre-eminence, is the ways in which Google does and does not - and it both does and does not - wind up behaving rather like Microsoft in the course of growing up.  There are sort of gravitational propositions that arise when you're the largest organism in an ecosystem. 

GM:  Do you think free software has been a little slow to address the problems you describe?

EM:  Yes, I think that's correct.  I think it is conceptually difficult, and it is to a large degree difficult because we are having generational change.  After a talk [I gave recently], a young woman came up to me and she said: I'm 23 years old, and none of my friends care about privacy.  And that's another important thing, right?, because we make software now using the brains and hands and energies of people who are growing up in a world which has been already affected by all of this.  Richard or I can sound rather old-fashioned.

GM:  So what's the solution you are proposing?

EM:  If we had a real intellectually-defensible taxonomy of services, we would recognise that a number of the services which are currently highly centralised, and which count for a lot of the surveillance built in to the society that we are moving towards, are services which do not require centralisation in order to be technologically deliverable.  They are really the Web repackaged. 

Social networking applications are the most crucial.  They rely in their basic metaphors of operation on a bilateral relationship called friendship, and its multilateral consequences.  And they are eminently modelled by the existing structures of the Web itself. Facebook is free Web hosting with some PHP doodads and APIs, and spying free inside all the time - not actually a deal we can't do better than. 

My proposal is this: if we could disaggregate the logs, while providing the people all of the same features, we would have a Pareto-superior outcome.  Everybody – well, except Mr Zuckenberg - would be better off, and nobody would be worse off.  And we can do that using existing stuff.

The most attractive hardware is the ultra-small, ARM-based, plug it into the wall, wall-wart server, the SheevaPlug.  An object can be sold to people at a very low one-time price, and brought home and plugged into an electrical outlet and plugged into a wall jack for the Ethernet, or whatever is there, and you're done.  It comes up, it gets configured through your Web browser on whatever machine you want to have in the apartment with it, and it goes and fetches all your social networking data from all the social networking applications, closing all your accounts.  It backs itself up in an encrypted way to your friends' plugs, so that everybody is secure in the way that would be best for them, by having their friends holding the secure version of their data.

And it begins to do all the things that we assume we need in a social networking appliance.  It's the feed, it maintains the wall your friends write on - it does everything that provides feature compatibility with what you're used to. 

But the log is in your apartment, and in my society at least, we still have some vestigial rules about getting into your house: if people want to check the logs they have to get a search warrant. In fact, in every society, a person's home is about as sacred as it gets.

And so, basically, what I am proposing is that we build a social networking stack based around the existing free software we have, which is pretty much the same existing free software the server-side social networking stacks are built on; and we provide ourselves with an appliance which contains a free distribution everybody can make as much of as they want, and cheap hardware of a type which is going to take over the world whether we do it or we don't, because it's so attractive a form factor and function, at the price. 

We take those two elements, we put them together, and we also provide some other things which are very good for the world.  Like automatically VPNing everybody's little home network place with my laptop wherever I am, which provides me with encrypted proxies so my web searching, wherever I am, is not going to be spied on.  It means that we have a zillion computers available to the people who live in China and other places where there's bad behaviour.  So we can massively increase the availability of free browsing to other people in the world.  If we want to offer people the option to run onion routeing, that's where we'll put it, so that there will be a credible possibility that people will actually be able to get decent performance on onion routeing networks.

And we will of course provide convenient encrypted email for people - including putting their email not in a Google box, but in their house, where it is encrypted, backed up to all their friends and other stuff.  Where in the long purpose of time we can begin to return email to a condition - if not being a private mode of communication - at least not being postcards to the secret police every day.

So we would also be striking a blow for electronic civil liberties in a way that is important, which is very difficult to conceive of doing in a non-technical way.

GM:  How will you organise and finance such a project, and who will undertake it?

EM:  Do we need money? Yeah, but tiny amounts.  Do we need organisation? Yes, but it could be self-organisation.  Am I going to talk about this at DEF CON this summer, at Columbia University? Yes.  Could Mr Shuttleworth do it if he wanted to? Yes.  It's not going to be done with clicking heels together, it's going to be done the way we do stuff: somebody's going begin by reeling off a Debian stack or Ubuntu stack or, for all I know, some other stack, and beginning to write some configuration code and some glue and a bunch of Python to hold it all together. From a quasi-capitalist point of view I don't think this is an unmarketable product.  In fact, this is the flagship product, and we ought to all put just a little pro bono time into it until it's done.

GM:  How are you going to overcome the massive network effects that make it hard to persuade people to swap to a new service?

EM:  This is why the continual determination to provide social networking interoperability is so important. 

For the moment, my guess is that while we go about this job, it's going to remain quite obscure for quite a while.  People will discover that they are being given social network portability.  [The social network companies] undermine their own network effect because everybody wants to get ahead of Mr Zuckerberg before his IPO.  And as they do that they will be helping us, because they will be making it easier and easier to do what our box has to do, which is to come online for you, and go and collect all your data and keep all your friends, and do everything that they should have done.

So part of how we're going to get people to use it and undermine the network effect, is that way.  Part of it is, it's cool; part of it is, there are people who want no spying inside; part of it is, there are people who want to do something about the Great Firewall of China but don't know how.  In other words, my guess is that it's going to move in niches just as some other things do.

GM:  With mobile taking off in developing countries, might it not be better to look at handsets to provide these services?

EM:  In the long run there are two places where we can conceivably put your identity: one is where you live, and the other is in your pocket.  And a stack that doesn't deal with both of those is probably not a fully adequate stack.

The thing I want to say directed to your point “why don't we put our identity server in our cellphone?”, is that our cellphones are very vulnerable.  In most parts of the world, you stop a guy on the street, you arrest him on a trumped-up charge of any kind, you get him back to the station house, you clone his phone, you hand it back to him, you've owned him.

When we fully commoditise that [mobile] technology, then we can begin to do the reverse of what the network operators are doing.  The network operators around the world are basically trying to eat the Internet, and excrete proprietary networking.  The network operators have to play the reverse if telephony technology becomes free.  We can eat proprietary networks and excrete the public Internet.  And if we do that then the power game begins to be more interesting.

Interview: Linus Torvalds - "I don't read code any more"

(This was originally published in The H Open in November 2012.)

I was lucky enough to interview Linus quite early in the history of Linux – back in 1996, when he was still living in Helsinki (you can read the fruits of that meeting in this old Wired feature.) It was at an important moment for him, both personally – his first child was born at this time – and in terms of his career. He was about to join the chip design company Transmeta, a move that didn't really work out, but led to him relocating to America, where he remains today.

That makes his trips to Europe somewhat rare, and I took advantage of the fact that he was speaking at the recent LinuxCon Europe 2012 in Barcelona to interview him again, reviewing the key moments for the Linux kernel and its community since we last spoke.

Glyn Moody: Looking back over the last decade and half, what do you see as the key events in the development of the kernel?

Linus Torvalds: One big thing for me is all the scalability work that we did. We've gone from being OK on 2 or 4 CPUs to the point where basically you can throw 4000 [at it] – you won't scale perfectly, but most of the time it's not the kernel that's the bottleneck. If your workload is somewhat sane we actually scale really well. And that took a lot of effort.

SGI in particular worked a lot on scaling past a few hundred CPUs. Their initial patches could just not be merged. There was no way we could take the work they did and use it on a regular PC because they added all this infrastructure to work on thousands of CPUs. That was way too expensive to do when you had only a couple.

I was afraid for the longest time that we would have the high-performance kernel for the big machines, and the source code would be separate from the normal kernel. People worked a lot on just making sure that we had a clean code base where you can say at compile time that, hey, I want the kernel that works for 4000 CPUs, and it generates the code for that, and at the same time, if you say no, I want the kernel that works on 2 CPUs, the same source code compiles.

It was something that in retrospect is really important because it actually made the source code much better. All the effort that SGI and others spent on unifying the source code, actually a lot of it was clean-up – this doesn't work for a hundred CPUs, so we need to clean it up so that it works. And it actually made the kernel more maintainable. Now on the desktop 8 and 16 CPUs are almost common; it used to be that we had trouble scaling to an 8, now it's like child's play.

But there's been other things too. We spent years again at the other end, where the phone people were so power conscious that they had ugly hacks, especially on the ARM side, to try to save power. We spent years doing power management in general, doing the kind of same thing - instead of having these specialised power management hacks for ARM, and the few devices that cellphone people cared about, we tried to make it across the kernel. And that took like five years to get our power management working, because it's across the whole spectrum.

Quite often when you add one device, that doesn't impact any of the rest of the kernel, but power management was one of those things that impacts all the thousands of device drivers that we have. It impacts core functionality, like shutting down CPUs, it impacts schedulers, it impacts the VM, it impacts everything.

It not only affects everything, it has the potential to break everything which makes it very painful. We spent so much time just taking two steps forward, one step back because we made an improvement that was a clear improvement, but it broke machines. And so we had to take the one step back just to fix the machines that we broke.

Realistically, every single release, most of it is just driver work. Which is kind of boring in the sense there is nothing fundamentally interesting in a driver, it's just support for yet another chipset or something, and at the same time that's kind of the bread and butter of the kernel. More than half of the kernel is just drivers, and so all the big exciting smart things we do, in the end it pales when compared to all the work we just do to support new hardware.

Glyn Moody: What major architecture changes have there been to support new hardware?

Linus Torvalds: The USB stack has basically been re-written a couple of time just because some new use-case comes up and you realise that hey, the original USB stack just never took that into account, and it just doesn't work. So USB 3 needs new host controller support and it turns out it's different enough that you want to change the core stack so that it can work across different versions. And it's not just USB, it's PCI, and PCI becomes PCIe, and hotplug comes in.

That's another thing that's a huge difference between traditional Linux and traditional Unix. You have a [Unix] workstation and you boot it up, and it doesn't change afterwards - you don't add devices. Now people are taking adding a USB device for granted, but realistically that did not use to be the case. That whole being able to hotplug devices, we've had all these fundamental infrastructure changes that we've had to keep up with.

Glyn Moody: What about kernel community – how has that evolved?

Linus Torvalds: It used to be way flatter. I don't know when the change happened, but it used to be me and maybe 50 developers - it was not a deep hierarchy of people. These days, patches that reach me sometimes go through four levels of people. We do releases every three months; in every release we have like 1000 people involved. And 500 of the 1000 people basically send in a single line change for something really trivial – that's how some people work, and some of them never do anything else, and that's fine. But when you have a thousand people involved, especially when some of them are just these drive-by shooting people, you can't have me just taking patches from everybody individually. I wouldn't have time to interact with people.

Some people just specialise in drivers, they have other people who they know who specialise in that particular driver area, and they interact with the people who actually write the individual drivers or send patches. By the time I see the patch, it's gone through these layers, it's seldom four, but it's quite often two people in between.

Glyn Moody: So what impact does that have on your role?

Linus Torvalds: Well, the big thing is I don't read code any more. When a patch has already gone through two people, at that point, I can either look at the patch and say: no, all your work was wasted, and micromanage at that level – and quite frankly I don't want to do that, and I don't have the capacity to do that.

So most of the time, when it comes to the major subsystem maintainers, I trust them because I've been working with them for 5, 10, 15 years, so I don't even look at the code. They tell me these are the changes and they give me a very high-level overview. Depending on the person, it might be five lines of text saying this is roughly what has changed, and then they give me a diffstat, which just says 15 lines have changed in that file, and 25 lines have changed in that file and diffstat might be a few hundred lines because there's a few hundred files that have changed. But I don't even see the code itself, I just say: OK, the changes happen in these files, and by the way, I trust you to change those files, so that's fine. And then I just say: I'll take it.

Glyn Moody: So what's your role now?

Linus Torvalds: Largely I'm managing people. Not in the logistical sense – I obviously don't pay anybody, but I also don't have to worry about them having access to hardware and stuff like that. Largely what happens is I get involved when people start arguing and there's friction between people, or when bugs happen.

Bugs happen all the time, but quite often people don't know who to send the bug report to. So they will send the bug report to the Linux Kernel mailing list – nobody really is able to read it much. After people don't figure it out on the kernel mailing list, they often start bombarding me, saying: hey, this machine doesn't work for me any more. And since I didn't even read the code in the first place, but I know who is in charge, I end up being a connection point for bug reports and for the actual change requests. That's all I do, day in and day out, is I read email. And that's fine, I enjoy doing it, but it's very different from what I did.

Glyn Moody: So does that mean there might be scope for you to write another tool like Git, but for managing people, not code?

Linus Torvalds: I don't think we will. There might be some tooling, but realistically most of the things I do tend to be about human interaction. So we do have tools to figure out who's in charge. We do have tools to say: hey, we know the problem happens in this area of the code, so who touched that code last, and who's the maintainer of that subsystem, just because there are so many people involved that trying to keep track of them any other way than having some automation just doesn't work. But at the same time most of the work is interaction, and different people work in different ways, so having too much automation is actually painful for people.

We're doing really well. The kind of pain points we had ten years ago just don't exist any more. And that's largely because we used to be this flat hierarchy, and we just fixed our tools, we fixed our work flows. And it's not just me, it's across the whole kernel there's no single person who's in the way of any particular workflow.

I get a fair amount of email, but I don't even get overwhelmed by email. I love reading email on my cellphone when I travel, for example. Even during breaks, I'll read email on my cellphone because 90% of them I can just read for my information that I can archive. I don't need to do anything, I was cc'd because there was some issue going on, I need to be aware of it, but I don't need to do anything about that. So I can do 90% of my work while travelling, even without having a computer. In the evening, when I go back to the hotel room, I'll go through [the other 10%].

Glyn Moody: 16 years ago, you said you were mostly driven by what the outside world was asking for; given the huge interest in mobiles and tablets, what has been their impact on kernel development?

Linus Torvalds: In the tablet space, the biggest issue tends to be power management, largely because they're bigger than phones. They have bigger batteries, but on the other hand people expect them to have longer battery life and they also have bigger displays, which use more battery. So on the kernel side, a tablet from the hardware perspective and a usage perspective is largely the same thing as a phone, and that's something we know how to do, largely because of Android.

The user interface side of a tablet ends up being where the pain points have been – but that's far enough removed from the kernel. On a phone, the browser is not a full browser - they used to have the mobile browsers; on the tablets, people really expect to have a full browser – you have to be able to click that small link thing. So most of the tablet issues have been in the user space. We did have a lot of issues in the kernel over the phones, but tablets kind of we got for free.

Glyn Moody: What about cloud computing: what impact has that had on the kernel?

Linus Torvalds: The biggest impact has been that even on the server side, but especially when it comes to cloud computing, people have become much more aware [of power consumption.] It used to be that all the power work originally happened for embedded people and cellphones, and just in the last three-four years it's the server people have become very power aware. Because they have lots of them together; quite often they have high peak usage. If you look at someone like Amazon, their peak usage is orders of magnitude higher than their regular idle usage. For example, just the selling side of Amazon, late November, December, the one month before Christmas, they do as much business as they do the rest of the year. The point is they have to scale all their hardware infrastructure for the peak usage that most of the rest of the year they only use a tenth of that capacity. So being able to not use power all the time [is important] because it turns out electricity is a big cost of these big server providers.

Glyn Moody: Do Amazon people get involved directly with kernel work?

Linus Torvalds: Amazon is not the greatest example, Google is probably better because they actually have a lot of kernel engineers working for them. Most of the time the work gets done by Google themselves. I think Amazon has had a more standard components thing. Actually, they've changed the way they've built hardware - they now have their own hardware reference design. They used to buy hardware from HP and Dell, but it turns out that when you buy 10,000 machines at some point it's just easier to design the machines yourself, and to go directly to the original equipment manufacturers and say: I want this machine, like this. But they only started doing that fairly recently.

I don't know whether [Amazon] is behind the curve, or whether Google is just more technology oriented. Amazon has worked more on the user space, and they've used a fairly standard kernel. Google has worked more on the kernel side, they've done their own file systems. They used to do their own drivers for their hard discs because they had some special requirements.

Glyn Moody: How useful has Google's work on the kernel been for you?

Linus Torvalds: For a few years - this is five or ten years ago - Google used to be this black hole. They would hire kernel engineers and they would completely disappear from the face of the earth. They would work inside Google, and nobody would ever hear from them again, because they'd do this Google-specific stuff, and Google didn't really feed back much.

That has improved enormously, probably because Google stayed a long time on our previous 2.4 releases. They stayed on that for years, because they had done so many internal modifications for their specialised hardware for everything, that just upgrading their kernel was a big issue for them. And partly because of the whole Android project they actually wanted to be much more active upstream.

Now they're way more active, people don't disappear there any more. It turns out the kernel got better, to the point where a lot of their issues just became details instead of being huge gaping holes. They were like, OK, we can actually use the standard kernel and then we do these small tweaks on top instead of doing these big surgeries to just make it work on their infrastructure.

Glyn Moody: Finally, you say that you spend most of your time answering email: as someone who has always seemed a quintessential hacker, does that worry you?

Linus Torvalds: I wouldn't say that worries me. I end up not doing as much programming as sometimes I'd like. On the other hand, it's like some kinds of programming I don't want to do any more. When I was twenty I liked doing device drivers. If I never have to do a single device driver in my life again, I will be happy. Some kind of headaches I can do without.

I really enjoyed doing Git, it was so much fun. When I started the whole design, started doing programming in user space, which I had not done for 15 years, it was like, wow, this is so easy. I don't need to worry about all these things, I have infinite stack, malloc just works. But in the kernel space, you have to worry about locking, you have to worry about security, you have to worry about the hardware. Doing Git, that was such a relief. But it got boring.

The other project I still am involved in is the dive computer thing. We had a break in on the kernel.org site. It was really painful for the maintainers, and the FBI got involved just figuring out what the hell happened. For two months we had almost no kernel development – well, people were still doing kernel development, but the main site where everybody got together was down, and a lot of the core kernel developers spent a lot of time checking that nobody had actually broken into their machines. People got a bit paranoid.

So for a couple of months my main job, which was to integrate work from other people, basically went away, because our main integration site went away. And I did my divelog software, because I got bored, and that was fun. So I still do end up doing programming, but I always come back to the kernel in the end.

"The H Open" is Closed and Offline; Here's What I Aim to Do...

Long-time readers of this blog may recall that for some years I wrote for the UK Heise title "The H Open".  Sadly, that closed last year; even more sadly, Heise seems to have taken its archive off line.  That raises all sorts of interesting questions about the preservation of digital knowledge, and the responsibility of publishers to keep titles that they have closed publicly accessible - not least to minimise link-rot.

However, here I want to concentrate on the question of what I, personally, can do about this.  After all, however minor my columns for The H Open were, they none the less form a part of the free software world's history, however footling.  Of course, I have back-up copies of all of my work, so the obvious thing to do is to post them here.  I can do that, because I never surrendered the copyright, and they therefore remain mine to do with as I please.

There are quite a few of them - nearly one hundred - so I have decided to begin with two of the most popular pieces that I published in The H Open: an interview with Linus from the end of my output, and an interview with Eben Moglen from the beginning.  I will then try to work my way through the other columns as and when I have time.  Don't hold your breath....

TAFTA/TTIP: European Commission Tells Us to "Get the Facts"; Here They Are

Readers with long memories may recall in the dim and distant past that at one time "Get the Facts" was a favourite war-cry of Microsoft when attacking GNU/Linux and free software.  Of course the "facts" were anything but, and I spent quite some time debunking them.  Significantly, once the claims had been debunked often enough, and by enough people, the campaign went away, and was never heard of again.

Rather interestingly, the European Commission now seems intent on recapitulating that saga and its fate.  I've noticed several times recently it has invoked the "facts", and I've tried to show why its idea of facts leaves much to be desired.  So far, most of my columns about TAFTA/TTIP have been over on Computerworld UK, under the rubric "TTIP Update."  There also a fair few on Techdirt.  Here I'd like to address a rather interesting addition to the "Get the Facts" collection that doesn't really sit well in either publication, since it's in German.

It comes in response to an epetition from campact.de, that is currently storming away (at the time of writing it has nearly 300,000 signatures.)  Evidently worried by that momentum, the European Commission has issued another of its point-by-point commentaries.  I will repay the compliment by rebutting its rebuttals.  I'll use the original German, but you can use a Google Translate version if you wish.

Campact behauptet, dass TTIP es ausländischen Unternehmen zukünftig ermögliche, Gesetze in Europa auszuhöhlen. Falsch

Ein bereits bestehendes Gesetz kann nicht durch ein Handelsabkommen "ausgehöhlt" werden. So kann beispielsweise ein bestehendes Verbot von Fracking oder von Chlorhühnerfleisch nicht in Frage gestellt werden. Das einzige, was das Abkommen unterstreicht – und das ist auch im Interesse der EU – ist ein Diskriminierungsverbot. Das heißt: Was für Inländer gilt, muss auch für Ausländer gelten. Dies ist besonders wichtig bei Investitionen, die entscheidend für wirtschaftliche Entwicklung und die Schaffung von Arbeitsplätzen sind. Hier brauchen wir Stabilität und Sicherheit, auch für europäischen Investitionen im Ausland. Allerdings heißt Investitionsschutz nicht, den Unternehmen unbegrenzte Rechte einzugestehen, oder die Möglichkeit zu geben, jedwede nationale Gesetzgebung in Frage zu stellen. Investitionsschutzklauseln dürfen nur in sehr begrenzten Bereichen eingesetzt werden, z.B. wenn gegenüber inländischen Firmen diskriminiert wird oder wenn eine Firma im Ausland ohne Entschädigung enteignet wird.

Well, it's true that a trade agreement can't change laws directly.  But it can have a chilling effect, as occurred in Canada.  When NAFTA was brought in, practically every proposed law to protect the environment was dropped when threats were received from US companies that they would use investor-state dispute settlement (ISDS), available under NAFTA, to sue the Canadian government.  That's a real hollowing out of laws not just in the future, but also in the present, since governments will be unwilling to run the risk of getting sued if they apply them rigorously.

The Commission also claims that ISDS is particularly important for investment; but here's what its own site says on the subject:

Total US investment in the EU is three times higher than in all of Asia.

EU investment in the US is around eight times the amount of EU investment in India and China together.

EU and US investments are the real driver of the transatlantic relationship, contributing to growth and jobs on both sidesof the Atlantic. It is estimated that a third of the trade across the Atlantic actually consists of intra-company transfers.

That's all without ISDS: so why bring it in?

Campact behauptet, dass TTIP zu Privatisierungen im Bereich Wasserversorgung, Gesundheit und Bildung führe. Falsch.

Das TTIP-Abkommen hat nichts mit verordneten Privatisierungen zu tun – das wird von den Regierungen alleine beschlossen. Kein Freihandelsabkommen verpflichtet Mitgliedsstaaten zur Liberalisierung oder Privatisierung der Wasserversorgung oder anderer öffentlicher Dienstleistungen, z.B. des öffentlichen Gesundheitswesens, des öffentlichen Verkehrswesens oder des Bildungswesens.

Again, that misses the point, probably wilfully.  This is not about formally forcing these privatisations: but that will be the effect of ISDS, since governments will find themselves sued for billions of Euros if they don't allow commons to be privatised, since that would reduce expectations of future profits - a big no-no under ISDS.

Campact behauptet, dass TTIP die Tore für Fracking, Chlorhühnchen oder Genfood öffne. Falsch.

Fracking, Chlorhühnchen und Genfood sind in der EU verboten oder streng reguliert. Das wird auch ein Freihandelsabkommen nicht ändern. Nur Regierungen oder Parlamente können entscheiden, Gesetzgebung zu ändern. Die Europäische Union wird unsere hohen EU-Standards nicht zur Verhandlung stellen

Even if that's true - and since the negotiations are completely secret, we have no way of telling until it's too late - it's already become clear how cholorinated chickens and GMOs will be brought to Europe: the institution of a transatlantic Regulatory Council.  As I've already discussed at length elsewhere, this body will not only be able to veto new regulations unless they favour transatlantic trade, but they will be able to suggest to both EU and US lawmakers *directly* what new laws should be brought in - for example, those mandating that EU supermarkets must accept chickens washed in chlorine, or beef pumped up with growth hormones.

Campact behauptet, dass TTIP die Rechte von Internetnutzern einschränken werde. Falsch.

Sowohl die EU als auch die USA verfügen bereits über effiziente Vorschriften zum Schutz des Rechts des geistigen Eigentums, wenn auch der Weg zum Ziel gelegentlich unterschiedlich ist. TTIP soll den Handel zwischen der EU und den USA vereinfachen, ohne diese Vorschriften aufzuweichen. „ACTA durch die Hintertür“ wird es mit TTIP nicht geben.

Well, the protection of intellectual monopolies may be efficient, but that didn't stop the US and EU trying to ram through ACTA, did it? So what's to stop that now?  Claims that TAFTA/TTIP won't be ACTA through the backdoor ring a little hollow thanks to a recent leak that reveals what one of the EU's chief negotiators has to say on the subject of a "Christmas list of items" that lobbyists want in this area:

According to the negotiator, the most repeated request on the Christmas list was in "enforcement". Concerning this, companies had made requests to "improve and formalize" as well as for the authorities to "make statements". The Commission negotiator said that although joint 'enforcement statements' do not constitute "classical trade agreement language" -- a euphemism for things that do not belong in trade agreements -- the Commission still looks forward to "working in this area".

Sounds like ACTA through the back door to me...

Campact behauptet, dass TTIP undemokratisch sei und gewählte Politiker keine Einflussmöglichkeit hätten. Falsch.

Regierungen der Mitgliedstaaten, um sie vor, während und nach den Verhandlungsrunden „live“ über den Verhandlungsstand aufzuklären und deren Positionen zu einzubeziehen. Das Europäische Parlament wird ebenfalls regelmäßig über den Verhandlungsstand informiert, damit die Standpunkte und Interessen der demokratisch gewählten europäischen Abgeordneten in die Verhandlungen einfließen können. Am Ende sind es die EU-Mitgliedstaaten und das Europäische Parlament, die das letzte Wort über TTIP haben. 

So let's look at those claims.  It may well be that the Member States are kept informed - since they never pass on anything to their electorate, that hardly helps the public, say, who remain in the dark.  The European Parliament as a whole certainly isn't kept informed, even if one or two selected individuals are given information under embargo that they also cannot pass on.  And that "last word" that the European Parliament has over TTIP is all or nothing: as with ACTA, either it accepts the whole package, or it rejects the whole package.  That means it will be unable to remove the bad bits and keep the good bits.  By using emotional blackmail about the good bits, the European Commission will doubtless try to force through things like ISDS even though the European Parliament is increasingly alarmed about its dangers.

Worum soll es dann in diesem Handelsabkommen gehen?

Meistens verfolgen unsere Behörden auf beiden Seiten des Atlantiks im Grunde das gleiche Ziel, wenn sie Standards und Zulassungsverfahren festlegen: Sie wollen Menschen vor Risiken für ihre Gesundheit schützen, für Sicherheit etwa am Arbeitsplatz sorgen, die Umwelt schützen oder die finanzielle Sicherheit einer Firma garantieren. Um dies zu erreichen, haben wir auf beiden Seiten des Atlantiks aber häufig unterschiedliche regulatorische Strukturen und Traditionen. Daraus entstehen, obwohl das oft gar nicht beabsichtig ist, unterschiedliche Regelungen, die den Zugang zum anderen Markt oftmals erheblich erschweren. Schätzungen zufolge entsprechen aber allein diese bürokratischen Handelshürden einem Zoll von 10-20 Prozent.

Well, the aim may be the same, but the results are very different.  Here in Europe, we have the Precautionary Principle: that's not only absent in the US, but US industries have said many times that one of their *demands* for TAFTA/TTIP is that the Precautionary Principle should be dismantled.  Similarly, here in Europe we have the very strict REACH - Registration, Evaluation, Authorisation and Restriction of Chemicals.  Again, US industries haves aid they want to get rid of this "barrier" to their profits.

Equally, nobody would suggest that social, employment or environmental standards in the US are anywhere near as stringent as those in the EU: the idea that they are somehow "equivalent" is ridiculous, and shows that the true intent of the European Commission is to water down EU standards to US levels.

Warum das alles? Die transatlantische Handels- und Investitionspartnerschaft könnte wie ein Konjunkturpaket wirken: Das Abkommen könnte der EU einen Wachstumsschub von 0,5 Prozent des Bruttoinlandsprodukts erbringen, das sind rund 120 Milliarden Euro, oder 500 Euro pro Haushalt – denn letztendlich bedeuten Kosteneinsparungen für Unternehmen auch preiswertere Produkte, mehr Qualität und Auswahl.

What that fails to mention is that the 119 billion euro GDP uplift would only come in 2027, and is the *most optimistic* scenario, which assumes massive deregulation.  So it would not produce more quality, but US-style chlorine-washed chickens, hormone-injected beef and GMOs.

And the idea that every household would somehow magically receive 500 euros, as if from some TAFTA/TTIP Father Christmas, is just dishonest: even if this impossibly ambitiously deregulation were achieved, most of the GDP boost would go to the giant international companies, which would then doubtless offshore their profits, so you can forget about any "trickle-down" effect either.

Meanwhile, to pay for those boosted bottom lines, and billions in bonuses for corporate fat-cats, ordinary people would find their jobs disappearing overseas, their food quality lowered, and broader environmental degradation caused by widespread fracking and extractive industries indifferent to the damage they cause.  If anyone needs to get the facts, it's the European Commission.

Towards a Post-H.264 World

In my post yesterday about Cisco making the code for its H264 codec available, I noted that the really important news was that Mozilla was working on Daala, a fully open next generation codec. One of the key people on the team doing that is Monty Montgomery, and he's written a really interesting blog post about the announcement and its background, which I recommend thoroughly (the discussion in the comments is also very illuminating):

On Open Enterprise blog.

Is Cisco Open-Sourcing its Code - or Openwashing?

You know that open source has won when everybody wants to wrap themselves in a little bit of openness in order to enjoy the glow. That's good news - provided it represents a move to true open source and not fauxpen source. Which brings me to the following news:

On Open Enterprise blog.

Of Surveillance Debates and Open Clinical Data

Revelations about the staggering levels of online surveillance that are now routine in this country have been met with a stunning silence from the UK government. There's an important meeting tomorrow where three MPs from the main parties are trying to get some kind of debate going on this crucial issue. It would be helpful if you could ask your MP to participate. Here's what I've written:

On Open Enterprise blog.

Open Clinical Trials: Please Write to Health Minister

I first wrote about the importance of open clinical trials two years ago. More recently, I urged people to contact their MEPs for a crucial vote that was taking place in one of the committees in the European Parliament. The AllTrials site, which is coordinating the fight to obtain access to this vital public health information, now asks for help during another stage in the battle for open data:

On Open Enterprise blog.

Brazil Grapples with the Problem of Software Patents

Software patents have figured quite frequently on this blog, usually in terms of their deep problems, especially for free software. Although I've tended to write about what's happening in Europe and the US, the rest of the world is also beginning to experience the same issues as computers enter ever-more deeply into daily life there, and is similarly seeking to come up with solutions.

On Open Enterprise blog.

Is Mozilla on the Bridge of Khazad - or on the Fence?

Last week I explored at some length the curious reasons that Sir Tim Berners-Lee gave for supporting the proposal to add hooks for DRM into HTML5. 

On Open Enterprise blog.

Linux Foundation Celebrates with a Quadruple Scotch

My last two posts about the Linux Foundation have been about how it is broadening its scope to embrace open projects well beyond the Linux kernel. For example, there was the OpenDaylight Project, and then the OpenBEL. Now we have this:

On Open Enterprise blog.

ISDS: ACTA by the Back Door?

As I noted in my last TTIP update, things are beginning to get moving again on this front. One reflection of the growing interesting in this important trade and investment agreement was the public discussion entitled "Internet, Trade and Democracy: Transatlantic Relations under the Shadow of Surveillance", held in Berlin, and organised by Internet & Society Collaboratory and the blogger project FutureChallenges.org of the Bertelsmann Stiftung.

On Open Enterprise blog.

Tim Berners-Lee on Why HTML5 "Needs" DRM

A couple of week ago, I discussed the awful idea of adding DRM to the official HTML5 standard, and where that would lead us. More recently, Tim Berners-Lee wrote a piece about openness that included the following comment:

On Open Enterprise blog.

TTIP Update III

It's been fairly quiet on the TAFTA/TTIP front recently. That's largely because Europe shuts down for its summer hols during August, and has only just got going again. Unfortunately (for TAFTA/TTIP), the next round of negotiations has just been cancelled because the US administration was busy being, er, not busy. But as a consolation prize, we have a couple of documents from the European Commission on the subject of Investor-State Dispute Settlement (ISDS), which by a happy coincidence was the subject of my previous TTIP Update.

On Open Enterprise blog.

US Free Trade Agreements Are Bad Not Just For The Economy, But For The Environment, Too

A couple of months ago, we reported on some interesting research into the reality of US trade agreements, in contrast to the rosy pictures always painted when they are being sold to the public by politicians. In particular, it turned out that far from boosting US exports and creating more jobs, both the North American Free Trade Agreement (NAFTA) and KORUS, the free trade agreement with South Korea, actually did the opposite -- increasing the US trade deficit with those countries, and destroying hundreds of thousands of American jobs. 

On Techdirt.

Dutch Telcos Used Customer Metadata, Retained To Fight Terrorism, For Everyday Marketing Purposes

One of the ironies of European outrage over the global surveillance conducted by the NSA and GCHQ is that in the EU, communications metadata must be kept by law anyway, although not many people there realize it. That's a consequence of the Data Retention Directive, passed in 2006, which: 

On Techdirt.

DRM In HTML5: What Is Tim Berners-Lee Thinking?

Back in January, we reported on a truly stupid idea: making DRM an official aspect of HTML5. Things then went quiet, until a couple of weeks ago a post on a W3C mailing announced that the work was "in scope". An excellent post on the EFF's blog explains: 

On Techdirt.

Russia Plans To Launch Sputnik Again -- This Time As A Search Engine

Techdirt has been reporting for a while the efforts of the Russian government to bring the Internet there under control. It now seems that it is taking a new approach: as well as banning or criminalizing activities it doesn't like, it wants to compete with them directly. Specifically, it plans to fund a new Russian search engine, called "Sputnik", named after the first artificial satellite, put into space by the Russians in 1957. According to an article in the news magazine "Der Spiegel" (original in German), this is designed to address two problems at once. 

On Techdirt.

Key Internet Institutions Ditch US Leadership; Brazil To Host Global Summit To Draw Up New Governance Model

Here's a hugely important story that brings together three major threads. First, the continuing wrangling over the form that Internet governance should take. Second, the fact that NSA's massive surveillance operations around the world have included economic espionage. And third, Brazil's increasingly angry reaction to that spying. As a post from the Internet Governance Project explains: 

On Techdirt.

The Difference Between Plagiarism And Copyright Infringement

Plagiarism is a complex and emotive issue, as previous Techdirt posts on the subject have shown. Perhaps because of that complexity, people often seem confused about the difference between plagiarism and copyright infringement. The palaeontologist Mike Taylor has put together a short post with this handy explanation of how it works in an academic context: 

On Techdirt.

Canadian-Based Company Sues Canada Under NAFTA, Saying That Fracking Ban Takes Away Its Expected Profits

We've written several posts about a growing awareness of the dangers of investor-state dispute settlement (ISDS), which lets foreign companies sue entire countries for the alleged loss of future profits. One of the most egregious examples of ISDS concerns Canada, which is being sued by Eli Lilly & Co for $500 million after refusing to grant it a couple of pharma patents. Now The Huffington Post has details about another ISDS case involving Canada: 

On Techdirt.

Universities Struggle To License Their Patents, In Desperation Team Up With Patent Trolls

A few months back, we wrote about the University of California's plan to lock up even more knowledge in the form of patents, in the hope that this would bring in lots of cash. But as Techdirt has reported time and again over the years, patenting research does not bring in more money to fund further research, in fact it probably doesn't bring in any money at all, once you allow for the costs of running tech transfer offices. Moreover, there's evidence that making the results of research freely available is much better for the wider economy than trying to turn them into intellectual monopolies. 

On Techdirt.

Fighting To Free Knowledge Paid For By Taxpayers -- And Winning

One of the pioneers of open access is Michael Eisen, who helped found what has become the leading open access publisher, Public Library of Science, back in 2000. Since then, he's been a pugnacious defender of the public's right to read the research it has paid for, so perhaps it's no surprise that he decided to take direct action in the following case involving NASA: 

On Techdirt.

Canadian Scientists Call Countrywide Protests Against Government Censorship, Found Advocacy Group

Back in April, we noted that the Canadian government has been trying to muzzle various groups in the country, including librarians and scientists. It now seems that some scientists have had enough, as the Guardian reports: 

On Techdirt.