Hello, We're catching the tail-end of discussions about Debian's up-coming official wiki at <http://wiki.debian.org/>, specifically, the migration of material from the unofficial wiki at <http://wiki.debian.net/>.
I'd like to raise the issue of wiki material licencing before it gets too late to do anything about it. Currently, most wikis do not express any licence regarding the material they provide: there is no clear indication how the material might be re-used (e.g. incorporating into debian's official documents) or what terms people can contribute under. wiki.debian.net has a retro-fitted copyright statement at <http://wiki.debian.net/copyright.html> which states only that the copyright is held by 'each author'. There is also a condition of publishing (namely, re-use, Fair Use). This isn't linked to from the edit form (can't confirm whilst it's read-only) so you are only likely to find this if you look for it. A piece of software which was released without any indication of licence would never be considered as a package for debian. I would not like to see anything produced by the wiki to be discounted in a similar way: it might be that the wiki proves to be a very useful tool for writing replacements for GFDL documents for example. It is possible with some wiki technologies to incorporate both a human-aimed indication of licence (all contributions must be made according to these terms...) and a machine-readable indication in the form of licence metadata. I've hacked GPLv2 metadata into mediawiki, for example (proof of concept at <http://wiki.debianflame.org/>). I am happy to work on how to do this with moin moin but I need to know that others agree this is necessary. Is the current statement on wiki.debian.net sufficient? In which case we need to add it to the .org one too. It would really need to be done before any material starts getting added (i.e., before the private discussions about content migration from .net to .org were started). We'd also need to decide on a licence for material. I'd suggest GPLv2, in order to be compatible with e.g. the new maintainer's guide, the developer's reference, etc. [With apologies for the length] -- Jon Dowland http://jon.dowland.name/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]