Tag Archives: USTR

The Anatomy of a Modern GPL Violation

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/12/06/anatomy-gpl-violation.html

I’ve been thinking the last few weeks about the evolution of the GPL
violation. After ten years of being involved with GPL enforcement, it
seems like a good time to think about how things have changed.

Roughly, the typical GPL violation tracks almost directly the adoption
and spread of Free Software. When I started finding GPL violations, it
was in a day when Big Iron Unix was still king (although it was only a
few years away from collapse), and the GNU tools were just becoming
state of the art. Indeed, as a sysadmin, I typically took a proprietary
Unix system, and built a /usr/local/ filled with the GNU tools, because
I hated POSIX tools that didn’t have all the GNU extensions.

At the time, many vendors were discovering the same frustrations I was
as a sysadmin. Thus, the typical violation in those days was a
third-party vendor incorporating some GNU tools into their products, for
use on some Big Iron Unix. This was the age of the violating backup
product; we saw frequently backup products that violated the GPL on GNU
tar in those days.

As times changed, and computers got truly smaller, the embedded
Unix-like system was born. GNU/Linux and (more commonly) BusyBox/Linux
were the perfect solutions for this space. What was once a joke on
comp.os.linux.advocacy in the 1990s began to turn into a reality: it was
actually nearly possible for Linux to run on your toaster.

The first class of embedded devices that were BusyBox/Linux-based were
the wireless routers. Throughout the 2000s, the typical violation was
always some wireless router. I still occasionally see those types of
products violating the GPL, but I think the near-constant enforcement
done by Erik Andersen, FSF, and Harald Welte throughout the 2000’s has
led the wireless router violation to become the exception rather than
the rule. That enforcement also led to the birth of community-focused
development of the OpenWRT and DD-WRT, that all started from that first
enforcement that we (Erik, Harald and FSF (where I was at the time)) all
did together in 2002 to ensure the WRT54G source release.

In 2009, there’s a general purpose computer in almost every electronics
product. Putting a computer with 8MB RAM and a reasonable processor in
a device is now a common default. Well, BusyBox/Linux was always the
perfect operating system for that type of computer! So, when you walk
through the aisles of the big electronics vendors today, it’s pretty
likely that many of the devices you see are BusyBox/Linux ones.

Some people think that a company can just get away with ignoring the
GPL and the requirements of copyleft. Perhaps if a company has five
customers total, and none of them ask for source, your violation may
never be discovered. But, if you produce a mass market product based on
BusyBox/Linux, some smart software developer is going to eventually buy
one. They are going to get curious, and when they poke, they’ll see
what you put in there. And, that developer’s next email is going to be
to me to tell me all about that device. In my ten years of enforcement
experience, I find that a company’s odds of “getting away”
with a GPL violation are incredibly low. The user community eventually
notices and either publicly shames the company (not my preferred
enforcement method), or they contact someone like me to pursue
enforcement privately and encourage the company in a friendly way to
join the FLOSS community rather than work against it.

I absolutely love that so many companies have adopted BusyBox/Linux as
their default platform for many new products. Since circa 1994 when I
first saw the “can my toaster run Linux?” joke, I’ve dreamed
of time when it would be impossible to buy a mass-market electronics
product without finding FLOSS inside. I’m delighted we’ve nearly
reached that era during my lifetime.

However, such innovation is made possible by the commons created by the
GPL. I have dedicated a large portion of my adult life to GPL
enforcement precisely because I believe deeply in the value of that
commons. As I find violator after violator, I look forward to welcoming
them to our community in a friendly way, and ask them to respect the
commons that gave them so much, and give their code back to the
community that got them started.

GPL Enforcement: Don’t Jump to Conclusions, But Do Report Violations

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/08/gpl-enforcement.html

In one of my favorite
movies, Office
Space
, Tom Smykowski (one of the fired employees) has a
magic-eight-ball-style novelty product idea:
a “Jump
to Conclusions” mat
. Sometimes, I watch discussions in the
software freedom community and think that, as a community, we’re all
jumping around on one of these mats.

I find that people are most likely to do this when something seems
novel and exciting. I don’t really blame anyone for doing it; I do it
myself when I have discovered an exciting thing that’s new to me, even
if it’s well known by others. But, often, this new thing is actually
rather mundane, and it’s better to check in with the existing knowledge
about the idea before “jumping” to any conclusions. In
other words, the best square on the mat for us to land on is the one
that reads: Think again!

Meanwhile, as some who follow
my microblog know, I’ve
been on a mission in recent months to establish just how common and
mundane GPL violations are. Since 21 August 2009, I’ve been finding one
new GPL violating company per day (on average) and I am still on target
to find one per day for 365 days straight. When I tell this to people
who are new to GPL enforcement, they are surprised and impressed.
However, when I tell people who have done GPL enforcement themselves,
they usually say some version of: Am I supposed to be impressed by
that? Couldn’t a monkey do that? Fact is, the latter are a little
bit right: there are so many GPL violations that I might easily be able
to go on finding one per day for two years straight.

In short, GPL violations are common and everyday occurrences. I
believe firmly they should be addressed, and I continue to dedicate much
of my life to resolve them. However, finding yet another GPL violation
isn’t a huge and earth-shaking discovery. Indeed, it’s what I was doing
today to kill time while drinking my Sunday morning coffee.

I don’t mean to imply that I don’t appreciate greatly when folks find
new GPL violations. I think finding and reporting GPL violations is a
very valuable service, and I wouldn’t spend so much time finding them
myself if I didn’t value the work highly. But, the work is more akin to
closing annoying bugs than it is to launching a paradigm-shifting FLOSS
project. Closing bugs is an essential part of FLOSS development, but no
one blogs about every single bug they close (although maybe we do
microblog them ;).

