In a recent message to debian-legal (may have not appeared yet when you read this) I said that I didn’t believe in oh, this clause in this license is not relevant, since it’s already implied by law . I believe that if it’s there, it’s for a reason, and I don’t want to be surprised when I find out what it is for. Furthermore, implied by law means nothing, since laws change, and different countries have different laws (really!). In other words, I don’t think lawyers go around putting decorative clauses in license statements. If they had such an artistic inclination, the results would rather look like this:

[…] construed as a distribution of this Package. 9.
      If you intend to advertise,
      our name you may not utilise.
      Get our written permission first,
      or in jail you’ll die of thirst. 10. THIS PACKAGE IS PROVIDED “AS IS” AND WITHOUT ANY EXPRESS OR […]

I found it fitting to do this to the Artistic License :-) (Yes, I know it’s hideous. Think of it as lawyer-poetry.)

summary of the problem I've re-read most of the calm and useful posts (yes some exist if you look hard :D) in the java-tro^H^Hhread. Yes, the pro-java-in-non-free are right if we omit to mention all the difficulties it will imply if such a removal has to happen for a stable update^[1] removing java from our mirrors do terminate the license solve most of the issues. Though, two major concerns remains:

1. clause 2.f (you agree to defend and indemnify Sun and its licensors from and against any damages ... and so forth) is IMHO unacceptable, even for non-free, because debian isn't in a position where it can risk to see that clause exercised by Sun ;
2. section 4 (and others of the same sort) makes the existence of java in non-free depending of Sun's mood: exercising clause 4 is trivial they just have to imagine a new kernel feature our kernel should support that we can't provide to terminate the license retro-actively. Many instances of that problem exists in the license.

The first problem in itself seems obvious, and none of the arguments of the pro-java-in-non-free have put me at rest. The second problem is a real concern because it means that our java support can be discontinued without possible clean upgrade path back to java-package. If Sun could not retire our right to redistribute one given version of java, then we could repackage the last version we can distribute with some debconf dialog to warn the user his java package won't be upgraded again, and that he must fall back to make-jpkg. But here, if Sun decides it, Sun can make the package simply disappear. And given the number of users that will concern, this is not a problem to be taken lightly.

I honnestly believe that putting java into non-free, whereas we already have java-package that allow a quite satisfying integration of Sun's JDK/JRE into a debian instance, implicitely means that we are confident that java will stay in here forever (or for a significant enough time). And I see nothing that can guarantee such a fact, and I see too many things that can prevent this with a probability significantely greater than 0. Yes there I know there is a FAQ about those issues, where Sun promise they won't use their power to hurt people. But if they don't itend to, why did they put those clauses in the license ? With all the good will I can provide, that does not makes sense to me. If you put landmines in your garden, well, that's for a purpose, not for the garnishment. debian issues And then, I've a couple of questions there, for which I've seen no real answer:

• why did that announce has been hurried like that ? yes Sun hadn't published their license, but I still don't understand how it can explain such a hurry.
• will debian switch to python 2.5 directly, so that we can skip one transition ? (that could explain why some maintainer have more time to dedicate to non urgent non-free packages, whereas some other would need its plain attention for etch)
• a more polite version of the previous question is: why do some people have been working soooo fast on this, when those people have other very real problems to deal with for etch ? that looks like a childish schedule, that puts shiny-public-things first^[2] instead of the problems that block a lot of DDs in their allday's work (some complains about NEW beeing stuck and it is, and was even before Debconf , other complain about the python2.4 transition that lags since ages, and other examples exists )
• why did only 3 persons worked on that, for a package that :
  • is well known ;
  • will obviously make noise, given to its history wrt the free software world ;
  • has a license that seem to have some obvious problems ;

and I'll skip the questions I don't want to ask, or more precisely I don't want/fear to read the answer to:

• why does this come 1 week after that ubuntu made it clear they had some things going on with Sun ?

