Back from FOSDEM 2013
As (almost) every year, I attended the annual incarnation of FOSDEM. It is undoubtedly (one of?) the most
remarkable events about Free Software in existence. No registration, no fees,
24 tracks in parallel, an estimated 5000 number of attendees. I also like that
it brings together people from so many different communities, not _just_ the Linux or Gnome or KDE or Telephony or Legal people, but a good mixture of everything.
I have to congratulate the organizers, who manage to pull this off, year after
year again. And as opposed to many other events, they do so quietly and
without much recognition, I feel. I'd also like to thank the many volunteers
working tirelessly before, at and after the event. Last, but not least, I'd
like to thank the local university (ULB Solbosch) hosting the event.
What made me truly sad though, is the amount of littering that surprisingly
many of the attendees did. This was particularly visible in the Cafeteria.
Imagine an event run by volunteers, who put in a lot of time and effort.
Imagine an event where food and drinks are sold by volunteers at such low
prices that there can barely be any profit at all. And then imagine people
eating there and leaving all their rubbish around, as if they were in some kind
of restaurant where they are being served and where somebody is cleaning up
after them. It really makes me feel very bitter to see this. Don't people
realize that those very volunteers who are creating the event will then have to
put in _their_ spare time just because those who just enjoyed their coffee or
lunch didn't have the extra 30 seconds of bringing their trash to the trashcan?
I feel ashamed for members of our community who behave this way. Please think
next time before acting and show your respect to the people behind FOSDEM.
Talk Idea: How to write code to make later enforcement easy
During FOSDEM 2013, I spoke with some fellow Free Software developers
about how my knowledge on copyright and specifically legal aspects of
software copyright has influenced the way how I write code, and
particularly how I design architecture of programs.
This made me realize that this would probably make a quite interesting
talk at Free Software conferences: How to architect and write code in
order to make later [GPL] enforcement easy.
Of course there are all the general and mostly well-known rules like
keeping track of who owns which part of the copyright, having proper
copyright claims and license headers, etc.
But I'm more thinking in the sense of: How do I write code in a way to
make sure people extending it in some way with their own code will be
forced to create a derivative work. If that is the case, they will have
absolutely no choice but to also license that under GPL.
This is particularly important in the case of GPL licensed libraries.
The common understanding in the community is that writing an executable
program against a GPL licensed library will constitute a derivative work
and thus the main program must be licensed under the GPL, if it is ever
However, in reality there is of course no precedent, and in some
particular cases, the legal framework, depending on the jurisdiction,
might come to different conclusions if it ever ended up in court. The
claim of a 'derivative work' would be particularly weak if the main
program is only using a set of standard function calls whose function
declarations are the same in many versions of the GPL licensed library
you link against. So let's assume there was a GPL licensed standard C
library for stuff like open(), close(), printf() and the like. I think
it would be very difficult to argue in court that a program written
against those functions and linked against such a library would
constitute a derivative work of the library. As in fact, there are many
other implementations providing the exact same interface, under
different licenses, and the API was not even drafted by the author of
the GPL licensed implementation.
So I think there are some things that an author of an (intentionally)
GPL licensed library can do while writing the code, which will later
help him to establish that an executable program is a derived work.
The same is true to some extent for executable programs, too. I
very intentionally did not introduce a plug-in interface for BTS drivers
in OpenBSC, even though while technically it would have been possible.
I _want_ somebody who adds code for a different BTS to touch the main
code of the program instead of just writing an external plugin. The
mere fact that he has to edit the main program in order to add a new BTS
driver indicates that he is creating a derivative work.
So I'll probably try to submit a talk on this topic to some
upcoming conference[s]. If you think this is an interesting topic and
want me to talk about it at a FOSS related event, please feel free to
send me an e-mail.