Re: Validity of DFSG #10
Hi MJ, thanks for your feedback! On Mon, Jan 07, 2013 at 01:32:20PM +, MJ Ray wrote: Stefano Zacchiroli lea...@debian.org wrote: Hold on :-) All you're discussing here already exists. FTP masters vet software that enters the archive, de facto deciding whether the associated licenses are DFSG free or not. Actually, don't they decide whether the *software* follows the DFSG? They're not the DFLG, after all. Right. That's in fact why I've written de facto in the sentence you quoted ;) So, let's be more precise. The list that I think would be useful is a list of copyright licenses that, if they were the only constraints attached to the usage/modification/redistribution of some content, would make that content suitable for the Debian main archive. That does not cover corner cases (not only the interaction between copyright and trademarks, but also license mixes), but it's useful---to us and others---in a whole lot of common scenarios. And then nothing stops us to do more to deal with the complex cases (e.g. which mixes of copyright licenses we consider acceptable, when code get linked together, in Debian main? which mixes of copyright/trademark?, etc), even though that's would require more work. It is quite possible to use a licence that works fine for some other software and botch it (I think there's a famous example where a trademark licence is applied in tandem with the copyright one), resulting in a fail. FWIW: the problem with iceweasel/firefox was the *burden* caused by the intermix of trademark/copyright licenses (e.g. the obligation of renaming the package upon security patches not vetted by Mozilla), not that it didn't make the package free per se. That is something that has been addressed in the current best approximation we have of a working draft of our inbound trademark policy, see: https://lists.debian.org/debian-project/2012/02/msg00073.html I think there have been at least three attempts to index them in the past, but few seemed to care about them and so they gradually bitrot. Even the DFSGLicenses wiki page was last edited 2012-08-16 and now appears to be immutable. I guess this is simply related to the recent need of resetting your wiki.d.o password. I can edit that page. Who wants this index? Who's willing to put the time in? I'd be happy to help, although I won't lead another attempt. In passing, I note that having such a list is not much different in principle than DFSG §10: it's a concretization, with real examples, of the DFSG which are by their own nature in the abstract. I don't think there is someone who wants this index. I think it's social value that we can offer to the free software world by maintaining it. Let's accept that we are not just yet another distro. Our licensing choices have effects which extend past our project borders, they can (and do) influence where the free software movement is going. We will do a service to the free software world by documenting them better than now. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Validity of DFSG #10
On Mon, Jan 07, 2013 at 02:16:59PM +, Ian Jackson wrote: I found a report of Richard Fontana's talk here: http://lwn.net/Articles/516896/ Oh, thanks, I forgot about that one. […] we are not doing a good job at documenting and explaining our choices […] This is unfortunate. But it's not true to say that the FTP masters have the final say. The Developers have the final say by General Resolution and have exercised that power on multiple occasions including most of the most controversial licensing decisions. That's an open, transparent democratic and community-based process which OSI and the FSF would IMO do much better to emulate. It is true that FTP masters do not have the final say: the Constitution offers very good balances in that respect and we haven't been shy about using them when needed. But I don't think that's the point. And I don't have a problem with delegating the decision to a team. In fact, I've been arguing with Richard (Fontana) this precise point at the time of the preliminary discussions which --- I believe --- have been the basis for his talk. You can see part of those discussions here: http://identi.ca/conversation/80340750#notice-83030966 (unfortunately, Richard's own dents are no longer available on identi.ca) So I think we are in agreement on this part. The main point I think we should discuss is the part to which you replied with This is unfortunate (I hope my quoting is correct here). Namely: the fact that we could do a better job in documenting our choices. Because that's useful to others and because there aren't that many license review bodies out there, and finally also because we're quite peculiar in our way of doing that --- as you pointed out. Debian is the only widely-referenced licence Free Software review body whose ultimate decisionmakers are anything other than a self-perpetuating oligarchy. FWIW, OSI is opening up, so this might change in the future. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Inbound trademark policy, round 3
I volunteered to Stefano to try to summarise and synthesise the discussion about our inbound trademark licence policy. Here is the previous discussion head article: https://lists.debian.org/debian-project/2012/02/msg00073.html In this message I'm going mostly to write things from the point of view of a more or less neutral summariser/shepherder of the discussion. But I also want to make some points of my own which I will mark with the symbol ] in the LH column. I think we have some areas of agreement but are still lacking in consensus answers to some important questions. I'm afraid I don't think we're quite ready to publish and deploy a concluded policy. Summary: ] We need to be clear about our objectives. Rought consensus: 1. DFSG principles should apply. 2. No Debian-specific licences; freedom to make changes. 3. Rebranding to avoid the trademarks makes the package OK. Outstanding questions: A. Is it OK for some changes to need rebranding? If so which? B. What if upstream have restrictive policy but relaxed attitude? C. What about risk or revocation or upstream change of mind? Detailed discussion: ] One thing that seems to be missing from the discussion is a clear ] statement of our objectives in this context. I know that perhaps ] they are obvious but I'd like to set them out. I think the adopted ] policy should explicitly state them. ] ] I think these are our goals: ] ] I. The primary and overriding objective is to ensure the freedom ]of our users and downstreams. This should be evaluated with ]respect to the DFSG and the FSF's Free Software Definition. ] ] II. Insofar as it doesn't conflict with the primary objective, ]we should honour the reasonable wishes of upstreams and ]respect their concern for their reputation (and their ]legal position). ] ] III. Insofar as it doesn't conflict with the primary objective, ]we would like users to see the software we package under its ]usual name and usual branding. That gives credit to upstream ]where it is due (assisting with objective II), and assists ]users and administrators (assisting with the primary ]objective). ] ] IV. We have a limited amount of effort available. If we have ]insufficient resources to distribute certain software while ]complying with the primary objective and applicable laws, we ]should not distribute that software. Otherwise, we should ]direct our efforts where they will do the most good and not ]undertake unnecessary work. Reading the thread, I come to the following conclusions: 0. Firstly we need to be clear that we're primarily discussing trademarks on logos, names, etc., which affect larger programs. Where the whole package embodies one or more trademarks (eg, it's a logo collection or something), different principles apply and the package is probably suitable only for non-free. For normal packages, I think we have rough consensus on the following: 1. We should try to apply the principles of the DFSG to potential restrictions attached to inbound trademarks. Exactly what that means in practice is subject to some discussion. 2. In particular Debian should not distribute packages affected by trademarks if those trademarks: a. restrict the activities of Debian's downstreams more than they restrict Debian (so no Debian-specific license agreements) b. restrict the ability to make changes we or our downstreams are likely to want make to the software. (This weak form of the criterion has consensus; some people want a stronger test.) 3. If we rename and rebrand a package as needed so that the trademarks no longer apply, there is no objection to the result being in main. (Whether this is an effort worth doing depends on the value of the package, of course; perhaps for some packages it would be better not to bother and simply leave the program out of Debian.) ] I think it is OK for the trademarked logos etc. still to physically ] exist in the source tree in main if their copyright licenses ] permit, since distributing them in the source tree but not ] presenting them doesn't engage trademark law. 4. Trademarks present at least somewhat different problems to copyright because we can escape trademarks by rebranding. So our treatment of trademark licences shouldn't be entirely identical to our treatment of copyright licences (but see below). The main big question that remains under discussion is this one: A. Is it acceptable for a trademark to impose any restrictions at all about the changes which might be made to the software. Or to put it in the words of 2b above, how much further than are likely to want to make should we go ? Are there changes prior to which it might be acceptable for the trademark holder to insist on rebranding ? Several people have answered this with no. Others have suggested
Re: Position statements short of a GR - DPL statements
A little while ago I wrote this: There are often topics about where it would be useful to have a statement of position, or some recommendations for project participants (or for users or citizens). I'm speaking here primarily of nontechnical matters. Often these are in the remit of individual maintainers or maintainership teams. So for example, the boundaries of what counts as a release-critical bug, or decisions about licence acceptability. But there are also topics which aren't covered by an existing team or delegation. There are a couple of these that are on the DPL's plate right now: - Dealing with inbound trademarks. Ie, how best to deal with possible trademark risks in the software we deal with; - A requests from Debian as a whole to its downstreams including particularly a specific request to eg Ubuntu; Up to this point in the project we have normally published only: - GRs - Formal policy documents issued by teams (of which the Dev Ref is an example); - Press releases - Informal statements by individuals I think it would be useful to add a new category to this list: - Formal policy document from the DPL This would be implemented by the DPL establishing a section of the website where they provide, in their role as Project Leader, some statements of their opinion about matters relating to Debian. For avoidance of doubt I envisage that the website section would be under the control of whoever was the DPL at the time (and any Delegates they appoint for the task of gardening it or parts of it). So a future DPL could revoke or amend the statements. And I would hope that a decision to publish such a statement would be a decision by the DPL and therefore subject to overturn by GR. Some people have suggested that such an action by the DPL would need a constitutional change. Can you please confirm your interpretation of the constitution ? If in your view formal statements from the DPL are not permitted, can you please comment on which of the following prospective web pages setting out position statements are permitted and which are also unconstitutional ? h1Position Statements from the Debian Project Leader/h1 h1Position Statements from Charles Plessey, Debian Developer/h1 h1Position Statements from the Debian Emacs team/h1 h1Position Statements from Alice Jones, Debian Gnomovision Maintainer/h1 h1Position Statements from Barking Kook, Debian User/h1 h1Position Statements from the Debian Project Secretary/h1 h1Position Statements from the Chairman of the Debian Technical Committee/h1 h1Position Statements from Andreas Barth, member of the Debian Technical Committee/h1 h1Position Statements from ow...@bugs.debian.org/h1 I look forward to hearing your views. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20716.18480.431085.374...@chiark.greenend.org.uk
authoritative list of DFSG-free licenses
On Mon, Jan 07, 2013 at 11:55:57PM +0100, Joerg Jaspert wrote: One thing first: The question if we change DFSG and documenting what we think is free (or not) are two entirely different things, and shouldn't be mixed together. I'm replying only to the documenting thing using my ftpmaster hat, the DFSG§10 one is entirely seperate and doesn't really touch ftp* opinions. Fair enough, let's fix the subject then. The whole of ftp* agrees that it would be nice to have a place documenting this. So much so that we started something for it in 2009, see http://ftp-master.debian.org/licenses/ for it. Oo, that's awesome! I had no idea something like that existed, and I can't find it listed anywhere: can you people please link it from http://ftp-master.debian.org/ ? And here is an ikiwiki instance in a git, check it out, ftp*. got it around 31 commits far, and then it slept in. It *is* entirely dull and non-fun and just boring work, with no direct payoff (in NEW/rm you at least have that direct payback :) ). For those willing to play with it, the associated Git repository seems to be at http://ftp-master.debian.org/git/licenses.git/ Joerg, it would be nice to rebuild it adding the repolist plugin http://ikiwiki.info/plugins/repolist/ , which would add the rel-vcs metadata, making the following work nicely out of the box with mr: $ webcheckout http://ftp-master.debian.org/ I haven't found the ikiwiki configuration in Git, so I'm unable to provide a patch for that. That said, we would be happy to get it back to live and end up with it (either where it is now or wherever fits) being a useful place. Seeing how it directly touches us (decide if $foo can go into the archive and be distributed or not), it certainly makes sense to have it within FTP* overview. Ideally, what I'd love is then to see that page replacing what we currently have at http://www.debian.org/legal/licenses/ . MJ, has you seem to have participated in the maintenance of the latter page, what do you think of that? Of course, we'll first need to bring the ftp-master page up to date. Also, I think Charles' idea of also publishing stats about which licenses are currently found in main/non-free would be useful. It can be toned down wrt the claim that these licenses are DFSG-free and presented as mere factual data of what we currently have in the archive. Doing it on the basis of machine parseable debian/copyright sounds reasonable and might further encourage adopting the new format. Any taker for writing a script that gather the corresponding statistics? That said, it is clear it can't be the FTP Team who is doing the work - the oh-so-recentness of it shows that it is a task that won't get done. There is too much else for us and we are few people only. But we would be happy to work with / lead / whatever-one-names it with a group of volunteers together. Exact details of how that works out are to be found, but im sure we can. If there are volunteers for it... Fair enough. Of course good part of the work will be reviewing the licenses that are already found in the archive and marking them as DFSG-free in your table. Which review status would you (as in ftp-masters assistants) want for those licenses? More generally, is there a specific work-flow, or state chart, you want to follow? That would help in proposing patches to the ikiwiki repo... The other big part of it is keeping up to date with future DFSG-free-ness ruling by ftp-masters. As pointed out in this thread, you usually send motivated REJECTs to maintainer only. How would you like to proceed to keep track of motivation for new licenses? Is Cc:-ing -project, as you did for the Ubuntu Font License and then indexing a link to the list archives something that would work for you? If not, what would? Thanks for this enlightening pointer to related work, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Validity of DFSG #10
Joerg Jaspert writes (Re: Validity of DFSG #10): But we would be happy to work with / lead / whatever-one-names it with a group of volunteers together. Exact details of how that works out are to be found, but im sure we can. If there are volunteers for it... I would volunteer. But: We have had problems in the past with a self-selecting group containing an imbalance of views (compared to the rest of the project) trying to take control of these important and politically charged[1] decisions. This has been worked around to an extent by ftpmaster essentially ignoring conclusions from debian-legal (which FAOD I think is entirely proper), but the perception from outside the project is confused to say the least. While licensing discussions are for many people a tedious interruption from real work there are also people for whom they are an attractive way to influence the world and advance their ideological[1] causes. (Obviously I'm including myself in that latter category.) So if we are to set up a formal decisionmaking group for licensing questions, we need to be sure that its selection mechanisms are sound, that it is properly representative of the project as a whole and that all of its members are DDs. Perhaps we should have a project-wide election, with hustings and a set of representative licence questions for the candidates to answer ? (Condorcet is a bad voting system for electing representative panels - it tends to result in majority domination; we should use STV or perhaps Shulze STV.) If we did this we'd have to redo the election every few years. Such a panel would arguably also be a more appropriate venue than the TC for deciding what policy should say about cross-suite dependency lines (#681419). IMO we should also establish a new forum for its deliberations to which only members of the panel are able to post. This avoids domination of the discussion by those (like myself...) who have a lot of time to argue about licensing, vis a vis those doing technical work. Ian. [1] I use political and ideological without criticism. Debian's chief goal - freedom - is a matter of ideology. And because freedom always means escaping from someone's control, it's also a matter of politics. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20716.22202.182931.301...@chiark.greenend.org.uk
Re: Validity of DFSG #10
On Tue, Jan 08, 2013 at 05:26:18PM +, Ian Jackson wrote: Joerg Jaspert writes (Re: Validity of DFSG #10): But we would be happy to work with / lead / whatever-one-names it with a group of volunteers together. Exact details of how that works out are to be found, but im sure we can. If there are volunteers for it... I would volunteer. But: Uhm... It looks like we've interpreted in radically different ways what ftp-masters are looking volunteers for. I interpreted it in the sense that they are looking for volunteers to *document* past, present, and future decisions made by ftp-masters. You interpreted it in the sense that they are looking for volunteers to participate in the decision process itself. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Validity of DFSG #10
Stefano Zacchiroli writes (Re: Validity of DFSG #10): I interpreted it in the sense that they are looking for volunteers to *document* past, present, and future decisions made by ftp-masters. You interpreted it in the sense that they are looking for volunteers to participate in the decision process itself. Ah. Sorry abouut that. As you said on IRC: 18:17 zack I wasn't exactly in the mood of making, right now, a revolution into how we decide DFSG-freeness 18:17 Diziet Oh I see. 18:18 Diziet Right. 18:18 Diziet Good. 18:18 Diziet Sorry to misunderstand. 18:18 zack (it could be done if needed :-), but that's another aspect) 18:18 Diziet No, it's not needed. If ftpmaster don't want things to change then great. 18:18 Diziet I will say that in the email thread. So yes I think tieing this decisionmaking to the hard work of ftpmastering is fine. Having stuck my neck out I ought to volunteer to help with the documentation. So please count me in. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20716.25475.895500.443...@chiark.greenend.org.uk
Re: authoritative list of DFSG-free licenses
On 13085 March 1977, Stefano Zacchiroli wrote: The whole of ftp* agrees that it would be nice to have a place documenting this. So much so that we started something for it in 2009, see http://ftp-master.debian.org/licenses/ for it. Oo, that's awesome! I had no idea something like that existed, and I can't find it listed anywhere: can you people please link it from http://ftp-master.debian.org/ ? Well, it is not, as it is currently not useful. It is (still) a proof-of-concept, thats why it isn't linked anywhere. Sure that will change when we get a bit more. And here is an ikiwiki instance in a git, check it out, ftp*. got it around 31 commits far, and then it slept in. It *is* entirely dull and non-fun and just boring work, with no direct payoff (in NEW/rm you at least have that direct payback :) ). For those willing to play with it, the associated Git repository seems to be at http://ftp-master.debian.org/git/licenses.git/ Yep. Joerg, it would be nice to rebuild it adding the repolist plugin http://ikiwiki.info/plugins/repolist/ , which would add the rel-vcs metadata, making the following work nicely out of the box with mr: $ webcheckout http://ftp-master.debian.org/ I don't see why I need a plugin (and whatever settings) for a one-line change, so I just went and added link rel=vcs-git href=http://ftp-master.debian.org/git/licenses.git; title=licenses.git / to the page.tmpl. It isn't supposed to change location every other day. :) But feel free to get me patches to change it, if you think it should. I'm not set on it. I haven't found the ikiwiki configuration in Git, so I'm unable to provide a patch for that. You are blind. :) It's all in git, but we don't use a setup file. The ikiwiki foo is in ikiwiki/ and the way we call it from our git hook is documented in README. I just did the few changes that it works with ikiwiki 3.x, so people can look at it at home too. That said, we would be happy to get it back to live and end up with it (either where it is now or wherever fits) being a useful place. Seeing how it directly touches us (decide if $foo can go into the archive and be distributed or not), it certainly makes sense to have it within FTP* overview. Ideally, what I'd love is then to see that page replacing what we currently have at http://www.debian.org/legal/licenses/ . Agreed, we don't need multiple. MJ, has you seem to have participated in the maintenance of the latter page, what do you think of that? Of course, we'll first need to bring the ftp-master page up to date. And actually cover a number of licenses, not just the initial ones I put there. Also, I think Charles' idea of also publishing stats about which licenses are currently found in main/non-free would be useful. It can be toned down wrt the claim that these licenses are DFSG-free and presented as mere factual data of what we currently have in the archive. Doing it on the basis of machine parseable debian/copyright sounds reasonable and might further encourage adopting the new format. Well. Any taker for writing a script that gather the corresponding statistics? Two good places to run/integrate that: - Using the tree we export for packages.d.o, with all changelogs, copyright files and README.Debians, one can go over that and grep around, counting it. Pro: Easy to get started Contra: Low performance. - Patch it into dak. We do extract the files anyways, at that point one can extract information from them and put them somewhere easy to access (hello projectb). Contra: Slightly harder to get started. Hello dak python Pro: Performance is good. Queries later can be anything you can imagine in sql. And I bet UDD would leech the data too. That said, it is clear it can't be the FTP Team who is doing the work - the oh-so-recentness of it shows that it is a task that won't get done. There is too much else for us and we are few people only. But we would be happy to work with / lead / whatever-one-names it with a group of volunteers together. Exact details of how that works out are to be found, but im sure we can. If there are volunteers for it... Fair enough. Of course good part of the work will be reviewing the licenses that are already found in the archive and marking them as DFSG-free in your table. Or opening bugs, when one finds a license that slipped through but shouldn't be in main, yeah. Which review status would you (as in ftp-masters assistants) want for those licenses? More generally, is there a specific work-flow, or state chart, you want to follow? That would help in proposing patches to the ikiwiki repo... There is, not yet, a defined workflow. So the details have to be worked out with whoever volunteers. I'm pretty open here for suggestions. Technically I would think it ends up somewhere along - volunteers clone from the central place and do their work. - every now and then they ping one of ftp*, to have us review it,
