I have, at several points over the past few years, been interested in finding out quite how the GPL applies when one has runtime dynamic linking in the mix. As such, I would like to set a little scenario up and then solicit responses from you as to how things might go. I have yet to receive any useful answers which consider all the aspects. Several people have basically said “oooh, hard.. erm therefore you can’t do it”, and the FSF have told someone I know who asked essentially this question, “erm… consult your lawyer”; and it took them four months to say that.

So, with all that in mind, here we go…

Setting the scene

1. There exists a company SuperMegaCorp...
2. ...who have a software product called FantasticUsefulApp...
3. ...which is released to the public in a proprietary/pay-for kind of way...
4. ...but has a BSD licenced set of header files for third parties to write plugins distributed with it.
5. There exists a useful GPLv2+ed library HandyStuffs...
6. ...which is authored by a freedom loving software engineer called Fred.
7. A pragmatic, yet freedom loving software engineer called Pete...
8. ...who does not know Fred...
9. ...writes a plugin for FantasticUsefulApp which we shall call IncrediblyCoolPlugin...
10. ...which incorporates parts of the HandyStuffs codebase...
11. ...and is GPLv2+ed by Pete...
12. ...who then releases it to the wider world on his website.

Next, the following happens…

13. Seeing that Pete has written IncrediblyCoolPlugin for their FantasticUsefulApp...
14. ...a user of the app called Uhura downloads it in binary form and drops it straight into the plugin folder.
15. Uhura then starts FantasticUsefulApp which proceeds to dynamically link itself to IncrediblyCoolPlugin for the duration of Uhura's use of the app.

So here is question one

Is anyone violating any of the GPLv2‘s terms (or the GPLv3‘s terms) by doing this at any point? If so, who is violating which terms, and how can that be fixed without losing functionality?

Extending the scenario

16. Uhura loves FantasticUsefulApp a lot. She also really loves IncrediblyCoolPlugin and wishes that each time she made a new installation of the app it would come with the plugin.
17. Uhura writes to SuperMegaCorp and asks them to include IncrediblyCoolPlugin with FantasticUsefulApp.
18. Liking the idea, and mindful to place the source code to IncrediblyCoolPlugin on their distribution media, SuperMegaCorp proceed to distribute the plugin along with their app in one easy to install bundle.

Here is question two

Is anyone violating any of the GPLv2‘s terms (or the GPLv3‘s terms) by doing the above? If so, who is violating which terms, and how can that be fixed without losing functionality? (For this question, consider the bundling of the plugin and the app together as functionality it is preferable to retain.)

An alternative way to extend the scenario

19. Concerned about the possibilities of upsetting freedom lovers, SuperMegaCorp decline to distribute IncrediblyCoolPlugin with their app...
20. ...however instead they distribute a plugin which connects to Pete's website and downloads IncrediblyCoolPlugin the first time FantasticUsefulApp loads, installing it for the user automatically.

And question three

Is anyone violating any of the GPLv2‘s terms (or the GPLv3‘s terms) by doing the above? If so, who is violating which terms, and how can that be fixed without losing functionality?

If anyone has any useful ideas on this, please either email them to me, or blog about it and email me a link. I intend to post a precis of the answers in a future entry.

The Google Summer of Code is upon us once more, and this year two projects dear to my heart are involved as mentoring groups. The first and perhaps most obvious is Debian but a less well known but equally important project to me is NetSurf which just announced that it is participating this year.

If you fancy working on a really cool small embedded browser project this summer, you could do worse than to look at NetSurf.

I am in need of a C parser which I can use to detect violations of a coding standard. Particularly it must be able to be sensitive to comments (the internals of which are important also) and whitespace, over and above the usual need to be sensible about the rest of the language.