Having this weekend witnessed another community tempest about a
potential GPL violation, I decided to share a few guidelines that I
encourage everyone to follow when finding a GPL violation. (In other
words, what follows are a some basic guidelines for reporting
violations; other such guides are also available
at the
FSF’s site

and the
gpl-violations.org site
(which is now defunct, since gpl-violations.org is
no longer active.)

Assume the violation is an oversight or an accident by the violator
until you have clear evidence that tells you differently. I’d say
that 98% of the violations I’ve ever worked on since 1998 have been
unintentional and due primarily to negligence, not malice.

Don’t go public first. Back around late 1999, when I
found my first GPL violation from scratch, I wanted to post it to every
mailing list I could find and shame that company that failed to respect
and cooperate with the software freedom community. I’m glad that I
didn’t do that, because I’ve since seen similar actions destroy the
lines of communication with violators, and make resolution tougher.
Indeed, I believe that if the Cisco/Linksys violations had not been a
center of public ridicule in 2003 when I (then at the FSF) was in the
midst of negotiating with them for compliance, we would not have ended
up with such
a long
saga
to resolution.

Do contact the copyright holders, or their designated
enforcement agents. Since
the GPL
is a copyright license, if the violator fails to comply on their own,
only the copyright holder (typically) has the power to enforce the
license0.
Here’s a list of contact addresses that I know for reporting various
violations (if you know more such addresses, please let me know and I’ll
add them here):

Linux, BusyBox, Samba, Mercurial, uClibc: <[email protected]&gt
(this address is primarily answered by me currently)
FSF copyrights (many GNU programs such as GnuPG, wget, glibc, gcc,
binutils): <[email protected]>
iptables, netfilter, mtd, initrd and
msdosfs: <[email protected]>
(note: gpl-violations.org is no longer active so this address might no
longer work)
XviD: <[email protected]>

If the GPL’d project you’ve found a violation on isn’t on the list above,
just find email addresses of people with commit access to the repository
for the project or with email addresses in the MAINTAINERS or CONTRIBUTORS
files. It’s better not to post the violation to a public discussion list
for the project, as that’s just “going public”.

Never treat a “community violator” the same way as a
for-profit violator. I believe there is a fundamental difference
between someone who makes a profit during the act of infringement than
someone who merely seeks to contribute as a volunteer and screws
something up. There isn’t a perfect line between the two — it’s a
spectrum. However, those who don’t make any money from their
infringement are probably just confused community members who
misunderstood the GPL and deserve pure education and non-aggressive
enforcement. Those who make money from the infringement deserve some
friendly education too, of course, but ultimately they are making a
profit by ignoring the rights of their users. I think these situations
are fundamentally different, and deserve different tactics.

Once you’ve reported a violation, please be patient with those of us
doing enforcement. There are always hundreds of GPL violations that
need action, and there are very few of us engaged in regular and active
enforcement. Also, most of us try to get compliance not just on the
copyrights we represent, but all GPL’d software. (This behooves both
the software freedom community and the violator, as the former wants to
see broad compliance, and the latter doesn’t want to deal with each
copyright holder individually). Thus, it takes much time and effort to
do each enforcement action. So, when you report a new violation, it
might take some time for the situation to resolve.

Do try your best to request source from the violator
on your own. While making the violation public doesn’t help, inquiring
privately does often help. If you have received distribution of a
binary that you think is GPL’d or LGPL’d (or used a network service that
you think is AGPL’d), do write to the violator (typically best to use the
technical support channels) and ask for the complete and corresponding
source code. Be as polite and friendly as possible, and always assume
it is their intention to comply until you have specific evidence that
they don’t intend to do so.

Share as much good information with the violator as you can to
encourage their compliance. My colleagues and
I wrote A
Practical Guide to GPL Compliance
for just this purpose.

We need a careful balance regarding GPL enforcement. Remember that the
primary goal of the GPL is encourage more software freedom in the world.
For many violators, the first experience the violator has with FLOSS is
an enforcement action. We therefore must ensure that enforcement action
is reasonable and friendly. I view every GPL violator as a potential
FLOSS contributor, and try my best to open every enforcement action with
that attitude. I am human and thus sometimes become more frustrated
with uncooperative violators than I should be. However, striving for
kindness with violators only helps give a great image to the software
freedom community.

0In
some situations, there are a few possibilities for users that
exist if the copyright holder is unable or unwilling to enforce
the GPL. We’ve actually recently seen an interesting
successful enforcement by a user. I plan to blog in detail
about this soon.

Conferences

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/lpc-bluez-maemo-2009.html

Last week I’ve been at the Linux Plumbers Conference in
Portland. Like last year it kicked ass and proved again being one of the most
relevant Linux developer conferences (if not the most relevant one). I
ran the Audio MC at the conference which was very well attended. The slides
for our four talks in the
track are available online
. (My own slides are probably a bit too terse
for most readers, the interesting stuff was in the talking, not the
reading…) Personally, for me the most interesting part was to see to which
degree Nokia actually adopted PulseAudio
in the N900. While I was aware that Nokia was using it, I wasn’t aware that
their use is as comprehensive as it turned out it is. And the industry
support from other companies is really impressive too. After the main track we
had a BoF session, which notes I’ll post a bit later. Many thanks to Paul,
Jyri, Pierre for their great talks. Unfortunately, Palm, the only manufacturer
who is actually already shipping a phone with PulseAudio didn’t send anyone to
the conference who wanted to talk about that. Let’s hope they’ll eventually
learn that just throwing code over the wall is not how Open Source works.
Maybe they’ll send someone to next year’s LPC in Boston, where I hope to be
able to do the Audio MC again.

Right now I am at the BlueZ Summit in Stuttgart. Among other things we have
been discussing how to improve Bluetooth Audio support in PulseAudio. I guess
one could say thet the Bluetooth support in PulseAudio is already one of its
highlights, in fact working better then the support on other OSes (yay, that’s
an area where Linux Audio really shines!). So up next is better support for
allowing PA to receive A2DP audio, i.e. making PA act as if it was a Headset or
your hifi. Use case: send music from from your mobile to your desktop’s hifi
speakers. (Actually this is already support in current BlueZ/PA versions, but
not easily accessible). Also Bluetooth headsets tend to support AC3 or MP3
decoding natively these days so we should support that in PA too. Codec
handling has been on the TODO list for PA for quite some time, for the SPDIF or
HDMI cases, and Bluetooth Audio is another reason why we really should have
that.

Next week I’ll be at the Maemo Summit in Amsterdam.
Nokia kindly invited me. Unfortunately I was a bit too late to get a proper
talk accepted. That said, I am sure if enough folks are interested we could do
a little ad-hoc BoF and find some place at the venue for it. If you have any
questions regarding PA just talk to me. The N900 uses PulseAudio for all things
audio so I am quite sure we’ll have a lot to talk about.

See you in Amsterdam!

One last thing: Check out Colin’s
work to improve integration of PulseAudio and KDE
!

Conferences

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/lpc-bluez-maemo-2009.html

Last week I’ve been at the Linux Plumbers Conference in
Portland. Like last year it kicked ass and proved again being one of the most
relevant Linux developer conferences (if not the most relevant one). I
ran the Audio MC at the conference which was very well attended. The slides
for our four talks in the
track are available online
. (My own slides are probably a bit too terse
for most readers, the interesting stuff was in the talking, not the
reading…) Personally, for me the most interesting part was to see to which
degree Nokia actually adopted PulseAudio
in the N900. While I was aware that Nokia was using it, I wasn’t aware that
their use is as comprehensive as it turned out it is. And the industry
support from other companies is really impressive too. After the main track we
had a BoF session, which notes I’ll post a bit later. Many thanks to Paul,
Jyri, Pierre for their great talks. Unfortunately, Palm, the only manufacturer
who is actually already shipping a phone with PulseAudio didn’t send anyone to
the conference who wanted to talk about that. Let’s hope they’ll eventually
learn that just throwing code over the wall is not how Open Source works.
Maybe they’ll send someone to next year’s LPC in Boston, where I hope to be
able to do the Audio MC again.

Right now I am at the BlueZ Summit in Stuttgart. Among other things we have
been discussing how to improve Bluetooth Audio support in PulseAudio. I guess
one could say thet the Bluetooth support in PulseAudio is already one of its
highlights, in fact working better then the support on other OSes (yay, that’s
an area where Linux Audio really shines!). So up next is better support for
allowing PA to receive A2DP audio, i.e. making PA act as if it was a Headset or
your hifi. Use case: send music from from your mobile to your desktop’s hifi
speakers. (Actually this is already support in current BlueZ/PA versions, but
not easily accessible). Also Bluetooth headsets tend to support AC3 or MP3
decoding natively these days so we should support that in PA too. Codec
handling has been on the TODO list for PA for quite some time, for the SPDIF or
HDMI cases, and Bluetooth Audio is another reason why we really should have
that.

Next week I’ll be at the Maemo Summit in Amsterdam.
Nokia kindly invited me. Unfortunately I was a bit too late to get a proper
talk accepted. That said, I am sure if enough folks are interested we could do
a little ad-hoc BoF and find some place at the venue for it. If you have any
questions regarding PA just talk to me. The N900 uses PulseAudio for all things
audio so I am quite sure we’ll have a lot to talk about.

See you in Amsterdam!

One last thing: Check out Colin’s
work to improve integration of PulseAudio and KDE
!

Support Your Friendly Neighborhood FLOSS Charities

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/05/12/start-giving.html

I don’t think we talk enough in the FLOSS community about the importance of individual support of FLOSS-related charitable organizations.
On a
recent podcast episode, Karen and I discuss
with Stormy Peters how
important it is for geeks — who may well often give lots of code
to many FLOSS projects — also should consider giving a little bit
of financial funding to FLOSS organizations as well.

Of course, it’s essential that people give their time to the charities
and the causes that they care about. In the FLOSS world, we typically
do that by giving code or documentation to our favorite FLOSS project.
I think that’s led us all into the classic “I gave at the
office” feeling. Indeed, I know that I too have fallen into this
rut at times myself.

I suppose I could easily claim that, more than most people, I’ve given
enough at the office. Working at various non-profit organizations since
the 1990s, I’ve always made substantially less in salary than I would in
the for-profit industry for similar work. I also have always
volunteered my time in addition to my weekly work schedule. For
example, I currently get paid for my 40 hour/week job at the SFLC, but I
also donate about 20 hours of work for
the Software
Freedom Conservancy
each week.

Still, I don’t believe that this is enough. There
are many,
many FLOSS non-profits
that deserve support — more than I have time to give. Meanwhile, very small
amounts of money, aggregated over many people giving, makes a world of
difference in a number of ways to these organizations.

Non-profits that are funded by a broad base of supporters are much more
stable and have greater longevity than other types of non-profits that
are funded primarily by corporate donations. This is because one donor
or even a few disappearing is not disaster. Also, through these donations, organizations
build a constituency of supporters that truly represent the people
that the non-profit seeks to serve.

Traditionally (with a few notable exceptions), non-profits in the FLOSS
world have relied primarily on corporate donations. I generally think
this is not ideal for a community that wishes to be fully represented by
the non-profits that embody the projects we care about. We want these
projects to represent the interest of developers and users, not
necessarily the for-profit corporate interests. Plus, we want the
organizations to survive even when companies stop supporting FLOSS or
just simply go out of business.

If we all contribute, it doesn’t take that much for each individual to
be a part of making a real difference. I believe that if each person
who has benefited seriously from FLOSS gave $200/year, we’d make a
substantial change and a wonderful positive impact on the non-profit
organizations that shepherd and keep these FLOSS projects alive. I’m
not suggesting giving to any specific organization: just to take
$200/year and divide in the way you think is best across 2-4 different
FLOSS non-profits that sponsor project you personally care about or
benefit from.

Think about it: $200/year breaks down to $16/month. For me (and likely
for most people in a major city), $16/month means one fewer dinner at a
restaurant each month. Can’t we all eat at home one more time per
month, and share that savings to help FLOSS non-profits?

If you are looking for a list of non-profits that could use your
support,
the FLOSS
Foundations Directory
is a good place to start. FWIW, in addition
to my volunteer work
with Conservancy,
here’s the list of non-profits that I’m supporting with a total of $200
this year (in
alphabetical order): The Free
Software Foundation
, GNOME
Foundation
, The Parrot
Foundation
,
and The
Twisted Project
. Which ones will you give to this year?

Fork Well: It Could Be The Last, Best Hope for Community

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/24/fork-well.html

I have faced with much trepidation the news of Oracle’s looming purchase
of Sun. Oracle has never shown any interest in community development,
particularly in the database area. They are the largest proprietary
database vendor on the planet, and they probably have very simple plans
for MySQL: kill it.

That’s why I read with relief
this
post by Monty (co-founder of the MySQL project) this week
, wherein
Monty plans (and encourages others, too) to put their full force behind
a MySQL “fork” that will be centered outside of Oracle.

Monty is undoubtedly correct when he says I don’t think that anyone
can own an open source project; the projects are defined by the de-facto
project leaders and the developers that are working on the project.
and that [w]ith Oracle now owning MySQL, I think that the need for an
independent true Open Source entity for MySQL is even bigger than ever
before.

I don’t find the root of this problem in that one company has sold
itself to another, pursuant to the the greater glory of the
Ferengi
Rules of Acquisition
. Instead, I think the error is that projects
inside Sun did not have a non-profit entity to shepherd them. When a
single for-profit company is in control of a project’s copyrights, its
trademarks, and employs nearly all its core developers, there is a gross
imbalance. The community around the project isn’t healthy, and can
easily be disrupted by the winds of corporate change, which blow in
service of the only goal of for-profit existence: higher profits.

I encourage Monty, as well as core developers of VirtualBox,
OpenOffice, OpenSolaris, Sun’s Java, and any other project that is
currently under the full control of Sun (or indeed any other for-profit
corporation) to think about this idea. Non-profits, particularly
501(c)(3)’s, are fundamentally different than for-profits. They exist
to serve a community or a constituency and the public good, never
profit. Therefore, the health of the codebase, the diversity of the
developer and user community, and the advancement of software freedom
can be the clear mission of a non-profit that houses a FLOSS project. A
non-profit ensures that while corporate funding comes and goes, the
mission of the project and its institutional embodiment stay stable.
For example, just like shareholders have a duty to fire a CEO when he
fails to make enough profit (i.e., the for-profit company is not
reaching its maximal goal), boards of directors and/or memberships of
non-profits must fire the President and/or Executive Director when they
fail to serve the community well. Instead of the “profit
motive”, 501(c)(3)’s have the “community motive”.

Yet, the challenge of focusing on such goals remains difficult for
projects that did not spawn from a community to start. GNU and Linux
were both started by individual developers that built strong communities
before there was any for-profit corporate interest in the software.
When a project started inside a company with profit in mind, shoehorning
community principles into the project can rarely succeed. I believe
that a community must usually evolve from the ashes of some incident
that wakes everyone up to realize the project will come to harm due to
strict adherence to the profit motive.

I should probably remind everyone that I’m not opposed to capitalism
per se. Indeed, I’ve often fought on the other side of this equation
when licenses (such as MySQL’s own very early pre-GPL license) permit
noncommercial use but prohibit commercial use. I believe that
commercial and non-commercial activity with the code should be
equally permitted in a non-discriminatory way. However, the center of
gravity for developers, where the copyrights and trademarks live, and
how core work on the codebase is funded are all orthogonal questions to
the question of the software’s license.

My experience has anecdotally taught me that FLOSS communities function
best when the following two things are true: (a) the codebase is held
neutrally, either in the hands of the individual developers who wrote
the code, or in a 501(c)(3) non-profit, and (b) not too many core
developers share the same employer. I believe that reaching that state
should be Job One of any for-profit seeking to build a FLOSS community.
Sadly, this type of community health is often at direct odds with
the traditional capitalist thinking of for-profit shareholders.
I’m thus not surprised when FLOSS community managers in for-profit
companies can only do so much. The rest is really up to the community
of developers to fork and demand that a non-profit or other neutral and
diverse developer-controlled management team exist. Attempts at this,
sadly, fail much more often than they succeed.

Monty’s post likely had more hope in it than this one. Monty didn’t
jump to my conclusion that Oracle will kill MySQL; Monty considers it
also possible that Oracle might sell MySQL or (and here’s the
possibility I really doubt) that Oracle will change into a
community-driven FLOSS company. I love Monty’s optimism in even
considering this possible. I honestly hope my pragmatism about this is
shown to be sheer pessimism. In the meantime, focusing on the MySQL
forks and pressuring Oracle to engage the FLOSS community in a genuine
way is the best strategy no matter what outcome you think is most
likely.

Update (on 17 May 2009):
Monty announced
an industry consortium
that will seek to be a neutral space for
MySQL development. I tend to prefer charitable non-profits to trade
associations, but better the latter than hoping for Oracle to do the
right thing.

TomTom/Microsoft: A Wake-Up Call for GPLv3 Migration

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/04/16/tomtom-microsoft.html

There has been a lot of press coverage about the Microsoft/TomTom
settlement. Unfortunately, so far, I have seen no one speak directly
about the dangers that this deal could pose to software freedom, and
what our community should consider in its wake. Karen and I discussed
some of these
details on
our podcast
, but I thought it would be useful to have a blog post
about this issue as well.

Most settlement agreements are sealed. This means that we won’t ever
actually know what TomTom agreed to and whether or not it violates
GPLv2. The violation, if one exists, would likely be of GPLv2’s §
7. The problem has always been that it’s difficult to actually witness
a v2§7 violation occurring (due in large part to less than perfect
wording of that section). To find a violation v2§7, you have to
discover that there were conditions imposed on [TomTom] … that
contradict the conditions of [GPLv2]. So, we won’t actually know if
this agreement violates GPLv2 unless we read the agreement itself, or if
we observe some behavior by Microsoft or TomTom that shows that the
agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For
TomTom to have agreed to something GPLv2-compliant with Microsoft, the
agreement would have needed to either (a) not grant a patent license at
all (perhaps, for example, Microsoft conceded in the sealed agreement
that the patents aren’t actually enforceable on the GPLv2’d components),
or (b) give a patent license that was royalty-free and permitted all
GPLv2-protected activities by all recipients of patent-practicing
GPLv2’d code from TomTom, or downstream from TomTom.

It’s certainly possible Microsoft either capitulated regarding the
unenforceability (or irrelevancy) of its patents on the GPLv2’d software
in question, or granted some sort of license. We won’t know directly
without seeing the agreement, or by observing a later action by
Microsoft. If, for example, Microsoft later is observed enforcing the
FAT patent against a Linux distributor, one might successfully argue
that the user must have the right to practice those
Microsoft patents in the GPLv2 code, because otherwise, how was TomTom
able to distribute under GPLv2? (Note, BTW, that any
redistributor of Linux could make themselves downstream from TomTom,
since TomTom distributes source on their website.) If no such
permission existed, TomTom would then be caught in a violation —
at least in my (perhaps minority) reading of GPLv2.0

Many have argued that GPLv2 § 7 isn’t worded well enough to
verify this line of thinking. I and a few other key GPL thinkers
disagree, mainly because this reading is clearly the intent of GPLv2
when you read the Preamble. But, there are multiple interpretations of
GPLv2’s wording on this issue, and, the wording was written before the
drafters really knew exactly how patents would be used to hurt Free
Software. We’ll thus probably never really have complete certainty that
such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like
it whose existence is not public, because lawsuits aren’t involved)
almost surely plays into this interpretation ambiguity. Microsoft
likely convinced TomTom that the deal is GPLv2-compliant, and that’s why
there are so many statements in the press opining about its likely GPLv2
compliance. I, Jeremy Allison, and others might be in the minority in
our belief of the strength of GPLv2 § 7, but no one can disagree
with the intent of the section, as stated in the Preamble. Microsoft is
manipulating the interpretation disagreements to convince smaller
companies like Novell, TomTom, and probably others into believing that
these complicated patent licensing deals and/or covenants are
GPLv2-compliant. Since most of them are about the kernel named Linux,
and the Linux copyright holders are the only ones with power to enforce,
Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the
situation. Therefore, this is a great moment in our community to
reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal,
considered carefully how to address these sorts of agreements.
Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

