systemd for Developers II

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/socket-activation2.html

It has been way too long since I posted the first
episode
of my systemd for Developers series. Here’s finally the
second part. Make sure you read the first episode of the series before
you start with this part since I’ll assume the reader grokked the wonders
of socket activation.

Socket Activation, Part II

This time we’ll focus on adding socket activation support to real-life
software, more specifically the CUPS printing server. Most current Linux
desktops run CUPS by default these days, since printing is so basic that it’s a
must have, and must just work when the user needs it. However, most desktop
CUPS installations probably don’t actually see more than a handful of print
jobs each month. Even if you are a busy office worker you’ll unlikely to
generate more than a couple of print jobs an hour on your PC. Also, printing is
not time critical. Whether a job takes 50ms or 100ms until it reaches the
printer matters little. As long as it is less than a few seconds the user
probably won’t notice. Finally, printers are usually peripheral hardware: they
aren’t built into your laptop, and you don’t always carry them around plugged
in. That all together makes CUPS a perfect candidate for lazy activation:
instead of starting it unconditionally at boot we just start it on-demand, when
it is needed. That way we can save resources, at boot and at runtime. However,
this kind of activation needs to take place transparently, so that the user
doesn’t notice that the print server was not actually running yet when he tried
to access it. To achieve that we need to make sure that the print server is
started as soon at least one of three conditions hold:

  1. A local client tries to talk to the print server, for example because
    a GNOME application opened the printing dialog which tries to enumerate
    available printers.
  2. A printer is being plugged in locally, and it should be configured and
    enabled and then optionally the user be informed about it.
  3. At boot, when there’s still an unprinted print job lurking in the queue.

Of course, the desktop is not the only place where CUPS is used. CUPS can be
run in small and big print servers, too. In that case the amount of print jobs
is substantially higher, and CUPS should be started right away at boot. That
means that (optionally) we still want to start CUPS unconditionally at boot and
not delay its execution until when it is needed.

Putting this all together we need four kind of activation to make CUPS work
well in all situations at minimal resource usage: socket based activation (to
support condition 1 above), hardware based activation (to support condition 2),
path based activation (for condition 3) and finally boot-time activation (for
the optional server usecase). Let’s focus on these kinds of activation in more
detail, and in particular on socket-based activation.

Socket Activation in Detail

To implement socket-based activation in CUPS we need to make sure that when
sockets are passed from systemd these are used to listen on instead of binding
them directly in the CUPS source code. Fortunately this is relatively easy to
do in the CUPS sources, since it already supports launchd-style socket
activation, as it is used on MacOS X (note that CUPS is nowadays an Apple
project). That means the code already has all the necessary hooks to add
systemd-style socket activation with minimal work.

To begin with our patching session we check out the CUPS sources.
Unfortunately CUPS is still stuck in unhappy Subversion country and not using
git yet. In order to simplify our patching work our first step is to use
git-svn to check it out locally in a way we can access it with the
usual git tools:

git svn clone http://svn.easysw.com/public/cups/trunk/ cups

This will take a while. After the command finished we use the wonderful
git grep to look for all occurences of the word “launchd”, since
that’s probably where we need to add the systemd support too. This reveals scheduler/main.c
as main source file which implements launchd interaction.

Browsing through this file we notice that two functions are primarily
responsible for interfacing with launchd, the appropriately named
launchd_checkin() and launchd_checkout() functions. The
former acquires the sockets from launchd when the daemon starts up, the latter
terminates communication with launchd and is called when the daemon shuts down.
systemd’s socket activation interfaces are much simpler than those of launchd.
Due to that we only need an equivalent of the launchd_checkin() call,
and do not need a checkout function. Our own function
systemd_checkin() can be implemented very similar to
launchd_checkin(): we look at the sockets we got passed and try to map
them to the ones configured in the CUPS configuration. If we got more sockets
passed than configured in CUPS we implicitly add configuration for them. If the
CUPS configuration includes definitions for more listening sockets those will
be bound natively in CUPS. That way we’ll very robustly listen on all ports
that are listed in either systemd or CUPS configuration.