In order to be ideal, it should not need the C to be preprocessed first. I am not after a syntax checker, after all – the compiler does that for me. I want to be able to detect things like struct{ where struct { is what we mandate in our coding style. However I also want to detect more complex things such as static functions which lack documentation comments, or functions which are not declared as returntypenewlinefunctionname(arglist)newline{.

I hope someone has a cunning idea…

D.

Ingo Juergensmann recently asked if there is a way to get more entropy for exim4 for a way to make exim4 take less entropy.

A while ago I posted my solution which grabbed the imagination of Steve Gran who I believe created and upload a debian package which garnered a not inconsiderable amount of back-flack from people who failed to realise that I wrote it because I wanted something which would solve my problem, and that perhaps the package needed more disclaimers or warnings.

One person actually took time to explain things to me and provide sample code which one day I will incorporate into the release copy of randomsound but for now it’s just crap :-)

So Ingo, one option is to install the randomsound package and enjoy that, you might have to backport it to stable if that’s what your server runs.

Another would be to spank the fool who wants to send huge mails through your server and tell them to get a web space :-)

Using the low order bit of the ADC output of your sound card, randomsound gathers entropy, debiases it and offers it up to your kernel's random pool.

It’s cool, it’s funky, it’s probably hideously insecure, but what the hey… download randomsound and have a play today.

Mostly, I wrote this to toy with the “exim4 eats all my entropy” problem which some of us who haven’t been able to upgrade to the very latest exim4 packages suffer from. Also it solves the problem of world peace; feeds all the starving; and magically resurrects the parents of every orphan ever, while curing everyone of HIV.^*

I’m interested in anyone who wants to tell me why I really shouldn’t run this, but thus far, it has been a life-saver for my mail infrastructure.

---

^* Some of these claims may be lies.

A few days ago I decided it’d be really handy to have a tool which would take a description of a structure as it apears on disk/flash/network (I.E. packed, not necessarily aligned, perhaps wrong endianness, etc) and provide as output a C header file containing an appropriate struct definition for manipulating the data and a set of functions for packing and unpacking the data. The idea was to be a little more efficient than the utterly generic pack/unpack routines which are out there, but perhaps not as efficient as a custom packer/unpacker would be. Indeed the intention was also to be robust in the face of madness rather than quick but explosive.

I now have a fairly stream-of-consciousness set of notes about what I am calling Yue Fei for want of a better name. Yue Fei was one of the more famous chinese generals who held a rank similar to ‘Field Marshall’. Given the purpose of the program is to marshall fields of data, it seemed appropriate and also conveniently two syllables and easy to remember.

What I am after is comments and ideas. Anything from “Pah, your idea is already implemented <here>” through to “Here are some ideas to improve things” or “It won’t work unless you do <foo>”. Anything useful basically. If you care, you should know where to find me.

If enough people think it’s a good idea and worth having, I’ll start work on it fairly soon and create the usual software page on my website etc.

Please do have a read of the notes and let me know what you think.

John Goerzen recently made a positing about Git, Mercurial and Bzr in which he states “bzr doesn’t support tags and has no support for emailing changesets whatsoever”. Just so you know John, Bzr 0.15 is carrying a form of tags support written by Martin Pool and also has had for some time now support for bundles. Bundles are easily emailed around and can be used to merge from. The main Bazaar development list uses them for this. All you’d need would be a trivial plugin to allow you to mail the bundle from the command line. And that’s just needed if you can’t cope with bzr bundle | mail -s “Here’s the feature you wanted” recipient@domain. You can even use BundleBuggy to monitor a mailing list and look after merge requests.

Of course, tags are not actually needed for bzr. After all, in a repo, a branch is practically free, so simply making a branch for a release is easy enough, although I can understand a desire for tags from people who are used to them. As for sending changesets by email… bundles are easy, but I prefer to push my branch to my server and send a reference instead.

Only I could leap into action when told ‘The scroll wheel doesn’t work in netsurf gtk’ add debug statements, work out what I think the problem is, launch netsurf, grab my mouse to do some scrolling to see if I was right, only to exclaim “Aaargh, I don’t have a scroll wheel!”

Still, explains why I’ve not fixed it yet :-)

Sometimes it’s easy to assume that everyone is at least vaguely sensible about source code they release on the world. Sometimes it’s easy to forget that out there are idiots who will attempt to fleece you for your money and in return supply you with utter dross.

Then sometimes you see something like this

Sigh

The following is a suitably anonymised report about some source code which recently passed before me. You just can’t make this stuff up, some people really don’t know how to produce good code…

---

PROJECT Software Review

The following is the result of an extensive review of the source code for the PROJECT project supplied by CUSTOMER to REVIEWER. The delivered source code (codebase) was supplied as a single tar file, with some accompanying documentation as provided by the company subcontracted by CUSTOMER (the contractor) to implement the software requirements of the PROJECT project.

General observations about the delivered codebase

The codebase was supplied as an uncompressed POSIX tar archive rather than as a source code revisioning system store as would be expected of such a delivery. Therefore there is no way to track the history of the project, nor indeed any way to accurately suggest how much time was spent in developing the codebase.

Initial investigation suggested that the codebase should be unpacked in the directory ”/opt/PROJECT”. Imposing such a requirement on the customer is extremely unprofessional. However to require that the codebase be unpacked in a directory in the ”/opt” heirarchy, which is explicitly not a suitable location for source code as per the UNIX file system hierarchy standard, is utterly unacceptable.

Once unpacked, a preliminary audit of the codebase revealed several intermediate object files inside the source tree and also build system intermediates such as preconfigured makefiles. This indicates that the codebase was not cleaned (mechanically or manually) by the contractor prior to delivery.

