Xfce

Subdomains
 

Licensing Suckage

  • December 15, 2008
  • Brian Tarricone
I just got an email from a developer who works on the nifty cairo-dock application, pointing me to a thread about licensing issues. A bunch of months ago, he’d emailed me asking about how to best use code from my Xfce Mailwatch Plugin in cairo-dock to add mail-checking capabilities. At the time, I was pretty [...]

Benchmarks: gtk+ engines

  • December 14, 2008
  • Josh Saddler

Here are some fast and dirty benchmarks of various gtk+ engines installed on my system, using app-benchmarks/gtkperf-0.40.

Notes on the hardware:

CPU: Athlon 64 X2 4600+
Graphics: nVidia 7600GT, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM

Notes on the testing environment:

OS: Gentoo Linux (duh)
Kernel: Linux 2.6.27-gentoo-r2 #3 SMP PREEMPT x86_64
nvidia-drivers: 177.82
CFLAGS: -march=athlon64 -O2 -msse3 -fomit-frame-pointer
DE: Xfce 4.4.3
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 1 instance each of www-client/mozilla-firefox, app-editors/gvim, xfce-extra/terminal
- Cairo: 1.6.4, compiled with glitz support. Not all engines use Cairo, but those that do should benefit from a small speed increase.

The gtk+ engines are all available in Portage. If you're not on Gentoo, look in your distribution's repositories or check here. Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.

All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.

Engine: Mist
Theme: Mist

GtkEntry - time: 0.01
GtkComboBox - time: 0.53
GtkComboBoxEntry - time: 0.47
GtkSpinButton - time: 0.09
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.13
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.24
GtkTextView - Add text - time: 0.28
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.07

Engine: Xfce
Theme: Xfce

GtkEntry - time: 0.03
GtkComboBox - time: 1.12
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.14
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.27
GtkTextView - Scroll - time: 0.17
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.56

Engine: Rezlooks
Theme: Blue Ink*

GtkEntry - time: 0.07
GtkComboBox - time: 0.95
GtkComboBoxEntry - time: 0.65
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.28
GtkCheckButton - time: 0.28
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.34
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 4.31

Engine: Industrial
Theme: Industrial

GtkEntry - time: 0.08
GtkComboBox - time: 1.52
GtkComboBoxEntry - time: 1.04
GtkSpinButton - time: 0.12
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.59
GtkCheckButton - time: 0.35
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.39
GtkTextView - Scroll - time: 0.21
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 5.86

Engine: Glider
Theme: Glider

GtkEntry - time: 0.04
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.62
GtkSpinButton - time: 0.42
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.25
GtkCheckButton - time: 0.19
GtkRadioButton - time: 0.32
GtkTextView - Add text - time: 0.37
GtkTextView - Scroll - time: 0.29
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 6.59

Engine: Pixmap
Theme: Elegant Autumn*

GtkEntry - time: 0.09
GtkComboBox - time: 1.64
GtkComboBoxEntry - time: 1.34
GtkSpinButton - time: 0.24
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.52
GtkCheckButton - time: 0.48
GtkRadioButton - time: 0.89
GtkTextView - Add text - time: 0.69
GtkTextView - Scroll - time: 0.22
GtkDrawingArea - Lines - time: 0.26
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 7.37

Engine: Clearlooks
Theme: Glossy

GtkEntry - time: 0.08
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.45
GtkSpinButton - time: 0.40
GtkProgressBar - time: 0.29
GtkToggleButton - time: 0.61
GtkCheckButton - time: 0.50
GtkRadioButton - time: 0.59
GtkTextView - Add text - time: 0.41
GtkTextView - Scroll - time: 0.32
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.18
---
Total time: 7.68

Engine: Candido
Theme: Graphite Light