Our function systemd_checkin() uses sd_listen_fds() from
sd-daemon.c to acquire the file descriptors. Then, we use
sd_is_socket() to map the sockets to the right listening configuration
of CUPS, in a loop for each passed socket. The loop corresponds very closely to
the loop from launchd_checkin() however is a lot simpler. Our patch so far looks like this.

Before we can test our patch, we add sd-daemon.c
and sd-daemon.h
as drop-in files to the package, so that sd_listen_fds() and
sd_is_socket() are available for use. After a few minimal changes to
the Makefile we are almost ready to test our socket activated version
of CUPS. The last missing step is creating two unit files for CUPS, one for the
socket (cups.socket), the
other for the service (cups.service). To make things
simple we just drop them in /etc/systemd/system and make sure systemd
knows about them, with systemctl daemon-reload.

Now we are ready to test our little patch: we start the socket with
systemctl start cups.socket. This will bind the socket, but won’t
start CUPS yet. Next, we simply invoke lpq to test whether CUPS is
transparently started, and yupp, this is exactly what happens. We’ll get the
normal output from lpq as if we had started CUPS at boot already, and
if we then check with systemctl status cups.service we see that CUPS
was automatically spawned by our invocation of lpq. Our test
succeeded, socket activation worked!

Hardware Activation in Detail

The next trigger is hardware activation: we want to make sure that CUPS is
automatically started as soon as a local printer is found, regardless whether
that happens as hotplug during runtime or as coldplug during
boot. Hardware activation in systemd is done via udev rules. Any udev device
that is tagged with the systemd tag can pull in units as needed via
the SYSTEMD_WANTS= environment variable. In the case of CUPS we don’t
even have to add our own udev rule to the mix, we can simply hook into what
systemd already does out-of-the-box with rules shipped upstream. More
specifically, it ships a udev rules file with the following lines:

SUBSYSTEM=="printer", TAG+="systemd", ENV{SYSTEMD_WANTS}="printer.target"
SUBSYSTEM=="usb", KERNEL=="lp*", TAG+="systemd", ENV{SYSTEMD_WANTS}="printer.target"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", TAG+="systemd", ENV{SYSTEMD_WANTS}="printer.target"

This pulls in the target unit printer.target as soon as at least
one printer is plugged in (supporting all kinds of printer ports). All we now
have to do is make sure that our CUPS service is pulled in by
printer.target and we are done. By placing WantedBy=printer.target
line in the [Install] section of the service file, a
Wants dependency is created from printer.target to
cups.service as soon as the latter is enabled with systemctl
enable
. The indirection via printer.target provides us with a
simple way to use systemctl enable and systemctl disable to
manage hardware activation of a service.

Path-based Activation in Detail

To ensure that CUPS is also started when there is a print job still queued
in the printing spool, we write a simple cups.path that
activates CUPS as soon as we find a file in /var/spool/cups.

Boot-based Activation in Detail

Well, starting services on boot is obviously the most boring and well-known
way to spawn a service. This entire excercise was about making this unnecessary,
but we still need to support it for explicit print server machines. Since those
are probably the exception and not the common case we do not enable this kind
of activation by default, but leave it to the administrator to add it in when
he deems it necessary, with a simple command (ln -s
/lib/systemd/system/cups.service
/etc/systemd/system/multi-user.target.wants/
to be precise).

So, now we have covered all four kinds of activation. To finalize our patch
we have a closer look at the [Install] section of cups.service, i.e.
the part of the unit file that controls how systemctl enable
cups.service
and systemctl disable cups.service will hook the
service into/unhook the service from the system. Since we don’t want to start
cups at boot we do not place WantedBy=multi-user.target in it like we
would do for those services. Instead we just place an Also= line that
makes sure that cups.path and cups.socket are
automatically also enabled if the user asks to enable cups.service
(they are enabled according to the [Install] sections in those unit
files).

