Older blog entries for ingvar (starting at number 125)

Very much "no coding" (except from "coding for work", but that is work, not play and so doesn't count, unless I have arranged a "let it free" agreement for it beforehand) for a good while. One micro-utility to simplify building ASDF-INSTALL-able packages, though. World, meet build-asdf-package. No docs, as of yet (well, there's some built-in help text) so here goes: "list all files you want in the package in .filelist and either force a version using -v version or have it in .version".

Thinking further on the whole "what is derivation" issue I have been discussing with Brian Mastenbrook (here, here, here and here).

After some thinking (and essay writing), I think the main contention is "is the copyright on the source, on the executable or on both".

Clearly, if the copyright covers the executable program, it will be incorporating the object library it links to and thus, at all instances of actually running, be a derived work.

Likewise, if the copyright is on the source code, it will only be referencing the library and thus ends up in a similar position to a critique, referencing well-chosen sections of another work.

And, naturally, I managde to misread the Lesstif homepage. Lesstif is licensed using LGPL and thus my whole analogy crumbles liek a badly-built house of cards.

Brian Mastenbrook replies to my reply on his blog entry on possible GPL problems:

Ingvar responded to my last post about the GPL. He says "When linking against libreadline, dynamically or not, libreadline is incorporated in whatever program is written and the result is, thus, a derivative work of libreadline." Unfortunately, I can't see how this works - the binary which dynamically links to libreadline references parts of the library by name, but I can't see how it's incorporating the library.

This is an interesting question that I tried to address in my diary entry. My thesis, for now, is that "standard dynamic linking" (as in "compile with suitable -l switches and end up with a binary that uses the system-provided dynamic linker to suck in the relevant dynamic libraries on program start") is morally equivalent to static linking and the "dynamic/static" distinction is merely cosmetic. This, in my view, means that one should copnsider what is derivative or not as if there were static linking happening.

He also references the Why CLISP is GPL mail exchange between Bruno Haible and RMS. In there, RMS tries to argue that providing a no-op stub for libreadline and providing instructions for how to link with libreadline still requires licensing CLISP as GPL. I would, off-hand, consider RMs to be wrong in this, since it places the "use readline or not, default is do not use it" squarely in the hands of the user.

Furthermore, I seem to have picked a somewhat unfortunate GPL library to use as example, since dtucker (in this entry) describes the NetBSD somewhat-plug-compatible readline replacement.

What I am trying to say is that there are at least two slightly different (from an "intent" point of view) ways of doing dynamic linking. Type 1 happens "under the hood" (normal, system-provided dynamic linking as patr of the normal startup process). Type 2 happens when the programmer explicitly writes code to link an external library into the program space. I'd say that when type 1 dynamic linking happens (and there are at least one non-GPL library that is API compatible) the facttaht it (on some computers) ends up linking against the GPL libarry is of no consequence fro teh GPL status of the program. Otherwise we'd end up in the thorny situation that all Motif programs must be GPL (since Lesstif puports to be a plug-compatible replacement lib and is GPLed). This is obviously absurd. Likewise, if I distribute my code with a library that is plug-compatible with a GPL library, I should be able to license my code as I want. Similarly, if I write a replacement library for a commercial library, I should be able to ship the code with my replacement library too. There might, of course, be other requirements on the commercial library.

Brian also writes (referring to me talking about commercial software libraries and commitments in code linking to them):

I'm not sure this is a convincing argument, since commercial libraries are by definition non-free, and for many of the same reasons that I would consider the GPL to be non-free too.

If we ignore the "free/non-free" distinction for the moment (it is, I find, a slight problem that RMS chose "Free" as a descriptive qualifier, I understand his reasoning behind it but there are interesting emotional undertones to the word "Free"), does it amke sense that GPL-licensed software requires derived software to be licensde under the same (or at least compatible) terms? Yes, without this requirement, the GPL wouldn't do what RMS wants it to do. I feel that this is the reason behind RMS arguing so strongly that providing a no-function readline library with CLISP is "just a circumvention device" (to paraphrase his reasoning why doing so would be bad).

As for "is GPL software non-free", the answer is "it depends on your definition of free". They are ceraintly license-encumbered. All software that is not in the public domain is, though in some cases (BSD without advertising clause) it's not really noticeable.

One must, before releasing GPLed software (or linking to GPLed software) consider if taht is the Right Thing to do. Most of my hobby-written software is released under the GPL, with an explicit mention to contact me if licensing under other terms is wanted. Most CL code I release is actually released as public domain (since it gets bundled with SBCL contributed code), since I feel that GPL and CL is a sticky mix I prefer not really touching.

Brian Mastenbrook mentions potential GPL problems. Specifically, what constitutes/does not constitute a derivative work. The specific example he chose was unfortunate in that libreadline comes in GPL flavour only and thus there is no non-GPL "vendor" who is API compatiple and one can therefore assume that his program linking against libreadline would be useless without that.