GtkEntry - time: 0.08
GtkComboBox - time: 2.10
GtkComboBoxEntry - time: 1.86
GtkSpinButton - time: 0.17
GtkProgressBar - time: 0.26
GtkToggleButton - time: 0.63
GtkCheckButton - time: 0.53
GtkRadioButton - time: 0.60
GtkTextView - Add text - time: 0.48
GtkTextView - Scroll - time: 0.25
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 8.05

Engine: Aurora
Theme: Aurora

GtkEntry - time: 0.47
GtkComboBox - time: 3.78
GtkComboBoxEntry - time: 3.50
GtkSpinButton - time: 0.96
GtkProgressBar - time: 0.31
GtkToggleButton - time: 1.53
GtkCheckButton - time: 1.29
GtkRadioButton - time: 1.66
GtkTextView - Add text - time: 0.58
GtkTextView - Scroll - time: 0.46
GtkDrawingArea - Lines - time: 0.31
GtkDrawingArea - Circles - time: 0.38
GtkDrawingArea - Text - time: 0.32
GtkDrawingArea - Pixbufs - time: 0.19
---
Total time: 15.73

As you can see, the older engines are generally the fastest, with the more modern Rezlooks engine coming in close behind. Though they're generally not as attractive, the old Mist and Xfce engines turn in very respectable rendering times. The Pixmap engine actually doesn't score too well, coming in at the lower middle of the pack. This is despite many reports I found via Google that suggest it's one of the best-performing engines out there. Not so much; it's about average.

But by far the worst performing engine is Aurora. Now, to be fair, Aurora does many graphical tricks the other engines do not. It came along some time after old engines like Pixmap, Industrial, Mist, and Glider. It features animated scrollbars, gauges, and many possible styles of dropdowns and arrows. In short, it's fully loaded. Yet it also doesn't seem to be optimized; at 15.73 seconds, it's almost twice as slow as the nearest contender, Candido.

The results for the Aurora engine were so dismal that I re-ran gtkperf another 3 rounds, thinking something was amiss. Every result turned in times between 15 and 16 seconds. Clearly, Aurora isn't the engine to use if you're on old hardware.

Conclusion:

Remember, these are down and dirty benchmarks. Cherry-picking the best time out of 3 runs may not be the most fair way of measurement, but since no single result varied more than 2 seconds either way, it can be considered pretty well representative of the engine's overall capabilities.

If you're on less capable hardware, the Mist and Xfce engines will go far. If you want something prettier, stick with Rezlooks. I have several screenshots of Rezlooks-based environments in my devspace. It's quite flexible, and it's still in the top three fastest engines, despite including goodies like subtly animated progress bars and gauges.

But even on my fairly powerful workstation, newer engines like Candido and Aurora were noticeably slower, suggesting they might not be a good fit for older hardware. Clearlooks and Pixmap are middle-of-the-road choices; neither has much of an advantage. It comes down to which engine you think has prettier themes.

Me? I stick with Rezlooks. And occasionally Clearlooks (the Glossy theme makes for a good wintry desktop foundation), and very occasionally I'll find a decent Pixmap theme that's worth modding for my system. Otherwise, it's Rezlooks all the way.

Benchmarks: gtk+ engines

  • December 14, 2008
  • Josh Saddler - Category: Xfce

Here are some fast and dirty benchmarks of various gtk+ engines installed on my system, using app-benchmarks/gtkperf-0.40.

Notes on the hardware:

CPU: Athlon 64 X2 4600+
Graphics: nVidia 7600GT, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM

Notes on the testing environment:

OS: Gentoo Linux (duh)
Kernel: Linux 2.6.27-gentoo-r2 #3 SMP PREEMPT x86_64
nvidia-drivers: 177.82
CFLAGS: -march=athlon64 -O2 -msse3 -fomit-frame-pointer
DE: Xfce 4.4.3
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 1 instance each of www-client/mozilla-firefox, app-editors/gvim, xfce-extra/terminal
- Cairo: 1.6.4, compiled with glitz support. Not all engines use Cairo, but those that do should benefit from a small speed increase.