As last step we then integrate our work into the build system. In contrast
to SysV init scripts systemd unit files are supposed to be distribution
independent. Hence it is a good idea to include them in the upstream tarball.
Unfortunately CUPS doesn’t use Automake, but Autoconf with a set of handwritten
Makefiles. This requires a bit more work to get our additions integrated, but
is not too difficult either. And
this is how our final patch looks like
, after we commited our work and ran
git format-patch -1 on it to generate a pretty git patch.

The next step of course is to get this patch integrated into the upstream
and Fedora packages (or whatever other distribution floats your boat). To make
this easy I have prepared a
patch for Tim that makes the necessary packaging changes for Fedora 16
, and
includes the patch intended for upstream linked above. Of course, ideally the
patch is merged upstream, however in the meantime we can already include it in
the Fedora packages.

Note that CUPS was particularly easy to patch since it already supported
launchd-style activation, patching a service that doesn’t support that yet is
only marginally more difficult. (Oh, and we have no plans to offer the complex
launchd API as compatibility kludge on Linux. It simply doesn’t translate very
well, so don’t even ask… ;-))

And that finishes our little blog story. I hope this quick walkthrough how to add
socket activation (and the other forms of activation) to a package were
interesting to you, and will help you doing the same for your own packages. If you
have questions, our IRC channel #systemd on freenode and
our mailing
list
are available, and we are always happy to help!

Identi.ca Weekly Summary

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/07/04/identica-weekly.html

Identi.ca Summary, 2011-06-26 through 2011-07-04

What’s This “…And the Rest” Crap!?!

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/28/gilligans-island.html

Famously,
the Gilligan’s
Island
theme song
, in its first season, left out mentioning
the Professor and Mary Ann characters by name, simply including
…And the Rest in that lyric where their names later
were heard. Mystery Science Theater 3000 even spoofed this issue
during
screening
of This Island Earth, in which the
actor Russell
Johnson
(The Professor) appeared. When Johnson first appears on
screen while viewing This Island Earth, MST3K’s Mike says
over the film: Hey, what’s this …And the Rest
Crap!?!
. Indeed, what’s that all about?

Screenshot of MST3K The Movie, watching This Island Earth, as Rusell Johnson appears on screen.

Anyone would get easily annoyed if they’ve contributed some work but,
when credit is giving, they were just relegated into … and the
rest
. Anyone who is thrown into that group would assume their contribution
is somehow also not important,
or that the contributions of the credited are somehow better.

Some Free Software projects websites, however, often relegate many of their
contributors to being And the Rest, just like The Professor and
Mary Ann in their first season of Gilligan’s Island. This is a mistake that ought to be
addressed when it occurs.

The example of this problem that was recently brought to my attention
was on Fedora Project’s website.
At the bottom of all of the pages of Fedora’s website,
there’s © 2011 Red Hat, Inc. and others. I’ve dubbed this a
“Gilligan’s Island copyright notice” because, while Red Hat
is probably a copyright holder some of Fedora, Red Hat employees are
also fond of pointing out how many contributors they have from outside
Red Hat. Yet, with regard to the website, those contributors aren’t
considered important enough to appear in the copyright notice. They’re
secondary characters that Red Hat is indicating don’t matter that much:
like The Professor and Mary Ann in Gilligan’s Island‘s first
season.

However, the solution for this problem isn’t completely clear.
Obviously, listing all the copyright holders at the bottom of every web
page is completely unreasonable. In projects themselves, we usually
have a CREDITS or COPYRIGHT file that has everyone’s notice collected,
but rarely is every copyright notice put in the single files of the project. Perhaps
website could do the same. Certainly, Gilligan’s Island copyright
notices can’t continue; they relegate everyone but the main entity into a
supporting character role, when in fact, in Free Software projects,
everyone should be equal.

I’ve been discussing
discussing this issue
on identi.ca lately with Richard Fontana of Red Hat, and
he’s started
a thread on Fedora list about this
. I hope that it gets resolved
soon, and I’m grateful to Fontana for addressing this issue.