Disclaimer Don't get me wrong. I've been really happy when I've seen that java entered non-free (even if I don't like the language but that's another story and is off topic here), because that meant that progress had been done in the good direction, and that's a thing I just have to praise. But then I've heard people complain about the damn license, and went read it. And then, I've been really disappointed, and I felt betrayed by those three people:
yes, I'm a DD, but I'm also a Debian User, and I trust my fellow developpers to bring to debian packages that don't have license issues, and will be supported enough^[3]. As a user, I feel betrayed because nothing that I expect from a package that is in debian (even in non-free) can be guaranteed for the java package.

One of the things that has kept Debian in heated discussion over the last few years is the question whether the GFDL, or the GNU Free Documentation License, is free according to Debian's own DFSG. We've had three votes on the subject, with the final one decisively saying it's conditionally free. Or so I thought. Yesterday, Josselin Mouette proposed another GR on the subject, since he believes there's a conflict between GR 2006 001 and the current text of the DFSG. Sigh. At least he isn't trying to reverse the effect GR 2006 001. But still; no, the GR does not conflict the text of the DFSG. I used to think otherwise, but got swayed by the discussions on -vote that occurred prior to GR 2006 001, especially (strangely) the one that happened as a result of Anton Zinoviev's amendment, which ended up as choice #3 on the ballot. At the the time, I was supportive of the original proposal to throw out all GFDL-licensed documents, even though I disliked doing so (for obvious reasons); but I felt that the arguments about the DRM clause did hold. This was wrong, and it took me an insult to see it. Quoting Anton, myself, and Craig Sanders:

This clause disallows the distribution or storage of copies on DRM-protected media only if a result of that action will be that the reading or further copying of the copies is obstructed or controlled. It is not supposed to refer [to] the use of encryption or file access control on your own copy.

No; however, as written it can be interpreted as such.

only by nutcases with an agenda. normal people (including lawyers and judges) wouldn't have such an insane and insupportable interpretation. that's because normal people rely on facts. and evidence. they don't just make up whatever crap they need to suit their argument.

Craig's way of saying things did not immediately have the intended effect; and had I not grown tired of the discussion, I probably would've missed it. But the fact that I stopped following the discussion gave me some time to think about it, and as such, Craig's argument had a chance to sink in. When I was finally swayed, I failed to attribute it to Craig, however, instead thinking it was an argument by Anton that did it. The point is this: the mere fact that you're able to construct an interpretation of a license which is logically sound and complies with everything, does not mean that it is a sane interpretation. Lawyers and judges, strange people though they might be according to some jokes, are still people; human beings. If you come up with an interpretation that nobody in court came up with on the first reading of a given text, then chances are rather high nobody will follow you. That's what really matters: whether something you claim will hold in court. Not whether something you claim holds up to your own argumentation. And yes, claiming that doing chmod -r, or storing something on an encrypted filesystem is somehow restricting distribution, seems a little far-fetched. After all, when I'm storing something on my own hard disk, or even in the privacy of my home-directory on a large shared fileserver, I'm not engaging in a distribution of any kind.

From WordNet (r) 2.0 (August 2003) [wn]:
  distribution
      n 1: (statistics) an arrangement of values of a variable showing
           their observed or theoretical frequency of occurrence
           [syn:  statistical distribution ]
      2: the spatial property of being scattered about over an area
         or volume [syn:  dispersion ] [ant:  concentration ]
      3: the act of distributing or spreading or apportioning
      4: the commercial activity of transporting and selling goods
         from a producer to a consumer

Definition 3 and 4 seem to require an active action by the originating person; when someone copies a file from your $HOME, you didn't distribute the file to them; they took it from you. In our culture of sharing is good, you should share!, I missed it; but a court would probably see copying without asking for permission more as stealing, rather than distributing. After all that, the arguments about the DRM clause being too broad seemed a bit weak to me; and given that the FSF had already agreed on it being a bug which needed to be fixed, as they had for the other arguments against the GFDL (apart from the Invariant sections, which are not being discussed here), made me decide that the big giant insane problems with the GFDL are not so much of a problem as most people seem to claim.

