Re: Moving discussions about DEP-5 details to another list.
Charles Plessy ple...@debian.org writes: Stefano, as admin of the DEP Alioth project (I think that the others retired), would you agree to create a dedicated mailing list for DEP-5? I volunteer for the mailman administration, and for taking the responsibility that no major changes are discussed there instead of on debian-project. If a new forum is created, can I ask that it be accessible by Gmane? If someone tells me about its existence, I'm happy to make the request to the Gmane administrators. -- \“There was a point to this story, but it has temporarily | `\escaped the chronicler's mind.” —Douglas Adams | _o__) | Ben Finney -- 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/87pqxouw75@benfinney.id.au
Re: Debian Facilitators
Hi Stephen, I like the idea and I think that having this role somewhat formalised will help achieving it goals. cheers, Holger signature.asc Description: This is a digitally signed message part.
DEP-5 meta: New co-driver; current issues
The effort to get a machine-readable format for debian/copyright has been going on for some years now. I think it is time to get it done. To help with this, I am joining Steve Langasek as a driver for DEP-5[0]. [0] http://dep.debian.net/deps/dep5/ The story so far, in a very rough summary: * Various things are easier if debian/copyright can be parsed and interpreted by software, rather than being free-form text. For example, answering questions like what stuff is GPLv2 only, and therefore incompatible with GPLv3?. * Started on the wiki in 2007, just over three years ago. Now using the DEP process. Many people have participated in the discussions. * Quite a number of packages already use some variant of the DEP-5 format. There's no goal to make using it mandatory, however. (Compare with debhelper: almost all packages use it, but it's entirely optional.) * Most of the spec seems reasonably stable, some details need to be fixed. It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. The current outstanding issues I am aware of: * a Comment field would be good * license shortnames/keywords: the set of keywords probably needs work, and hopefully can be compatible with what other projects use; the current thread on the meaning of public domain is part of this * file globbing syntax * clarify the text so it's clear DEP-5 won't require more precision than is currently needed If there's more issues, please raise them. I will be be starting separate threads on the above topics later (in other words, please don't discuss these topics in this thread, only the meta stuff). My role as driver is not to make decisions, but to guide the discussions, and update the DEP-5 document based on the consensus of the discussions. In a bikeshedding situation, however, I will use editorial control and pick a winner in order to guide the discussion to more productive topics. (In other words, the more you bikeshed, to more power I get.) I am aiming for the following workflow: * We discuss, on debian-project, whatever issues need discussing. * I and Steve update the DEP-5 draft, and post a diff. * If there is something else to discuss on that topic, we do that, otherwise we move on to the next one. It was just suggested we move the DEP-5 discussions off debian-project. I think that would be a mistake. This is something that affects the project as a whole, and should therefore be easy for the whole project to follow, now and in the future via the list archives. If we keep DEP-5 in the subject, it'll be easy to filter away for those uninterested. If we build DEP-5 outside the normal project structures, we'll just have to re-discuss it when it's time to approve it, so it's better to have the discussion just once. Uh, this e-mail became longer than intended. Thanks for reading this far. Let's get this thing done and out and finished and over with. -- 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/1281617130.2264.35.ca...@havelock
Re: Moving discussions about DEP-5 details to another list. (Was Re: DEP-5 and public domain)
On to, 2010-08-12 at 13:58 +0900, Charles Plessy wrote: Stefano, as admin of the DEP Alioth project (I think that the others retired), would you agree to create a dedicated mailing list for DEP-5? I volunteer for the mailman administration, and for taking the responsibility that no major changes are discussed there instead of on debian-project. Alternatively, we could use an existing list, for instance debian-legal. I'm un-retiring, and also becoming a co-driver for DEP-5, in order to get it finished reasonably soon. See the meta e-mail I just sent out to -project. For what it's worth, I am opposed to a DEP-5 specific mailing list. See my other e-mail for reasons. -- 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/1281617469.2264.38.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On 08/12/2010 02:45 PM, Lars Wirzenius wrote: It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. A few comments: - Personally I find the format unnecessarily complicated and much more annoying to use than writing a normal debian/copyright file, especially for complicated cases. - Migrating all packages to the new format is an insane task which would take a *long* time and a lot of work. Time which could be spent much better on more important tasks, like fixing RC bugs or releasing faster. - Instead of writing such files (and keeping them updated), we should put more energy into doing this task automatically. There are various tools to analyze licenses automatically, for example from OpenLogic (commercial unfortunately) or http://fossology.org/ - tasks which could be handled automatically should be done automatically, even if it means that we need to spend time to write tools to do so (yes, I know this is not an easy task). So my opinion in short words: DEP-5 is a nice idea, but too far away from reality. Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4c63f023.50...@bzed.de
Re: DEP-5 meta: New co-driver; current issues
On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. A few comments: - Personally I find the format unnecessarily complicated and much more annoying to use than writing a normal debian/copyright file, especially for complicated cases. You're not required to use it. If you want to improve the format, please make concrete proposals, or at least explain why it is complicated and annoying. (If you've already done so, a URL will be sufficient. I do not, unfortunately, have the time to re-read three years worth of old discussions about this.) - Migrating all packages to the new format is an insane task which would take a *long* time and a lot of work. There is no goal to migrate all packages. That's a strawman. - Instead of writing such files (and keeping them updated), we should put more energy into doing this task automatically. It is obviously true that it would be good to make all of this reliably automated. However, even when that is done, it's useful to have things in one place in a Debian package, i.e. debian/copyright, and it'll still be useful for that place to be machine parseable. More importantly, making debian/copyright be machine parseable provides some immediate benefits, without having to wait for a solution to the big, difficult problem. -- 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/1281619632.2264.65.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
Le Fri, Aug 13, 2010 at 12:45:30AM +1200, Lars Wirzenius a écrit : It was just suggested we move the DEP-5 discussions off debian-project. I think that would be a mistake. This is something that affects the project as a whole, and should therefore be easy for the whole project to follow, now and in the future via the list archives. If we keep DEP-5 in the subject, it'll be easy to filter away for those uninterested. If we build DEP-5 outside the normal project structures, we'll just have to re-discuss it when it's time to approve it, so it's better to have the discussion just once. Hi Lars, I think that your answer does not reflect well my proposition, which I quote here: … “create a dedicated mailing list for DEP-5? I volunteer for the mailman administration, and for taking the responsibility that no major changes are discussed there instead of on debian-project.” I fully agree that the core of the discussion has to be on a high-profile mailing list. But for the details, I think that peer-review and open discussions are very important. Following the discussions can be tedious, but I volunteer to keep a track as I have been doing since the DEP process has started. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100812140339.gg26...@merveille.plessy.net
Re: DEP-5 meta: New co-driver; current issues
On 08/12/2010 03:27 PM, Lars Wirzenius wrote: On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. A few comments: - Personally I find the format unnecessarily complicated and much more annoying to use than writing a normal debian/copyright file, especially for complicated cases. You're not required to use it. If you want to improve the format, please make concrete proposals, or at least explain why it is complicated and annoying. (If you've already done so, a URL will be sufficient. I do not, unfortunately, have the time to re-read three years worth of old discussions about this.) Its nothing that could be done by improving the format. Especially in large projects you often have a lot of weird situations reagrding the licensing, or GPL with various exceptions (not only to allow linking ssl, there are many more...) and a lot of other weirdness. For me its just faster to describe the situation in human-parsable words and copy+paste the license. For small sources or largish sources with one developer and one license it should not make a difference in the time one needs to spend to write debian/copyright. Don't understand me wrong, I'm all in favor for making debian/copyright machine-readable, I just think that there are more important things to do when you have to decide what to do with your spare time. - Migrating all packages to the new format is an insane task which would take a *long* time and a lot of work. There is no goal to migrate all packages. That's a strawman. Good. - Instead of writing such files (and keeping them updated), we should put more energy into doing this task automatically. It is obviously true that it would be good to make all of this reliably automated. However, even when that is done, it's useful to have things in one place in a Debian package, i.e. debian/copyright, and it'll still be useful for that place to be machine parseable. More importantly, making debian/copyright be machine parseable provides some immediate benefits, without having to wait for a solution to the big, difficult problem. True, but to gain some benefit you'd need a lot of DEP-5'ed packages to have something useful to work on. Are there any statistics about the number of packages which use DEP5 in d/copyright? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4c640523.7060...@bzed.de
Re: DEP-5 meta: New co-driver; current issues
On 12.08.2010 16:28, Bernd Zeimetz wrote: On 08/12/2010 03:27 PM, Lars Wirzenius wrote: On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. A few comments: - Personally I find the format unnecessarily complicated and much more annoying to use than writing a normal debian/copyright file, especially for complicated cases. You're not required to use it. If you want to improve the format, please make concrete proposals, or at least explain why it is complicated and annoying. (If you've already done so, a URL will be sufficient. I do not, unfortunately, have the time to re-read three years worth of old discussions about this.) Its nothing that could be done by improving the format. Especially in large projects you often have a lot of weird situations reagrding the licensing, or GPL with various exceptions (not only to allow linking ssl, there are many more...) and a lot of other weirdness. For me its just faster to describe the situation in human-parsable words and copy+paste the license. For small sources or largish sources with one developer and one license it should not make a difference in the time one needs to spend to write debian/copyright. Don't understand me wrong, I'm all in favor for making debian/copyright machine-readable, I just think that there are more important things to do when you have to decide what to do with your spare time. But most of discussion is already taken, so now we have DEP-5 for free. And anyway not we are in frozen time, so I doubt that changes of copyright will be allowed before squeeze release. IMHO it is good to have some machine parseable format, so we can compare with other distributions, and probably do some cross-check with licensecheck and fossology (and probably we could generate a template from such tools). From few Debconf talks, it seems that corporate users want a better overview of licenses, so a DEP-5 will definitely help us, to gain again some more visibility. ciao cate PS: and transforming a machine parseable format to an other should be trivial (if the original format is well done). -- 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/4c640ada.2030...@debian.org
Re: DEP-5 meta: New co-driver; current issues
On 12/08/2010 14:59, Bernd Zeimetz wrote: - Instead of writing such files (and keeping them updated), we should put more energy into doing this task automatically. There are various tools to analyze licenses automatically, for example from OpenLogic (commercial unfortunately) or http://fossology.org/ - tasks which could be handled automatically should be done automatically, even if it means that we need to spend time to write tools to do so (yes, I know this is not an easy task). Yes but to do that automagically, you need a format the tools will generate the doc in. So DEP-5 still has a point here. Cheers, -- Yves-Alexis -- 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/4c641d9d@debian.org
Re: DEP-5 meta: New co-driver; current issues
* Lars Wirzenius l...@liw.fi, 2010-08-13, 00:45: The current outstanding issues I am aware of: * a Comment field would be good * license shortnames/keywords: the set of keywords probably needs work, and hopefully can be compatible with what other projects use; the current thread on the meaning of public domain is part of this * file globbing syntax * clarify the text so it's clear DEP-5 won't require more precision than is currently needed * Format-Specification: is unnecessarily long. Can it be shortened to just Format:? * Maintainer: is a very poorly chosen name; see e.g. this thread: http://lists.debian.org/debian-project/2010/07/msg00010.html -- Jakub Wilk signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
On Fri, 13 Aug 2010, Lars Wirzenius wrote: The current outstanding issues I am aware of: [...] If there's more issues, please raise them. It would also be nice to take a hard look at the SPDX format,[1] adopt any good ideas from it, and try to make sure that the resultant DEP-5 can be translated into SPDX, and vice versa. [There's no reason for us to do all of the hard work of copyright and license auditing and verification when we can colaborate with the work of others.] From a few conversations I had at DebConf with Kate Stewart, my understanding is that parts of SPDX were based off of DEP-5, so this should be possible. (It's at least worth looking at.) Don Armstrong 1: http://spdx.org/spec/current -- I'd never hurt another living thing. But if I did... It would be you. -- Chris Bishop http://www.chrisbishop.com/her/archives/her69.html http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100812173239.gh17...@teltox.donarmstrong.com
Re: DEP-5 meta: New co-driver; current issues
On Thu, Aug 12 2010, Lars Wirzenius wrote: On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: - Migrating all packages to the new format is an insane task which would take a *long* time and a lot of work. There is no goal to migrate all packages. That's a strawman. I found that surprising; perhaps I have forgotten a lot about this proposal. So, if I understand this correctly, this proposal is to come up with some way of creating a standard format for copyrights that is not meant to be universal (since lacunae that make it unusable for some packages are not going to be addressed), and not all packages will ever have a machine readable copyright? I had hoped that we would try for a format simple enough to be generally usable (just a header Type: GPL; Subtype: V3) would address a lot of use cases without being onerous and much more detailed than what is required now. Do we know what use cases we are trying to address? Just having a machine parseable list of licenses per package (perhaps with known tags for popular licenses, and other) seems to be far more simply addressed than the complex schema I seem to recall being bandied about. manoj -- The 80's -- when you can't tell hairstyles from chemotherapy. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/871va3o8wh@anzu.internal.golden-gryphon.com
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 01:27:12AM +1200, Lars Wirzenius wrote: On to, 2010-08-12 at 14:59 +0200, Bernd Zeimetz wrote: - Personally I find the format unnecessarily complicated and much more annoying to use than writing a normal debian/copyright file, especially for complicated cases. You're not required to use it. If you want to improve the format, please make concrete proposals, or at least explain why it is complicated and I actually second Bernd's comments. It seems uneccessarily complex and so very much harder to read. It's especially insane if you have multiple authors and where the license stays the same but the copyright years change. I tried to use it once on one program and just ditched it. It only made it more difficult for me and for anyone who read it. You really need to stop and think what is this for? What information is important to have and what can be found in the source files later if someone really cares. My suggestions: * Split out the authors and the copyright dates into one chunk. The fact that fileA is copyright 2005 Joe and fileB is copyright 2006 Fred and then fileC is copyright 2006 both of this is completely irrelevant for most people, just that Joe and Fred have copyright of some parts of the package is enough. * Make it possible to say this package is licensed under foo except fileA which is licensed under bar More importantly, making debian/copyright be machine parseable provides some immediate benefits, without having to wait for a solution to the big, difficult problem. What are these benefits? I am not doubting there would be some but maybe knowing the benefits can drive the format a little? Just because you can specify the license, year and authors to the n'th degree doesn't mean you should. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- 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/20100812230806.gb32...@enc.com.au
Re: DEP-5 meta: New co-driver; current issues
Lars Wirzenius l...@liw.fi writes: The current outstanding issues I am aware of: * a Comment field would be good * license shortnames/keywords: the set of keywords probably needs work, and hopefully can be compatible with what other projects use; the current thread on the meaning of public domain is part of this * file globbing syntax * clarify the text so it's clear DEP-5 won't require more precision than is currently needed If there's more issues, please raise them. I will be be starting separate threads on the above topics later (in other words, please don't discuss these topics in this thread, only the meta stuff). I'll start a new thread for a few (relatively minor) things that I talked to Steve about during DebConf10. I wanted to mention here, though, that one of my goals is for DEP-5 to not be Debian-specific. As an upstream maintainer, I would like to use DEP-5 for the upstream LICENSE file for the software that I maintain, both because I think the benefits of machine-readability are important beyond just Debian and because it will save me substantial work as a Debian package maintainer since I can just reuse the upstream LICENSE file with some programmatic modifications as the Debian copyright file. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87eie3crb1@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
Bernd Zeimetz be...@bzed.de writes: True, but to gain some benefit you'd need a lot of DEP-5'ed packages to have something useful to work on. Are there any statistics about the number of packages which use DEP5 in d/copyright? I don't have any hard statistics, but I think the number is already well over 1,000, or in other words I think we already have more than enough to have something useful to work on. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87aaorcr86@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
Dear project, On Thu, Aug 12, 2010 at 02:59:15PM +0200, Bernd Zeimetz wrote: On 08/12/2010 02:45 PM, Lars Wirzenius wrote: It would be good to have DEP-5 done quite early in the squeeze+1 development cycle to give as much time as possible for adoption. [...] So my opinion in short words: DEP-5 is a nice idea, but too far away from reality. I just wonder what does localhost:/usr/lib/cdbs/licensecheck2dep5 :) Cheers, -- Hector Oron -- 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/20100813000543.ga3...@flaco.tsc-farm.upc.es
Re: DEP-5 meta: New co-driver; current issues
Craig Small csm...@debian.org writes: I actually second Bernd's comments. It seems uneccessarily complex and so very much harder to read. It's especially insane if you have multiple authors and where the license stays the same but the copyright years change. I combine all the copyright notices into one block with that license. I don't see anything in the DEP-5 format that says you can't do that, but if there is anything, clearly we should fix that. Legally, I believe doing that is fine. My suggestions: * Split out the authors and the copyright dates into one chunk. The fact that fileA is copyright 2005 Joe and fileB is copyright 2006 Fred and then fileC is copyright 2006 both of this is completely irrelevant for most people, just that Joe and Fred have copyright of some parts of the package is enough. I think *allowing* this would be fine, but *requiring* that the authors be separated from the corresponding license block is a bad idea. It's often quite easy to retain this (by just copying the copyright and license from a portion of the package), and I personally don't want to lose that information. * Make it possible to say this package is licensed under foo except fileA which is licensed under bar I'm not sure why you don't think this is already possible. I do this all the time using the existing DEP-5 specification. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8762zfcr2w@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 09:08 +1000, Craig Small wrote: I tried to use it once on one program and just ditched it. It only made it more difficult for me and for anyone who read it. That would indicate there is a bug in the DEP-5 spec. It is, in my very non-humble opinion, not acceptable for DEP-5 to make it harder to maintain debian/copyright in DEP-5 format than as a free-form one, except for minimal markup. It seems that the process so far has created an impression that a DEP-5 file should be incredibly specific and detailed, and we'll have to fix that. You really need to stop and think what is this for? What information is important to have and what can be found in the source files later if someone really cares. The answer (obviously to me, but not so obviously to others) is that it should have the same information as a free-form copyright file, at the same precision as the free-form file would have, while allowing more precision for those who want provide it. My suggestions: * Split out the authors and the copyright dates into one chunk. The fact that fileA is copyright 2005 Joe and fileB is copyright 2006 Fred and then fileC is copyright 2006 both of this is completely irrelevant for most people, just that Joe and Fred have copyright of some parts of the package is enough. Files: * Copyright: 2005-2006, Joe 2006, Fred But I'll bring this up later in a separate thread, since there is a detail that may need discussing. * Make it possible to say this package is licensed under foo except fileA which is licensed under bar Files: * License: foo Files: fileA License: bar More importantly, making debian/copyright be machine parseable provides some immediate benefits, without having to wait for a solution to the big, difficult problem. What are these benefits? From me initial mail in this thread: 'For example, answering questions like what stuff is GPLv2 only, and therefore incompatible with GPLv3?.' (With 'stuff' being 'package', and not 'file'.) -- 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/1281658184.2264.115.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On Fri, 13 Aug 2010, Craig Small wrote: On Fri, Aug 13, 2010 at 01:27:12AM +1200, Lars Wirzenius wrote: More importantly, making debian/copyright be machine parseable provides some immediate benefits, without having to wait for a solution to the big, difficult problem. What are these benefits? The major important bits are that people who are basing distributions on Debian or are using Debian in the enterprise or embedded environments can more easily determine the set of licences that they need to audit for compliance purposes and due dilligence. Debian will also know better what licences we are distributing in main, and can possibly track issues where we are unable to ship specific derivative works. If we work with SPDX, we'll also be able to share the effort of producing these files with other distributions and our downstreams. We can also utilize Fossology and some of the other tools to also generate the copyright files and keep them updated with new releases, eventually reducing the maintainer burden of dealing with manually produced copyright files even further. I hope eventually that you'll be able to just run a tool on a source package, get a debian/copyright out of it, and maybe look at a few files which are questionable, then have it be kept automatically updated. If we're even luckier, upstreams will create the SPDX files themselves, and we'll just use them to generate the copyright files. DEP-5 itself has already been useful in seeding the creation of SPDX. Don Armstrong -- Your village called. They want their idiot back. -- xkcd http://xkcd.com/c23.html http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20100813001011.gy31...@rzlab.ucr.edu
DEP-5: additional requirements to use with upstream
As mentioned in the other thread, one goal for DEP-5 for me is to make the format sufficiently rich to allow me to use it for the upstream LICENSE file. Towards that end, I have three changes I'd like to have. * An additional section with the same syntax as the Files section but with no Files field that would be used for documenting the copyright of the distribution as a whole. (In US law, this is called a compilation copyright.) This is not the same thing as a Files: * section, which would specify a default copyright and license for any individual file that doesn't have other information. In some edge cases, the compilation copyright and license can be different than the copyright and license of any individual file in the distribution. * A comment field in the header section into which I can put statements like: All individual files with no other license statement are released under this license. Some files have additional copyright dates from earlier releases or may be owned by other copyright holders as noted in those files. Some files are individually released under different licenses, all of which are compatible with the above general package license. * An origin field in the files section where I can note the origin of that set of files. For example, my packages contain some files copied from GNU Libtool, and I currently say that in the LICENSE file. I don't want to lose that information. This use case could be served by just allowing a comment field in the files section, I suppose, and that may be a better approach since it's more general. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871va3cqrn@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
Le Fri, Aug 13, 2010 at 12:45:30AM +1200, Lars Wirzenius a écrit : The effort to get a machine-readable format for debian/copyright has been going on for some years now. I think it is time to get it done. To help with this, I am joining Steve Langasek as a driver for DEP-5[0]. Dear Lars, thank you for your interest in the DEP. I hope that this time we can gain some momentum and finish it. I would like to say in public that the work that you will start from is partly done by me, and that I consider myself as a driver as much as you and Steve are, because I have been in the facts driving this DEP for more than a year now, and contributed many changes on the DEP draft itself. I have aksed the DPL to solve the disagreement between Steve and me, but he is in [VAC], so it will take time. Let's be gentlemen and work together. The core of my argument with Steve is the obligatory use of bzr in a complex workflow together with bzr-svn. What I want is that on the final documents, the names on the front page includes the people who did the work, not only the people who approved it. I think it is very important in a do-o-craty like Debian. I am still concerned with the idea of dramatically increasing the traffic on debian-project with the work on the DEP, so I will list pending issues in a monolithic email for the moment. Comments It is necessary to let people add comments in debian/copyright. Some people have asked for free-form comments and I think that it is a valid request. Enclosing comments in a DEP-5 fields give extra work since for each line a space needs to be added, with a dot if the line was empty. Also, it reduces the complexity of the syntax, by having a way to insert comments that are out of the scope of the parsers. A `Comment` field can be a useful complement, in the case the goal is to provide extra information that is to be displayed with the license. This can include statements like for instance “The authors request but do not require that use of this software be cited in publications as…” Such statements are often the result of the authors kindly relicensing their work to remove non-DFSG-free clauses from their license, and in that example I think it would be appropriate to keep them in debian/copyright. As example of free-form comments that do not need a field, there is extracts of the correspondance with the authors when some points need to be confirmed, and the traditional “On Debian systems, the complete text of the … License can be found in /usr/share/common-licenses…”, which can be inferred by the parsers themselves. File format --- The “paragraph” format that is popular in Debian control files does not allow the use of free comments. Also, in addition to indentation it requires empty lines to be represented by a single dot. I can tell you by experience that it is unfun and frustrating to go through long texts, for instance the Artistic license version 2.0, and add the missing dots. Of course there are programmatic ways to solve that, but adding requirements like this is adding barriers to the adoption of the format, and at the end of the day, the small barriers add up in a quite tall one (as you can already read from the other comments on this list). I propose to use a simpler format, that is trivial to parse: ## Format It is proposed to implement this proposal in a format that has similarities with Debian control files. The main differences are: - Plain comments are allowed and are not required to start with sharp (#) signs. - Within multi-line field bodies, empty lines do not need to be symbolised with a dot. - A line with multiple spaces does not end the machine-readable section. ### Specification of the format Fields are logical elements composed of a field name, followed by a colon that can be flanked by spaces, followed by a field body, and terminated by a line terminator. - A field name is composed of printable characters, except colons. - The field body is composed of any character. Leading spaces of the body are ignored. To avoid problems with multi-line values, any line terminator must be escaped by following it with a space. The line that contains that space is called a continuation line. - Lines that are not continuation lines and do not start a new field are plain comments. - Fields are grouped in paragraphs that are separated by empty lines. The paragraphs are organised in a sequential order. Within a paragraph, the fields are not ordered. If the same field appears more than once in the same paragraph, their contents are added. Here is a small example in this format, with free-form comments: - Name: X Solitaire Contact : John Doe jo...@example.com Source : ftp://example.com/games License: GPL-2+ This program is free software; you can redistribute it and/or modify
Re: DEP-5 meta: New co-driver; current issues
Charles Plessy ple...@debian.org writes: It is necessary to let people add comments in debian/copyright. Some people have asked for free-form comments and I think that it is a valid request. Enclosing comments in a DEP-5 fields give extra work since for each line a space needs to be added, with a dot if the line was empty. This is true. I think the flipside of this argument, though, is that if we're going to have an RFC 5322 header (or, equivalently, a Debian control file) format, it would be nice to be able to point an RFC 5322 or Debian control file parser at it and have it just work. This doesn't work with free-form comments. As Steve pointed out in a separate discussion, the Debian control file format does support # as a comment character, so we could do free-form comments that way instead, but after thinking about it for a while, I don't mind making it a real field. As example of free-form comments that do not need a field, there is extracts of the correspondance with the authors when some points need to be confirmed, This is a good point. and the traditional “On Debian systems, the complete text of the … License can be found in /usr/share/common-licenses…”, which can be inferred by the parsers themselves. Oh, hm. I was going to argue that this should be part of the license text, but that's a very good point. It's actually redundant information for a Debian-aware parser. File format --- The “paragraph” format that is popular in Debian control files does not allow the use of free comments. Also, in addition to indentation it requires empty lines to be represented by a single dot. I can tell you by experience that it is unfun and frustrating to go through long texts, for instance the Artistic license version 2.0, and add the missing dots. Of course there are programmatic ways to solve that, but adding requirements like this is adding barriers to the adoption of the format, and at the end of the day, the small barriers add up in a quite tall one (as you can already read from the other comments on this list). I propose to use a simpler format, that is trivial to parse: I would prefer to stick to a Debian control file format, since otherwise implementing DEP-5 aware checks in tools like Lintian is going to be more painful than it needs to be. Lastly, there are cases like for the ‘BSD’ that needs to answer to a question first: If a work is not copyright of the Regents of the University of California, and forbits the use of another names for endorsment or promotion, can we call it the “BSD” licenses? My answer to this would be no, and it should be clearly written in the DEP. This said, we could provide a formalised way to indicate that a license is “similar to” the BSD or MIT licenses: My preference would be for the keywords to indicate a particular class of licenses, such as all BSD-style licenses with the same number of clauses and the same provisions but possibly different listed people that you can't attribute without permission. This would make the keywords much more useful for automated analysis. However, specifying when you can use the keyword and when you can't is a bit tricky. File globbign syntax Here is what I think represents the broader consensus from previous discussion: * **`Files`**: List of space-separated pathnames indicating files that have the same licence. Question marks indicate any character and asterisks indicate any string of characters. When this field is omitted in the first paragraph containing a `License` field, its value will be assumed to be '*'. If multiple `Files` declaratioun match the same file, then only the last match counts. I would prefer to use the same syntax as .gitignore, since it already deals with all of the complicated cases of matching files in particular paths versus a file by that name anywhere in the tree and does so in a well-specified way. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87sk2j9uov@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
On to, 2010-08-12 at 10:32 -0700, Don Armstrong wrote: It would also be nice to take a hard look at the SPDX format,[1] adopt any good ideas from it, and try to make sure that the resultant DEP-5 can be translated into SPDX, and vice versa. [There's no reason for us to do all of the hard work of copyright and license auditing and verification when we can colaborate with the work of others.] I've had a look at one version of the SPDX draft, and I agree that it's good to ensure convertability. SPDX has different goals from debian/copyright, and seems to be even more verbose than DEP-5 (they have no globbing, each file is listed separately), so using the exact same format probably isn't sensible. But convertability from one format to the other would be nice, and should not be excessively hard, either. -- 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/1281672312.2264.134.ca...@havelock
Re: DEP-5: additional requirements to use with upstream
On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote: As mentioned in the other thread, one goal for DEP-5 for me is to make the format sufficiently rich to allow me to use it for the upstream LICENSE file. Towards that end, I have three changes I'd like to have. Thanks, that's an interesting use case for the file format, and I'm glad you brought it up. * An additional section with the same syntax as the Files section but with no Files field that would be used for documenting the copyright of the distribution as a whole. (In US law, this is called a compilation copyright.) This is not the same thing as a Files: * section, which would specify a default copyright and license for any individual file that doesn't have other information. In some edge cases, the compilation copyright and license can be different than the copyright and license of any individual file in the distribution. I am uncomfortable signalling compilation copyright just with the absence of a Files: field. It seems to error prone to me. It would be better to be explicit, I think. What would be a good way of being explicit in this case? * A comment field in the header section into which I can put statements like: All individual files with no other license statement are released under this license. Some files have additional copyright dates from earlier releases or may be owned by other copyright holders as noted in those files. Some files are individually released under different licenses, all of which are compatible with the above general package license. Would a generic multi-line Comment: field be sufficient? * An origin field in the files section where I can note the origin of that set of files. For example, my packages contain some files copied from GNU Libtool, and I currently say that in the LICENSE file. I don't want to lose that information. This use case could be served by just allowing a comment field in the files section, I suppose, and that may be a better approach since it's more general. Perhaps it'd be sufficient to stick to a generic Comment: field for now, until there's some experience to see what other new fields are useful in the real world. This would be my personal preference. If others think an Origin: field would be good to have, I'll add it, my job as DEP driver is to record consensus. Can you suggest a wording? What do others think? Anyone for or against and Origin: field? -- 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/1281676915.2264.154.ca...@havelock
Re: DEP-5: additional requirements to use with upstream
Lars Wirzenius l...@liw.fi writes: On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote: * An additional section with the same syntax as the Files section but with no Files field that would be used for documenting the copyright of the distribution as a whole. (In US law, this is called a compilation copyright.) This is not the same thing as a Files: * section, which would specify a default copyright and license for any individual file that doesn't have other information. In some edge cases, the compilation copyright and license can be different than the copyright and license of any individual file in the distribution. I am uncomfortable signalling compilation copyright just with the absence of a Files: field. It seems to error prone to me. It would be better to be explicit, I think. What would be a good way of being explicit in this case? Maybe allow Copyright and License fields in the header? This would also has the advantage of being the way, in DEP-5, to do what several people are asking for and just state the license for the whole package without enumerating files, equivalent to what they're doing without DEP-5 now. (This differs from a Files: * block in that the latter makes specific claims about individual files, whereas the general copyright and license statement does not and has the same granularity as most upstream license declarations.) * A comment field in the header section into which I can put statements like: All individual files with no other license statement are released under this license. Some files have additional copyright dates from earlier releases or may be owned by other copyright holders as noted in those files. Some files are individually released under different licenses, all of which are compatible with the above general package license. Would a generic multi-line Comment: field be sufficient? Yes. * An origin field in the files section where I can note the origin of that set of files. For example, my packages contain some files copied from GNU Libtool, and I currently say that in the LICENSE file. I don't want to lose that information. This use case could be served by just allowing a comment field in the files section, I suppose, and that may be a better approach since it's more general. Perhaps it'd be sufficient to stick to a generic Comment: field for now, until there's some experience to see what other new fields are useful in the real world. This would be my personal preference. If others think an Origin: field would be good to have, I'll add it, my job as DEP driver is to record consensus. Can you suggest a wording? What do others think? Anyone for or against and Origin: field? It's similar to Source, but it may not contain a URL. I'd say something like: (Optional.) Free-form text documenting, for humans, the source of this set of files if they originally came from some other software distribution. This information is not required in debian/copyright files. This optional field is provided for cases where documenting this information is desired or useful. which tries to reassure people that the complexity is here for people who actively want it and everyone else can ignore it. But it may be that just adding Comment everywhere would be enough. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87pqxnt725@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 09:57 +0900, Charles Plessy wrote: The “paragraph” format that is popular in Debian control files does not allow the use of free comments. [- - -] ... I propose to use a simpler format, that is trivial to parse: Having debian/copyright use the same file format as debian/control would seem to me to be a plus. People are already used to writing in that format, and there are parser implementations for the format, so it's a very convenient one to use. The format even allows using '#' for comments. Therefore it is my personal opinion that we should stick to this. However, as DEP-5 driver, I will record any consensus that emerges. If there is wide support for Charles's new format, I'll modify DEP-5 to use that. So if you support it, please speak up now. (Until and unless a consensus in favor of the new syntax is clear, I will assume the consensus is for the syntax in the current revision of the specification.) On the other hand, it was noted by Don yesterday and by Steve in December that other projects, in particular Fedora, also use short names. I think that it important that we converge on a common set. I proposed in December to contact Fedora, but did not get positive answers on debian-project. I volunteer again to contact Fedora and the Linux Foundation as a DEP driver, to propose them to use a common set. The SPDX people are collaboration with other projects, including Fedora, on this right now. Steve and I discussed it and he'll join the SPDX mailing list to represent us, and will relay any concerns and updates. (I don't know if the SPDX list is public. I hope it is. If someone can find out and post a URL to their list archive, it would be a good thing.) Personal opinion: mostly the license shortnames should just require agreeing what they are for each of the most common licenses, and it doesn't really matter what the exact string for each one is. I'm OK with anything that is unambiguous. I would like to see us avoid painting this bikeshed as much as possible. Unbranding -- To my knowledge, you were the first to suggest this. I can't remember what this is about. Can you refresh our memories? I am running out of time, but that is already a couple of things to discuss. I have not commented on most of your topics, because I have no opinion on most of them. If others comment and there's a consensus for the changes you propose, I'll edit the spec accordingly. -- 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/1281678216.2264.170.ca...@havelock
Re: DEP-5: additional requirements to use with upstream
On to, 2010-08-12 at 22:28 -0700, Russ Allbery wrote: Lars Wirzenius l...@liw.fi writes: On to, 2010-08-12 at 17:14 -0700, Russ Allbery wrote: * An additional section with the same syntax as the Files section but with no Files field that would be used for documenting the copyright of the distribution as a whole. (In US law, this is called a compilation copyright.) This is not the same thing as a Files: * section, which would specify a default copyright and license for any individual file that doesn't have other information. In some edge cases, the compilation copyright and license can be different than the copyright and license of any individual file in the distribution. I am uncomfortable signalling compilation copyright just with the absence of a Files: field. It seems to error prone to me. It would be better to be explicit, I think. What would be a good way of being explicit in this case? Maybe allow Copyright and License fields in the header? This would also has the advantage of being the way, in DEP-5, to do what several people are asking for and just state the license for the whole package without enumerating files, equivalent to what they're doing without DEP-5 now. (This differs from a Files: * block in that the latter makes specific claims about individual files, whereas the general copyright and license statement does not and has the same granularity as most upstream license declarations.) This sounds good to me. Does anyone object? -- 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/1281678321.2264.171.ca...@havelock
Re: Squeeze, firmware and installation
On Sat, May 15, 2010 at 11:24:27AM -0400, Steve Langasek wrote: On Wed, May 12, 2010 at 04:27:01PM +0200, Martin Schulze wrote: I would rather not complicate the CD+DVD building process even more to produce non-free images. There are so many images that need to be created already. I would like us to provide non-free firmware blobs that may be required during installation in tarballs that can be downloaded or - if this is not possible - be loaded via USB sticks, floppies or cdroms. The installer would need a possibility to include such firmware blobs and detect hardware again if required to continue the installation process. There's a solution that seems obvious to me here, but no one has implemented it yet, so I must be missing something; but I'll throw it out as a starting point for discussion. Why don't we offer tools - either web-based or commandline - that can append a prepared firmware blob to an ordinary ISO in order to create an image that can be burned as a multisession disk? If this is technically possible - and I believe that it should be - then we don't have to waste mirror space, build time, etc. on a second set of non-free images. We would just have to make sure we leave enough extra room on our regular ISOs to allow grafting on the firmware at the end, and prepare firmware blobs in an appendable format. So what am I missing? More of a hack than what you describe, but I have a shell script to append firmware for a release to a given piece of media: http://dannf.org/bloggf/tech/add-firmware-to.html (yes, I'm quite behind on -project) -- dann frazier -- 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/20100813055829.gd10...@lackof.org