It’s worth noting that a few examples of other distributions, such
as Debian, Arch
Linux
, and Ubuntu, are even worse
in this regard, because they list only a few authors (or a single
corporate entity) that may or may not have all the copyright on the
project and the website; they don’t do the minimal … and the Rest. For example, Debian’s copyright notice
says: Copyright © 1997-2011 SPI. Such notices
are even worse than Gilligan’s Island Copyright Notices,
because they fail to even acknowledge at all that a diversity of
contributors are present and hold copyrights. Note that
there’s
a long-standing
Debian bug on this issue (and the related issue of poor licensing of
the site)
.

I suppose Gilligan’s Island Copyright Notices are better than marking
the work as an organization’s own when in fact there has been no
assignment of copyright. Still, I think Free Software projects should
take more care on this issue. As is noted in
the GNOME
Foundation Guidelines on Copyright Assignment
(which I co-authored),
many developers want to see their “name in lights” under the
copyright notice when they contribute to a project. It’s important that
we give them that opportunity.

Identi.ca Weekly Summary

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/26/identica-weekly.html

Identi.ca Summary, 2011-06-19 through 2011-06-26

Impressions of Japan, Thailand and India

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/photos/india-bangkok-japan.html

It has been a while since I blogged photos of my various travels, although I
have visited quite a number of countries in the past 12 months, and travelled
overland in a number of them. Here are a few selected shots from three: India
(November/December), Thailand (January), Japan (June).

Japan
Japan
Japan
Japan
Japan
Japan

Japan
Japan
Japan
Japan
Japan
Japan

Japan
Japan
Japan
Japan
Japan
Japan
Japan
Japan

Japan
Japan
Japan
Japan
Japan
Japan
Japan
Japan

These pictures are from Kyoto, Nara and Takayama in Honshu, Japan.

Thailand
Thailand
Thailand
Thailand
Thailand
Thailand

Thailand
Thailand
Thailand
Thailand
Thailand
Thailand

Thailand
Thailand
Thailand
Thailand
Thailand
Thailand
Thailand

Thailand
Thailand
Thailand
Thailand
Thailand
Thailand
Thailand

Thailand
Thailand
Thailand
Thailand
Thailand
Thailand

All this is Bangkok, Thailand. Particular interest deserve the gold-based patterns used widely to adorn Thai architecture:

Thailand
Thailand
Thailand
Thailand
Thailand
Thailand
Thailand
Thailand
Thailand

And finally India (one picture NSFW!):

India
India
India
India
India
India

India
India
India
India
India
India

India
India
India
India
India
India

India
India
India
India
India
India

India
India
India
India
India
India

India
India
India
India
India
India

India
India

India
India
India
India
India
India
India

India
India
India
India
India
India
India

India
India
India
India
India
India
India

India
India
India
India
India
India
India

India
India
India
India
India
India
India

India
India
India
India
India

This is Mumbai, Ellora, Ajanta, Aurangabad (in Maharashtra); Mandu, Sanchi, Gwalior, Khajuraho (Madhya Pradesh); Orchha, Varanasi (Uttar Pradesh); Bangalore, Mysore (Karnataka).

Call For Volunteers

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/call-for-volunteers.html

The Desktop Summit 2011 in Berlin, Germany Needs Your Help!

Are you attending the Desktop Summit? Are you interested in helping the GNOME and KDE communities organize this year’s Summit? Do you want to work with other Free Software enthusiasts to make the Desktop Summit rock? Would you like to own one of the exclusive Desktop Summit Team T-Shirts?

If so, please sign up as a volunteer for the Desktop Summit!

Read the full Call For Volunteers!

Read Patricia’s original announcement.

Or go directly and sign up as a volunteer.

Welcome to Karen Sandler, New GNOME Foundation Executive Director

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/21/karen-gnome.html

