Another photoblog. :-) I unsubscribed from JavaBlogs because some people didn't like my off-topic postings over there. I just (already?) acquired a new lens for my new camera (50mm prime, f1.4 for those who care), and I was walking around in the Ghent city center to give it a spin. Shot this weird photostory:

Some boys have all the luck. And daddy finally got a chance to put those 3 fps of the new camera to test. "Halfvasten" Fair in Ghent, featuring my SO and our second boy. The first one was away for a district boy scout meeting, and the little daughter was ill at home with my parents. After a night of caring for vomiting baby girls, the change for nice weather and fair fun was welcome.

Saturdays happen to be busy days at our home: shopping, swimming lessons, and today some cleaning and a visit to my wife's parents were added to the mix. Still, I was able to hunt down some precious quality time with my new camera. The weather here is awful, so nothing colorful: meet Hector, a chicken which agreed to pose during one of my many test shots today.

Hector was looking a bit down, perhaps because the heavy winds messed up his feathers, and because he/she(?) confusingly looks very cock-like, still to the best of my knowledge cocks usually come with fancy colours. Hector might be a white cock - who knows?

Hector of course is a crop out of a larger picture. If you're one of those people who kick on large image downloads, here's the tiny version of the original crop (the actual image is still quite a bit larger, and has no tweaking of levels and unsharp masking applied).

I already sense some dark secret alliance between digital camera vendors and hard disk companies. Go get them, Hector!

If only I had some of this guy's talent: Ashkan Sahihi.

Much to my intellectual pleasure (or rather some weak form of masochism, hopefully bordering to some kind of catharsis), I've primarily been busy this week with lengthy email conversations about licenses, forks, and copyright. I'm linking only to the public tip of the proverbial iceberg, the meat on the bone unfortunately resides in private lists. But I've learned a lot along my newbie legal scholar way, and I wanted to write up some fine points about what I learned so far.

Software licensing, or my keen interest in software licensing, without any doubt has to do with my professional past: my first job was with a large legal publisher, which wanted to SGMLify all Belgian legislation and jurisprudence, next to a whole lot of interpretative and commentary works, to produce slice-and-dice cross-media products on specific legal or market-relevant areas. Being a techie kind of guy, I was there for the SGML (later on: XML) bits, but we worked in a nice cross-competence team, and I learned a whole lot of things about laws and courts from my non-techie, legal specialist co-workers. Unfortunately, patents, copyrights and IPR weren't exactly on my radar at that moment, but still there was plenty of other stuff I had to understand at least a bit from in order to come up with means of automation for handling this kind of information. Our small team set the foundation of an all-encompassing SGML grammar to define the structure (or lack thereof) of Belgian legislation and jurisprudence - and for many years after I quit I heard that our work was still in active use and adaptation, even across the Belgian borders. Fun stuff, and a mix of colleagues that truly required you to think out of your technical box. But that was the past, let's forward to the here and now...

Many open source licenses don't only provide you with terms and conditions you need to abide to when grabbing the code and playing around with it, but also very precisely describe what needs to be done with eventual code enhancements (patches), or derivative works that are built upon the code base you just downloaded. Most of the time, end users are not aware of this, since they only use a given product (like the Apache webserver, or Ant or Cocoon), and they enjoy a free (as in $$) ride and hopefully also some active support from the product's developers and peer users. For them, free is free as in beer, and they couldn't care less about whether someone opts for a GPL license, a BSD-style license, or put stuff in the public domain.

Wrapping such products into your own offering however opens up a whole different can of worms. People are already aware of the fact that the GPL license is reciprocal, and that you are required to publish modifications to the original codebase under the same open terms. Within the C world of dynamic linking, the LGPL is used a lot to provide people with open source library code, which doesn't require one to open up the application which uses said LGPL-licensed library. Unfortunately, in the Java world, it is next to impossible to dynamically invoke (or link to) a library without leaving traces of the library's method signatures in the invoking code - signatures which come with the same license conditions as the linked libary. To that extent, the invoking code could become subject of the license conditions of the LGPL itself, which means it would be required to be opened up as well. This is the main reason why ASF projects cannot include, refer to or use LGPL libraries: it has never been made clear (by the FSF) how to legally link to a LGPL library in the Java language. Most probably because they don't like Java itself, since it's a non-free language - but I'll leave that up to their own judgement.

Given that the ASF license (the new AL2.0) is also an open source license, one could wonder what the problem exactly is. It isn't exactly a problem for the ASF developers or contributors, since they produce open source code anyway. The problem starts however when someone downloads an ASF project, which contains or requires "tainted" code libraries, and that person builds a commercial offering around it - making a proprietary product with a commercial license for resale based on the AL-licensed code. While this is perfectly possible within the spirit of the AL (which requires you only to credit the original developers, and not to expect any warranties), the library has tainted the code, and would require the commercial guy to open up his code - something he didn't meant to. The problems can even be more subtle that that, like licenses which require you to keep the code available by some electronic means for a period of 6 or 12 months.

Looking from the AL perspective, basically any additional requirement imposed by a license of an included library or dependency will make the intended AL terms void. For the ASF contributor, this isn't a problem per se, but it becomes a problem for the users of some ASF software. Or paraphrasing what a wise and pragmatical person said on some mailing list, it all depends on whether you only want to cover your own meaty backend, or that of your users too. If you opt for a liberal open source license, and want to see your code blossom in both commercial and non-commercial settings, you better make sure your users have the same rights as well.

Just got off the phone with the camera shop: the Nikon D70 is scheduled for shipping this month - could even be this week. I wired in my money, so now let's keep fingers crossed...

I'm not sure whether I should laugh, or cry, seeing this kind of cleverly social-engineered virus mail. And I have been receiving similar mails from support at apache.org, and administration at cocoondev.org. For some strange reason, I'm starting to believe those bastards are actually targeting .org addresses.