On Sat, 13 Jun 2009 10:52:36 +0200 Josselin Mouette <joss@debian.org> wrote: ... the first positive contribution to DEP5 that I've seen in months - but then I haven't been paying a lot of attention to the bike-shedding. > currently, DEP5 is not, contrary to what the name says, about a > “machine-readable debian/copyright”. It is about providing a much > broader amount of licensing information on our source packages. > The real problem with DEP5 is not the format (which is not worse for a > small package than the current one), it is with the unrealistic amount > of information that it requires to fill and maintain. > > So, how about dropping entirely anything that’s related to files and > only keep the amount of information we are requiring now? I feel sorry > for the giant bikeshedding thread about spaces and commas, but it is not > getting us anywhere. > > > Source: foo > Authors: John Doe > Jane Toe > # Some comment > Copyright: © 2008 John Doe > © 2009 Initrode, Inc. > # Actually I don’t think we should include detailed copyright > # information, but that’s another story. If we can get a list of licences that do and do not require detailed copyright breakdowns in the binary packages, this would be solvable. Are we still waiting for confirmation on that? > License: GPL-2+ > License blurb. > > Some comments about the GPL applying to the binaries, the libraries > being MPL. > > License: MPL > MPL text. > > > It doesn’t look like too much work to switch an existing file to this > format, it could even be partly automated. > It is still human-readable. > It could reasonably be made mandatory after some time. > It brings grossly the same advantages as the current DEP5 proposal. > It doesn’t cause any problems with commas, spaces or other characters > that can appear in filenames. This looks ideal because it is a simple structure to be overlaid on existing file layouts. It is loose enough that it can reasonably apply to all packages and it can be a write-once-and-forget debian/copyright file, just as with the current one. Requiring any details of precisely which files are affected makes the whole thing impossible because that requires some form of mass-update (or at least mass check of individual files) at every upstream release. Let's just drop the whole idea for Files: - if some packages find it useful, then the Files: field can be optional but it cannot be sensible to mandate it for large upstream teams. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpAA2ezW5swo.pgp
Description: PGP signature