In November 2010, after I informed
the GNOME Foundation that I’d
like to submit some names of potential Executive Director candidates,
Germán
Póo-Caamaño
invited me to serve
on the
GNOME Foundation’s Executive Director Hiring Committee
. We agreed
that the Committee’s work would remain confidential (as any hiring
process is wrought with complicated and frank discussions). I usually
prefer open processes to confidentiality, but with things like hiring,
confidentiality is somewhat of a necessity.

As it turned out, though, I did find myself needing to resign from the
committee. Once a particular candidate seriously submitted herself for
consideration, I felt that I just had too much of a conflict of interest
to continue as part of the Hiring Committee. Specifically, this
candidate has been my personal friend for six years (we met after she
was hired to work at SFLC), and even co-hosts
an oggcast with me
.

By now, the world knows why it is that I had to resign from the Hiring
Committee: Karen Sandler was today appointed the
Executive Director of the GNOME Foundation
.

The GNOME project faces a lot of challenges in the next few years.
While I am obviously biased, I firmly believe that Karen is an excellent
choice to lead the GNOME Foundation and help the GNOME project through
these challenges.

Karen will fortunately continue co-hosting the Free as in
Freedom
oggcast with me, and will still spend some time as pro
bono legal counsel to Conservancy. But, her primary role now is
leader of the GNOME Foundation, and I welcome her into the job of
Executive Director. I did warn her how hard of a job Executive
Director can be, but she’s the type to take on a challenge. 🙂

Update: You
can hear Karen discuss
her new position on Free as in Freedom Episode
0x12
, or
her interview
on LWN with Joe ‘Zonker‘ Brockmeier about the new position
.

With GPLv3, Everything Old Can Be New Again

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/20/new-again.html

I was invited last week to keynote at
the Sixth
OpenFOAM Conference
held at Penn State University in State College,
PA. OpenFOAM is
a computational
fluid dynamics
software package released
under GPLv3. I was
grateful for this opportunity, because rarely do I get the opportunity
to meet what I think of as insulated Free Software communities.

By “insulated”, I don’t mean that these communities are
naïve in any way. They are, however, insulated from the usual
politics of the general software freedom community. While the users of
OpenFOAM are all familiar with GNU/Linux and other interesting software
freedom packages, OpenFOAM users and developers aren’t generally reading
blogs like mine or following the weekly discussions about copyleft and
non-copyleft licensing, or debating
with Simon Phipps
what “Open By
Rule” means
.

These users and developers interact with one software freedom license,
GPLv3, about one specific codebase. All of there focus comes about that
codebase and how the licensing impacts their businesses, their work and
their research. This is as it should be: some of the best work in
society comes out of communities focusing together very intently on an
important area of study.

For me, it’s quite interesting to see how these communities sometimes,
quite organically, end up having some serious similarities to other ones
we find. As I began to research the history of the OpenFOAM, I started
as I usually do with
the Wikipedia entry,
which is (at the time of
writing) marked
with the Advert template
. This was an immediate sign that something
odd was going on, so I dug deeper.

Between my research before the workshop and from discussions with users
and developers at it, I’ve pretty much gotten a straight,
non-advertising story of what happened. The OpenFOAM codebase was
developed at Imperial College as an academic codebase. As often
(unfortunately) happens, the university allowed the codebase to be spun
off as a proprietary software product into a for-profit company.
Eventually, in 2004, the codebase was released under GPL. After usual
corporate politics and disputes that our community has seen before, a
single corporation, OpenCFD, Ltd., now maintains itself as sole
copyright holdership and trademark holdership of the OpenFOAM name.

As such, events have progressed as we have all seen before with MySQL,
and other would-be community projects that have ended up under single
corporate control. OpenCFD maintains
a proprietary
relicensing business model, a practice that I’ve previously
denounced
. Also, there is aggressive trademark enforcement and
licensing control going on, which we have also seen more than once in
the software freedom world.