Since Joey Hess posted a short conversation we had on IRC today about the role of the DPL, I thought it's a good time to express some of my thoughts. Basically, I think that most people have a bad understanding of which tasks are really involved in being DPL (e.g. much more purely administrative crap that nobody else wants to do) and that they're quite naive about what the DPL can achieve, at least in the current climate. Let's just look at the current discussions on the -vote list. It's this time of the year when everyone pretends that its Christmas, expresses their feelings of what's wrong with Debian and where Santa Claus^W^Wthe candidates reassure them that everything will be fine. "Will you fix NM? Fix or replace ftp-master? etc." "Oh, sure I will, all of that (and more)." Honestly, would you elect someone if they told you they won't or can't? The strange thing is that the same questions get asked every year, and yet people don't get the hint and look for other solutions. I'm not overly happy with any of the candidates this year, and I was seriously considering running again, not next year but possibly later. However, this Christmas wankfest reminded me again why that may not be such a good idea after all. I remember how much time I spent answering questions on -vote myself, and while I'm all for transparency, many of the questions were just a waste of time. This year, the questions were relatively sane in the beginning but now it's just a waste of time most questions are posed in a way that it's clear what kind of answer people want to hear. I spent hours and hours answering questions, but at some point I thought "cannot we just stop talking for hours about what I'd do if elected and actually start doing all that stuff?". That would have been so much more productive. Instead of asking the DPL what they'll do to solve All The Problems In Debian, why don't you ask yourself what you can do to improve the situation? There's a bottleneck with the DAM, you say. Right, the chances that you'll be added as DAM are relatively small. But have you ever considered helping the DAM and to make their life easier? How about signing up as an Application Manager and producing such good reports that it'll be a piece of cake for the DAM to approve people based on your reports? Right, it won't fix the bottleneck, but it will make the situation so much better. Instead of bitching about the security team, why don't you prepare a package, write the text for the DSA and get everything ready in a way that a DSA member can simply take your work, recompile the package and issue the advisory? Now I'm sure some people will say that they've tried that and failed. Yes, not every upload for DSA will be accepted as it is, but how hard have you tried? And people always complain about the cabal and how hard it is to join teams. And while I agree that this is partly true, there are so many counter examples too. Look at me as an example. In 2.5 years, I became the most productive Application Manager, joined (and took over) the NM Front Desk, became a "senior" Quality Assurance member, and got elected as project leader. Am I special? No, in no way I just put in a lot of effort. Look at Jeroen van Wolffelaar, who joined at the end of 2004, and who is involved in QA (especially MIA) and lintian, is the co-author of the new packages.d.o code and an ftp assistant. Andi Barth (who got an account in January 2004) has done important QA work (bts2ldap), is a maintainer of the developers reference and a release manager. So it's not possible to join a team, you say? Maybe you're just not trying hard enough (and the right way!). (Hint: "make me a DAM/ftp-master/whatever" doesn't work as well as "how can I make your job easier?"). What I'm trying to say is that people should stop believing that the DPL will fix everything and that they should actually help out themselves. If we all work together and put effort into the areas that need work we might actually achieve something. People have been asking for a strong leader and this urge got stronger over the last few years. But, face it, we currently don't have a culture which accepts a strong leader. Joey Hess mentioned that he wants to see a DPL who pushes technical changes. I did that too, to some degree (mostly in private since that works much better than on a mailing list where a big flamewar is guaranteed). For example, I kindly asked Joey to lower the priority of the non-free question so it would not get asked in a default installation. And he did because Joey is a reasonable guy. (He also told me that me making this request made it easier for him to justify.) However, unfortunately, not everyone is like Joey. And what are you going to do if a maintainer refuses to listen, as many do? I mean, seriously, what can you do? Some are increasingly talking about the good old times of Bruce Perens who would tell people what to do and make decisions. The urge for a strong leader increased over the last years. I think that's partly a reason why Branden got elected last year people expected him to completely shake things up. I haven't talked to him and I wasn't part of the leadership team, so I don't really know what happened, but from what (little) I've heard, it seems that he tried, quickly realized just how rigid some of the structures are and gave up. You have to see things in a historical perspective (and I can only recommend that people who have access to the debian-private archives take the time to read through them). There's a reason we have had "weak" leaders since Bruce. While now a large number of people think that Bruce was the best thing since sliced bread, lots of people were really pissed off back then with him commanding people around. And what was the result? A constitution that would ensure that no leader would ever have such power again. And that's what we're currently stuck with. I think that one of the biggest problems Debian is currently facing is the inability to make decisions. There are so many endless, completely futile (and repetitive) discussions going on. We need someone who comes in, tells people to shut up and makes a decision on behalf of the project. A decision people will follow, even if they personally disagree with it. But seriously, do you think our culture would currently accept such a leader? I can tell you from experience that even people who have been asking for a "strong" leader won't actually follow a leader who tells them to take a certain course of action. We really need to fix this problem, and the problem is in our culture. And since our culture is defined by who we are, you should start with yourself first. Start by asking yourself a few questions. Do you think before posting something to our lists, and ask yourself twice whether it really adds value to the discussion? If there's an area that is problematic, will you try to help out? If asked to do something you're not particularly interested in but which is good for the project will you do it? And most importantly, will you contribute to make our culture something that is fun? The project leader is important, but don't wait for them to fix all of our problems. If there's a problem, try to figure out a way how you can solve it!