A patent license is “discriminatory” if it does not include
within the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is in
the business of distributing software, under which you make payment to the
third party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who would
receive the covered work from you, a discriminatory patent license (a) in
connection with copies of the covered work conveyed by you (or copies made
from those copies), or (b) primarily for and in connection with specific
products or compilations that contain the covered work, unless you entered
into that arrangement, or that patent license was granted, prior to 28
March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those
in the second paragraph, would clearly and unequivocally prohibit TomTom
from entering into any arrangement with Microsoft that doesn’t grant a
license to any Microsoft patent that reads on Linux. Indeed, even what
has been publicly said about this agreement seems to indicate strongly
that this deal would violate GPLv3. While the Novell/Microsoft deal was
grandfathered in (via the date above), this new agreement is not. Yet,
the most frustrating aspect of the press coverage of this deal is that
few have taken the opportunity to advocate for GPLv3 adoption by more
projects. I hope now that we’re a few weeks out from the coverage,
project leaders will begin again to consider adding this additional
patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should
explain a bit why special patent licensing deals like this are bad for
software freedom; it’s not completely obvious. To do so, we can look
specifically at what TomTom and Microsoft said in the press coverage of
their deal: The agreement protects TomTom’s customers under the
patents …, the companies said
(Microsoft,
TomTom Settle Patent Dispute
, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort
of “patent protection” to TomTom customers,
and presumably no one else. This means that if someone buys a
GNU/Linux-based TomTom product, they have greater protection from
Microsoft’s patents than if they don’t. It creates two unequal classes of
users: those who pay TomTom and those who don’t. The ones who don’t pay
TomTom will have to worry if they will be the next ones sued or attacked
in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is
precisely what all versions of the GPL seek to prevent. This is why the
Preamble of GPLv2 said: any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a
free program will individually obtain patent licenses, in effect making
the program proprietary.

Further to this point, in
the Rationale
Document for the Third Discussion Draft of GPLv3
, a similar
argument is given in more detail:

The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to the
extent that users feel compelled, by the threat of the patent, to get
their copies in this way. So far, the Microsoft/Novell deal does not seem
to have had this result, or at least not very much: users do not seem to
be choosing Novell for this reason. But we cannot take for granted that
such threats will always fail to harm the community. We take the threat
seriously, and we have decided to act to block such threats, and to reduce
their potential to do harm. Such deals also offer patent holders a crack
through which to split the community. Offering commercial users the chance
to buy limited promises of patent safety in effect invites each of them to
make a separate peace with patent aggressors, and abandon the rest of our
community to its fate.

It’s true that one can blissfully use, redistribute, sell and modify
some patent-covered software for years without ever facing a patent
enforcement action. But, particularly in situations where known patents
have been asserted, those without a patent license often live in fear of
copying, modifying and sharing code that exercises the teachings of the
patent. We saw this throughout the 1990s with RSA, and today most
commonly with audio and video codecs. Microsoft and other anti-Free
Software companies have enough patents to attack if we let them. The
first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3
with the improved patent provisions, and (b) condemning GPLv2-only deals
that solve a patent problem for some users but leave the rest out in the
cold, and (c) pointing out that the purported certainty that such deals
are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under
GPLv2 has probably been underestimated, we cannot overestimate the
additional protection that GPLv3 gives us in this regard. Microsoft
clearly knows that the GPLv3 terms will kill their patent aggression
business model, and have therefore focused their attacks on
GPLv2-licensed code. Shouldn’t we start to flank them by making less
GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom,
as a company, is not necessarily an ally of software freedom. They are
like most for-profit companies; they use FLOSS when it is convenient for
them, and give back when the licenses obligate them to do so, or when it
behooves them in some way. As a for-profit company, they made this deal
to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their
products was done legitimately (that
is, once
their GPLv2 non-compliance was corrected by Harald Welte in 2004
).
However, I do not think we should look upon TomTom as a particularly
helpful member of the community. Indeed, most of the patents that
Microsoft asserted against TomTom were on their proprietary components,
not their FLOSS ones. Thus, most of this dispute was a proprietary
software company arguing with another proprietary software company over
patents that read on proprietary software. Our community should tell
TomTom that if they want to join and support the FLOSS world, they
should release their software under a FLOSS license — including
software that they aren’t obligated to do so by the licenses. Wouldn’t it be quite interesting if TomTom’s mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom’s patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn’t they allow us to at least practice the teachings of their patents in GPL’d software?

0Update:
Andrew Tridgell pointed out that my verb tenses in my hypothetical example
made the text sound more broadly worded than I intended. I’ve thus
corrected the text in the hypothetical example to be clearer. Thanks for
the clarification, Tridge!

Writing Volume Control UIs is Hard

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/writing-volume-control-uis.html

Writing modern volume control UIs (i.e. ‘mixer tools’) is much harder to get
right than it might appear at first. Because that is the way it is I’ve put
together a rough
guide what to keep in mind when writing them for PulseAudio
. Originally
just intended to be a bit of help for the gnome-volume-control guys I believe
this could be an interesting read for other people as well.

It touches a lot of topics: volumes in general, how to present them,
what to present, base volumes, flat volumes, what to do about multichannel
volumes, controlling clients, controlling cards, handling default devices,
saving/restoring volumes/devices, sound event sliders, how to monitor PCM and
more.

So make sure to give it at least a quick peek! If you plan to write a volume
control for ncurses or KDE (hint, hint!) even more so, it’s a must read.

Maybe this might also help illustrating why I think that abstracting volume
control interfaces inside of abstraction layers such as Phonon or GStreamer is
doomed to fail, and just not even worth the try.

And now, without further ado I give you ‘Writing Volume Control UIs’.

Writing Volume Control UIs is Hard

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/writing-volume-control-uis.html

Writing modern volume control UIs (i.e. ‘mixer tools’) is much harder to get
right than it might appear at first. Because that is the way it is I’ve put
together a rough
guide what to keep in mind when writing them for PulseAudio
. Originally
just intended to be a bit of help for the gnome-volume-control guys I believe
this could be an interesting read for other people as well.

It touches a lot of topics: volumes in general, how to present them,
what to present, base volumes, flat volumes, what to do about multichannel
volumes, controlling clients, controlling cards, handling default devices,
saving/restoring volumes/devices, sound event sliders, how to monitor PCM and
more.

So make sure to give it at least a quick peek! If you plan to write a volume
control for ncurses or KDE (hint, hint!) even more so, it’s a must read.

Maybe this might also help illustrating why I think that abstracting volume
control interfaces inside of abstraction layers such as Phonon or GStreamer is
doomed to fail, and just not even worth the try.

And now, without further ado I give you ‘Writing Volume Control UIs’.

Welcome (Finally!) to the GCC Runtime Library Exception

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/01/27/gcc-exception.html

For the past sixteen months, I participated in a bit of a “mini-GPLv3
process” among folks at the FSF, SFLC, the GNU Compiler Collection
Steering Committee (GCC SC), and the GCC community at large. We’ve been
drafting an important GPLv3 license exception (based on a concept by
David Edelsohn and Eben Moglen, that they invented even before the
GPLv3 process itself started).
Today, that
GCC Runtime Library Exception for GPLv3 went into production
.

I keep incessant track of my hours spent on various projects, so I have
hard numbers that show I personally spent 188 hours — a full month
of 40-hour weeks — on this project. I’m sure my colleagues
have spent similar amounts, too. I am proud of this time, and I think
it was absolutely worthwhile. I hope the discussion gives you a flavor
of why FLOSS license exception drafting is both incredibly important and
difficult to get right without the greatest of care and attention to
detail.

Why GPL Exceptions Exist

Before I jump into discussion of this GCC Runtime Library exception,
some background is needed. Exceptions have been a mainstay of copyleft
licensing since the inception of the GNU project, and once you’ve seen
many examples over many years, they become a standard part of FLOSS
licensing. However, for the casual FLOSS developer who doesn’t wish to
be a licensing wonk (down this path lies madness, my friends, run
screaming with your head covered!), exceptions are a rare discovery in a
random source file or two, and they do not command great attention. An
understandable reaction, but from a policy perspective, they are an
essential part of the copyleft system.

From the earliest days of the copyleft, it was understood that copyleft
was a merely a strategy to reach the goal of software freedom. The GPL
is a tool that implements this strategy, but like any tool, it doesn’t
fit every job.

In some sense, the LGPL was the earliest and certainly the most widely
known “GPL exception”. (Indeed, my friend Richard Fontana
came up with the idea to literally make LGPL an exception to
GPLv3, although in the v2 world, LGPLv2 was a fully separate license
from GPLv2.) Discussions on why the LGPL exists are beyond the scope of
this blog post
(although I’ve
written about them before
). Generally speaking, though, LGPL is
designed to be a tool when you don’t want the full force of copyleft for
all derivative works. Namely, you want to permit the creation of some
proprietary (or partly proprietary) derivative works because allowing
those derivations makes strategic sense in pursuing the goal of software
freedom.

Aside from the LGPL, the most common GPL exceptions are usually what we
generally categorize as “linking exceptions”. They allow
the modifier to take some GPL’d object code and combine it in some way
with some proprietary code during the compilation process. The simplest
of these exceptions is found when you, for example, write a GPL’d
program in a language with only a proprietary implementation, (e.g.,
VisualBasic) and you want to allow the code to combine with the
VisualBasic runtime libraries. You use your exclusive right as
copyright holder on the new program to grant downstream users,
redistributors and modifiers the right combine with those proprietary
libraries without having those libraries subject to copyleft.

In essence, copyleft exceptions are the scalpels of copyleft. They
allow you to create very carefully constructed carve-outs of permission
when pure copyleft is too blunt an instrument to advance the goal of
software freedom. Many software freedom policy questions require this
fine cutting work to reach the right outcome.

The GCC Exception

The GCC Exception (well, exceptions, really) have
always been a particularly interesting and complex use of a copyleft
exception. Initially, they were pragmatically needed to handle a
technological reality about compilers that interacts in a strange way
with copyright derivative works doctrine. Specifically, when you
compile a program with gcc, parts of GCC itself, called the runtime
library (and before that, crt0), are combined directly with your program
in the output binary. The binary, therefore, is both a derivative work
of your source code and a derivative work of the runtime library. If
GCC were pure GPL, every binary compiled with GCC would need to be
licensed under the terms of GPL.

Of course, when RMS was writing the first GCC, he realized immediately
this licensing implication and created an exception to avoid this.
Versions of that exception has been around and improved since the late
1980s. The task that our team faced in late 2007 was to update that
exception, both to adapt it to the excellent new GPLv3 exceptions
infrastructure (as Fontana did for LGPLv3), and to handle a new policy
question that has been kicking around the GCC world since 2002.

The Plugin Concern

For years, compiler experimentalists and researchers have been
frustrated by GCC. It’s very difficult to add a new optimization to GCC
because you need quite a deep understanding of the codebase to implement
one. Indeed I tried myself, as a graduate student in programming
languages in the mid-1990s, to learn enough about GCC to do this, but
gave up when a few days of study got me nowhere. Advancement of
compiler technology can only happen when optimization experimentation
can happen easily.

To make it easy to try new optimizations out, GCC needs a plugin
architecture. However, the GCC community has resisted this because of
the software freedom implications of such an architecture: if plugins
are easy to write, then it will be easy to write out to disk a version
of GCC’s internal program representation (sometimes called the
intermediate representation, or IR). Then, proprietary programs could
be used to analyze and optimize this IR, and a plugin could be used to
read the file back into GCC.

From a licensing perspective, such an optimizing proprietary program
will usually not be a derivative work of GCC; it merely reads and writes
some file format. It’s analogous to OpenOffice reading and writing
Microsoft Word files, which doesn’t make it a derivative of Word by any
means! The only parts that are covered by GPL are the actual plugins to
GCC to read and write the format, just as OpenOffice’s Word reader and
writer are Free Software, but Microsoft Word is not.

This licensing implication is a disaster for the GCC community. It
would mean the advent of “compilation processes” that were
“mixed”, FaiF and proprietary. The best, most difficult and
most interesting parts of that compilation process — the
optimizations — could be fully proprietary!

This outcome is unacceptable from a software freedom policy
perspective, but difficult to handle in licensing. Eben Moglen, David
Edelsohn, and a few others, however, came up with an innovative idea:
since all binaries are derivative of GCC anyway, set up the exception so
that proprietary binary output from GCC is permitted only when the
entire compilation process involves Free Software. In other words, you
can do these proprietary optimization plugins all you want, but if you
do, you’ll not be able to compile anything but GPL’d software with
them!

The Drafting and the Outcome

As every developer knows, the path from “innovative idea”
to “working implementation” is a long road. It’s just as
true with licensing policy as it is with code. Those 188 hours that
I’ve spent, along with even more hours spent by a cast of dozens, have
been spent making a license exception that implements that idea
accurately without messing up the GCC community or its licensing
structure.

With jubilation today, I link to
the announcement
from the
FSF
, the
FAQ and Rationale for the exception
and
the final
text of the exception itself
. This sixteen-month long cooperation
between the FSF, the SFLC, the GCC SC, and the GCC community has
produced some fine licensing policy that will serve our community well
for years to come. I am honored to have been a part of it, and a bit
relieved that it is complete.

One gpg –gen-key per Decade

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/12/09/gpg-gen-key-decade.html

Today is an interesting anniversary (of sorts) for my cryptographic
infrastructure. Nine years ago today, I generated the 1024 bit DSA key,
DB41B387, that has been my GPG key every day since then. I remember
distinctly that on the 350 MhZ machine I used at the time, it took quite
a while to generate, even though I made sure the entropy pool remained
nice and full by pounding on the keyboard.

The horribleness of the
recent Debian vulnerability
meant that I have spent a much time
this year pondering the pedigree my personal cryptographic
infrastructure. Of course, my key was far too old to have been
generated on a Debian-based system that had that particular
vulnerability. However, the issue that really troubled me this
past summer was this:

Some DSA keys may be compromised by only their use. A strong
key (i.e., generated with a ‘good’ OpenSSL) but used locally
on a machine with a ‘bad’ OpenSSL must be considered to be
compromised. This is due to an ‘attack’ on DSA that allows the
secret key to be found if the nonce used in the signature is reused or
known.

Not being particularly hard core on cryptographic knowledge — most of my expertise comes from only one class I took 11 years ago on
Encryption, Compression, and Secure Hashing in graduate school —
I found this alarming and tried my best to do some ancillary reading.
It seems that DSA keys, in many ways, are less than optimal. It seems
(to my mostly uneducated eye) in skimming academic papers that DSA keys
are tougher to deploy right and keep secure, which leads to these sorts
of possible problems.

I’ve resolved to switch entirely to RSA keys. The great thing about
RSA is its simplicity and ease of understanding. I grok factoring and
understand better the complexity situation of the factoring problem
(this time, from the two graduate courses I took on Complexity
Theory, so my comfort is more solid :). I also find it intriguing that
a child can learn how to factor in grade school, yet we can’t teach a
computer to do it efficiently. (By contrast, I didn’t learn the
discrete logarithm problem until my Freshman year of college, and I
still have to look up the details to remind myself.) So, the
“simplicity brings clarity” idea hints that RSA is a better
choice.

Fact is, there was only one reason why I revoked my ancient RSA
keys and generated DSA ones in the 1990s. The RSA patent and the strict
licensing of that patent by RSA Data Security, Inc. made it impossible
to implement RSA in Free Software back then. So, when I switched from
proprietary PGP to GPG, my keys wouldn’t import. Indeed, that one RSA
patent alone set back the entire area of Free Software cryptography at least ten years.

So, when I decided this evening that I’d need to generate a new key and
begin promulgating it at key-signing parties sometime before DB41B387
turns ten, I realized I actually have the freedom to choose my
encryption algorithm now! Sadly, it took almost these entire nine years
to get there. Our community did not only have to wait out this
unassailable patent. (RSA is among the most novel and non-obvious ideas
that most computer professionals will ever seen in their lives). Once
the RSA patent finally expired0, we had to then slowly but
surely implement and deploy it in cryptographic programs, from
scratch.

I’m still glad that we’re free of the RSA patent, but I fear among the
mountain of “software patents” granted each year, that the
“new RSA” — a perfectly valid, non-obvious and novel
patent that reads on software and fits both the industry’s and patent
examiner’s definition of “high quality” — is waiting
to be discovered and used as a weapon to halt Free Software again. When
I finally type gpg –gen-key (now with
–expert mode!) for the first time in nine years, I hope
I’ll only experience the gladness of being able to generate an RSA key,
and succeed in ignoring the fact that RMS’
old essay about this issue remains a cautionary tale
to this very
day. Software patents are a serious long-term threat and must be
eradicated entirely for the sake of software freedom. The biggest threat among them will always be the “valid”, “high quality”
software patents, not the invalid, poor quality ones.

0 Technically speaking,
RSA didn’t need to expire. In a seemingly bizarre
move
, RSA Data Security, Inc. granted a Free license to the
patent a few weeks before the actual expiration date. To
this day, I believe the same theory I espoused at the time:
their primary goal in doing this was merely to ruin all the
“RSA is Free” parties that had been planned.

GNU’s Birthday

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/09/02/gnu-birthday.html

Twenty-five years ago this month, I had just gotten my first computer,
a Commodore 64, and was learning the very basics (quite literally) of
programming. Unfortunately for my education, it would be a full eight
years before I’d be permitted to see any source code to a computer
program that I didn’t write myself. I often look back at those eight
years and consider that my most formative years of programming learning were
wasted, since I was not permitted to study the programs written by the
greatest minds.

Fortunately for all the young programmers to come after me, something
else was happening in an office at an MIT building in September 1983
that would make sure everyone would have the freedom to study code, and
the freedom to improve it and contribute to the global library of
software development knowledge. Richard
Stallman announced
that he would start the GNU project
, a complete operating system
that would give all its users freedom.

I got involved with Free Software in 1992. At the time, I was the one
student in my university who had ever heard of GNU and the recently
released kernel named Linux. My professors knew of “that Stallman
guy” but were focused primarily on academic research. Fortunately
for me, they nevertheless gave me free reign over the systems to turn
them into what might have been, in late 1992, one of the first Computer
Science labs running entirely Free Software.

Much more has happened since even then. To commemorate all that has
come since Stallman’s announcement, my colleagues at the FSF, home of
the GNU project, released a video for
this historic 25 year anniversary
. It took twenty-five years, and a
fight at the BBC over DRM, but now even a famous, accomplished actor
like Stephen Fry
is interested in the work that Stallman began way back in a year when
Michael Jackson was a musical phenomenon and not merely a punchline of a
joke.

These days, I have almost weekly moments of surprise that people
outside of the Software Freedom Movement have actually heard of what I
do for a living. When Matt Lee (whom I got to know when he came up through the
ranks in the 2000’s as I did in the 1990’s as a new FSF volunteer) told
me a few months ago that Stephen Fry had enthusiastically and
immediately agreed to make this video, it was yet another moment of
surprise. We now live in a movement that impacts everyone in the
industrialized world, because nearly everyone who has access to
electricity also must use a computer to interact with daily life. So
many people are impacted by the problems of proprietary software that
Stallman noticed in 1983 impacting his small developer community.
Thanks to the work of thousands, we now have the opportunity to welcome
new groups into a computing world that can give them freedom. I’m happy
that the friendly face of a talented and accomplished entertainer and
world-class actor is here to welcome them.

Singapore, Australia, Hong Kong and Recife

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/sg-au-hk.html

In January/February around FOMS 2008 and linux.conf.au I traveled to Singapore, Hong Kong and Australia,
together with two fellow hackers, Kay and David. It took a while until I found the
time to go through and sort all the photos I made on this trip. But finally I am done, and I am not going
to spare you a few shots.

Singapore  
Singapore  
Singapore  
Singapore  

Singapore  
Singapore  
Singapore  
Singapore  
Singapore  
Singapore  

Singapore  
Singapore  
Singapore  
Singapore  
Singapore  
Singapore  

That was Singapore. The next destination on the trip was Australia, more specifically Great Ocean Road and the Northern Territory.

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

And on we went, for Hong Kong.

Hong Kong  
Hong Kong  
Hong Kong  
Hong Kong  

Hong Kong  
Hong Kong  
Hong Kong  

In March I attended the BOSSA Conference in Brazil and visited Recife and Olinda.

Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  

Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  

That’s all for now.

Singapore, Australia, Hong Kong and Recife

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/sg-au-hk.html

In January/February around FOMS 2008 and linux.conf.au I traveled to Singapore, Hong Kong and Australia,
together with two fellow hackers, Kay and David. It took a while until I found the
time to go through and sort all the photos I made on this trip. But finally I am done, and I am not going
to spare you a few shots.

Singapore  
Singapore  
Singapore  
Singapore  

Singapore  
Singapore  
Singapore  
Singapore  
Singapore  
Singapore  

Singapore  
Singapore  
Singapore  
Singapore  
Singapore  
Singapore  

That was Singapore. The next destination on the trip was Australia, more specifically Great Ocean Road and the Northern Territory.

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

Australia  
Australia  
Australia  
Australia  
Australia  
Australia  
Australia  

And on we went, for Hong Kong.

Hong Kong  
Hong Kong  
Hong Kong  
Hong Kong  

Hong Kong  
Hong Kong  
Hong Kong  

In March I attended the BOSSA Conference in Brazil and visited Recife and Olinda.

Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  

Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  
Brazil  

That’s all for now.

Back from LCA

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/lca2008.html

After coming back from my somewhat extended linux.conf.au trip I spent the
whole day grepping through email. Only 263 unprocessed emails left in my inbox.
Yay.

PRTPILU

Thanks to the LCA guys, video footage is now available of all talks,
including my talk
Practical Real-Time Programming in Linux Userspace
(Theora,
Slides).
In my endless modesty I have to recommend: go, watch it, it contains some
really good stuff (including me not being able to divide 1 by 1000). Right now,
the real-time features of the Linux kernel are seldomly used on the desktop due
to a couple of reasons, among them general difficulty and unsafety to use them
but predominantly it’s probably just unawareness. There are a couple of
situations however, where scheduling desktop processes as RT makes a lot of
sense (think of video playback, mouse curse feedback, etc.), to decouple the
execution (scheduling) latency from the system load. This talk focussed mostly
on non-trivial technical stuff and all the limitations RT on Linux still has.
To fully grok what’s going on you thus need some insight into concurrent
programming and stuff.

My plan is to submit a related talk to GUADEC wich will focus more on
actually building RT apps for the desktop, in the hope we will eventually be
able to ship a desktop with audio and video that never skips, and where user
feedback is still snappy and quick even if we do the most complicated IO
intensive processing in lots of different processes in the background on slow
hardware.

I didn’t have time to go through all my slides (which I intended that way
and is perfectly OK), so you might want to browse through my slides even if you
saw the whole clip. The slides, however, are not particularly verbose.

Rumors

Regarding all those
rumors
that have been spread while I — the maintainer of PulseAudio — was in the
middle of the australian outback, fist-fighting with kangaroos near Uluru: I
am not really asking anyone to port their apps to the native PulseAudio API right now. While I do think
the API is quite powerful and not redundant, I also acknowledge that it is
very difficult to use properly (and very easy to misuse), (mostly) due to its
fully asynchronous nature. The mysterious libsydney project is
supposed to fix this and a lot more. libsydney is mostly the Dukem Nukem
Forever of audio APIs right now, but in contrast to DNF I didn’t really
announce it publicly yet, so it doesn’t really count. 😉 Suffice to
say, the current situation of audio APIs is a big big mess. We are working on
cleaning it up. For now: stick to the well established and least-broken APIs,
which boils down to ALSA. Stop using the OSS API now! Don’t program
against the ESD API (except for event sounds). But, most importantly: please
stop misusing the existing APIs. I am doing my best to allow all current APIs
to run without hassles on top of PA, but due to the sometimes blatant misues,
or even brutal violations of those APIs it is very hard to get that working
for all applications (yes, that means you, Adobe, and you, Skype). Don’t
expect that mmap is available on all audio devices — it’s not, and especially
not on PA. Don’t use /proc/asound/pcm as an API for enumerating audio
devices. It’s totally unsuitable for that. Don’t hard code device strings. Use
default as device string. Don’t make assumptions that are not and
cannot be true for non-hardware devices. Don’t fiddle around with period
settings unless you fully grok them and know what you are doing. In short: be
a better citizen, write code you don’t need to be ashamed of. ALSA has its
limitations and my compatibility code certainly as well, but this is not an
excuse for working around them by writing code that makes little children cry.
If you have a good ALSA backend for your program than this will not only fix
your issues with PA, but also with Bluetooth, you will have less code to
maintain and also code that is much easier to maintain.

Or even shorter: Fix. Your. Broken. ALSA. Client. Code. Thank you.

Oh, if you have questions regarding PA, just ping me on IRC (if I am
around) or write me an email, like everyone else. Mysterious, blogged pseudo
invitations to rumored meetings is not the best way to contact me.

Back from LCA

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/lca2008.html

After coming back from my somewhat extended linux.conf.au trip I spent the
whole day grepping through email. Only 263 unprocessed emails left in my inbox.
Yay.

PRTPILU

Thanks to the LCA guys, video footage is now available of all talks,
including my talk
Practical Real-Time Programming in Linux Userspace
(Theora,
Slides).
In my endless modesty I have to recommend: go, watch it, it contains some
really good stuff (including me not being able to divide 1 by 1000). Right now,
the real-time features of the Linux kernel are seldomly used on the desktop due
to a couple of reasons, among them general difficulty and unsafety to use them
but predominantly it’s probably just unawareness. There are a couple of
situations however, where scheduling desktop processes as RT makes a lot of
sense (think of video playback, mouse curse feedback, etc.), to decouple the
execution (scheduling) latency from the system load. This talk focussed mostly
on non-trivial technical stuff and all the limitations RT on Linux still has.
To fully grok what’s going on you thus need some insight into concurrent
programming and stuff.

My plan is to submit a related talk to GUADEC wich will focus more on
actually building RT apps for the desktop, in the hope we will eventually be
able to ship a desktop with audio and video that never skips, and where user
feedback is still snappy and quick even if we do the most complicated IO
intensive processing in lots of different processes in the background on slow
hardware.

I didn’t have time to go through all my slides (which I intended that way
and is perfectly OK), so you might want to browse through my slides even if you
saw the whole clip. The slides, however, are not particularly verbose.

Rumors

Regarding all those
rumors
that have been spread while I — the maintainer of PulseAudio — was in the
middle of the australian outback, fist-fighting with kangaroos near Uluru: I
am not really asking anyone to port their apps to the native PulseAudio API right now. While I do think
the API is quite powerful and not redundant, I also acknowledge that it is
very difficult to use properly (and very easy to misuse), (mostly) due to its
fully asynchronous nature. The mysterious libsydney project is
supposed to fix this and a lot more. libsydney is mostly the Dukem Nukem
Forever of audio APIs right now, but in contrast to DNF I didn’t really
announce it publicly yet, so it doesn’t really count. 😉 Suffice to
say, the current situation of audio APIs is a big big mess. We are working on
cleaning it up. For now: stick to the well established and least-broken APIs,
which boils down to ALSA. Stop using the OSS API now! Don’t program
against the ESD API (except for event sounds). But, most importantly: please
stop misusing the existing APIs. I am doing my best to allow all current APIs
to run without hassles on top of PA, but due to the sometimes blatant misues,
or even brutal violations of those APIs it is very hard to get that working
for all applications (yes, that means you, Adobe, and you, Skype). Don’t
expect that mmap is available on all audio devices — it’s not, and especially
not on PA. Don’t use /proc/asound/pcm as an API for enumerating audio
devices. It’s totally unsuitable for that. Don’t hard code device strings. Use
default as device string. Don’t make assumptions that are not and
cannot be true for non-hardware devices. Don’t fiddle around with period
settings unless you fully grok them and know what you are doing. In short: be
a better citizen, write code you don’t need to be ashamed of. ALSA has its
limitations and my compatibility code certainly as well, but this is not an
excuse for working around them by writing code that makes little children cry.
If you have a good ALSA backend for your program than this will not only fix
your issues with PA, but also with Bluetooth, you will have less code to
maintain and also code that is much easier to maintain.

Or even shorter: Fix. Your. Broken. ALSA. Client. Code. Thank you.

Oh, if you have questions regarding PA, just ping me on IRC (if I am
around) or write me an email, like everyone else. Mysterious, blogged pseudo
invitations to rumored meetings is not the best way to contact me.

Three Sisters

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/three-sisters.html

Finally I found the time to sort my photos from Australia, when I vistited the country after linux.conf.au, in January this year. Some photos are quite good, many are not. However one panoramic view of the Three Sisters in the Blue Mountains NP is particularly beautiful:

Three Sisters

Just perfect as a desktop background on your Xinerama setup!

Three Sisters

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/three-sisters.html

Finally I found the time to sort my photos from Australia, when I vistited the country after linux.conf.au, in January this year. Some photos are quite good, many are not. However one panoramic view of the Three Sisters in the Blue Mountains NP is particularly beautiful:

Three Sisters

Just perfect as a desktop background on your Xinerama setup!