Over the summer, there was a bit of a tussle at the highest level of
Ubuntu governance over whether or not Canonical Ltd., the company
that funds the majority of work done directly in Ubuntu, should name its
file syncing and backup service Ubuntu One.
Canonical's service involved a freely licensed client included in the
Ubuntu distribution but, as a network service running on Canonical
servers, it was not clearly a part of Ubuntu (the GNU/Linux
distribution) or Ubuntu (the community) in the way the term was usually
used within the community. Although the network service itself was not
Franklin Street Statement free, this was not the most important
issue for everyone who objected to the name. The major issue for many
seemed to boil down to the fact that, free or not, Ubuntu One is a
service run entirely by Canonical outside the reaches of the Ubuntu
governance structures.
Decisions were made and not everybody -- and maybe not anybody -- was
absolutely happy with the outcome. My goal is not try to revive old
arguments here. As far as I'm concerned, the issues are settled and the
service is called Ubuntu One. That said, the questions raised during
the episode are fundamental to Ubuntu and to other firm-sponsored FLOSS
projects. Now that the dust has settled, they are worth reflecting on.
From a legal perspective, there never was any ambiguity. Canonical "owns"
the Ubuntu trademark. In this important sense, "Ubuntu" means whatever
Canonical says it means. This is hardly new. As just one example, the
Official Ubuntu Book (of which I am an author) was written by
community members but became official because Canonical blessed it. But
despite the fact that they don't need to, Canonical has often consulted
with the community and its governance structures about trademark
licensing policy.
This was also not a case of Canonical not listening to the community.
Canonical employees approached the Ubuntu Community Council
(Ubuntu's highest governance board of which I am a member), listened
carefully to concerns, and responded thoughtfully.
The question was not even about a clash between what Canonical and the
CC thought about the issue. An unambiguous majority of the board,
including all the Canonical employees and several of the community
members, supported the idea of Canonical using the trademark.
The question was one about who gets to make the decisions about the
Ubuntu name and about what role the community and Canonical would each
play. Despite the fact that a majority of the Ubuntu community council
was likely to support the proposed name, the CC was told by Canonical
CEO Mark Shuttleworth that a vote was irrelevant. Canonical made it
clear that decisions about the Ubuntu trademark were simply not in the
CC's purview. The decision on how the name was to be used was something
that Canonical was not willing to delegate to an "outside" (the firm)
governance body. Few businesses would. And although I don't agree with
the decision as a community representative, I might have even made the
same call from Canonical's shoes.
In traditional firms, it's usually pretty clear where the organization's
boundary lies. In FLOSS projects -- and especially in FLOSS project
like Ubuntu who are sponsored in very large part by a single for-profit
company -- boundaries are fuzzier. The conversation about "Ubuntu One"
can be seen as a fight over what "Ubuntu" refers to, and, more
importantly, who gets to answer that question. In deciding whether to
call a service "Ubuntu", a decision is made on what Ubuntu is. Names are
powerful.
Is Ubuntu just a Canonical project? Are Ubuntu's contributors really
just Canonical contributors by proxy? I think the answer to both
questions is "no" but the boundary issues involved are complicated and
under constant negotiation. Every time Canonical uses the Ubuntu name
itself or grants others the ability to do so, these boundary issues
are negotiated, one way or another.
This boundary setting work reveals an important tension that firms
releasing FLOSS must all struggle with. To what extent and in what ways
do communities get to decide what a FLOSS project is and to what
extent do sponsoring firms get to do so? How should projects and firms
do this most effectively? What should we even be optimizing for?
I think that any resulting balance has a huge effect on whether a FLOSS
project is, on one hand, released under a free license but run like any
old corporate project or, on the other, a true "bazaar" style project
where no single firm dominates -- or where they fall on that spectrum.
Names and trademarks are one way that projects define their own
identities and act as an important frontier in this balancing act. As
every firm/project negotiates their own answers to questions of names
and boundaries, there are important implications for the project's
ability to attract volunteers, solicit contributions from other firms,
and more. The confusion around conversations about Ubuntu One shows that
we still have a lot to learn.
$ cat libtest.c
static int static_var = 100;
int global_var = 100;
static int static_function(void)
return static_var;
int global_function(int i)
return static_function() + global_var + i;
$ gcc -c -fPIC -o libtest.o libtest.c
$ readelf --symbols ./libtest.o
Symbol table '.symtab' contains 18 entries:
Num: Value Size Type Bind Vis Ndx Name
...
5: 00000000 4 OBJECT LOCAL DEFAULT 5 static_var
6: 00000000 22 FUNC LOCAL DEFAULT 3 static_function
13: 00000004 4 OBJECT GLOBAL DEFAULT 5 global_var
16: 00000016 36 FUNC GLOBAL DEFAULT 3 global_function
$ strip --strip-unneeded libtest.o
$ readelf --symbols ./libtest.o
Symbol table '.symtab' contains 15 entries:
Num: Value Size Type Bind Vis Ndx Name
...
10: 00000004 4 OBJECT GLOBAL DEFAULT 5 global_var
13: 00000016 36 FUNC GLOBAL DEFAULT 3 global_function
$ gcc -shared -fPIC -o libtest.so libtest.c
$ strip --strip-all ./libtest.so
$ readelf --syms ./libtest.so
Symbol table '.dynsym' contains 11 entries:
Num: Value Size Type Bind Vis Ndx Name
...
6: 00000452 36 FUNC GLOBAL DEFAULT 12 global_function
10: 000015e0 4 OBJECT GLOBAL DEFAULT 21 global_var
RInside, a set
of convenience classes to facilitate embedding of R
inside of C++ applications, was updated to release 0.2.0 over the weekend.
Sources as well as binary packages are at CRAN;
sources are also at
my RInside page
The biggest news is that we now support builds on Windows -- if and only
if you use the R toolchain -- more on that below. Since I had first released
RInside people
had emailed about support on Windows. However, Richard Holbrey deserves
special mention as he actually sat down and tried to build it. Over a few
email exchanges we made decent progress, but stalled. More recently, I
sat down and had another go and lo and behold, it works. This required a few
#ifdef statements here and there, as well as a function
setenv() which Windows does not have -- Richard kindly helped
here and borrowed most of the code from R itself.
Now, to make this plain: you need gcc (as this is how R
itself is built). This gcc compiler is the native compiler on Linux and OS X.
But on Windows this requires installing the
Rtools compiled by Duncan Murdoch
as detailed in the
The Windows Toolset
appendix to the R Installation manual. Do not, I repeat, do not report an
error if you fail to build this with another compiler as this is not supported.
That said, if you have the proper tools, things are peachy. Install the
package, change into the examples directory installed with it
and say make (or on Windows: make -f Makefile.win).
That's it -- now run the examples (which on Windows will most likely require
setting the environment variable R_HOME). Now you can run
simple examples like the one from the
previous
blog post or any of the other ones.
Happy embedding!
after attending the Munich
BSP 3 weeks ago (thanks for inviting me, & thanks especially to
Stefan for hosting me) I've tasted blood & started to look at our RC bugs more often. I'm
still far from zack's RCBW
frequency; but I thought I'd give a short overview anyway; maybe it
motivates others to chime in? So here's a list of RC bugs I've
touched in the last weeks (not counting some merges in the BTS):
Lintian reports 5 errors and 221 warnings about this package. You should make the package lintian clean getting rid of them.
A new release of Rcpp
awaits inclusion on CRAN and has also
been sent as a .deb to Debian. It will
hit mirrors over the next few days, in the meantime you can get it
here as well.
This release has a couple new features :
cfunction from Oleg Sklyar's excellent
inline package
has been imported and adapted. This means simple C++ programs can be defined in an R character
vector and passed to cfunction which will create a complete file that it then
compiles, links and loads --- giving you access to compiled C++ code right from the R prompt
without having to worry about compiler flags, linker options, ... Better still, we extended
this to not only support Rcpp but
any external library via addtional header / linker arguments that will be passed to R via
the PKG_CPPFLAGS, PKG_CXXFLAGS and PKG_LIBS environment
variables.
RcppSexp for simple int, double or std::string scalars as well as vectors; this is particularly
useful for the inline support.
Tutorials at the Garching Debian Stammtisch
Munich traditionally used to have a lot of Debian
Developers, but over the last couple of years quite a few of
us who used to be students graduated and moved elsewhere
or became very busy with their day jobs. We still meet for
having a beer and a chat, but not as much as some years ago.
We used to meet about once a month, but in 2009 we only
managed to meet four
times (however, we organized a Bug Squashing
Party in November and had a special meeting as Lenny
Release Party in February)
As the meetings are really rather informal and not
necessarily very Debian related, it is difficult to attract
new people this way. So Johannes Wiedersich and I decided
to try a more hands-on approach by having a second meeting
in Garching, in the student-run bar on
the campus
of the Technische
Universit t
M nchen (TUM). The idea was
to get more of the local science, mathematics and computer
science students (as well as possibly interested faculty
members) involved.
We tried a first time about a year ago, but after two or
three meeting in late 2008 and early 2009, we lost momentum.
However, we began organizing the meetings again with the
start of the winter term, and had two rather successful
meetings so far. For the first meeting, we basically handed
out some information on how to get involved locally (the
Debian-Munich list, its subscription
address, the wiki
etc.) and discussed Debian in general and Debconf11
in Munich in particular. About half a dozen people
showed up, and two of these attended the Bug Squashing Party
later that month, and another one (a faculty member) got
very active in Debconf11 organization. Thus, I was quite
happy with the outcame of that meeting.
Some days ago, we had another meeting, and this time I was
doing a live-tutorial on Debian package building. As
Johannes was ill, we did not manage to announce or publicize
the meeting well in advance, so only three people showed up.
Still, I think it went rather OK, and we will be doing
another Debian package-building tutorial for the next
meeting, and possibly other turorials/workshops afterwards
(ideas so far include library maintenance, Debconf, how the
Debian community is organized and how to get involved in
it). As doing a live-tutorial on one notebook is a bit
difficult if you both have to type on it and people should
see what happens, we will either use some extra hardware
next time, or move to some nearby seminar room with a
projector, this will be announced in advance.
So if you are on Garching campus or nearby and interested in
Debian development (and Debian package-building in
particular), come to the next meeting on January
13th! We
decided to meet on the second Wednesday of each month, at
18h. Subscribe
to the Debian-Munich list to get the invitation or watch out
for the flyers on the campus.
This is a bit of a silly note for a Saturday while I m currently working on translating the co-op s web pages into Esperanto. The old site was translated, but the new site launched as English-only. I d like to have other languages too, but I ll start with the one that s easiest for me as a test case to get the internationalisation working again. That means that I m currently lost in django-blocks language settings.
Apparently both our co-op and Google speak Esperanto. Facebook is mostly translated. Most Plone-based sites have some translation, but often it s only the standard Plone parts and any customisations remain in English, which looks a bit odd.
Have you seen Esperanto on other major websites where you weren t expecting it?
After several months of not-too-intensive searching for a
KVM-hoster with native
IPv6 connectivity,
Steve hooked me up with a
VPS
at Bytemark, and I am very
pleased. In addition to a properly virtualised KVM instance, I got
access to a console server, which allows me to reset the machine,
switch kernels, and log in locally . It s exactly what I wanted,
but it was hard to find, as everyone else seems to offer only
Xen or Vservers, both of which
are nearing end-of-life.
Thanks Steve, and Bytemark.
NP:
Porcupine Tree: Up the Downstair
gfcombinefs is a side project I did some work on a few weeks ago. It
combines several "shares" of a secret file previously split using Shamir
secret sharing, to produce the original secret, and presents it as a file in
a FUSE filesystem. It uses libgfshare for the actual mathematics, and
expects its input to have been split with the gfsplit tool shipped with
libgfshare.
At this stage of development, I suggest not trusting it with important data,
like the GnuPG secret keyrings it's designed for. However, I hope that with
some feedback from others I can get it into a state where it's ready to
be released and packaged (perhaps I'm being unnecessarily conservative, but
for something that deals with GnuPG keys, it seems wise to be careful).
Source code is available in a git repository, and I'd welcome contributions,
bug reports (other than the limitations that are already listed in the
documentation) and in particular, a systematic code audit from someone (the
good news is that there isn't very much code, so that shouldn't actually
take long).
I ve kept a page of email clients that support mailing lists for a while and it s been a bit disappointing that I couldn t suggest Mozilla Thunderbird or its freer derivatives (IceDove?) as good clients. They work fine in most other ways and it s nice having something good that we can suggest to users on MacOS and Windows, but there was a long-standing bug requesting support for the List-Post header.
In an email discussion on ALUG s main list, a couple of people mentioned that Thunderbird 3 was released last week with a working reply to list command. This is excellent news, removing the need for the Reply To List add-on.
I hope we ll see it in IceDove soon. Fantastic work. I wish it was in the release notes so we d spotted it sooner. Now there is even less excuse for MUNGing the Reply-To header, even on lists where Windows users are present.
This is a question that Project Honey Pot's report answers.Do spammers take holidays?
The volume of spam drops approximately 21% on Christmas Day and 32% on New Year's Day. Saturday is the quietest day of the week.
How much harm does a harvester visiting my site do?
You can expect to receive 869 spam email messages every time a harvester picks up your email address from a website online.
Having excitedly bought an Arduino from the nice folks at tuxbrain.com while they were at DebConf9, I was then a little deflated to discover (while attending the UKUUG's Arduino Workshop in August), that the IDE is written in Java. While I can see that the authors might perceive this as the easiest way to provide cross-platform pointy-clicky-ness, JREs have a half-life of about an hour on my systems.Anyway, I fought with Java to show willing, until I'd determined that the IDE didn't seem to be happy running under xmonad (rendering menus so that they were unclickable) and gave up -- spending the rest of the tutorial proving to myself that I could compile and upload C code for the little beastie, but failing to compile Arduino sketches on the command line.Ever since, I've been meaning to work out the required CLI incantations, and finally made time over the weekend. The incantations turn out to be rather simple, if not very obvious, so I thought the world could benefit from a package that encapsulates the required knowledge.I've pared the source tree down to the c++ code and some examples and tweaked the Makefile so that it'll do it's work out of tree, referring to the files that the package installs for you, which allows you to apt-get install aurduino-core and then cut&paste a few lines from the contained README.Debian in order to get an LED blinking for the first time.The resulting git repo is now on Alioth. The binary-indep package it produces I've called arduino-core -- hopefully I've left enough room for any fan of the Java IDE to shove that back into the upstream branch and add packages for the full IDE, and maybe throwing in another package for the GTK IDE that's out there.I'm very mildly concerned by the fact that Arduino is a trademark of the Arduino Team, but that trademark is for the circuits, not the software, so this is probably irrelevant. If you think I should care enough to rename the package to freeduino, say, please get in touch.Anyway, if you have an Arduino (or similar) please grab a copy and test it.
I've been watching some good films recently. Two I especially liked.
Still, I felt so much more at home in Tulpan. Kept pausing it to check out
how the family had their yurt set up and furnished, and watched their
very real-seeming life unfold, right down to the lambing scene. While Solo
took the very familiar, and confounded expectations and biases at every step.
They're both fine films, from directors I want to see more of. I've
seen Ramin Bahrani's work before Solo, and especially liked
Man Push Cart. Don't know
if I will ever find any of Sergei Dvortsevoy's earlier films.
I have spent the last 27 years creating and working on MySQL and I hope, together with my team of MySQL core developers, to work on it for many more years.Since it's under the GPL, he can do that himself for as long as he wants - he doesn't have to worry about making a living, after all. If he took away something closer to the 100 million number, he can also fund several of his friends to work on it for years and years, without worrying much about income. They could always do consulting if they wanted to make a few bucks, in any case. Now, what he's worried about is that Oracle will no longer put money into Mysql. I agree that that's a real risk. However, I also think that since it's Oracle's money that is being spent, they have the right to do as they see fit, within certain limits, and this case is well within those limits. My view is that there are plenty of cases when governments should intervene. For instance, if Mysql were the only competitor to Oracle in the database market, it might be quite unhealthy to let them buy it. But that's not the case - not at all. There are numerous competitors, both closed and open. So the risk to 'the public' is relative: people bought into a product that may now stagnate, but if they really want, they have plenty of other places they can jump without too much pain (SQL is a standard, after all). It's like if FreeBSD disappeared tomorrow: you could switch to OpenBSD or Linux or something else. Perhaps not painlessly, but it wouldn't be the end of the world, either (let's hope FreeBSD has a long and happy future ahead of it, though). We're back to wanting to both have and eat the cake: Monty seems to want the EC to force Oracle to divest itself of Mysql or impose various restrictions on its development. If he had imposed those conditions on Sun when that sale was made, they might not have done the deal, or placed a smaller value on it. He didn't, but now he is back and trying to impose them on a deal in which he is not a participant (although I suppose he may have some Sun shares). That doesn't strike me as being entirely fair: if he really wanted to ensure the future of Mysql, he would not have sold the company. In terms of open source, keep in mind that Mysql was not released under the GPL until 2001: http://www.mysql.com/news-and-events/generate-article.php?id=23 For many years it was under a "sort of open" license that was not proper open source. Then there's the Richard Stallman angle: that somehow, Mysql "deserves" to have developers funded to work on it. I don't buy that, either. Mysql is a nice project, but I don't think that there's any moral imperative that the government should step in and fund some open source projects. Should the EC step in and say that Oracle should also fund Postgres development while they're at it? There are plenty of deserving projects that could use some cash to fund their development. For instance, my friend Salvatore is looking for donations for Redis development. It's not as big or "important" a project as Mysql, but it's good code and already being taken up by various companies. For that matter, I'd like to keep working on Hecl full time. In short: I hope that the EC approves the sale "as-is". I also hope that Oracle continues to take good care of Mysql, but if they don't, that is ultimately their decision as long as there remain plenty of competitors in the market. I think that our time as "the open source community" is better spent fighting for more important things: against bad software patents, for open standards in governments, and that sort of thing, that will benefit everyone, rather than trying to wrest control of Monty's code back from Oracle after he's already been paid handsomely for it.
Next.