However, despite this, I’m actually quite hopeful about this community
I met last week, despite how grim the last paragraph sounds. I theorize
this has something do with the heavy academic connections of the
project, but for whatever reason, there is
a burgeoning but reasonably
healthy fork, currently called OpenFOAM-Extend
, with a community of
academics, volunteer developers, and small businesses interested in it.
They are in the classic catbird seat when facing a proprietary
relicensed codebase: they can take all they want from the official
OpenFOAM releases under GPLv3, and can add their own code without
assigning it back to OpenCFD and keeping their own copyrights. I
encouraged everyone I met at the conference to do this.

The community faces really only one difficult obstacle: they will
eventually have to give up the name, OpenFOAM. The name is trademarked
by OpenCFD, and therefore there will always be difficult trying to build
a healthy software freedom community around a project whose name is
trademarked and aggressively enforced by a for-profit company. I spent
my time at the workshop pointing out that a name is just a moniker and
that developers and users will gravitate to wherever the healthiest
codebase lives, regardless of a name. I pointed out how forks of MySQL
like Drizzle have easily built
communities, and encouraged OpenFOAM users to watch with interest what
happens with other fork+name-change projects
like LibreOffice
and Jenkins. I hope the
OpenFOAM-Extend community will take these examples to heart.

Finally, I’d like to thank the OpenFOAM Workshop organizers for
inviting me to keynote at their sixth annual event. I enjoyed meeting
everyone at the workshop. I’ve put
the slides from talk
there
on my website. I also hope to release the recording of my
talk as Free as in Freedom
oggcast
, but I have discuss that with my co-host Karen Sandler
before I do.

Desktop Summit Workshops and BoFs Call for Participation

Post Syndicated from Lennart Poettering original https://0pointer.net/blog/projects/dsbofcfp.html

The Desktop Summit schedule for
the talks and presentations
has been published a couple of weeks ago. Now it
is time to open the 2nd Call for Participation, this time for Workshops and BoFs.

If you’d like to run a workshop, BoF, hack session or training/teaching
session, then please submit it here. If
you do it will appear in the printed schedule and get a prominent time slot
assigned. BoFs, workshops, hack sessions and training/teaching sessions can
also be added after the deadline of July 3rd, and even be registered
ad-hoc at the conference, but if you register your slot in advance we can make
sure people will find it in the printed schedule, will know about it, can plan
to attend it and we can do everything to make sure a lot of people show up.

Note that BoF/workshop proposals are unrestricted, i.e. there is no program
committee that will accept or reject submissions: we have a lot of room and
we’ll accept liberally what is submitted.

For GNOMErs: this part of the conference is supposed to be much like the
Boston GNOME summit, but with a printed schedule. So please be welcome to
submit your sessions like you’d want to have them take place at the GNOME
summit as well.

Also see Jonnor’s original announcement.

So, hurry, file your session
request right-away
and before July 3rd!

Identi.ca Weekly Summary

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/19/identica-weekly.html

Simon Phipps, when I
recently expressed surprise
at how he makes 1.37 blog posts/day
,
suggested that I post
enough to identi.ca to make them into blog posts that frequent
. I
doubt I’m going to do that, but I’m going to have a short go at posting
a “Identi.ca Weekly Summary” of threads of interest from the
week.

Identi.ca Summary, 2011-06-11 through 2011-06-19

That was longer than I thought. I suspect it’ll be shorter once/if
it’s a regular thing.

Ditching Copyleft to Compete with a Fork?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/06/01/open-office.html

I was disturbed today
to read
that
Oracle
will
seek to relicense
all
OpenOffice
code
under
the Apache-2.0 license
and
move
OpenOffice
into the Apache Software Foundation.

I’ve written
recently
about how among the permissive licenses, my favorite is
clearly
the Apache
License 2.0
. However, I think that one should switch from a
copyleft license to a permissive one only in rare circumstances and
with the greatest of care.