The gtk+ engines are all available in Portage. If you're not on Gentoo, look in your distribution's repositories or check here. Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.

All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.

Engine: Mist
Theme: Mist

GtkEntry - time: 0.01
GtkComboBox - time: 0.53
GtkComboBoxEntry - time: 0.47
GtkSpinButton - time: 0.09
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.13
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.24
GtkTextView - Add text - time: 0.28
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.07

Engine: Xfce
Theme: Xfce

GtkEntry - time: 0.03
GtkComboBox - time: 1.12
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.14
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.27
GtkTextView - Scroll - time: 0.17
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.56

Engine: Rezlooks
Theme: Blue Ink*

GtkEntry - time: 0.07
GtkComboBox - time: 0.95
GtkComboBoxEntry - time: 0.65
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.28
GtkCheckButton - time: 0.28
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.34
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 4.31

Engine: Industrial
Theme: Industrial

GtkEntry - time: 0.08
GtkComboBox - time: 1.52
GtkComboBoxEntry - time: 1.04
GtkSpinButton - time: 0.12
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.59
GtkCheckButton - time: 0.35
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.39
GtkTextView - Scroll - time: 0.21
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 5.86

Engine: Glider
Theme: Glider

GtkEntry - time: 0.04
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.62
GtkSpinButton - time: 0.42
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.25
GtkCheckButton - time: 0.19
GtkRadioButton - time: 0.32
GtkTextView - Add text - time: 0.37
GtkTextView - Scroll - time: 0.29
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 6.59

Engine: Pixmap
Theme: Elegant Autumn*

GtkEntry - time: 0.09
GtkComboBox - time: 1.64
GtkComboBoxEntry - time: 1.34
GtkSpinButton - time: 0.24
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.52
GtkCheckButton - time: 0.48
GtkRadioButton - time: 0.89
GtkTextView - Add text - time: 0.69
GtkTextView - Scroll - time: 0.22
GtkDrawingArea - Lines - time: 0.26
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 7.37

Engine: Clearlooks
Theme: Glossy

GtkEntry - time: 0.08
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.45
GtkSpinButton - time: 0.40
GtkProgressBar - time: 0.29
GtkToggleButton - time: 0.61
GtkCheckButton - time: 0.50
GtkRadioButton - time: 0.59
GtkTextView - Add text - time: 0.41
GtkTextView - Scroll - time: 0.32
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.18
---
Total time: 7.68

Engine: Candido
Theme: Graphite Light

GtkEntry - time: 0.08
GtkComboBox - time: 2.10
GtkComboBoxEntry - time: 1.86
GtkSpinButton - time: 0.17
GtkProgressBar - time: 0.26
GtkToggleButton - time: 0.63
GtkCheckButton - time: 0.53
GtkRadioButton - time: 0.60
GtkTextView - Add text - time: 0.48
GtkTextView - Scroll - time: 0.25
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 8.05

Engine: Aurora
Theme: Aurora

GtkEntry - time: 0.47
GtkComboBox - time: 3.78
GtkComboBoxEntry - time: 3.50
GtkSpinButton - time: 0.96
GtkProgressBar - time: 0.31
GtkToggleButton - time: 1.53
GtkCheckButton - time: 1.29
GtkRadioButton - time: 1.66
GtkTextView - Add text - time: 0.58
GtkTextView - Scroll - time: 0.46
GtkDrawingArea - Lines - time: 0.31
GtkDrawingArea - Circles - time: 0.38
GtkDrawingArea - Text - time: 0.32
GtkDrawingArea - Pixbufs - time: 0.19
---
Total time: 15.73

As you can see, the older engines are generally the fastest, with the more modern Rezlooks engine coming in close behind. Though they're generally not as attractive, the old Mist and Xfce engines turn in very respectable rendering times. The Pixmap engine actually doesn't score too well, coming in at the lower middle of the pack. This is despite many reports I found via Google that suggest it's one of the best-performing engines out there. Not so much; it's about average.