Gotta love Debian sometimes. ;) My beloved mutt seems a little broken in unstable currently. I’m in the market for a new AM. 3rd time lucky? Ok, so I am packaging Aaron’s web.py library and so I check the license with debian-legal. “Vorlon”, the omnipresent and omniscient got back to me pretty quickly, saying no. Goddam! ;) I’m no legal expert and my brain hurts thinking about these distribution clauses, GPLv3 issues and controversies. I hope debian-legal reaches some agreement. At about 6pm I noticed the Ubuntu crowd were in Seoul. I emailed hastily asking about a meetup or something. Probably too late. Damn. I’m feeling quite alone in my Linux usage here in Korea. I see Mark has been in Japan. I have fond memories of Japan and the debian guys out there. Yeah, if any Korean devs are reading this, get in touch. Part asked me to get in contact with some mail administrators in order to curtail some of the massive amounts of spam coming out of Korea.

Licenses are just too nice... Especially if you put special clauses in the context of the application they apply to. SUN states the following in a code example for the Java Micro Edition.

You acknowledge that this software is not designed, licensed or intended
for use in the design, construction, operation or maintenance of any
nuclear facility.

Now consider that the Java Micro Edition usually runs on mobile phones. Well, yes it’s for embedded devices too, but I found it in a GUI example. If I imagine to control a nuclear power plant by just using my phone in the bus, using a nice little Java application... What a threat I would be.

ralsina: Nautilus doesn't really link with Mozilla, AFAIK it embeds a Bonobo component which is itself linked with Mozilla using gtkmozembed. As for other Gnome/Gtk apps linking with Mozilla, such as Galeon or SkipStone, they both have an additional distribution clause allowing linking with Mozilla. Regarding what Debian did, I won't argue whether it was right or wrong (though I believe it was the right thing [tm]), but I'm certain Qt wouldn't be GPL now if Debian had included KDE at the beginning. You may call this being anal about licenses, but IMHO it's the only way to show licenses still mean something.