As far as I am aware, incorporating substantial material into work A from another (copyrighted) work B is, in the eyes of the law, creating a derivative work of work B. When linking against libreadline, dynamically or not, libreadline is incorporated in whatever program is written and the result is, thus, a derivative work of libreadline.

At least that is, as far as I am aware, the reasoning behind "link against GPL and you need to comply with the license". Having worked for a while at a software house, linking against any commercially available library does entail getting a specific license that allows incorporation and may (possibly) entail further per-seat or per-site license fees. This is, again, because the end result is a derivative work.

Note that in the "commercial library" case there tends to be an extreme lack of API-compatible code, so there's a choice of "write code oneself" or "use the commercial library". I can easily see the need for implementing a non-GPL libreadline with a compatible API. That way, people who want to write code using a libreadline-alike have a choice (either compile-time or, for dlopen() and friends, run-time) between using a GPL or non-GPL library.

Harking back to what Brian writes, it is slightly murky if he means dynamically link against as a compile-time "linked againsta dynamic library" or "run-time dynamic linking with explicit code handling and use of dlopen()" (there is, in my view, a small difference between these).

In the first case, I see no moral distinction between static and dynamic linking. The intent is definitely to incorporate a library into the program. In the second, it is slightly murkier, in that tehre could be code trying to find a non-free version by preference and only when not finding that falling back to a GPL version or (possibly) no version at all.

In the case of CL, it's hyper-murky, since the only way one can interact (as far as I know, with the majority of CL compilers) with a normal C library is by the latter method.

Not much publicly postable source code written in the last while. Currently fooling around with McCLIM, in the feeble hope that it will make writing a lisp GUI front-end (instead of an existing web UI front-end) for my book database. I started out with the intention of writing it in CL, but at that point in time MySQL and CLSQL were not entirely happy. Thanks to UFFI, things are now much better.

For those who like the roundabout ways programming projects "come home" to their original language, I first took a stab at debugging a blank perl file. It was moderately functioning, but my perl is weak. About as weak as a dead, floogy, soggy stick of celery in fact. So I rewrote it in Python (that's the version I'm using for accessing and updating the db at the moment). Soon, hopefully, I should have a nicely integrated application, instead of a set of semi-coherent web pages, written in the language I had originally intended to write it in in the first place.

New version of genhash (my generic hash table library, written to work, rather than to be fast) has been packaged and released.

Bill Clementson mentioned recently in his blog different methods of making sure one's wrists "survives emacs". He missed one method, though probably from the fact that it seems completely counter-intuitive. Saying that, it has seen me use emacs on a more-or-less daily basis for the last 14-or-so years. The method? "Go beyond touch-typing" My normal finger positioning (once trained in typewriter class, to the point where I could type reasonably fast with a screen between me and the keyboard) is fairly fluid, with my right (stronger) hand usually pressing two keys for each my left presses. It has some curious draw-backs, I am more likely to transpose characters, especially when they alternate between fingers and I do need to re-sync hands and keyboard at regular intervals. I also need to not have my hands, wrists or arms resting on anything. Apart from that, I use either a SE/FI keyboard layout (at home) or a UK layout (at work), with no swapping of Control or CapsLock (though when typing in X at home, CapsLock is disabled completely).

Part of it is, as mentioned there, choosing a good keyboard. My keyboard of choice is a buckle-spring keyboard, they make a bit of a racket, but I've noticed that I can type for somewhere between 4 and 16 hours (depending on how well fed and watered I am before going "into the zone") without noticeable wrist problems. On a "normal" PC keyboard, I need to take a short break every 45 minutes or so, otherwise my forearms start feeling as if they're about to cramp up.

Anyway, when it comes to ergonomics, if it feels good, it probably isn't bad. Experiment with various keyboards (layout, mechanical construction, positions, sizes...) and other things that are somewhat easily changed. Try to stay with a change for at least a week, since all change tends to feel "bad" and "odd" in the beginning. Above all, consult an expert in the area and don't rely on hearsay from the Internet (but do take inspiration from it and find new possibilities to ask said expert about).

22 Oct 2004 (updated 22 Oct 2004 at 23:28 UTC) »

OK, small (really minor) code change to teh netflow reader library. One type declaration (declaring the return value from a READ-BYTE call as an (UNSIGNED-BYTE 8)) seems to knock teh speed down to "comparable with C".

; Evaluation took:
;   16.45 seconds of real time
;   10.88 seconds of user run time
;   1.52 seconds of system run time
;   39,267,241,128 CPU cycles
;   [Run times include 0.59 seconds GC run time]

Same test file as before, so we're down about 0.56 s on plain "chug through the file".

So, the code for my netflow log reader has been posted to small-cl-src. Once I've spent some effort writing a small(ish) readme and possibly a few more support functions (I am considering one to format IPv6, for those who may or may not need it, as an example), I'll stick it in a tar ball and on the web, somewhere.

116 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!