But by far the worst performing engine is Aurora. Now, to be fair, Aurora does many graphical tricks the other engines do not. It came along some time after old engines like Pixmap, Industrial, Mist, and Glider. It features animated scrollbars, gauges, and many possible styles of dropdowns and arrows. In short, it's fully loaded. Yet it also doesn't seem to be optimized; at 15.73 seconds, it's almost twice as slow as the nearest contender, Candido.

The results for the Aurora engine were so dismal that I re-ran gtkperf another 3 rounds, thinking something was amiss. Every result turned in times between 15 and 16 seconds. Clearly, Aurora isn't the engine to use if you're on old hardware.

Conclusion:

Remember, these are down and dirty benchmarks. Cherry-picking the best time out of 3 runs may not be the most fair way of measurement, but since no single result varied more than 2 seconds either way, it can be considered pretty well representative of the engine's overall capabilities.

If you're on less capable hardware, the Mist and Xfce engines will go far. If you want something prettier, stick with Rezlooks. I have several screenshots of Rezlooks-based environments in my devspace. It's quite flexible, and it's still in the top three fastest engines, despite including goodies like subtly animated progress bars and gauges.

But even on my fairly powerful workstation, newer engines like Candido and Aurora were noticeably slower, suggesting they might not be a good fit for older hardware. Clearlooks and Pixmap are middle-of-the-road choices; neither has much of an advantage. It comes down to which engine you think has prettier themes.

Me? I stick with Rezlooks. And occasionally Clearlooks (the Glossy theme makes for a good wintry desktop foundation), and very occasionally I'll find a decent Pixmap theme that's worth modding for my system. Otherwise, it's Rezlooks all the way.

Limitations of the PulseAudio backend for GStreamer

  • December 12, 2008
  • Jannis Pohlmann

I'm at the Ubuntu Developer Summit this week and Emmet Hikory just approached me with a question about the PulseAudio support in xfce4-mixer. The problem he has is that when he wants to plug in in a bluetooth headset PulseAudio might act weird and there's only one way to fix this from the user's point of view, which is to use pavucontrol or one of the other PulseAudio tools. Unfortunately those tools don't provide a good user experience. Controls are given technical names and too much of the internal technical stuff is being exposed to the user.

So, his idea is that there has to be a user-friendly way (like using xfce4-mixer) to e.g. control the bluetooth headset after it has been plugged in.

I just took a quick look at the PulseAudio code shipped with gst-plugins-good and to me it seems to be in a pretty bad shape. Unless I'm mistaken it only exposes one track through the GstMixer interface: Master. So if you have several devices capable of audio playback/recording, like a normal sound card and a bluetooth headset, you have no control over which of them is being muted, used for recording or whatever.

What I would expect is to either have a list of tracks (one for each sink - and please give them user-friendly names!) exposed through the GstMixer interface or to have a switch for choosing the sink you want to control with the Master track. Without this, no mixer application is able to provide a user-friendly way to control PulseAudio - unless it implements its own PulseAudio support.

One major reason for rewriting xfce4-mixer based on GStreamer has always been to get rid of the need to maintain our own audio system backends. The old mixer had its own backends for ALSA, OSS and BSD and it really sucked.

So I'm hoping that maybe someone steps up to implement a proper PulseAudio backend for GStreamer, with tracks for all available audio sinks and streams. I think I'd prefer tracks over a simple switch because they allow for a more fine-grained configuration of your devices. Thanks Emmet for pointing that out.

Licensing Suckage

  • December 11, 2008
  • Brian Tarricone

I just got an email from a developer who works on the nifty cairo-dock application, pointing me to a thread about licensing issues.

A bunch of months ago, he’d emailed me asking about how to best use code from my Xfce Mailwatch Plugin in cairo-dock to add mail-checking capabilities. At the time, I was pretty stoked that someone else had actually found my code useful enough to incorporate into their program, and offered my encouragement.

Sadly, though, licensing ugliness has reared its… well… ugly… head.