Obviously, in this case, I oppose Oracle’s relicense of OpenOffice.org
under Apache-License-2.0. It is probably obvious why I feel that way,
but I shall explain nonetheless, just in case. I’m going to mostly
ignore the motives for doing so, which I think are obvious: Oracle (and
IBM, who are quoted in support of this move) for their own reasons don’t
like The Document
Foundation
fork
(LibreOffice) of
OpenOffice.org. This is
a last-ditch
effort by IBM and Oracle to thwart the progress of that fork, which has
been reported as quite successful
and many
distributions have begun to adopt LibreOffice
. (Even non-software
sites sites like
Metafilter have users discussing changing to LibreOffice
.)

Anyway, as you might suspect, I’m generally against the idea of
relicensing from
a copyleft to
a non-copyleft license in most situations. In fact, I generally take
the stance that you should go with the strictest copyleft possible
unless there’s a strong reason not to. This is well-argued
in RMS’ essay
on the LGPL itself
, and I won’t repeat those arguments here.
Frankly, if I were picking a license for OpenOffice.org and/or
LibreOffice from start, I’d
pick AGPLv3-or-later,
because of the concern that it could be turned into a Google Docs-like
web service. But, what I’d do is obviously irrelevant.

OpenOffice.org was put out
under LGPLv3, and
that was its license for some time. LGPL was presumably chosen to allow
proprietary plugins to OpenOffice.org. That might be useful and perhaps
a reasonable trade-off decision, since one of the goals of the project
is to woo users away from Microsoft’s tools which presumably permit
proprietary plugins too. Thus, an argument can be made that the
situation is vaguely analogous to the C Library situation that inspired
LGPL’s creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully
permissive license do? Specifically, it allows not only proprietary
plugins using the OpenOffice.org’s defined plugin interfaces, but also
for any sort of plugin that reaches into OpenOffice.org code in
any way. Even worse, a permissive license allows for direct integration
of OpenOffice.org into larger proprietary systems that might offer other
desktop suite applications hitherto unimplemented in Free Software.

It’s my belief that this license change, if successful in its goals,
may help foster a bit of a tragedy of the commons for the core codebase.
The codebase is already well known for being somewhat unwieldy and
time-consuming to learn. Those who take the time to learn it, but who
aren’t Free Software enthusiasts, may quickly decide that it’s better
for them to use that rare knowledge to proprietarize the codebase rather
than contribute to the public Free Software versions. The LGPLv3
currently keeps such developers “honest”; the
Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the
ultimate impact on the LibreOffice fork. To consider that impact, we
have to look at the instigators of the relicense. IBM and Oracle both now will have
a vested interest in maintaining a “barely adequate” public
Apache-2.0-licensed codebase while keeping the best stuff in their
proprietary versions. OpenOffice.org has actually always suffered from
this very tragedy, but historically the regime was held up by mandatory
copyright assignment to Oracle (and a semi-exclusive proprietary license
from Oracle to IBM) rather than a permissive license. On the surface,
then, this seems subtly
like the
kind of improvement I’ve written about before
— namely —
at least a public permissive license puts everyone on
equal footing, whereas copyleft with a single for-profit proprietary
relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I
probably would have concluded that an Apache-2.0 relicense of
OpenOffice.org was the lesser of two evils. However, LibreOffice’s very
existence and momentum turns those two evils into a false dichotomy.
Specifically, there’s now a third alternative: LibreOffice is a vibrant,
open, easy-to-contribute-to, non-copyright-assigned LGPLv3’d codebase
now. In that community, the LGPLv3 is the shared and equal agreement;
no one has special rights to the code outside of LibreOffice’s license.
Free Software communities, in fact, always rely on an equitable shared
agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice
may actually be the most insidious attack Oracle and IBM could make on
the project. Unilateral relicense is the single most destabilizing
action you can take against a Free Software community, particularly if
the relicense comes from wholly outside the community. Indeed, in my
time at various copyright-holding Free Software organizations, I’ve seen
situations where I was helping support a relicensing effort by the
copyright holder. In every case, I’ve seen leaders who could
have done a unilateral relicense chose to first consult the community
before taking the action to ensure that there weren’t any key community
members who dissented. Just because you have the right to do something
doesn’t mean it’s the correct action to take, and Free Software leaders
know this well; that’s why they very rarely act unilaterally on
anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle)
whose primary goal in relicensing is, in fact, to cause the outcome that
Free Software leaders seek to avoid; Oracle is relicensing to undermine
a successful Free Software project that relies on its copyrighted
code.

