Re: SPDX, unbranding? (Re: DEP-5 meta: New co-driver; current issues)
On Sun, Aug 15, 2010 at 11:39:36AM -0700, Steve Langasek wrote: On Sun, Aug 15, 2010 at 01:42:41PM +0200, Jonas Smedegaard wrote: Not sure if this point has been raised already: If Debian use an own format rather than e.g. SPDX then we might easier be able to deal with potential disagreements on licensing interpretations. Debian has different opinion than, say, FSF, on what is an acceptable FLOSS license. We might in the future disagree with other distros on how to interpret some licensing issues like what exactly the OpenSSL license conflicts with, or how to handle licenses mentioning patents. I know that we are not lawyers. But we still have opinions that may reflect our view on licenses - sometimes differently from other distros. Imagine the SPDX folks deciding that two licenses are so similar that they use a single shortform for both. And imagine that we want to distinguish those particular licenses. Then it is better to have a format of our own - which ideally is then machine-translatable to the universal format, where the translator then deals with the quirks of merging or hinting as fuzzy. My understanding is that the SPDX folks are also not lawyers, and are open to drawing the lines between different license keywords where it's useful to consumers of SPDX - including Debian. We may wish to allow for temporal divergence from SPDX, just as we do for the FHS in Debian Policy; but I wouldn't like us to start from the assumption that SPDX shortnames will be unsuitable, particularly when the implementors have gone to quite a bit of effort already to incorporate the DEP-5 work as a basis for theirs. Sounds reasonable. I agree. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Advertisement clauses (Re: DEP-5 meta: New co-driver; current issues)
Le Fri, Aug 13, 2010 at 08:59:11PM -0500, Peter Samuelson a écrit : [Lars Wirzenius] * 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 Is it worth adding metadata to make it easy to extract all the acknowledgements you have to add to your advertising materials to comply with old 4-clause BSD licenses? It wouldn't benefit me, but maybe it would benefit CD vendors. Of course, I'd hope there isn't too much software in Debian anymore that still has those clauses. This looks like a quite specialised use, but if for instance the CD team expresses some interst of collecting this information, it would be a useful addition. Otherwise we could generalise the concept and have simple ‘Warning’ field, with the assumption that a large number of license do not need a warning and that the list of packages with this field will be small enough for a developer to browse. This said, it would already contain a quite long list of packages who use RSA's version of md5.c… Alternatively, the field you suggested could be first proposed as an extra field, and then incorporated later as an update if it has been successfully adopted. With the advent of virtualisation, the problem of advertisement clauses is also striking all our projects and derivatives that produce and advertise Debian-based images ‘for the cloud’. And this may be a stronger problem since in that case the overlooked advertisement clauses may have more chances to be directly relevant to the field of use of the system images (i.e. the copyright holders may be more annoyed by the license infringement). Actually, I would support a moratory on the acceptance of new works with advertisement clauses in Debian. 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/20100815061127.gc14...@merveille.plessy.net
Re: DEP-5 meta: New co-driver; current issues
On Thu, Aug 12, 2010 at 01:47:42PM -0700, Manoj Srivastava 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? The goal of this DEP is to craft a machine-readable copyright format that has broad support from the Debian community and is *suitable* for use in any package. That's quite a different goal from proposing that it be *adopted* in all packages, or mandating such adoption. Many of the objections that have been raised on this mailing list to DEP-5 are objections to the very idea of a machine-parseable format. No machine-parseable format is ever going to have zero syntactic overhead, nor will it satisfy developers who are opposed to the idea of a structured debian/copyright. It is not a productive use of anyone's time to engage in discussions on this mailing list about the format being heavy or ugly or too much work when those advancing these claims offer no suggestions for improvement. There are almost 3000 source packages in Debian today that are already using some variation on DEP-5. When the rate of adoption is this high for something that's still a half-baked draft, arguing about the /need/ for a machine-parseable format, as some have continued to do, is missing the point. That avalanche has already started, it's too late for the pebbles to vote. Instead, the task at hand is to craft a file format that does a good a job as possible of meeting the disparate demands placed on debian/copyright, so that as maintainers *do* implement it, we get something that's useful to Debian instead of something that's a burden. To that end, concrete suggestions for improving the format are definitely welcome. 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 Splitting the license name and version number into separate fields implies that one can do useful analysis using only the license name. I don't believe this is the case; I don't know of any license family whose versions are bidirectionally compatible, and as for third-party license auditing, the most common free license that people want to avoid nowadays is GPLv3 because of terms not present in GPLv2. without being onerous and much more detailed than what is required now. Message-ID: 20100814053938.gc2...@dario.dodds.net 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. The complexity of the schema is simply a reflection of the richness of the information that maintainers already ship in their debian/copyright files today. Listing separate licenses for separate source files is already a common practice; DEP5 is just allowing maintainers to represent this information in a structured manner. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100815074652.ga14...@dario.dodds.net
Re: SPDX, unbranding? (Re: DEP-5 meta: New co-driver; current issues)
On Sun, Aug 15, 2010 at 02:32:39PM +0900, Charles Plessy wrote: Le Fri, Aug 13, 2010 at 05:43:36PM +1200, Lars Wirzenius a écrit : 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.) https://fossbazaar.org/pipermail/spdx/ I looked at SPDX today (I should have done earlier), and wondered how DEP-5 would be useful in that context. One of the reasons I was in favor of unbranding the DEP was to propose to upstream developers to use it, so that we can forward the fruit of our efforts and make them useful outside the Debian world. SPDX will change the situation a lot, and it may be less benefical to forward a DEP-5 file than a SPDX file. If SPDX takes off, there is not much point unbranding DEP-5 anymore. Especially if, as Russ suggests, the DEP it is integrated in the Debian Policy. Not sure if this point has been raised already: If Debian use an own format rather than e.g. SPDX then we might easier be able to deal with potential disagreements on licensing interpretations. Debian has different opinion than, say, FSF, on what is an acceptable FLOSS license. We might in the future disagree with other distros on how to interpret some licensing issues like what exactly the OpenSSL license conflicts with, or how to handle licenses mentioning patents. I know that we are not lawyers. But we still have opinions that may reflect our view on licenses - sometimes differently from other distros. Imagine the SPDX folks deciding that two licenses are so similar that they use a single shortform for both. And imagine that we want to distinguish those particular licenses. Then it is better to have a format of our own - which ideally is then machine-translatable to the universal format, where the translator then deals with the quirks of merging or hinting as fuzzy. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: SPDX, unbranding? (Re: DEP-5 meta: New co-driver; current issues)
On Sun, Aug 15, 2010 at 01:42:41PM +0200, Jonas Smedegaard wrote: Not sure if this point has been raised already: If Debian use an own format rather than e.g. SPDX then we might easier be able to deal with potential disagreements on licensing interpretations. Debian has different opinion than, say, FSF, on what is an acceptable FLOSS license. We might in the future disagree with other distros on how to interpret some licensing issues like what exactly the OpenSSL license conflicts with, or how to handle licenses mentioning patents. I know that we are not lawyers. But we still have opinions that may reflect our view on licenses - sometimes differently from other distros. Imagine the SPDX folks deciding that two licenses are so similar that they use a single shortform for both. And imagine that we want to distinguish those particular licenses. Then it is better to have a format of our own - which ideally is then machine-translatable to the universal format, where the translator then deals with the quirks of merging or hinting as fuzzy. My understanding is that the SPDX folks are also not lawyers, and are open to drawing the lines between different license keywords where it's useful to consumers of SPDX - including Debian. We may wish to allow for temporal divergence from SPDX, just as we do for the FHS in Debian Policy; but I wouldn't like us to start from the assumption that SPDX shortnames will be unsuitable, particularly when the implementors have gone to quite a bit of effort already to incorporate the DEP-5 work as a basis for theirs. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100815183936.gg19...@dario.dodds.net
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 08:00:49AM +, Sune Vuorela wrote: On 2010-08-12, Lars Wirzenius l...@liw.fi wrote: * 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?. This is quite useless as long as we are making copyright files for sourcefiles. source foo produces a library and some tools the files ending up in the library is lgplv2+ the files ending up in the tools (executables) are gplv2only and then a different gplv3+ app also uses libfoo. should this then be marked as a problem ? If someone is interested in addressing this limitation of source-based license tracking, it should be very possible to write something that integrates with a build system to calculate the effective license of a binary based on already-present information about make dependencies; or to annotate the binaries themselves with ELF notes that can be analyzed prior to stripping the binaries for packaging, if you want to avoid a dependency on a particular build system (make). And with such a tool in hand, one might even write a further tool to transform a sourceful debian/copyright into an accurate per-binary copyright file. One or more of these tools might make an interesting GSoC project for someone next year. But in any event, the absence of such tools today is no reason not to provide a structure for the sourceful license information we're recording today. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100815220346.gl19...@dario.dodds.net
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 11:19:13AM +0200, Bernd Zeimetz wrote: Also it should be possible to say something like this package is licensed under license FOO, but with the following exceptions - and then add a field which takes a longish text with the exceptions. As Jonas stated, you can do that with the exceptions bit. The DEP needs a little formatting to me because it's difficult to describe to you (or anyone else) which bit I'm talking about. - 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/20100814075319.gb5...@enc.com.au
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 02:07:23PM -0700, Steve Langasek wrote: On Fri, Aug 13, 2010 at 05:23:06PM +0200, Jonas Smedegaard wrote: But really If you believe it is enough to state in debian/control that the work is GPLv2, then that is just as possible using DEB5, with the following statement: Copyright: John Doe License: GPL-2 Verbatim license from source bla bla with reference to common-licenses No, this is not a complete copyright statement, you have to include the years of the copyright :-) Whoops. Right! Otherwise, I believe you're entirely correct. Thanks :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
SPDX, unbranding? (Re: DEP-5 meta: New co-driver; current issues)
Le Fri, Aug 13, 2010 at 05:43:36PM +1200, Lars Wirzenius a écrit : 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.) https://fossbazaar.org/pipermail/spdx/ I looked at SPDX today (I should have done earlier), and wondered how DEP-5 would be useful in that context. One of the reasons I was in favor of unbranding the DEP was to propose to upstream developers to use it, so that we can forward the fruit of our efforts and make them useful outside the Debian world. SPDX will change the situation a lot, and it may be less benefical to forward a DEP-5 file than a SPDX file. Unbranding -- To my knowledge, you were the first to suggest this. I can't remember what this is about. Can you refresh our memories? You are right, and my memory was wrong. I am terribly sorry. I checked my mailboxes, and a private thread, it is me who raised the question of unbranding. I am not sure however if it is my original idea, or if I picked it somewhere else earlier. If SPDX takes off, there is not much point unbranding DEP-5 anymore. Especially if, as Russ suggests, the DEP it is integrated in the Debian Policy. Charles -- 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/20100815053239.gb14...@merveille.plessy.net
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 12:09:44PM +1200, Lars Wirzenius wrote: On pe, 2010-08-13 at 09:08 +1000, Craig Small wrote: 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, It might be how its written. I don't have the background of the DEP-5 creation so have to read the spec as it is. 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 That means all files Fred worked on in 2006 and all files Joe worked on in 2005 and 2006? You'll get yourself tangled up into some horrible year X author matrix this way. I had a look at one of my packages, 400 files with 50 different copyright combinations. Maybe Files: * needs clarification. The difference between 'all' and 'any'. The interaction with authors and licenses causes the problem. It is solvable though. Currently having copyright lines and license lines mandatory for all files is what driving this. I saw a suggestion that there could be a package copyright and authors. That would simplify things. If a files stanza has no copyright or author you use the package one, or the Files: all (or whatever, I dont care about the syntax) information. Yes, I agree it should be an option. If you want to list every file and every author and license then it should be permitted. I'm also interested in seeing how this pans out as the dh-make templates will need updating. - 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/20100813061357.ga22...@enc.com.au
Re: DEP-5 meta: New co-driver; current issues
On 2010-08-12, Lars Wirzenius l...@liw.fi wrote: * 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?. This is quite useless as long as we are making copyright files for sourcefiles. source foo produces a library and some tools the files ending up in the library is lgplv2+ the files ending up in the tools (executables) are gplv2only and then a different gplv3+ app also uses libfoo. should this then be marked as a problem ? /Sune -- 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/slrni69uth.rvp.nos...@sshway.ssh.pusling.com
Re: DEP-5 meta: New co-driver; current issues
On 2010-08-13, Lars Wirzenius l...@liw.fi wrote: 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 I like to offer people to try to do a DEP-5 based copyright file for e.g. src:kdebase-workspace, even the overhead from 'minimal markup' is actually ending up as quite a big thing. /Sune -- 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/slrni69v48.rvp.nos...@sshway.ssh.pusling.com
Re: DEP-5 meta: New co-driver; current issues
On Thu, Aug 12, 2010 at 05:10:11PM -0700, Don Armstrong wrote: 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. CDBS supports semi-automated tracking using an additional debian/copyright_hints file in DEP5 format which only needs proof-reading (and optional compacting). In my experience copyright and licensing declarations are too often too fuzzy to rely on full automation. Examples are nice machine-discoverable licenses with a small but crucial addition added right below it. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
On 08/13/2010 01:08 AM, Craig Small wrote: 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 Also it should be possible to say something like this package is licensed under license FOO, but with the following exceptions - and then add a field which takes a longish text with the exceptions. -- 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/4c650e11.9050...@bzed.de
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 11:19:13AM +0200, Bernd Zeimetz wrote: On 08/13/2010 01:08 AM, Craig Small wrote: 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 Also it should be possible to say something like this package is licensed under license FOO, but with the following exceptions - and then add a field which takes a longish text with the exceptions. Files: libtool.m4, Copyright: 1996-2001, 2003-2005, 2008, Free Software Foundation, Inc License: GPL-2+ with Libtool exception As a special exception to the GNU General Public License, if you distribute this file as part of a program or library that is built using GNU Libtool, you may include this file under the same distribution terms that you use for the rest of that program. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
On Thu, Aug 12, 2010 at 05:10:11PM -0700, Don Armstrong wrote: On Fri, 13 Aug 2010, Craig Small wrote: 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. In order to truly deliver on this we'd need the entire distro to be converted to DEP5 format but elsewhere in the thread it was stated that this is not a goal. -- 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/20100813131335.ga4...@sirena.org.uk
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 02:13:35PM +0100, Mark Brown wrote: On Thu, Aug 12, 2010 at 05:10:11PM -0700, Don Armstrong wrote: On Fri, 13 Aug 2010, Craig Small wrote: 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. In order to truly deliver on this we'd need the entire distro to be converted to DEP5 format but elsewhere in the thread it was stated that this is not a goal. By making it easier to handle parts of the distro we make it more easy to resolve licensing issues across all of the distro, no? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13 2010, Mark Brown wrote: On Thu, Aug 12, 2010 at 05:10:11PM -0700, Don Armstrong wrote: On Fri, 13 Aug 2010, Craig Small wrote: 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. In order to truly deliver on this we'd need the entire distro to be converted to DEP5 format but elsewhere in the thread it was stated that this is not a goal. Also, this goal only requires one to list the licenses under which the package sources are delivered, but need not say anything about which _files_ are under which license (and currently, there is no requirement to list any source files in copyright either, so listing the files is an additional requirement). manoj -- Executive ability is deciding quickly and getting somebody else to do the work. John G. Pollard 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/87mxsqmux5@anzu.internal.golden-gryphon.com
Re: DEP-5 meta: New co-driver; current issues
On Fri, 13 Aug 2010 09:08:07 +1000, Craig Small wrote: 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. FWIW: I find it much easier to read than some free-form prose where I have to hunt down the relevant bits. IMO the main advantage is actually that it's human-readable. (Which doesn't mean it can't be improved or simplified.) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-BOFH excuse #78: Yes, yes, its called a design limitation signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 04:02:12PM +0200, Jonas Smedegaard wrote: On Fri, Aug 13, 2010 at 02:13:35PM +0100, Mark Brown wrote: In order to truly deliver on this we'd need the entire distro to be converted to DEP5 format but elsewhere in the thread it was stated that this is not a goal. By making it easier to handle parts of the distro we make it more easy to resolve licensing issues across all of the distro, no? ...then in the spirit of continuing to improve things it gets rolled out over all the distribution. -- 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/20100813151039.gb4...@sirena.org.uk
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 07:47:18AM -0700, Manoj Srivastava wrote: On Fri, Aug 13 2010, Mark Brown wrote: On Thu, Aug 12, 2010 at 05:10:11PM -0700, Don Armstrong wrote: On Fri, 13 Aug 2010, Craig Small wrote: 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. In order to truly deliver on this we'd need the entire distro to be converted to DEP5 format but elsewhere in the thread it was stated that this is not a goal. Also, this goal only requires one to list the licenses under which the package sources are delivered, but need not say anything about which _files_ are under which license (and currently, there is no requirement to list any source files in copyright either, so listing the files is an additional requirement). Goal of DEP5 is *not* to tighten requirements of what to document, only to tighten *how* it is documented. Personally I like the pain put upon myself of keeping track of each single file that I distribute. But really If you believe it is enough to state in debian/control that the work is GPLv2, then that is just as possible using DEB5, with the following statement: Copyright: John Doe License: GPL-2 Verbatim license from source bla bla with reference to common-licenses - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
Manoj Srivastava wrote: 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 don't think it's fair to say that the format is unusable for some packages. Unless you have examples? It's entirely reasonable to contribute things to Debian without the expectation that all packages will be required to use them. Indeed, this may be the only way to actually advance the state of the art in Debian. 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. I don't think that DEP-5 is required to be more detailed. Policy has minimum requirements for what information should be in the copyright file, and it is possible to use DEP-5 to provide only that information, and no more. -- see shy jo signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
Bernd Zeimetz wrote: 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. Just as a data point in the other direction, as a maintainer of several packages that receive frequent contributions from others, and have fairly complicated copyright situations (no assignment, multiple licences), I've found the format makes it much easier to maintain debian/copyright as when I get a new file from someone I can just add a quick stanza documenting it, without needing to write a bunch of English boilerplate. Ie, compare: Files: creole.pm Copyright: Copyright (C) 2008 Bernd Zeimetz be...@bzed.de License: GPL-2+ With: The creole plugin is Copyright (C) 2008 by Bernd Zeimetz be...@bzed.de and is licensed under version 2 or greater of the GNU GPL. However, there is a big, big problem with DEP-5, and it is named /usr/share/doc/chromium-browser/copyright. It is 1.3 mb in size (out of a 25 mb package), and completely unreadable and unusable. It appears to be machine generated, and is full of redundancies and useless information. (So I am very skeptical of claims that we should machine-generate copyright files.) It could probably be replaced by a hand-written file of about 20k. IMHO, we should not allow such unnecessarily complicated copyright files in Debian. -- see shy jo signature.asc Description: Digital signature
Re: DEP-5 meta: New co-driver; current issues
Craig Small csm...@debian.org writes: On Fri, Aug 13, 2010 at 12:09:44PM +1200, Lars Wirzenius wrote: Files: * Copyright: 2005-2006, Joe 2006, Fred That means all files Fred worked on in 2006 and all files Joe worked on in 2005 and 2006? You'll get yourself tangled up into some horrible year X author matrix this way. I had a look at one of my packages, 400 files with 50 different copyright combinations. I think you're overthinking this. It's very common with copyright notices to roll them up in this way and not worry too much about who has copyrights on individual files. Upstreams do this all the time. If someone wants the exact breakdown per file, the original files aren't going anywhere. At least in US law, the important thing about copyright notices is to preserve all of them; it's not nearly as important to make sure they're associated with only the relevant file. It's quite likely that, even at the file level, Joe didn't work on the entire file and holds no copyright interest on much of it. Maybe Files: * needs clarification. The difference between 'all' and 'any'. We should say explicitly that the copyright field is a rollup of all relevant copyright declarations for that group of files, yes. -- 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/8762zetpxh@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 08:00 +, Sune Vuorela wrote: On 2010-08-12, Lars Wirzenius l...@liw.fi wrote: * 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?. This is quite useless as long as we are making copyright files for sourcefiles. I believe debian/copyright is supposed to cover both source and binary packages, so I think your premise is invalid. However, let's assume it is valid. Even so, I don't think it is useless to have debian/copyright machine parseable, even if it does not solve all problems. Having a partial solution is already better than nothing, since it will make it easier to find the cases where manual inspection will be needed. For example, in the example you gave, it is helpful to get a list of the packages where there might be a problem, and exclude the majority of packages where there is obviously no problem with license compatibility. Without automation, manual inspection is going to be necessary for all packages, and that's a lot of work. Now, obviously there are already tools that use pattern matching and other heuristics to figure out the licenses for each package. The point of DEP-5 is to reduce the guessing, and make it easier to automate things. It will not be a complete solution, but if it gets adopted, it will help. I like the comparison with debhelper. It also does not solve the entire problem (though dh comes close), and we can't ever make it mandatory, but even so, it makes everyone's life quite a lot easier. For some people, for whatever reason, it doesn't help enough to warrant the effort to convert to it, so they don't, and that's fine, too. And I think that's just about enough from me on the topic of justifying the point of making debian/copyright machine readable. -- 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/1281721952.2017.31.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 08:04 +, Sune Vuorela wrote: On 2010-08-13, Lars Wirzenius l...@liw.fi wrote: 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 I like to offer people to try to do a DEP-5 based copyright file for e.g. src:kdebase-workspace, even the overhead from 'minimal markup' is actually ending up as quite a big thing. Here's a quick-and-dirty conversion to DEP-5, which took about an hour to do, using regular expression searchreplace, the vi . command, plus manual editing: http://files.liw.fi/dep5-long-example.txt Some statistics: originaldep5 bytes 64053 38853 words 70983363 lines 17961100 The DEP-5 version is shorter, without (I think) sacrificing precision. It saves space by avoiding repeating boilerplate text such as The full text of the GNU General Public License version 2 is available on Debian systems in /usr/share/common-licenses/GPL-2. every time the license is used for a module. Now, I admit that my DEP-5 version is a) quite dirtily created b) in need of review and c) certainly incorrect. I did not, for example, bother to fix up all lists of file specification to handle exceptions. I claim, however, that DEP-5 is not going to make it larger. The original file already had some markup, using some markup language (not sure which, but similar in spirit to resturctured text and markdown, and it might have been one of them). Also, there was something that looked like markup for lists of files. You might be able to write a script to convert from your markup to the DEP-5 one. Whether you want to do that or not is of course up to you. Whether you want to use DEP-5 or not is up to you. I don't care. To me, this idea that DEP-5 has a massive over head now a equestrian zombie. -- 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/1281726663.2017.44.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 11:39 -0400, Joey Hess wrote: However, there is a big, big problem with DEP-5, and it is named /usr/share/doc/chromium-browser/copyright. It is 1.3 mb in size (out of a 25 mb package), and completely unreadable and unusable. It appears to be machine generated, and is full of redundancies and useless information. (So I am very skeptical of claims that we should machine-generate copyright files.) It could probably be replaced by a hand-written file of about 20k. IMHO, we should not allow such unnecessarily complicated copyright files in Debian. Ouch. Yes, the chromium-browser debian/copyright file does not seem sane to me. If an automatic tool is used to generate it, it should take care to minimize the size, right now there is a lot of duplication there, and that's silly. I doubt that is fixable in DEP-5, though. If they didn't use a machine-parseable format, the could just generate a similar free-form file, with the same amount of repetition. (The root problem seems to me to be that chromium-browser is an aggregation of a large amount of code from other projects. I don't think that's a sustainable way of developing software in the long run. It might work for one project at a time, but it harms the ecosystem.) -- 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/1281727355.2017.47.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
On 2010-08-13, Lars Wirzenius l...@liw.fi wrote: Here's a quick-and-dirty conversion to DEP-5, which took about an hour to do, using regular expression searchreplace, the vi . command, plus manual editing: I'm not talking about doing conversion. I'm talking about building from scratch. I get quite quickly fed up with trying to follow a specific format when it is things this size. /Sune -- 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/slrni6b9go.rvp.nos...@sshway.ssh.pusling.com
Re: DEP-5 meta: New co-driver; current issues
On Fri, Aug 13, 2010 at 05:23:06PM +0200, Jonas Smedegaard wrote: But really If you believe it is enough to state in debian/control that the work is GPLv2, then that is just as possible using DEB5, with the following statement: Copyright: John Doe License: GPL-2 Verbatim license from source bla bla with reference to common-licenses No, this is not a complete copyright statement, you have to include the years of the copyright :-) Otherwise, I believe you're entirely correct. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100813210723.gb17...@dario.dodds.net
Re: DEP-5 meta: New co-driver; current issues
[Lars Wirzenius] * 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.) and then you say 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. So, you guys keep saying this is just like debhelper in that it won't be mandated, just something a lot of developers will adopt, aiming for enough critical mass to make it useful. You almost protest too much. But if you start talking about when it's time to approve it on debian-project, the comparison breaks down. Why does DEP-5 need to be approved? And by whom? Nobody had to discuss and approve debhelper. Because it's optional. Because nobody is forced to use it. Oddly, I'd feel better if the project drivers were _not_ trying for explicit Project approval. (A strange position, since I'm usually opposed to cabal-based decision making.) Peter -- 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/20100813233349.gb8...@p12n.org
Re: DEP-5 meta: New co-driver; current issues
Peter Samuelson pe...@p12n.org writes: But if you start talking about when it's time to approve it on debian-project, the comparison breaks down. Why does DEP-5 need to be approved? And by whom? Nobody had to discuss and approve debhelper. Because it's optional. Because nobody is forced to use it. I would read approval in this context as approval by all the people who are interested in using something like DEP-5. In other words, consensus that, should one want to do this sort of thing, this is the way in which we're going to do it, with explicit acknowledgement that some people aren't interested in doing this sort of thing at all. For example, I have packages scattered across 10 or 15 different revisions of the format right now, and I've been waiting on making them all consistent until we have a format that has reached consensus among the people discussing it and isn't going to keep changing. I'm also waiting for consensus on format before changing packages for which I'm upstream to use this format for their LICENSE files. -- 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/87aaoqoxye@windlord.stanford.edu
Re: DEP-5 meta: New co-driver; current issues
[Lars Wirzenius] * 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 Is it worth adding metadata to make it easy to extract all the acknowledgements you have to add to your advertising materials to comply with old 4-clause BSD licenses? It wouldn't benefit me, but maybe it would benefit CD vendors. Of course, I'd hope there isn't too much software in Debian anymore that still has those clauses. To people new to free software (10 years or less), see http://www.gnu.org/philosophy/bsd.html for a pretty good summary of the issue I'm talking about. Peter -- 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/20100814015911.gc8...@p12n.org
Re: DEP-5 meta: New co-driver; current issues
On pe, 2010-08-13 at 17:11 -0700, Russ Allbery wrote: I would read approval in this context as approval by all the people who are interested in using something like DEP-5. In other words, consensus that, should one want to do this sort of thing, this is the way in which we're going to do it, with explicit acknowledgement that some people aren't interested in doing this sort of thing at all. That is exactly right. -- 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/1281758868.5840.13.ca...@havelock
Re: DEP-5 meta: New co-driver; current issues
One more piece of meta: We the drivers are now using the wiki page[0] to track outstanding issues, in the interest of transparency. We'll be updating it as we go along. Further, in order to avoid having everything discussed at the same time, I think it would be good to discuss one or two things at a time. I'll raise the next topic whenever discussion dies on the previous one. Or someone else will, that's obviously fine. [0] http://wiki.debian.org/Proposals/CopyrightFormat -- 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/1281759357.5840.17.ca...@havelock
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: 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
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 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