When licensing code under the terms of the GNU GPL or LGPL, the FSF suggests (and most people follow) that you license under “or (at your option) any later version” terms, which means that, while you initially license the code under the version of the GPL or LGPL of your choice, someone can later take your code and relicense it under the terms of a later version of the same license. This also makes the code automatically compatible with future versions of the license.

You might think this sounds pretty good for convenience and licensing compatibility, and you’d probably be right.

However, this isn’t so great from a philosophical perspective, at least from my philosophical perspective. The problem I have is this:

Licensing a work under “GPL version 2 or later” terms means that I am implicitly agreeing with any new restrictions that the FSF dreams up (or any existing restrictions the FSF wants to drop), forever. I’d basically be saying that I agree with something that doesn’t exist yet, and could take any shape or form imaginable.

Don’t get me wrong: in general, I think the FSF is good people, and I agree with their message for the most part.

But I don’t know them, personally, and I don’t agree with them 100%. And I don’t know who’s going to be running the FSF next year, or in five years, or in 20 years. So how can I know, or even have reasonable belief, that their philosophies and values will align with mine such that I’ll agree with future versions of their licenses? There are already parts of version 3 of the GPL and LGPL that I don’t completely understand or agree with, so why should I expect that versions 4, 5, or 10 will be completely to my liking?

The short answer is: I can’t.

And so, for the most part, I release my software under “GPL version 2 only” terms. (Because I’m a bit lazy and don’t want to make a big stink, I’ll release code under “or any later version” terms if I’m contributing to an existing code base that uses those terms.)

it really pained me to have to answer that email saying that my code’s licensing (GPLv2-only) wasn’t compatible with theirs (GPLv3-or-later), but it’s the truth, and there’s not much I can (or want to) do about it.

The only solution I can think of (I’m not a lawyer, of course) that allows them to use my code is that they relicense their code under GPLv2-or-later terms. Of course, then they lose any restrictions that the GPLv3 has over the GPLv2, which I assume they’d prefer to have, since that’s how they’ve licensed their code.