The application appears to expect to be run as the super-user which is inadvisable within a UNIX environment. The build system itself expects to be run as the super-user as it implicitly overwrites configuration files belonging to the user called ‘root’. This is considered to be extremely poor practice and is strongly discouraged in relevant documentation regarding the building of software in a UNIX environment.

The supplied build script configures the system so that the machine will reset its database on every startup. This means that the PROJECT will not retain CRITICAL_DATA across reboots, power loss, or even restarts of the windowing environment.

The supplied internationalisation is a gesture rather than the pervasive presence which would be expected of such an effort. Indeed all the internationalisation appears to be is that which the “GNU autotools” provide by default as infrastructure for the developers to build around.

Given that almost every file in the codebase is marked executable, it is reasonable to assume that the codebase has passed through a Windows-based computer (or at minimum a poorly configured Linux system with Windows file systems) and this makes it very confusing when looking for scripts or tools during a code audit as everything is considered to be a program by a Linux system.

The codebase is a patchwork of different styles, indicating that the contractor employs several different programmers who do not adequately communicate with each other with respect to code structure and styling. This suggests that communication within the contractor with respect to design and requirements may also be poor.

The codebase appears to contain source code licensed under the “GNU General Public License” (GPL). The GPL is an open-source licence which does not permit direct linking or inclusion without all parts of the project being placed under the same licence. As a result, CUSTOMER would have to release the entire application under the “GNU General Public License” which requires that the authors supply the source code to anyone to whom they provide object code; or else risk a lawsuit from anyone who discovered such a discrepancy.

The fact that the contractor felt it acceptable to include source code encumbered by such a licence is not heartening; indeed it raises the question of the provenance of the rest of the code base as it is now not beyond reasonable doubt that, given the apparent patchwork nature of the codebase, the contractor may have included code wholesale from other projects they have been, or are, involved with.

General design structure and source code quality

It was extremely difficult to discern any form of overarching design from the codebase; raising concerns that there may have been insufficient time invested by the contractor in planning the software project.

Several files implemented the same “gross hack”, regarding the PROPERTY of the HARDWARE_ELEMENT, independently yet often in an identical manner. This single issue is indicative of a lack of understanding of the concept of correct code reuse within the project.

The codebase appears to implement exactly the use cases provided by CUSTOMER to the contractor. However this appears to have been done by layering hack upon hack until the application behaves as required, rather than (where appropriate) performing a fundamental refactor of the approach being taken with respect to a design.

The codebase required simple (but numerous) changes to syntax in order to be compiled. This suggests that the contractor has never compiled this codebase from scratch and thus is not regularly auditing its output.
Some of the coding styles in use within the codebase seem to call for mechanically extractable code comments which describe the interfaces and mechanisms within the software. This is a laudable practice which in this codebase has been thwarted by three major issues:
1.The code commentary is not pervasive.
2.The comments are often empty, misspelled or incomplete.
3.Several comments in a random selection checked were outdated, incorrect or erroneous.

A cursory inspection of a random selection of files uncovered an appalling lack of attention to spelling which has been propogated through the use of auto-complete features in editors and never spotted. This suggests that the contractor may not have performed sufficient internal code reviews during the development of the software.

The codebase has the feel of several independently constructed sections glued together by an integrator. This is a common practice within large software projects but relies on a very high degree of care and attention on the part of the integration lead. There is no evidence of the required level of competency in the delivered codebase.

The approach taken in developing the codebase has resulted in what is essentially little more than a set of cue cards with pictures on, backed by a small amount of inconsistent, and at times incorrect, logic. This shows a true lack of foresight in the design of the project; a lack of understanding that a piece of software which has a user interface is usually more than just a user interface; and a lack of sensitivity to the future requirements likely to come out of CUSTOMER.

The interface to the hardware, which is clearly one of the most important parts of this software project as the software is intended to drive a machine, appears to be scattered, incomplete and does not use the source code supplied by CUSTOMER to the contractor for this specific purpose. Otherwise it is so well hidden in the rest of the codebase that REVIEWER were unable to find it. Either way, this does not inspire confidence in the codebase.

While the presence of a database in the software’s architecture is commendable, the choice of SQLite was short-sighted and clearly did not take into account the resources available on the target system.

The supplied initial database, as found in the codebase, is a single binary lump. This means that were the codebase to be placed under a revision control system, it would be impossible to request the difference between versions, in the accepted manner, directly from the revision control system.

To have constructed this database from source during the build would have been trivial. That the contractor did not do this indicates that they exercised little or no change management during the production of the software.

The presence of the ‘Patch’ file containing the number of the PROPERTY is a direct example of how poor some of the source code design (and implementation) is.