Last October I filed an RFP for GyachE, a feature-rich Yahoo! Messenger client that supports, among other things, webcams. I requested so because Eric wanted to package this, and at the time I didn’t have any time to allot for packaging. Now, Eric has asked me to take over the packaging. And indeed, this is a difficult package, since upstream (aka Ms. Erica Andrews) seems to have a rather snobbish attitude with regard to providing support for GyachE (well, it is not required anyway, remember about the non-warranty clause.) She can’t even provide a decent autotooling of the software, and what’s worse, is that the source itself seems to be a mixture of two different applications, one involving GTK2 and the other Python. Hell, I couldn’t even get the source to compile, and when I tried fixing the autotools, it was even more hell I almost gave up on it, until I came across gyach-improved from Google. Mick Howe, thank you for being such a nice guy! /me proceeds to renaming the ITP…

Artist: Mr. Garrison Lyrics
Song: Merry Fucking Christmas Lyrics
Mr. Garrison: I heard there is no Christmas
In the silly Middle East
No trees, no snow, no Santa Claus
They have different religious beliefs They believe in Muhammad
And not in our holiday
And so every December
I go to the Middle East and say… “Hey there Mr. Muslim
Merry fucking Christmas
Put down that book the Koran
And hear some holiday wishes. In case you haven’t noticed
It’s Jesus’s birthday.
So get off your heathen Muslim ass
and fucking celebrate. There is no holiday season in India I’ve heard
They don’t hang up their stockings
And that is just absurd! They’ve never read a Christmas story.
They don’t know what Rudolph is about
And that is why in December
I’ll go to India and shout… Hey there Mr. Hinduist
Merry fucking Christmas
Drink eggnog and eat some beef
And pass it to the missus. In case you haven’t noticed
It’s Jesus’s birthday
So get off your heathen Hindu ass
and fucking celebrate! Now I heard that in Japan
Everyone just lives in sin
They pray to several gods
And put needles in their skin. On December 25th
All they do is eat a cake
And that is why I go to Japan
And walk around and say… Hey there Mr. Shintoist
Merry fucking Christmas
God is going to kick your ass
You infidelic pagan scum. In case you haven’t noticed
There’s festive things to do
So lets all rejoice for Jesus
And Merry fucking Christmas to you. On Christmas day I travel round the world and say,
Taoists, Krishnas, Buddhists, and all you atheists too,
Merry Fucking Christmas, To You! (Clapping) Thank you Mr. hat

The usual suspects are now arguing that the name-change clause in the PHP license is not free. (I have been too much busy to blog for the last few months, but this was worth reporting...)