(Before anyone says it, another possible solution would be for me to relicense under LGPLv2.1. The problem with that is one I’ve discussed before: section 3 of the LGPLv2.1 explicitly allows a recipient of the code to relicense the code under regular GPLv#-or-later terms, regardless of the only/or-later status of the original LGPL licensing. This of course completely defeats the intent of my rationale above.)

And so, the OSS licensing mess has caused yet more pain to people who just want to share code and avoid duplicating effort. I love the GPL. I really do. But I also hate it.

Licensing Suckage

  • December 11, 2008
  • Brian Tarricone

I just got an email from a developer who works on the nifty cairo-dock application, pointing me to a thread about licensing issues.

A bunch of months ago, he'd emailed me asking about how to best use code from my Xfce Mailwatch Plugin in cairo-dock to add mail-checking capabilities. At the time, I was pretty stoked that someone else had actually found my code useful enough to incorporate into their program, and offered my encouragement.

Sadly, though, licensing ugliness has reared its... well... ugly... head.

When licensing code under the terms of the GNU GPL or LGPL, the FSF suggests (and most people follow) that you license under "or (at your option) any later version" terms, which means that, while you initially license the code under the version of the GPL or LGPL of your choice, someone can later take your code and relicense it under the terms of a later version of the same license. This also makes the code automatically compatible with future versions of the license.

You might think this sounds pretty good for convenience and licensing compatibility, and you'd probably be right.

However, this isn't so great from a philosophical perspective, at least from my philosophical perspective. The problem I have is this:

Licensing a work under "GPL version 2 or later" terms means that I am implicitly agreeing with any new restrictions that the FSF dreams up (or any existing restrictions the FSF wants to drop), forever. I'd basically be saying that I agree with something that doesn't exist yet, and could take any shape or form imaginable.

Don't get me wrong: in general, I think the FSF is good people, and I agree with their message for the most part.

But I don't know them, personally, and I don't agree with them 100%. And I don't know who's going to be running the FSF next year, or in five years, or in 20 years. So how can I know, or even have reasonable belief, that their philosophies and values will align with mine such that I'll agree with future versions of their licenses? There are already parts of version 3 of the GPL and LGPL that I don't completely understand or agree with, so why should I expect that versions 4, 5, or 10 will be completely to my liking?

The short answer is: I can't.

And so, for the most part, I release my software under "GPL version 2 only" terms. (Because I'm a bit lazy and don't want to make a big stink, I'll release code under "or any later version" terms if I'm contributing to an existing code base that uses those terms.)

it really pained me to have to answer that email saying that my code's licensing (GPLv2-only) wasn't compatible with theirs (GPLv3-or-later), but it's the truth, and there's not much I can (or want to) do about it.

The only solution I can think of (I'm not a lawyer, of course) that allows them to use my code is that they relicense their code under GPLv2-or-later terms. Of course, then they lose any restrictions that the GPLv3 has over the GPLv2, which I assume they'd prefer to have, since that's how they've licensed their code.

(Before anyone says it, another possible solution would be for me to relicense under LGPLv2.1. The problem with that is one I've discussed before: section 3 of the LGPLv2.1 explicitly allows a recipient of the code to relicense the code under regular GPLv#-or-later terms, regardless of the only/or-later status of the original LGPL licensing. This of course completely defeats the intent of my rationale above.)

And so, the OSS licensing mess has caused yet more pain to people who just want to share code and avoid duplicating effort. I love the GPL. I really do. But I also hate it.

Licensing Suckage

  • December 11, 2008
  • Brian Tarricone

I just got an email from a developer who works on the nifty cairo-dock application, pointing me to a thread about licensing issues.

A bunch of months ago, he’d emailed me asking about how to best use code from my Xfce Mailwatch Plugin in cairo-dock to add mail-checking capabilities. At the time, I was pretty stoked that someone else had actually found my code useful enough to incorporate into their program, and offered my encouragement.

Sadly, though, licensing ugliness has reared its… well… ugly… head.

When licensing code under the terms of the GNU GPL or LGPL, the FSF suggests (and most people follow) that you license under “or (at your option) any later version” terms, which means that, while you initially license the code under the version of the GPL or LGPL of your choice, someone can later take your code and relicense it under the terms of a later version of the same license. This also makes the code automatically compatible with future versions of the license.

You might think this sounds pretty good for convenience and licensing compatibility, and you’d probably be right.

However, this isn’t so great from a philosophical perspective, at least from my philosophical perspective. The problem I have is this:

Licensing a work under “GPL version 2 or later” terms means that I am implicitly agreeing with any new restrictions that the FSF dreams up (or any existing restrictions the FSF wants to drop), forever. I’d basically be saying that I agree with something that doesn’t exist yet, and could take any shape or form imaginable.

Don’t get me wrong: in general, I think the FSF is good people, and I agree with their message for the most part.

But I don’t know them, personally, and I don’t agree with them 100%. And I don’t know who’s going to be running the FSF next year, or in five years, or in 20 years. So how can I know, or even have reasonable belief, that their philosophies and values will align with mine such that I’ll agree with future versions of their licenses? There are already parts of version 3 of the GPL and LGPL that I don’t completely understand or agree with, so why should I expect that versions 4, 5, or 10 will be completely to my liking?

The short answer is: I can’t.

And so, for the most part, I release my software under “GPL version 2 only” terms. (Because I’m a bit lazy and don’t want to make a big stink, I’ll release code under “or any later version” terms if I’m contributing to an existing code base that uses those terms.)

it really pained me to have to answer that email saying that my code’s licensing (GPLv2-only) wasn’t compatible with theirs (GPLv3-or-later), but it’s the truth, and there’s not much I can (or want to) do about it.

The only solution I can think of (I’m not a lawyer, of course) that allows them to use my code is that they relicense their code under GPLv2-or-later terms. Of course, then they lose any restrictions that the GPLv3 has over the GPLv2, which I assume they’d prefer to have, since that’s how they’ve licensed their code.

(Before anyone says it, another possible solution would be for me to relicense under LGPLv2.1. The problem with that is one I’ve discussed before: section 3 of the LGPLv2.1 explicitly allows a recipient of the code to relicense the code under regular GPLv#-or-later terms, regardless of the only/or-later status of the original LGPL licensing. This of course completely defeats the intent of my rationale above.)

And so, the OSS licensing mess has caused yet more pain to people who just want to share code and avoid duplicating effort. I love the GPL. I really do. But I also hate it.

Limitations of the PulseAudio backend for GStreamer

  • December 10, 2008
  • Jannis Pohlmann

I’m at the Ubuntu Developer Summit this week and Emmet Hikory just approached me with a question about the PulseAudio support in xfce4-mixer. The problem he has is that when he wants to plug in in a bluetooth headset PulseAudio might act weird and there’s only one way to fix this from the user’s point of view, which is to use pavucontrol or one of the other PulseAudio tools. Unfortunately those tools don’t provide a good user experience. Controls are given technical names and too much of the internal technical stuff is being exposed to the user.
So, his idea is that there has to be a user-friendly way (like using xfce4-mixer) to e.g. control the bluetooth headset after it has been plugged in.
I just took a quick look at the PulseAudio code shipped with gst-plugins-good and to me it seems to be in a pretty bad shape. Unless I’m mistaken it only exposes one track through the GstMixer interface: Master. So if you have several devices capable of audio playback/recording, like a normal sound card and a bluetooth headset, you have no control over which of them is being muted, used for recording or whatever.
What I would expect is to either have a list of tracks (one for each sink – and please give them user-friendly names!) exposed through the GstMixer interface or to have a switch for choosing the sink you want to control with the Master track. Without this, no mixer application is able to provide a user-friendly way to control PulseAudio – unless it implements its own PulseAudio support.
One major reason for rewriting xfce4-mixer based on GStreamer has always been to get rid of the need to maintain our own audio system backends. The old mixer had its own backends for ALSA, OSS and BSD and it really sucked.

So I’m hoping that maybe someone steps up to implement a proper PulseAudio backend for GStreamer, with tracks for all available audio sinks and streams. I think I’d prefer tracks over a simple switch because they allow for a more fine-grained configuration of your devices. Thanks Emmet for pointing that out.

Backlight Change Notification?

  • December 9, 2008
  • Brian Tarricone

Is there a decent (non-polling) way to get notified when a laptop panel’s backlight brightness changes? HAL exports methods to set and get the brightness level, as well as query the number of possible levels, but there doesn’t appear to be a way to get notified if the level changes. Calling org.freedesktop.Hal.LaptopPanel.GetBrightness() every five or ten seconds or so sounds like an awful idea, of course.

I’ve heard plans to use the XBACKLIGHT randr 1.2 property to do backlight setting, but I don’t think any drivers use this yet. Polling /sys is just as bad (why doesn’t sysfs or procfs support inotify, dammit!), and obviously isn’t portable anyway (not that HAL is particularly portable these days either).

Backlight Change Notification?

  • December 9, 2008
  • Brian Tarricone

Is there a decent (non-polling) way to get notified when a laptop panel's backlight brightness changes? HAL exports methods to set and get the brightness level, as well as query the number of possible levels, but there doesn't appear to be a way to get notified if the level changes. Calling org.freedesktop.Hal.LaptopPanel.GetBrightness() every five or ten seconds or so sounds like an awful idea, of course.

I've heard plans to use the XBACKLIGHT randr 1.2 property to do backlight setting, but I don't think any drivers use this yet. Polling /sys is just as bad (why doesn't sysfs or procfs support inotify, dammit!), and obviously isn't portable anyway (not that HAL is particularly portable these days either).