The lack of care and attention used when selecting fonts for display, such that labels often spilled out of their display element (or in some cases directly overlapped neighbouring elements) indicates that the contractor’s developers did not understand how to correctly construct a user interface for today’s modern operating systems.

The combination of hand-drawn and software-produced user interface widgets within the same window indicates a lack of professionalism with respect to the look and feel of the application.

The build system for the software is incomplete and misuses the development tools it directly relies upon. It has hard-coded paths for its dependencies, instead of using the commonly available and accepted industry standard mechanisms of discovery, which results in a lack of portability to a build environment other than the contractor’s own.

Concerns regarding the supplied documentation.

The primary concern regarding the documentation is the clear lack of any substantive documents regarding the codebase itself. This would not be so much of an issue were it not for the inconsistent, appallingly badly written and in places incorrect, in-line code documentation.

The document entitled ‘Scope of the Release’ supplied by the contractor appears to simply be a list of use cases which the contractor had considered for the release. Several of them are marked as unavailable or incomplete for the release made for the TRADE_SHOW and many of them are marked as incomplete or unimplemented regardless. However, no summary was provided meaning that in order to discover the lack of useful content in this document, all forty-five pages needed to be read carefully.

Conclusion

In summary, the basic audit performed by REVIEWER has uncovered numerous points of concern within the codebase that any reasonable developer should have discovered.

That the codebase was delivered in this state is, simply put, incredible, worrying and disappointing. The quality of the codebase is such that in the opinion of REVIEWER, no professional contract developer would have delivered it as anything other than a throw-away proof of concept with an explicit note to the effect that the codebase itself contains no recoverable or re-usable source code.

It is the recommendation of REVIEWER that CUSTOMER discontinue the use of this codebase pending the acceptable resolution of all concerns raised in this document. It is also the opinion of REVIEWER that such a resolution would require a greater investment of time and money than starting a new implementation.

CUSTOMER may be able to recover some user-interface concepts and graphic elements from the codebase, however REVIEWER do not recommend the re-use of the source code or design itself.

As some of you know, and fewer of you care, I changed jobs to work at Simtec Electronics some time ago. I changed for the fun of hardware, and low level programming and other such work which I hadn’t seen much of in my career thus-far. But as we all know, the apple never falls far from the tree and it wasn’t long before I was back writing application software.

However this time it was for fun (rather than profit) and it was at least low-level in the sense that I started hacking on a system emulator for the Simtec BAST development board with a colleague of mine (and co-debian-developer) – Vincent Sanders – in qemu.

From this was born the idea that we could at last provide a free ARM box to each and every Debian developer. We have been very very busy beavering away for a little over 10 days and though our eyes are bleeding from reading hardware datasheets with a view to implementing the hardware rather than the software we have cut a release.

Thus it is with great pleasure that I invite you all to come take a look at the QEMU Simtec BAST Project and have a go with version 0.8.2+stcb1 of the code.

Perhaps you would rather simply buy a real one since unlike the ARM Versatile or Integrator development boards, the BAST isn’t actually that expensive.

…on the fourth and fifth days of this month I did perpetrate the true evil of a macro system by token filter in Lua 5.1. I offer this patch as evidence of my transgressions.

So deep was my sin that I did not even make it recursively expand macros, nor did I develop anything actually useful using the technology I did perpetrate. Then, to compound my sin did I present a talk to the assembled masses and they did rain down scorn upon my folly.

I shall go now, and sin no more…for a while

Some people such as Erich Schubert have suggested how to fold entries by editing planet’s CSS.

I offer the following (works in recent firefoxes) as a userContent.css hack for how I fold long entries on planet. Notably different to Erich’s choice, I use 30em (I have a small font choice) and I use the auto setting for overflow so that I don’t get scrollybars if they’re not needed.

@-moz-document url-prefix(http://planet.debian.org/) {
  div.content {
    max-height: 30em;
    overflow: auto;
  }
}

I am proud to announce the second release of my secret-sharing library (libgfshare).

This release covers a few important things:

• Memory leak fix
• Manual pages for the tools and the concept.
• tar.gz release to enable easier packaging

I expect most people will care little for the tar.gz, more for the memory leak and most for the manual pages. They’re still a little rough around the edges, but as Søren Hansen discovered — if you want to help, branch, fix, and share the fixes with me.

I am proud to announce the first release of my secret-sharing library (libgfshare). This library will eventually go on to be used in my planned fuse filesystem for secret-sharing.

The library has been tested on Ubuntu (i386, amd64), Debian (i386), FreeBSD (i386) and OSX/PowerPC. If you discover a problem with it, please do contact me ASAP so I can put out a fixed version.

If you wish to package it for a linux distribution (or anything else I s’pose) then please go ahead, but let me know so I can link them on the software page for the library.