 OK. I'm sure everybody wants to get off to dinner, so let's make a start. I'm not really going to say anything earth-shattering, but hopefully you'll get a few quotes, you'll get a bit of explanation, a bit of background about what Debyn Lleidwyl actually does, what it's good at, what I think it's not so good at, where it came from, what people think it does, and also maybe some directions that it could go with a bit more sort of effort, a bit more involvement. So first of all, where did Debyn Lleidwyl come from? Well, the DFSG, Debyn Free Software Guidelines, the first 1.0 version was actually passed in July 1997, and that was quite some time before Debyn Lleidwyl actually existed as a thing on itself. So if you've got a problem with the Free Software Guidelines and how they were originally written, that's not our problem, please don't blame us. And then in November 1998, Debyn Lleidwyl mailing list was actually requested and announced by Martin Schultzer, and the first two threads on it, it's quite interesting to look at, the first one was about revising the DFSG, that was a discussion started by Ian Jackson, and I think mentioned it in the last talk or an earlier talk, and analysing the QT public licence. Now if you've looked at Debyn Lleidwyl in the last few years, if you try raising either of those topics still, they're still quite hot topics, some things never really change. In April 2000, Debyn Lleidwyl actually had a mention added to the Debyn policy saying that if you're uncertain when you're packaging something about copyright licensing, trademarks, anything to do with Free Software Guidelines, ask Debyn Lleidwyl. Up to that time, I actually told you to ask Debyn Devel. I'm not quite sure whether some of the developers are still smarting about that change, but that's the bug number if you want to see the reasoning. January 2002, a set of legal pages were actually added to the Debyn website explaining about the move of crypto into main. Now, the top level of pages there, for a long time, actually had very little to do with the Debyn legal mailing list, and I don't think even mention them for some time, but that changed a bit later as we'll see. April 2004, there was an update to the Free Software Guidelines, and surprisingly, that sort of stemmed out of something that was discussed quite a lot during 2003 on Debyn legal, but was actually discussed itself there much. So, if you followed Debyn vote, you would have known probably more about that than if you followed Debyn legal. So, again, it's just my request. Don't blame Debyn legal for any changes, any revisions to the Free Software Guidelines. A few other notable things. In 2004, there was a general resolution about whether Sarge should release with non-free software documentation and so on, mainly still in it. And in 2006, there was one about etch releasing with binary firmwares. These are quite subtle, almost quite corner cases of the Free Software Guidelines and packages that don't quite live up to them as fully as maybe we'd like. And if you actually look at the vote tallies for those two, the Sarge release with non-free and the etch releasing with binary firmware votes, you'll see quite a lot of the Debyn legal regulars, if you would like, actually voted to release and deal with the problem when we get time. On the other hand, there was also a resolution about the FDL, GNU's Free Documentation Licence, where the vote didn't really go the way that a lot of legal would have liked it to, but then I think you'll find legal contributors voting for about three different options without a clear move for any one of them in particular. Now, just a quick mention of myself just to explain some of the limitations in this talk. You'll see it was actually called Four Years on Debyn Legal, and I've only been there for four years. There's stuff about the early days and what happened there before that point. I can't tell a great deal about. I've gone back into the archives for some of the more interesting discussions, but there's a hell of a lot of stuff to read there if you go all the way back to the beginning. I actually started using Debyn about 1999 because some other people at the university were using it and suggested I take a look at it. Before that, I'd used FreeBSD, Solaris, Digital Unix and so on, and Slackware even, and just kept moving from one to another. But I stayed with Debyn because it actually upgrades. I became a Debyn developer at the suggestion of one of the other Debyn developers at the university in February 2003, and then in May I joined the Debyn Legal mailing list because somebody was talking about me, and I'm not quite as bad as Kibo, but if you talk about me, somebody seems to tell me. I don't know why. They seem to think I'm going to fly off the handle all the time. I've no idea where they get that idea from. It's quite interesting to look at what was actually going on when I joined Debyn Legal, I think, because you see a lot of things, a lot of similarity between May 2003 and, say, May 2007. There was a fairly significant licence for Debyn, the latech project public licence, and a new version of that was coming out that dealt with some of Debyn Legal members' worries, concerns about it. M Player was a topic of discussion. It was being kept out of Debyn at that time because of some concerns about patents and some concerns about its copyrights. You can find that one recurring again, and again, and again. PHP nukes advertising clause, and advertising clauses in general were fairly hotly discussed, and the ultimate conclusion was it's a sort of use restriction, but some people, it's not clear-cut. People often ask about compatibility between different licences. If I mix this work under that licence with this one under this other one, what happens? Can I actually use the result in combination? Of course, the FTL was being discussed, which is where I got mentioned. The most frequently asked question is definitely about the GPL and combining it with whatever other licence you'd like to pick. A common one is the open SSL licence because it is essentially BSD with the old so-called obnoxious advertising clause, sort of style, but generally combining the GPL with anything is asked fairly often on the legal mailing list, and it's sort of interesting that people ask Debyn about that and looked at Debyn legal about that, rather than looking to the free software foundation, and there's all sorts of reasons you can speculate about why that is, but in general, if you ask the FSF a question, the conversation happens in private, and if you ask Debyn legal a question, the conversation happens very much in public, which has a problem that I'll cover later. If you asked Debyn legal in May 2003 what licence should I use for my free software? You'd get pretty much the same answer that you get today. You should use the GPL, or if you really don't like the GPL, you should use the modified BSD, and even back then, people were looking to apply the free software guidelines to other things than programmes. There's a quote there from Henning Macomb, who I don't know if he's in the audience today, or even here, but there's a few more quotes coming, so if anybody feels I've misquoted you, then tough, these are the actual words. If you think I've taken you out of context, take it up with me in the questions. A venue is another thing, and this is a discussion that's still running now, four years later. But even back then, we'd got Joey Hess asking, haven't we rejected choice of venue before? And Brandon being a bit stronger. And there are also quite a lot of apologies going around. We don't understand copyright all that well. There is quite often a bit of the noise, is people saying what they think copyright means, and not getting it quite right. And so there's rather a lot of people saying sorry then. I think there's probably more apologies four years ago than there are now. There was also quite a bit of humility. If you started to press someone on something they'd written even after they'd been corrected, you'd quite often get a comment like, why are you still bothering? Other people have pointed out what an idiot I am. So there's quite a bit of humility, and I'm not sure that that's quite so common now. I don't know if that's general across all the project lists though. So what does Debian League actually do? I wonder about describing it, to rip off somebody else's phrase. Many eyes make licence bugs shallow. Now some people accuse Debian League of going looking for problems, but in general we don't. We wait for people to come to us. We've got quite enough things to look at without going out looking for trouble. Sometimes a problem that we look at actually blows up into a much bigger problem and we think, should we really have started playing with this ball of yarn? We're now well and truly tangled, but that's just the way things are. One of the things to remember when asking Debian League, is in general, it's better for the friends of Debian to find a problem, to notice a potential problem or an actual problem before somebody was really going to hold it against us or come after us in the best case with bad publicity for us but in the worst case with actually trying to take us to court. I'm not sure anybody's done that, but some of you may know better. Debian League are not our lawyers. There are some lawyers on there. I've seen at least three. If you want to try playing lawyer spotting in the archives, it's a great sport, but they're not our lawyers. They're giving us the Debian Project legal advice. If you need to access our lawyers about a real nasty of a problem, don't post it to Debian Legal. Take it to the Debian Project leader or take it to the software in the public interest to pass to the lawyers. They can do it much more discreetly without causing problems. Debian Legal are not necessarily developers. That's okay by me. If any of you want to suggest a better way of handling it in the questions at the end, be interested whether that's okay with you. Generally the skills needed to be a Debian developer are a bit different from what it takes to be interested in something like copyright law where all too often we have to throw our hands up in disgust and say I can't answer this whereas with something you're developing quite often you run some tests. Running tests of legal things tends to be rather expensive. Debian Legal are not our gods. I'm not sure anybody really thinks they are, but I'm sure there's at least one Debian developer who fairly frequently posts to Debian Legal to remind us that Debian Legal does not speak for the project. At least once I've seen a journalist take something that was posted to Debian Legal as if it was the absolute true word of the project carved on stone tablets. Licence approval is not democratic. Debian Legal is just one part here. There's a more detailed explanation. Debian Legal has a sort of input or is thought to have an input, though sometimes attempts to find out for sure can be rather frustrating. But ultimately it is the package maintainer who would say, okay, no, I've got this wrong. I'm not willing to carry on uploading this package. Or the FTP masters can say, nope, it's no good. I'm not letting this into the archive. Now this is a more interesting question. I've sort of been sitting quietly in the background the last couple of days and I've heard a few mentions of Debian Legal and what people think it does. And I've been interested here because what you think it does or doesn't do at the end. But the top one is probably flame. And that's probably sort of been fair over the last four years from what I've seen. There's been a hell of a lot of noise there, hell of a lot of flames. There's been every type of flame you can imagine and now just for amusement value I'll quickly put up a few of the ones I spotted. I'm not going to give an example of last word wins where however long the discussion is going there's always somebody who wants the last word. And the main reason is most of the examples I could find about that were from Sven Luther so moving on. Next type of flame is you're wrong because you're you. Andrew Soffield, past master there another one who's no longer so involved in Debian. You're wrong because you're arguing. This was particularly fun during the FDL discussions where sometimes a discussion would just fall completely through the cracks and you'll be arguing over some tiny small point that doesn't matter at all. And so Brandon actually puncturing me there. And sometimes it just gets too late at night and you go you're wrong because you're wrong. Which I'm sorry to say that's one from me. You're wrong because you're new. So it's actually I'll pick up again later on but if you're asking Debian legal something that you think is going to be a frequently asked question actually look at the FAQ actually look at the archives and sometimes you get flames as comedy. You get people posting completely outrageous things just to see if any of the press are going to pick something up again. Usually you can spot these because they stick out like a sore thumb and sometimes it just gets far too silly and I think you can safely write any who to the mailing list now but where the asbestos underwear. So how could we actually use Debian legal more effectively though? How can we get away from it going off into these very niche things and all getting rather too overheated? If you actually want to see something that works look at one of the many intent to package bug reports that gets passed to Debian legal. It's usually a couple of these a month I think and generally they're answered quite quickly. You've got a fairly new developer saying I've not seen this before and you get a fairly quick answer usually or you'll get a suggestion to look at something else. If you're asking a question an ITP is a good example because generally that comes with the name of the package short description of the copyright terms and any relevant links and it's really about asking smart questions and there's so many things about smart bug reports and so on. So a quick summary of what to include. Search the archives before asking I've just mentioned that there's actually three different archives that seem to work in fairly different ways. The top one is the best in some ways because it'll actually give you a link to something on list.debian.org but the other two, the Google groups and lurker will actually let you download the message to see the message ID and from that from the main list search you can then get the official archive post as well. Another thing to do that works is to talk to your own upstream if you find a licensing problem don't ask Debian Legal to take it up with your upstream. Generally we don't know your upstream from Adam your upstream won't know us from Adam and some of the people on Debian Legal can be a little bit too blunt or a little bit too rushed. So you've generally got if you're on Backage Maintain you should hopefully have a better relationship with your upstream than we do. Subscribe us if there are many we've got many people here actually on Debian Legal. Refer back to the archives if you don't already if you say such and such has already happened we've already looked at this actually take a look back at the archives point somebody back because hopefully they've tried searching the archives for it already they haven't found it and so they've asked if you post it a link back in response then the next person to search hopefully will find the original discussion. Don't snipe so they can't spell so they can't punctuate so what and challenge bad habits you see in other people. Yes there are actually some bad habits on Debian Legal I've mentioned flames already going off topic is probably the key one if you spot somebody going off topic please try to gently bring them back down to earth early on. Fairly recently we had somebody saying what happens if I put a poster of a copyrighted image on my window and google map street view pictures it. Unfortunately a fairly gentle reply came back saying well we don't know what happens and it's probably not going to affect Debian too much so try and stick to packages in Debian or at least something that affects Debian in some way. Analyzing licences in abstract is a bad habit I think when it's done on the main list. Now this is not a universally shared view but I think experience in the four years sort of backs this one up. Early in 2004 it was suggested that rather than analysing the same licence over and over again when it's used for lots of packages to analyse the licence. Now that seems fair enough but it's sort of petered out and then the Debian project leader got involved saying I think this is a good idea. Until in April 2004 the first licence summary was posted to the website. And then summer 2004 a licence summary hit the press in a fairly bad way all over the place about the Mozilla public licence. What actually happened on the main list is somebody who was fairly new and fairly enthusiastic had put up a draft licence summary fairly quickly gone on to say ok no more comments this is the licence summary and I'm not sure whether that actually got as far as getting on to the website before it was all over everybody else's website. The Mozilla public licence is actually if you try to read it you'll know it's a fairly complicated licence it's up there with the GPL in the terms of length and wordiness and so on and I think I've read it from end to end once or twice but I think my mind has blotted out the experience it's not terribly relevant it doesn't come up that often in its plain form but when it does then usually it's in combination with something else even Mozilla itself is triple licence now under the GPL and LGPL as well as the MPL when this all blew up we sort of noticed there's a problem here and analysing licences is a rather tricky thing to do generally done by people with a lot more paid staff than we have as in we don't have any and the suggestion was made that's why we had packages not licences and then about a year later we finally removed the sort of eight or so licence summaries that actually made it to the website so the question actually comes how do we reduce the load of going back and indexing back over the archives the licences Debbie and legal have looked in the past can we make that easier for people to access if you've got thoughts on that please throw them in the questions I'll just run through a couple more of the bad habits hand waving I've mentioned I've suggested should refer back even in May 2003 you've got hand waving at the end there check the legal archive refer people to the FAQ if it's not in the FAQ and it seems to be frequently asked try and get it into the FAQ and does hand waving get worse when Debbie and legal is overworked or are there some persistent hand waivers if you think there's a persistent hand waver try to learn to spot them and maybe sort of take them aside quietly and ask them to start building some bookmarks and putting those into their messages another bad habit I think is voting to settle arguments we've seen this at least twice and it tends not to work the DFSG revision 1.1 I think it was one example of this which sort of started on the main list and then turned into a GR in about a year later maybe and the FDL I think was pretty much a licence on we combined with a vote so two of those bad habits we've seen other approaches used recently rather than try to analyse the licences on the list we've seen small groups taken off of Debbie and legal and invited to contribute more directly not sure whether that's been a good idea or not there was a discussion about that yesterday which some of you I think were part of but if you've got more comments about that I'd love to hear them and there's organisations taking the consultations more into their own house which we've seen with the wonderful wacky web interface for the GPLv3 and now the FDLv2 so I'd say keep Debbie and legal for package questions maybe pick group to comment on licence drafts we need help with non-copyright matters if you know a lot about trademarks or patents or non-disclosure agreements and so on then please throw that in if you know about them share it with us but please gently and so there's the sort of legal website there's a few more talks later this week if you know about trademarks SPI trademark is also so wonderfully wonderfully understaffed not quite sure I meant that so come along to that meeting this evening and see whether you can get involved with SPI have we got any questions please wonderful, I like this oh no, no dear I spoke too soon oh my phone behind you so I'll throw in the proverbial here to get started so one of the things that has come up multiple times repeatedly is the lack of communication between Debbie and legal and the rest of the project is a whole and we've tried at some points to do this by promogating licence summaries written by various people with various agendas to push both con and pro against a specific licence but one of the things that would be interesting is your thoughts and other people's thoughts here on what Debbie and legal can do and what the project actually in general expects from Debbie and legal as a whole and how it can meet both those goals and contribute better to the project as a whole now I've seen three attempts at feeding back to the rest of the project and I'm quite like a quick show of hands just if anybody's seen any of these who here had seen the Debbie and licence summaries when they were running two, about three with me who saw bits from Debbie and legal while that was running one and who saw the Debbie and legal package list none so okay so carry on the question what would you actually like to see how would you like to see Debbie and legal feeding back yeah I mean I guess that's kind of what I was sort of asking a question both of you and the rest of the audience because I know there's some people here so I mean I mean either we need to make more summaries or we need to beat developers over the head or perhaps developers are better off just are happier ignoring it and that's something that I mean I don't really know what to say I mean you see in the most recent discussion of the CDDL when it's basically spilled over onto the project mailing list what sort of happens there so I just want to make the comment that something I do like is the wiki on wiki.debbing.org that has an overview of various licenses I've used that quite a bit and you know as licenses are reviewed and as they're maybe instead of a summary whatever if it's posted on the wiki that's a great resource for me speaking of which on the wiki maybe it would be good if we had a bunch of the active contributors to legal who once they've done stuff on the wiki could sign on to a particular summary of a license so a particular version that's done on the wiki you can say hey yeah I agree with the summary the summary is represents my understanding of how this license works and you know if the developer not it doesn't really matter but that way they're saying yeah okay I agree with this maybe that would be useful at least to track consensus of legal because there are other options that we could use I mean we could it's been suggested a couple of times we could try and use something like deb tags to actually flag each thread with when a particular license is discussed and then also add to the packages the same tags about relevant discussions but I'm not quite sure how that would work so if anybody's going along to the deb tags talk which I think is Thursday afternoon see whether you can pick anything up from that if you're interested have we got any more comments, questions oh getting time out at the end is that the end of questions then okay I assume so no response with the loud answer so thank you very much and maybe speak to some of you over the next couple of days