... and stop that annoying "Xmas" thing. Oh, and I hate all the red santa claus (shouldn't he be caled X-man?) stuff everywhere. Christmas used to be something very different than it is now, you know. Merry christmas, and enjoy what used to be the 'quiet time' of the year: Electronic christmas greeting card

Ian Murdock's recent piece on the whole Debian/Nexenta controversy contained what is an almost-universal misunderstanding (so common, in fact, that I held the same misunderstanding myself until fairly recently) about what the GPL actually says about linking in other software with a GPL-licenced work. Ian writes:

It seems to me the argument that linking a GPL application to a CDDL library and asserting that that somehow makes the library a derivative work of the application is, to say the least, a stretch&emdash;not to mention the fact that we're talking about libc here, a library with a highly standard interface that's been implemented any number of times and, heck, that's even older than the GPL itself. It's interpretations like this, folks, that give the GPL its reputation of being viral, and I know how much Richard Stallman hates that word.

The core misunderstanding there is that the GPL somehow claims that libraries linked into a GPL-licenced binary are derived works. Nothing in the text of the GPL states that, and a quick scan of the GPL FAQ doesn't provide any opinions of that nature, either. What the GPL does state are a few conditions which you have to abide by in order to be given permission by the copyright holder to exercise rights ordinarily held exclusively by said copyright holder. One of those is that, in order to be given permission to distribute a compiled binary, you must be able to provide source code for the binary itself, as well as all interface definition files, build scripts, and modules contained in the binary, and that all of this material must be provided under terms no more restrictive than those of the GPL. The GPL isn't trying to lay a "derived work" claim on any of those other parts. It's just saying to you, as someone who wants to distribute a binary, "here are some other things that must be OK if you want to do this". A similar clause exists with regards to patents and court judgments (section 7, for those of you playing along at home). This doesn't mean that the GPL is attempting to claim that the patents or court judgments are derived works. A licence could also say "you must delete all copies of any Microsoft product from your hard drive before duplicating this software", but that wouldn't mean that the licence is attempting to claim that all Microsoft products are derived works of the licenced software! As anyone who's looked at a typical proprietary software EULA probably already knows, a software licence can claim pretty much anything (and, apparently, thanks to the DMCA, in the US they can make it stick). The licence doesn't make the claim on the basis of derivation, it makes it because that's just what the licence claims. The GPL is no different in that respect. If you can't fulfill the licence conditions (either because you don't want to, or because -- as in the case of the clause under discussion -- the module you are including in your binary can't be licenced under terms equivalent to the GPL) then you can't do whatever it is that the licence would otherwise allow you to do. To be fair to Ian, some of the comments he made to his blog post indicate that he does understand the distinction between a claim due to derivation and one due to a simple licence term, but I thought it worth making the point crystal clear to everyone out there in the blogsphere, because it's a very common misunderstanding, and I'd hate for it to spread any further than it has already.

Mike Sperber finally reviewed my patches; they unfortunatly were not deemed appropriate for the Scheme48 distribution, see this thread. Hopefully these issues can be sorted out in the not-to-far future. If you also need the one or other features from my hacks so far, and are adventurous, you can conact me on #scheme on freenode for help with getting and building my fork. Writing portable Scheme programs with scmxlate and spells For the conjure project, we are using scmxlate to make it portable across multiple Schemes. For that purpose, I slightly extended scmxlate and built a kind of meta-module system on top of it. Here is how that looks like: You write a description of the modules your application or library is made of; this is done in a sightly extended subset of the Scheme48 configuration language. For example (from this page, see there for more details):

 (define-structure conjure.foo.bar (export qux baz
					  ((froboz fribnitz)
					  :syntax))
  (open scheme srfi-1 srfi-13 conjure.util.files)
  (dialect (guile (open ice-9.syncase))
           (scheme48 (open extended-ports)))
  (files (foo basic-bar)
         (foo bar)))

This defines the module conjure.foo.bar, which exports the identifiers qux and baz, as well as the macros froboz and fribnitz. The open clause means: this module is written in R5RS Scheme (scheme), plus additionally using srfi-1, srfi-13 and the conjure.util.files module. The dialect clause can be used for specifiying additional modules needed for the dialect-specific code for the module. Finally, the files clause tells us that this module consists of the files foo/basic-bar.scm and foo/bar.scm. This file then gets processed by scmxlate, generating a file with the right module definitions for the selected target dialect, e.g.:

(define-module (conjure foo bar)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-13)
  #:use-module (conjure util files)
  #:use-module (ice-9 syncase)
	
   #:export (qux baz)
  #:export-syntax (froboz fribnitz))
	
 ;; code for foo/basic-bar.scm and foo/bar.scm follows

will be generated for Guile. We recently split scmxlate and the meta-module systeem out of conjure, see the scmxlate category in the conjure archive, so it is available for other projects. Now the split-out of the general purpose modules into a separate project — SPELLS, (S)pell’s a (P)ortability (E)nvironment (L)ibrary for (L)ots of (S)chemes — is in preparation. This library will further aid writing portable code, by providing a consistent interface to functionality that has different APIs in different Schemes. These modules are already there:

• spells.util.pregexp: Dorai Sitaram’s portable regular expressions
• spells.util.named-args: Conviniently create procedures with named arguments
• spells.util.table: Hash tables
• spells.util.condition: SRFI 34 and SRFI 35
• spells.system.file: Lots of file-related proedures, e.g. copy-file, directory?, …

All of those are implemented for all of mzscheme, Guile, Scheme48 and Gauche, using native functionality where available. Other modules will surely follow, a project has been requested at Gna! to facilitate contribution. The spells library will also be used by my upcoming port of G-Wrap to Scheme48.