Archive for the ‘Open Source’ Category
I wrote previously about why privacy and security require open-source, inspectable hardware and software to run on, and software that makes encryption the default so everyone uses it. My example application was email, and I concluded that it’s currently impractical to think that we can block government snooping on a large scale even in the domain of email.
Now, think what a small fraction of people’s Internet-connected activities we’re talking about: email. What about web browsing, social network use, chat clients, game playing, phone use, GPS use, credit card transactions, search engine activity, smartphone apps, online video streaming, television viewing, car driving, access to personal devices such as security systems and webcams, cable TV use, and on and on? How can all of this be made secure and intrusion-proof? And make no mistake, all of this data is intensely personal, private, and meaningful. Email is a tiny part of the story.
And day by day, our lives are becoming ever more electronic, ever more connected, and thus ever more trackable. Wearable computing and RFID chips are going to be reality for normal citizens in the next decade or less. In twenty years many people will probably have Internet-connected, GPS-enabled, RFID-broadcasting devices physically implanted in their bodies. (The rest of us already carry these in our pockets every day). This is not sci-fi, it’s the quite predictable and ordinary extension of current trends and developments.
It’s not to say that this is evil. All of these things have good and wholesome uses, and will become available for good reasons — medical, business, convenience, entertainment, and so on. They’ll enhance us and our lives greatly. But their potential for abuse, and thus the virtual certainty that they will be abused, is stunning.
And as I’ve pointed out in my previous posts, it’s practically impossible to prevent such abuse, even for the mundane technologies such as email. Any workably-secure technology that I currently know of is unsuitable for mass use, and thus won’t be used. All of these devices and technologies will, in their convenience, expose us to intrusion on a scale I’m not sure I can imagine.
Put it this way: have you heard of bitcoin? It’s a radical departure from traditional currencies. Now imagine that every kind of electronic activity you engage in needs to be similarly radically invented if there’s any hope of privacy and security. This might not be an exaggeration.
What can we do? I think that all devices, technologies, and services need to be designed to be surveillance-proof, but I think the very foundations of our technology platforms, such as the Internet itself and all of the components that make it work, might have to be redesigned. Perhaps there’s another way, such as building a secure “tunnel” or VPN-like environment inside and on top of existing technology. But I’m not the expert in such matters.
If someone can solve this, it could be a more significant technological advance than all of the technological advances in human history thus far, because rather than just enabling technical innovation, it could enable and guarantee freedom — both freedom to and freedom from. If so, this would truly be a first. However, I believe that freedom is never guaranteed and won universally and permanently; I believe there will always have to be a fight for freedom against those who seek to limit it.
In the meantime I personally plan to carry on as usual, doing what I can and working to become successful within the system, so that I have more of an opportunity to counteract the potential and actual abuses. Because that’s what it seems to come down to: stopping governments from monitoring and thus (as I said previously) partially controlling us seems to be impossible or impractical.
I also want to end on a positive note. I don’t worry about these things; I don’t make myself unhappy about them. And I hope you don’t, either. The future is always uncertain. If it’s not the race between technological good and evil, it’s something else. This is simply another challenge to be met with a clear, present, joyful head and heart.
Those who’ve been around the MySQL world are probably aware of the much-discussed topics of GPL licensing, dual licensing, and in particular, licensing of the client libraries (also called connectors or drivers) and the FOSS exception to that licensing. This is newly relevant with the announcement of a permissively-licensed MySQL-compatible client library for MariaDB.
The difference is that this time there’s been some question about the provenance and history of the source code. Some people asked me about this. Some of them were aware of a relatively obscure detail: there’ve been permissively licensed MySQL client libraries for years, in the form of libdrizzle, a BSD-licensed library for the Drizzle fork of MySQL.
Here are some of the thoughts that seemed to be going through peoples’ minds:
- This changes everything, doesn’t it? Now I don’t have to to open-source my application or pay Oracle licensing fees.
- Is the source code of these new connectors untainted, or am I exposing myself to liability problems by using it?
- Isn’t MariaDB’s driver just a copy-paste and LGPL relicense of the BSD-licensed Drizzle driver? Sure, that’s legal, but is it ethical?
- Are these connectors really compatible, or will they cause problems?
Many people seem constitutionally incapable of understanding the GPL. I consider myself forever done with discussions about what the GPL permits or forbids, so I won’t address that. But I thought some of these things were worth looking into, at least quickly.
In particular, I was curious whether the allegations of plagiarism on MariaDB’s behalf were true. So I downloaded the latest release of the Drizzle and MariaDB C libraries, unpacked the source code, and just took a quick look. Here’s what I found.
The first thing I wanted to check was the allegation that MariaDB’s drivers were just an LGPL wrapper or copy-paste of Drizzle’s libraries. A few minutes of study showed no obvious plagiarism from Drizzle’s source. The MariaDB drivers appear to have a lot more code, documentation, tests, and so on, and it looks to be organized very differently than the Drizzle drivers. Files are in different directory hierarchies, code appears to be split up among files very differently, files are named differently, and so on. After about ten minutes of reading source, I saw no code that looks similar. A cursory grepping of the source code also shows words like “infile” that appear only in the MariaDB code. If there’s plagiarism from Drizzle’s library source code, it’s going to take a little more work to find it. In fact, from what I see, the Drizzle libraries don’t implement all of the protocol’s features, and that tangentially answers one of the other questions about true compatibility.
The next question is about MariaDB’s code versus MySQL’s code. The MariaDB library’s source looks and feels very similar to MySQL’s source. This is no surprise to me. If Monty sat alone in a room and coded a library from scratch, based only on the MySQL protocol documents and his memory, I’d expect the result to look a lot like MySQL’s source code anyway. But when I opened some of the files, things got less clear to me. For example, the copyright header in include/my_list.h begins with this:
/* Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
I was surprised. I thought I’d see a “clean-room” reimplementation of the protocol, with no relationship to MySQL’s source code. But this file appears to be the same code as MySQL’s, although the header says that the file is licensed under the LGPL. I compared that with the same header file in MySQL 5.6′s source code, and here’s the result:
/* Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.
So that file is licensed under the “viral” copyleft GPL version 2 only, not the more permissive LGPL version 2 or later. Did the license terms on that file get changed over time? I am not surprised to see Oracle erasing prior copyright history and updating it to show themselves as the owners, but did they change the license from LGPL to GPL too? One way to find out is to check the MySQL 5.0 source code, because that was released before Sun or Oracle entered the picture. Here’s the header file’s copyright notice for MySQL 5.0.28:
/* Copyright (C) 2000 MySQL AB This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
The license matches Oracle’s, although of course the copyright owner has changed since then. So it looks to me like Oracle didn’t change the license terms; they just updated the ownership information.
Some important questions arise from this. I’m not qualified to answer them because I’m neither a lawyer nor a MySQL historian, but I’m qualified to ask them and I’d surely like to know the answers:
- Is a legitimately LGPL-licensed copy of these header files available?
- What’s the origin of the triple copyright ownership listed in MariaDB’s header file, to include “MySQL Finland AB” and “TCX DataKonsult AB” ? What’s the relationship between these entities and MySQL AB?
I think that perhaps someone from Monty Program or SkySQL is in the best position to answer these questions; in fact, Monty himself is probably the most knowledgeable. I’m looking forward to understanding more of the history around the source code and its licensing and provenance.
I’ve just sent an email to the Maatkit discussion list to announce a planned change to how Maatkit (and Aspersa) are developed. In short, Percona plans to create a Percona Toolkit of MySQL-related utilities, as a fork of Maatkit and Aspersa. I’m very happy about this change, and I welcome your responses to that thread on the discussion list.