Nevertheless, I’m not too worried. I believe the LibreOffice community
is strong and grows stronger every day. Since their license is LGPLv3,
and they continue to add new code, the fact that most of the underlying
code is suddenly available under Apache-2.0 license may matter a lot
today, but it will matter less and less with each passing day of new
commits under LGPLv3.

In fact, I hope the LibreOffice folks will use
this relicense to their advantage. Specifically, I suggest they take an
Apache-2.0 license of Oracle’s code, which is an LGPLv3-compatible
license, and relicense the whole project to LGPLv3-or-later0, so
they have an easy way (years from now) to switch to LGPLv4, GPLv3, or
AGPLv4 if they want to. (BTW, they already have an easy way to switch
to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this
action: according
to TDF, some OpenOffice.org code that had previously been proprietary is
coming with the Apache-2.0-licensed code dump
. This alone may make
it all worthwhile, and given the points I make above, I think the
ultimate outcome, long term, will be all positive for the LGPL’d
LibreOffice codebase.

(I’d like note finally that I’m not the only one to point out that
Oracle’s action would
be different
if LibreOffice didn’t exist. Sean Michael Kerner said
something similar.)

Update (on 2011-06-02):
This comment
on the Apache/OpenOffice issue by my friend Jeremy Allison
was so
well written that I felt compelled to update this blog post with it.
He’s made the comment on the blog of Rob Wier, who appears to be IBM’s
pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM’s been saying
about this situation, I hope you’ll notice how politically manipulative
it is. Unlike Oracle, which acts like a big gorilla that browbeats
their customers, IBMers are a politically aware group of folks deeply
skilled at rhetoric. The Free Software community should feel honored
that IBM sends skilled diplomats to deal with us, but we shouldn’t be
fooled by what they are saying. As Jeremy points out, this is about
copyleft vs. non-copyleft. We’ve got a vibrant, weak-copyleft community
going now, and IBM and Oracle are making a final attempt to disrupt
it.

For example, look carefully at how Wier uses the verb
“blessed” to refer to
FSF’s recent
announcement

of its
licensing recommendations
. Of course, he quotes FSF out of context,
and doesn’t quote this part of FSF’s recommendations:

When you contribute to an existing project, you should usually release
your modified versions under the same license as the original work. It’s
good to cooperate with the project’s maintainers, and using a different
license for your modifications often makes that cooperation very
difficult. You should only do that when there is a strong reason to
justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3.
Oracle, in coordination with IBM, unilaterally changed the license out
from under the community, rather than cooperating with the existing
licensing. Oracle of course had the legal right to do so as copyright
holder, but this was an act in conflict with the existing community in a
moral sense, even if, again, it was a permissible act under the OO.o
“community” guidelines.


0
Update on
2011-06-05:
idoric
pointed out to me
that
the LibreOffice
website says it’s LGPLv3-or-later
. The LibreOffice website is a bit
misleading on in some places on this
point. idoric later pointed
out
that the better description is on
the LibreOffice
Get Involved for Developers page
, which makes it clear that the
effective license of Libreoffice is LGPLv3, but the community has chosen
(LGPLv3-or-later|MPL) for new contributions. I don’t really understand
why the dual license with MPL makes sense; I presume it’s there to help
out pro-software-patent companies that might want to avoid the patent
provisions of LGPLv3. It’s a shame really, so in some ways, I’m
slightly glad that LibreOffice is stuck on LGPLv3 as the effective
license, even if it is LGPLv3-only. That brings me back to what I
suggest in the main body of the post: relicensing the Apache-2.0 license
code from Oracle as LGPLv3-or-later would presumably allow the effective
license of the whole codebase to be LGPLv3-or-later.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close