On Sat, Nov 17, 2007 at 04:45:53PM -0500, Yaroslav Halchenko wrote: > > On Sat, Nov 17, 2007 at 12:32:28PM -0500, Yaroslav Halchenko wrote: > > > I guess it could be of higher level since it violates a must in the > > > policy, but... > > Or maybe it is not a bug at all ... Probably you should start by > > pointing out exactly which MUST in policy you think is not covered > > here. > you must be kidding... first of all it is plain wrong:
No I'm not kidding, and you still haven't shown a MUST that has been violated, just some stylistic bloopers in the text. > Copyright: GPL > > GPL is not a copyright, it is a license Yeah, I don't exactly recall how that line got to look like that, but its hardly like anyone who actually knows what they are looking for in a copyright file is going to be terribly confused by that, and ftp-admin apparently weren't. s/Copyright:/Licence:/ is a simple typo fix though, and hardly against the spirit, or even perhaps the letter of -policy. I don't think we have an official brown paper bag policy for things like that yet. > > > Please refactor copyright file so it properly lists copyright holder(s), > > > The upstream group we pull from is listed, there is no single copyright > > holder. > if there is no single -- they all have to be listed. Where does policy say that? > grep -i -r Copyright . > in the source gives me lots of them even if I omit autotools scripts And if so, where does it say that it is ok to omit autotools scripts? That's going to be one hell of a mass bug filing if we suddenly decide to enforce that. > > I'm not aware of any requirement to explicitly re-list everyone > > where there are many copyright stakeholders in many files. > policy: <snipped> I do have a copy, please point to the precise clauses you are referring to in each case you are arguing non-compliance. > and you don't list *any* copyright holder It refers to the group responsible for the source. Who themselves only say: "There are a number of authors - just check the ChangeLog." with respect to copyright holders. > just look into copyright of other packages (pretty much any serious > package like openssh-server, apache, etc) Ok, how about this one: Linux is copyrighted by Linus Torvalds and others. Even without any autotools scripts to worry about, I'd say that's just a few names short of 'listing them all', and possibly doesn't even cover the copyright of so much as half the code ... And what do we have here in the same file, but: The Xen patch was obtained from: http://hg.et.redhat.com/kernel/linux-2.6.18-xen Which looks awfully similar to: ... downloaded from http://linuxwacom.sf.net And seems to be satisfactory indication to people who reviewed that copyright file also. Policy would seem to back this up: 12.5 ... the copyright file MUST say where the upstream sources (if any) were obtained. It SHOULD name the original authors of the package CAPS are mine, but clearly the MUST here is covered and the SHOULD seems to make reasonable allowance for just such a case as we have here. > > > brief text of license, > > They are common-licenses, we do what policy says we SHOULD. > indeed, I had some misunderstanding in my mind -- mixed up what had to > be there and what is considered to be of a good manner to the there ;-) > indeed, it seems just reference might be enough. Just the reference is explicitly recommended. If you think that is bad manner you should talk to the policy maintainers about that one. > > > Some files in the linuxwacom distribution are now covered by the LGPL, > > > the individual files are marked accordingly. > > > list those files accordingly > > Why? Who will that help? None of these files are presently intended to > > be linked to any user application, so from a binary package user point of > > view it actually makes very little or no difference whether files are GPL > > or LGPL. If you are actually going to be hacking on the code, you'll find > > the relevant detail in the files that you modify and link to. > well -- why the heck to have copyright file then at all? just add a > field in control and list a license... Actually I think something not totally unlike that is proposed for having machine parseable copyright files. > copyright file is intended to list copyright/licensing terms for shipped > material so if I need to know them I don't have to go through the code > figuring out what I could and what I couldn't link against in my > software The answer here has a simple short-circuit as I said before, mostly you can't link _any_ of this with your own software, it's just not that kind of software. You install and use it, not derive from it. If you are deriving from this you are in a totally different category to someone using a library package intended for that purpose. If there was some real confusion here, then sure we can fix it, but so far all I see is a hypothetical fish out of water. If the kernel code is GPL, it is still GPL even if it happens to have a public domain or BSD source file linked into it. That is the only distinction that users of the binary have to practically care about. If you are going to rip lines out of the code, or derive something else from it, then maybe the other licences are relevant again, but only in isolation, not as combined work. And there is almost no way the Debian copyright file alone can tell you everything you need to be sure that sort of thing is ok, you are going to have to dig deeper anyhow. Here all you have is some driver code that is GPL and some tools that are LGPL -- what does the copyright file not tell you that could possibly affect the way you use the things from this package? > > I don't see much benefit to duplication that can only go out of date and > > become misleading. > well.. not exactly -- it might be only helpful -- if license terms were > changed at some version (recall xserver/X.org split), having them > mentioned in the copyright only be of help if someone decides to go with > older license terms by taking older version What is said in the copyright file isn't going to help you here either. Either it accurately reflects the actual licence(s) or not. If someone changes the licence you are still going to have to get a version from before the change to the files you want. In this case, we have many authors over a long period of time, and constraints from things like the kernel, so we probably don't have to worry too much about it in terms of licence change madness. It's really just new files that are added and old files that are removed which will gradually tend to rot any such list maintained separately. Right now, we just need to make sure they are all still GPL or LGPL. > > If you need finer grain information than that, it too is > > available in a way most people would expect to find it. > on debian systems we are expected to find them in copyright files and > once again that is what policy says (see citing above) Where does policy say that? I only see mention of the copyright and distribution terms for the package (as a whole). If individual components are licenced differently and might reasonably be used separately under different terms, then there is clearly value in elaborating that -- but that doesn't really seem to apply here. Both LGPL and GPL say you can _use_ it however you please. Can you point me to a single derived work of this package that would be affected by the differences in their distribution terms? If policy was to imply what you suggest there would be another mass bug filing again. The kernel copyright file for starters would be short maybe as many 'sublicences' as it is short copyright holders... but all of them are effectively GPL in the combined work and that is what debian/copyright tells users. Which seems about right to me. > > If you want to submit a patch suggesting actual changes I'll certainly > > consider it, but otherwise I don't really see much here that constitutes > > an actionable bug ... > > Copyright: GPL > > is a bug on its own ;-) As I said, I don't really see much... ;) And nothing that looks like a clear policy violation. If there is real confusion, that is always good to get rid of, but I don't see much scope for it here really either. I don't see that you've actually been misled by anything you've seen ... Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
