In 2008 I stopped contributing to an open source project when it was pwned by a commercial interest. At that time a number of my original works existed in their source code repository, and still exist there pretty much as I left them 2 years ago, when I moved further development to a different repository. All of these works were released under the GPL, and carry my personal copyright notice, or that of a wider group of contributors who had worked on the project up to that date.

Since I left the project, the now-owners have redefined that contributors group, and have taken to retrospectively applying a different copyright to a number of these works. They have made some minor changes (mostly removing my personal branding, but also adding some scraps of new documentation) and added a dated copyright notice of their own that extends their claim back several years, despite the fact that (according to their own public records) no changes have been made until very recently.

Now, all the code and documentation is in their source code repository, so I would have no problem proving that I am the original copyright holder. However by making some very small changes, they have technically created a derivative work, and I don't have any problem with them adding a copyright notice to cover these new changes.

But what I find really objectionable is the dating of that new copyright notice back to a point well before the changes (5 years before, in at least one case).

This is obviously immoral, but the question is, is it actually illegal?

Update: it has come to light that in at least one case (not my code) the new copyright notice has been extended back to a date before the work was first published. I'm not sure whether to laugh or cry!

Some time ago we (C-Dot Consultants and Kontextwork) jointly released the WebDAVContrib and FilesysVirtualPlugin, which together support access to Foswiki data via the WebDAV protocol. More recently we released the WebDAVLinkPlugin, which enhances the integration of WebDAV documents into Foswiki, by allowing links to WebDAV documents to be edited using native applications on the client, such as the Microsoft Office™ suite.

That's great for working with attachments, but what about topics? Up to now, if you wanted to edit a topic, you had to edit the raw Topic Markup Language (TML) that the topic was stored in. Using Microsoft Word to edit TML is like using the space shuttle to commute 2km to work. Life would be much simpler if we could feed Word with a format it understands, like HTML.

We've been able to WYSIWYG edit Foswiki topics in the browser for a long time now; so the technology to convert topic content to other formats and back again exists; all we needed was a way to present this through WebDAV.

What we need to do is to give the WebDAV user a way to select what format they want the topic in. We've done this by allowing the same topic content to be mapped to more than one file entry in a WebDAV directory listing; each file entry is referred to as a "view" (because it's just a different way of looking at the same data).

The FilesysVirtualPlugin is configured with a list of views that it supports; for example, txt, html, json. When it is asked for a list of files in a Foswiki web, it generates a file entry for each of the different views, so the topic MyTopic ends up with the entries:

• MyTopic.txt
• MyTopic.html
• MyTopic.json

These file entries can be read and written just like normal files; the FilesysVirtualPlugin takes care of mapping the content back to TML. Because these file entries are all views of the same data, then if you edit MyTopic.txt, then MyTopic.html automatically changes too, and vice-versa.

Besides txt, html, and raw, two meta-data views have been provided, json and perl. These views allow you access to topic meta-data. It's easy to add new views, and we foresee other useful view types, such as xml and yaml coming along later.

WebDAVContrib, FilesysVirtualPlugin and the companion WebDAVLinkPlugin are available from Kontextwork.

For the last couple of years, C-dot Consultants has been working with a client to develop a plugin that interfaces to the well known (and quite excellent) IBM ClearQuest bug tracking and workflow management system. This interface allows Wiki users to make queries into the ClearQuest database, and present the results of those queries in tabular and graphical form. The interface was developed for the client's internal use, and has been heavily used by a large number of people for quite some time. It has proven to be very reliable. It occurred to us that it might be of some use to other enterprises who use ClearQuest. If you are interested, please contact me.

KontextWork and C-Dot Consultants have worked together to create the WebDAVContrib, a brand new Web DAV implementation for Foswiki and Apache 2.

Web DAV (Web-based Distributed Authoring and Versioning) is a set of extensions to the Hypertext Transfer Protocol (HTTP) that allows users to edit and manage files collaboratively on remote World Wide Web servers.

The new Web DAV module maps Foswiki content – webs, topics and attachments – to a directory structure, and exports it using the Web DAV protocol. It allows users to work with Foswiki content using the tools they are most familiar with, without compromising on Foswiki features. For example attachments can be opened, manipulated and saved right within desktop applications such as Microsoft Office, Open Office, Adobe Photoshop (and many more). Wiki webs can be opened in file browsers such as Windows Explorer, and wiki topics can be edited using many different text editors.

The new plugin is a completely new Perl implementation of Web DAV, written specifically for Apache 2, and has been extensively tested using the standard litmus tests. It works over HTTP and secure HTTPS, fully respects Foswiki permissions, and can be used with all standard Apache authentication methods. A version for TWiki is also available.

The WebDAVContrib is currently undergoing final pre-release testing. Contact Andre Ulrich for availability and pricing.

Here are some of the requirements I've been thinking about:

1. More flexible specification of publish sets, including publishing groups of webs
2. Record keeping (who published what, when, and what they published)

Michael Daum has related, but slightly different requirements. Michael publishes by copying content to a static web where it is picked up by a different CMS. So he has a common requirement to specify publish sets, but has additional requirements such as unpublishing, and automation of approval processes. Anyway, the upshot of the conversation was that we should have some common way of specifying "publish sets". The current method – regexes in the publish topic – is so crude as to be laughable. The obvious approach to specifying publish sets would be to use WebNotify, but as Michael points out that's far too geeky. Another approach would be to think about "specification" and focus on the UI, perhaps build on the SubScribePlugin. Another approach would be to use a wiki app to gather published content into one place, similar to the genwebnotify.pl approach taken to generate the notification mails from the Foswiki:Tasks web. Record keeping means maintaining unforgeable records of a publishing event. That means stamping the published docs with publishing information, including the history in the published data, and publishing to publish-event specific targets (e.g. directories named by the current date).

It would be interesting to hear what other ideas people have had.