Re: Sponsorship requirements and copyright files
Charles Plessy wrote: [If I remember correctly, the question below is whether the law in the U.S.A. requires us to reproduce all copyright statements from the source files when we redistribute binary programs, or if this is only needed when the license expliciterly asks so.] I believe there was also a related question concerning who might be held liable for copyright infringement in the case of something dodgy making it into the archive - would it be the FTP team because they exert editorial control over the archive, would it be SPI as the umbrella organisation, or would the axe fall on the individual maintainer? Cheers, David. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
[If I remember correctly, the question below is whether the law in the U.S.A. requires us to reproduce all copyright statements from the source files when we redistribute binary programs, or if this is only needed when the license expliciterly asks so.] Le Sun, Mar 22, 2009 at 12:55:58PM -0700, Russ Allbery a écrit : Joerg Jaspert jo...@debian.org writes: Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let SPI get us some lawyers input on the question. Thats probably the best course. Yes. I'm wholeheartedly in favor of this, and I think we should hold any resolution of this discussion for the results of that. There are a surprising number of gotchas hidden in licenses that people think are straightforward and read past, and it would be nice to know what our basic legal requirements are. Dear Steve, FTP team, and everybody. The discussion was held for half a year now. Can we have an update on what is happening on the lawyer side? Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Russ Allbery wrote: Joerg Jaspert jo...@debian.org writes: Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let SPI get us some lawyers input on the question. Thats probably the best course. Yes. I'm wholeheartedly in favor of this, and I think we should hold any resolution of this discussion for the results of that. Has this happened? Did we get a reply yet? signature.asc Description: OpenPGP digital signature
Re: Sponsorship requirements and copyright files
Manoj Srivastava sriva...@debian.org writes: On Thu, Mar 26 2009, Russ Allbery wrote: One intermediate way in which I could see this specification going into Policy without it being required for anyone would be to add a subsection of the copyright section that says you are not required to use any particular format for debian/copyright, but if you *want* to use a structured format, please use this one. I can see some value in doing that without requiring the format and I think it would fit into the mandate of Policy to do so. You think policy shol recommend people use a format known to ve flawed, in draft form, and scheduled to be radically changed? No, no. Not until it's been discussed and is fairly stable. Sorry, I wasn't clear. My only point was that we can put it into Policy without making it mandatory (or even recommended unless people *want* to use a machine-parsable format). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Thu, Mar 26 2009, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: Not currently seems to imply that at some point it will be mandatory at some point. I find that somewhat presumptuous, but perhaps I am reading too much into the in this current time bit. I would put it as this is a proposal. It is not, and will not become policy, unless something improves radically. Even so, it might never become policy, and at this point a proposal in good enough shape to even start discussing the merits of the idea does not exist. When a proposal which is even maginally viable is licked into shape, it shall be brought forth to light again. And, if it is very good, it might live to see light in policy. One intermediate way in which I could see this specification going into Policy without it being required for anyone would be to add a subsection of the copyright section that says you are not required to use any particular format for debian/copyright, but if you *want* to use a structured format, please use this one. I can see some value in doing that without requiring the format and I think it would fit into the mandate of Policy to do so. You think policy shol recommend people use a format known to ve flawed, in draft form, and scheduled to be radically changed? I think this is one case where policy should instead butt out and let the format be tested and adopted by users and have the kinks worked way out before recommending something that no one actually defends using. Indeed, changing recommendations on an ongoing basis as the specification is modified, tested, and modified again would lead to people who follow policy recommendations to be using something that is deprecated, and would be the wrong thing for policy to do. Am I missing something? (It has been a long day of meetings, and the hotel bed is lumpy, and I am replying to these mails fighting bouts of insomnia) manoj -- No matter who you are, some scholar can show you the great idea you had was had by someone before you. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24 2009, Ben Finney wrote: Manoj Srivastava sriva...@debian.org writes: On Tue, Mar 24 2009, Ben Finney wrote: If the spec is being bruited under the understanding that the flaws do not matter Who's doing that? Of course the flaws matter. So answering criticism of the current spec with well, it is not going to be policy any time soon, so just urn your attention elsewhere If you got that impression, I can only say I don't think it's accurate. Try this: The machine-parseable copyright format is still in draft form and is not currently mandatory, so no-one is forced to use it. Not currently seems to imply that at some point it will be mandatory at some point. I find that somewhat presumptuous, but perhaps I am reading too much into the in this current time bit. I would put it as this is a proposal. It is not, and will not become policy, unless something improves radically. Even so, it might never become policy, and at this point a proposal in good enough shape to even start discussing the merits of the idea does not exist. When a proposal which is even maginally viable is licked into shape, it shall be brought forth to light again. And, if it is very good, it might live to see light in policy. There is nothing pre-ordained about this idea to assume it will become policy -- that happens when a whole lot of people agree that it is a good idea. Those who don't like the form it's currently in are welcome to discuss it, once the discussion moves to a forum more amenable to actually building on what is discussed. I believe this is in progress with a DEP under way. Generally, the forum for discussion development for Debian is the debian-devel mailing list. If we are having to move to some other forum, or wait around and not discuss this while something happens to a DEP, I think the DEP drivers have failed. At this point, I have spent some effort looking over the proposed solution, thinking about the issue, and coming up witht he flaws in the current proposal, and how they might be changed. I am unlikely to keep this in my working set, and once it swaps out I am unlikely to want to go through the same effort again. manoj -- Beware of a tall blond man with one black shoe. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Manoj Srivastava sriva...@debian.org writes: Not currently seems to imply that at some point it will be mandatory at some point. I find that somewhat presumptuous, but perhaps I am reading too much into the in this current time bit. I think perhaps you are. I read it only as leaving that option open; the proponents of the format should at least have the ambition of working toward a format good enough to propose as policy. I would put it as this is a proposal. It is not, and will not become policy, unless something improves radically. Would it surprise you to know that I find *that* rather presumptuous? :-) I think that a format good enough to bring consistency to the chaos of disparate ‘debian/copyright’ files would in itself be enough to propose such a format as policy. I think the current format is not far away from that state. Note that none of the above is meant to predict the format is anywhere near good enough yet to be proposed as policy; only that I can't see what would cause you to reject it in such absolute terms. Even so, it might never become policy, and at this point a proposal in good enough shape to even start discussing the merits of the idea does not exist. We evidently *have* been discussing the merits of such an idea, precisely because such a format is being actively developed. I don't understand what basis you have for your statement. When a proposal which is even maginally viable is licked into shape, it shall be brought forth to light again. And, if it is very good, it might live to see light in policy. Yes. There is nothing pre-ordained about this idea to assume it will become policy -- that happens when a whole lot of people agree that it is a good idea. Totally agreed. Those who don't like the form it's currently in are welcome to discuss it, once the discussion moves to a forum more amenable to actually building on what is discussed. I believe this is in progress with a DEP under way. Generally, the forum for discussion development for Debian is the debian-devel mailing list. If we are having to move to some other forum, or wait around and not discuss this while something happens to a DEP, I think the DEP drivers have failed. Sure. DEP 5 is now online and the drivers are, by their own account, active in their role and taking the recent discussions here into consideration. -- \ “Pleasure's a sin, and sometimes sin's a pleasure.” —“Lord” | `\ George Gordon Noel Byron, _Don Juan_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Le Thu, Mar 26, 2009 at 01:32:46AM -0500, Manoj Srivastava a écrit : Generally, the forum for discussion development for Debian is the debian-devel mailing list. If we are having to move to some other forum, or wait around and not discuss this while something happens to a DEP, I think the DEP drivers have failed. Manoj, -devel (or -project) is the right place for discussing the DEP. I have posted an answer to the comments made on -mentors by Sune and have not got any reply yet, so I suppose that people were satisfied and are now waiting for us to finish to clean and slim down the proposal. http://lists.debian.org/msgid-search/20090320092858.gd4...@kunpuu.plessy.org If your are short of time, you will save some by patienting a few more days and let us finish the rewriting. On the other hand, if you want to help us, your propositions are of course welcome. Can you summarise them ? -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Manoj Srivastava sriva...@debian.org writes: Not currently seems to imply that at some point it will be mandatory at some point. I find that somewhat presumptuous, but perhaps I am reading too much into the in this current time bit. I would put it as this is a proposal. It is not, and will not become policy, unless something improves radically. Even so, it might never become policy, and at this point a proposal in good enough shape to even start discussing the merits of the idea does not exist. When a proposal which is even maginally viable is licked into shape, it shall be brought forth to light again. And, if it is very good, it might live to see light in policy. One intermediate way in which I could see this specification going into Policy without it being required for anyone would be to add a subsection of the copyright section that says you are not required to use any particular format for debian/copyright, but if you *want* to use a structured format, please use this one. I can see some value in doing that without requiring the format and I think it would fit into the mandate of Policy to do so. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
ti, 2009-03-24 kello 17:50 -0500, Manoj Srivastava kirjoitti: I am expressing my opinion now, on a mailing list devoted to debian development. I have not been keeping up witht eh bureaucratic rigmarole that seems to be being wrapped around discussions, not after we got the notice that there was a topic to be discussed, but we should not discuss it since the red-tape software was broken. It's not very clearly written into DEP0, but it was always my intention, I and think Zack's and Dato's (that is, the people who came up with DEP in the first place), that the DEP process should introduce very low levels of bureucracy, and that _all_ the bureaucracy would be handled by the drivers. Indeed, as far as anyone else is concerned, the DEP might not even exist. Whoever is drafting the draft ought to be paying attention to the feedback being generated now, and create a better draft to start with. I fully concur. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
ke, 2009-03-25 kello 01:32 +, Noah Slater kirjoitti: On Wed, Mar 25, 2009 at 12:39:46AM +, Steve McIntyre wrote: I'm curious... What do you think *is* the Debian way of doing things like this ? Manoj's email strongly implied that a DEP was needless bureaucracy. I'm hardly likely to argue with you about what constitutes the Debian way, but considering we've let a proposal stew on a wiki for over a year, have taken some discussion over to the mailing list and are now working on a DEP, I find it very confusing that it should be considered that we are somehow abusing the process. Speaking as one of the drivers of DEP0, I think you are misunderstanding how DEPs should be driven. They should not be used to control the discussion. They are, very fundamentally, a way to record consensus and the state of the discussion. As a by-product, they hopefully produce a document that will be useful later. If the people participating in a discussion have to be aware that something is discussed as part of a DEP, and have to adjust their behavior accordingly, the drivers have failed. (Also, DEPs are hardly the established Debian way of doing things. There's only two accepted ones, and only six ones ever registered, counting DEP0 itself. I hope that DEPs will some day be accepted, but they won't be, if it's OK to use them as hitting implements.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Wed, Mar 25 2009, Lars Wirzenius wrote: ke, 2009-03-25 kello 01:32 +, Noah Slater kirjoitti: On Wed, Mar 25, 2009 at 12:39:46AM +, Steve McIntyre wrote: I'm curious... What do you think *is* the Debian way of doing things like this ? Manoj's email strongly implied that a DEP was needless bureaucracy. The recent memoranda about DEPs did lead me to believe that. However ... I'm hardly likely to argue with you about what constitutes the Debian way, but considering we've let a proposal stew on a wiki for over a year, have taken some discussion over to the mailing list and are now working on a DEP, I find it very confusing that it should be considered that we are somehow abusing the process. Speaking as one of the drivers of DEP0, I think you are misunderstanding how DEPs should be driven. They should not be used to control the discussion. They are, very fundamentally, a way to record consensus and the state of the discussion. As a by-product, they hopefully produce a document that will be useful later. If the people participating in a discussion have to be aware that something is discussed as part of a DEP, and have to adjust their behavior accordingly, the drivers have failed. This paragraph, and this one It's not very clearly written into DEP0, but it was always my intention, I and think Zack's and Dato's (that is, the people who came up with DEP in the first place), that the DEP process should introduce very low levels of bureucracy, and that _all_ the bureaucracy would be handled by the drivers. Indeed, as far as anyone else is concerned, the DEP might not even exist. make me view a DEP far more favourably. Using a process to track discussion, which does not impede said discussion, can only be positive. (Also, DEPs are hardly the established Debian way of doing things. There's only two accepted ones, and only six ones ever registered, counting DEP0 itself. I hope that DEPs will some day be accepted, but they won't be, if it's OK to use them as hitting implements.) +1 manoj -- The truth is rarely pure, and never simple. Oscar Wilde Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 12:55:58PM -0700, Russ Allbery wrote: Well, the one thing that I think we need to clarify here is whether we need to list the licenses for files that aren't source code for what goes into the binary distribution, such as the build system. The files from Autoconf and Automake have a bunch of different licenses and documenting them is a fair bit of work for each package. Actually, thinking about it for a little while, I think we're all missing the point. Who cares that file foo.c is licensed under GPL and bar.c under BSD? People that want to take the source and use it elsewhere. These people are obviously looking at the sources, and don't really need debian/copyright information. But on the other hand, what are people looking at debian/copyright probably expecting? (and all the use cases for a machine parseable format I've seen quoted so far do respect this rule) Licensing terms for the *binary* files. They don't care that file foo.c is licensed under GPL and bar.c under BSD, they care that libfoo.so is licensed under GPL and libbar.so under BSD, or that libfoobar.so is under GPL/BSD, foo.h under GPL and bar.h under BSD... Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:00:34PM +0100, Arthur de Jong wrote: On Sun, 2009-03-22 at 12:11 +, Noah Slater wrote: Firmly in my mind is the cost/benefit of this extra effort. If we succeed in integrating debian/copyright checks into lintian, or dpkg and it's front-ends, it seems reasonable to imagine that this effort would be a good trade-off. I have been reading this discussion a bit and I've been wondering what use-case you actually have for machine-readable debian/copyright files. This is quite different than having the *license terms* recorded in a machine-parseable format, which is potentially useful in lots of ways; e.g., license solvers, letting open source-friendly companies get a broad overview of what they're getting into when they consider deriving, and so on. http://lists.debian.org/debian-devel/2009/03/msg01116.html I'll add to this that there are various tools out there capable of reporting on the license status of works. HP has a project that's doing this, and there's also the 'licensecheck' tool in devscripts that can give you what it thinks are the licenses for the files in your package. Those are each useful in their own right; but combined with a machine-parseable copyright format, we have potential for scalable reporting about *discrepancies* between what the automatic tools say and what the maintainer has asserted in debian/copyright, making it much easier to identify possible bugs (wishlist, serious, or otherwise) in one or the other. Please don't reply with arguments why this isn't enough reason to make maintainers do extra work. I'm not trying to make any maintainers do extra work; I'm pointing out reasons why having a consistent and machine-parseable copyright format is useful, which is the question that was asked. That benefit is there even if only a subset of maintainers opt to use a machine-parseable format; but given that there is interest in having such a format, it's important that we come to some agreement on what that format should be, so that we don't have a dozen incompatible formats running around. That's what we should be working on. This thread with people refusing to use a parseable format for debian/copyright, and arguing about whether using the format does or does not provide assurances about the copyright status of a work, is all an irrelevant (and irritating) distraction. This means that if you want to introduce a new format you have to convince the maintainer of a package that there is some benefit, be it in tools that make their life easier or some concrete benefit for our users. Not really. There is currently no format specified for debian/copyright, only content. That means maintainers can use whatever format they want; if a number of maintainers choose to use a common and machine-parseable format, they can do that without having to persuade anyone else of its utility. On Mon, Mar 23, 2009 at 10:56:57PM +0100, Arthur de Jong wrote: The problem is that I don't see much use for a machine-parsable format though at this point. Firstly (and most importantly for me), there are no tools to support it so there is no immediate benefit (except the improvement in readability). Of course there aren't. Why spend time writing tools yet, when people keep changing the format definition itself? Once there's a stable spec that has a measure of consensus surrounding it, instead of a wiki page that someone takes the liberty of rewriting every month or two, that's when I would expect to see adoption of the format by more folks writing tools. BTW, the use-case where you don't want to install FDL content and have some way for apt to warn you before doing so won't be solved by a new format because debian/copyright is written at the source-level and not on the binary package level (think -doc packages that have FDL stuff and -bin packages that have other-licensed stuff). (not that I've given this too much thought) Well, aside from the section header, nothing in Debian Policy actually says you need to have a per-source debian/copyright file; and you certainly can have separate per-binary copyright files in your package that get installed individually if you choose, there's nothing that prevents you from doing that even though it's clearly not common practice 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Mike Hommey m...@glandium.org wrote: Hi, Who cares that file foo.c is licensed under GPL and bar.c under BSD? People that want to take the source and use it elsewhere. These people are obviously looking at the sources, and don't really need debian/copyright information. Let's add that if you are reusing code, you have to do your own assessment anyway. Of course you can decide to trust debian/copyright, but there's no guarantee and you're taking the risk. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, 24 Mar 2009 07:37:48 +0100 Mike Hommey m...@glandium.org wrote: On Sun, Mar 22, 2009 at 12:55:58PM -0700, Russ Allbery wrote: Well, the one thing that I think we need to clarify here is whether we need to list the licenses for files that aren't source code for what goes into the binary distribution, such as the build system. The files from Autoconf and Automake have a bunch of different licenses and documenting them is a fair bit of work for each package. Actually, thinking about it for a little while, I think we're all missing the point. Who cares that file foo.c is licensed under GPL and bar.c under BSD? Only if foo.c is compiled into libfoo and bar into an application called bar - i.e. separate compiled objects like plugins or multiple libraries per package. There is nothing in debian/copyright to help with that decision (nor should there be, before anyone suggests it, because that doesn't scale either). People that want to take the source and use it elsewhere. These people are obviously looking at the sources, and don't really need debian/copyright information. Agreed. But on the other hand, what are people looking at debian/copyright probably expecting? (and all the use cases for a machine parseable format I've seen quoted so far do respect this rule) Licensing terms for the *binary* files. They don't care that file foo.c is licensed under GPL and bar.c under BSD, they care that libfoo.so is licensed under GPL and libbar.so under BSD, or that libfoobar.so is under GPL/BSD, foo.h under GPL and bar.h under BSD... Exactly - but that is what debian/copyright does not provide and by basing the proposed format on source files, there is nothing to gain there either. Identifying the licence of individual binary components of a package requires detailed knowledge of the build systems - most packages are relatively clean and try to keep one component to one sub-directory but there are frequent cases of AM_CFLAGS having -I../../foo/ and LD_FLAGS having -L../../foo/libfoo.la - correlating all those in even a medium sized package would be a horrible burden - and, again, those linkages can change more frequently than the licences themselves, especially in the case of how an application links against private libraries where there are no transitions to worry about. As with discussions about the source code listings, this simply does not scale. I could pick out the dependencies in an autotools package because I'm familiar with autotools, but it would be much harder to identify what was going on in Scons or CMake or other systems. I fail to see any development use case for parsing debian/copyright that does not inevitably lead to a detailed study of the source code in order to actually make any real-life decision to do with whether to use a particular package as a dependency of my own code - at which point debian/copyright becomes irrelevant anyway. The licence is always only one part of such a decision process - if the functionality is not appropriate, it is better to use a different library with a different licence, as long as the licences are strictly compatible. Vague ideas about users being extra-picky about the licences of packages that they install from main seem completely impractical and the likelihood of ever being able to convert Debian into GNewSense simply by choosing licences at install time is unreasonably slim IMHO. Principally this is because the existing licence information relates to the source code, not the binaries and converting it to apply to binaries is not scalable to Debian or particularly useful to upstream developers. Even lintian tests for licence incompatibilities are going to be very hard to make reliable because lintian isn't going to know which source files were compiled into which objects. Having a hotlist of libraries that may require exceptions to be added to the GPL etc. is not particularly easy to implement and would rely on objdump, not debian/copyright. Are we getting to the point of considering debian/copyright is largely irrelevant to development/users and only really applies to distribution of the binaries? If so, the sole arbiter of what goes into debian/copyright should be ftp-master because it is only actions based on distribution that have any real relevance to the contents of the file and those considerations should be solely driven by the requirements of the licence(s). I must admit, when I'm doing upstream work and looking for libraries that I can use to assist me, I have never ONCE looked at debian/copyright for those packages - I have always gone to the upstream source code. Each debian/copyright file I've written has been written with the objective of meeting the requirements of ftp-master and without any consideration of those who want to use the package in development of other code, simply because I don't consider it wise to base such decisions on debian/copyright and would be very surprised if any other
Re: Sponsorship requirements and copyright files
On Tue, 24 Mar 2009 09:18:41 + Neil Williams codeh...@debian.org wrote: There is nothing in debian/copyright to help with that decision (nor should there be, before anyone suggests it, because that doesn't scale either). Actually, I'm reconsidering that a bit - separate copyright files for separate binary packages could be good for various reasons, unrelated to the format of the files themselves. I must admit, I hadn't considered that option - I was assuming all along that there would only be one debian/copyright file and that it would remain tied to the source package. It could be good to split a 48kb copyright file into a number of smaller files. (libx11-data has a 48kb copyright file) Identifying the licence of individual binary components of a package requires detailed knowledge of the build systems - most packages are relatively clean and try to keep one component to one sub-directory but there are frequent cases of AM_CFLAGS having -I../../foo/ and LD_FLAGS having -L../../foo/libfoo.la - correlating all those in even a medium sized package would be a horrible burden - and, again, those linkages can change more frequently than the licences themselves, especially in the case of how an application links against private libraries where there are no transitions to worry about. As with discussions about the source code listings, this simply does not scale. That still applies though - some packages would have severe problems implementing copyright files for specific binary packages. Are we getting to the point of considering debian/copyright is largely irrelevant to development/users and only really applies to distribution of the binaries? If so, the sole arbiter of what goes into debian/copyright should be ftp-master because it is only actions based on distribution that have any real relevance to the contents of the file and those considerations should be solely driven by the requirements of the licence(s). I must admit, when I'm doing upstream work and looking for libraries that I can use to assist me, I have never ONCE looked at debian/copyright for those packages - I have always gone to the upstream source code. Each debian/copyright file I've written has been written with the objective of meeting the requirements of ftp-master and without any consideration of those who want to use the package in development of other code, simply because I don't consider it wise to base such decisions on debian/copyright and would be very surprised if any other upstream developers would disagree. When I talk about readability of debian/copyright, I'm thinking solely of my work as a sponsor where I have to check that the file is (in my estimation) going to meet the requirements of ftp-master when I finally upload the package to NEW. So far, this thread has failed to identify a single real-world use case for debian/copyright that is not solely the remit of ftp-master. (or people in a similar position who need to distribute parts of Debian) Unless ftp-master want a particular format, I'm not sure that there is any point choosing one version over another beyond human readability. I just want to be able to read debian/copyright in packages that I offer to sponsor and be sure that I can understand it and that I can satisfy myself that it will be OK for ftp-master. In that respect, I still consider the later revisions of the format to be unhelpful and I won't be using it or recommending it. If, when sponsoring, I find any debian/copyright file that I cannot read or understand, I will require changes to the file whether that breaks the format or not, until I'm happy that the file contains all information likely to be necessary for ftp-master. As far as the format goes, that still stands - the use of per-binary copyright files is (or can be) distinct from the format of those files. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpqupE4jnHgJ.pgp Description: PGP signature
Re: Sponsorship requirements and copyright files
On Tue, 24 Mar 2009 00:43:48 -0700 Steve Langasek vor...@debian.org wrote: I have been reading this discussion a bit and I've been wondering what use-case you actually have for machine-readable debian/copyright files. This is quite different than having the *license terms* recorded in a machine-parseable format, which is potentially useful in lots of ways; The format would still need to match source code licence terms with compiled objects that could include a variety of source files and have to deal with changes in the linkages within a package that can change during the lifetime of a package? There is no permanent/reliable link between the licence of a source code file and the licence of a specific compiled binary from the final package, only with the collection of source code and the collection of binaries. Even within a single .deb it might not be possible to identify exactly which licences apply if the source package builds lots of variant binary packages. Also, runtime information can be checked for some simple .deb packages on the basis of all that the package contains but development information about which licence applies to the source code someone copies and pastes from the source package are entirely separate. Other issues affect packages that build twice with different options to ./configure that may or may not omit certain source code files from one or other build. If I have a modular source package that can enable or disable various build options and various components and some of those components have differing licences, it becomes very hard to track subtle changes between builds that may or may not result in source code under licence A being compiled into binary bar in some circumstances but not in others. Individual versions of a package must build the same way on each architecture but subsequent versions can change, making it hard for the maintainer to track what is going on. If such a modular source package (foo) builds a number of different binary packages, how is the checker to know whether binary package bar, linking against libfoo-with-baz is any different to linking against libfoo-without-baz other than relying on the package names? Licence incompatibilities between source packages are not the issue, AFAICT, if only because the offending source code might not actually be being compiled; incompatible licences between binaries linked at runtime are the problem. I'm not sure that any proposed format of debian/copyright would allow a checker to be at all certain that a particular .so from package foo has a compatible licence with a particular .so from package bar where both foo and bar include multiple libraries, multiple binaries and multiple linkages at build time. (debian/libfoo.copyright is a separate idea with different problems, see later.) Yes, the checker might be able to say that source package foo contains code under licence A and source package bar contains code under licence B and that a certain conflict might result but whether that is a real problem or not still depends on exactly how the relevant code is compiled and linked - something that can change much more frequently than the licences themselves. This is the problem with licensecheck - it relies on the source and cannot hope to understand how the source becomes a binary. I fear that such a checker would be very misleading and cause unnecessary work dealing with the 'bugs' that could result. (relocating from the end of Steve's message) Well, aside from the section header, nothing in Debian Policy actually says you need to have a per-source debian/copyright file; and you certainly can have separate per-binary copyright files in your package that get installed individually if you choose, there's nothing that prevents you from doing that even though it's clearly not common practice today. Can't help thinking that the packages that would benefit from debian/libfoo.copyright are the very ones where maintaining that file will make the idea rather unappealing due to the issues above. However, it is something I hadn't considered and there could be some mileage in that for some packages, especially those with different licences for the API documentation. It could make the main debian/copyright file much cleaner and easier to read for a small number of packages. I'm still not convinced that machine-parseable formats are genuinely useful or maintainable and I feel that machine-parseable requirements inevitably impair human readability of copyright files. That's not a win, AFAICT. Please don't reply with arguments why this isn't enough reason to make maintainers do extra work. I'm not trying to make any maintainers do extra work; I'm pointing out reasons why having a consistent and machine-parseable copyright format is useful, which is the question that was asked. That benefit is there even if only a subset of maintainers opt to use a machine-parseable format; but given that there is
Re: Sponsorship requirements and copyright files
Giacomo A. Catenazzi wrote: Joerg Jaspert wrote: The real problem here is that FTP masters require the list of copyright holders to be up-to-date each time the package goes through NEW. Whatever justification exists for this requirement, I???m starting to find it unacceptable. If a package has to go through NEW, it takes about twice as much time to update this list than to do the actual packaging work. Why is this list needed? Often the license requires it. For instance the BSD license says, Redistributions in binary form must reproduce the above copyright. *binary* But we do distribute binaries in the debs - and debian/copyright is not only for the source but also ends up in the deb. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Rene Engelhard wrote: Giacomo A. Catenazzi wrote: Joerg Jaspert wrote: The real problem here is that FTP masters require the list of copyright holders to be up-to-date each time the package goes through NEW. Whatever justification exists for this requirement, I???m starting to find it unacceptable. If a package has to go through NEW, it takes about twice as much time to update this list than to do the actual packaging work. Why is this list needed? Often the license requires it. For instance the BSD license says, Redistributions in binary form must reproduce the above copyright. *binary* But we do distribute binaries in the debs - and debian/copyright is not only for the source but also ends up in the deb. Yes, or better debian/copyright is *only* for the binary [1]. The sources have the original license files and all legal notices in the right place. Debian source format don't allow to remove legal notices (but recreating the orig.tar). Note: a insane developer could remove it in diff, but the original notice is still distributed in the orig.tar. The point was: we are mixing sources requirements (the part you did not quoted) with binary requirement (the quoted part). [1] Note: I did not write the license of binary. It is fine to document all sources licenses, as an additional information for the *binary*, but sources-only requirements are not necessary in binary packages. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 10:38:47AM +, Neil Williams wrote: I'm still not convinced that machine-parseable formats are genuinely useful or maintainable and I feel that machine-parseable requirements inevitably impair human readability of copyright files. That's not a win, AFAICT. Don't use it then, I guess. As Steve pointed out, we're working an a format that people can use voluntarily if they wish. We are not suggesting that this format become mandatory at this stage, at least not until it had seen widespread adoption. As someone who's been maintaining several packages with this format for over a year, I am pleased to tell you that I find it very useful and easily maintainable. YMMV, of course. Is it really useful to have only a subset of packages using the format? Isn't only going to be the small packages that have no particular licence problems that would adopt it because it's almost trivial to do so? Unless maintainers of complex packages or packages where licence problems are likely (those that need exceptions added to the GPL etc.) can implement the format cleanly, is there really any benefit? You are using the Nirvana Fallacy in your argument. Even if only one person finds the format helpful, there has been benefit. For every additional person who finds this format helpful, even more benefit is had, and each packages shares a consistent, readable, and parseable structure. There are elements of the format that aid human readability but making the format completely machine-parseable means making allowances for so many ifs and buts that the copyright files become only readable by machine. Of course, this is not true. What a peculiar thing to say. The format proposal follows debian/control, and is quite simple in structure. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Neil Williams codeh...@debian.org writes: Is it really useful to have only a subset of packages using the format? Isn't only going to be the small packages that have no particular licence problems that would adopt it because it's almost trivial to do so? Unless maintainers of complex packages or packages where licence problems are likely (those that need exceptions added to the GPL etc.) can implement the format cleanly, is there really any benefit? Let's try it and find out. -- \ “If nothing changes, everything will remain the same.” —Barne's | `\ Law | _o__) | Ben Finney pgp2Zf7ktYiF4.pgp Description: PGP signature
Re: Sponsorship requirements and copyright files
On Sun, Mar 22 2009, Russ Allbery wrote: Neil Williams codeh...@debian.org writes: We also need clarity on why debian/copyright should have a higher level of scrutiny than the upstream itself. Debian does not hold copyright on most upstream source packages, why do we second-guess upstream teams? It's worth noting here that most upstreams distribute only source, and hence rely on the fact that the source carries the licenes and the copyright statement and they don't have to do anything special with it. When we compile that software and distribute only the binaries as a separate package, we've stripped off, say, a BSD license statement and its corresponding copyright statement from where upstream put it, and we do, under the license, have to preserve that somewhere in our derived work, including the corresponding copyright notice. If upstream has a bunch of files under various varients of the BSD license, we are required by those licenses to preserve all of those notices in the binary package. This much is a very valid point which I was vaguely aware of but hadn't really thought about before this thread. , | 2. Redistributions in binary form must reproduce the above copyright |notice, this list of conditions and the following disclaimer in the |documentation and/or other materials provided with the distribution. ` Do we ever distribute just the binary on our archives? That would be illegal, yes. But, if in the *other materials* we distribute is the source tar ball, we a re all OK. I think we have source areas of the archive, we have source CD iso's, we provide ways to get said other materials via apt-get source, and so we are all covered. There is not real reason to add all that into debian/copyright just to cater to the BSD license excerpted above. manoj -- It is impossible to defend perfectly against the attack of those who want to die. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Manoj Srivastava wrote: On Sun, Mar 22 2009, Russ Allbery wrote: Neil Williams codeh...@debian.org writes: We also need clarity on why debian/copyright should have a higher level of scrutiny than the upstream itself. Debian does not hold copyright on most upstream source packages, why do we second-guess upstream teams? It's worth noting here that most upstreams distribute only source, and hence rely on the fact that the source carries the licenes and the copyright statement and they don't have to do anything special with it. When we compile that software and distribute only the binaries as a separate package, we've stripped off, say, a BSD license statement and its corresponding copyright statement from where upstream put it, and we do, under the license, have to preserve that somewhere in our derived work, including the corresponding copyright notice. If upstream has a bunch of files under various varients of the BSD license, we are required by those licenses to preserve all of those notices in the binary package. This much is a very valid point which I was vaguely aware of but hadn't really thought about before this thread. , | 2. Redistributions in binary form must reproduce the above copyright |notice, this list of conditions and the following disclaimer in the |documentation and/or other materials provided with the distribution. ` Do we ever distribute just the binary on our archives? That would be illegal, yes. But, if in the *other materials* we distribute is the source tar ball, we a re all OK. I think we have source areas of the archive, we have source CD iso's, we provide ways to get said other materials via apt-get source, and so we are all covered. There is not real reason to add all that into debian/copyright just to cater to the BSD license excerpted above. And even if it was, there are binary packages whose /usr/share/doc/$pkg is a symlink, so they have no copyright. Which is another reason why we don't it, at least in the general case. Emilio signature.asc Description: OpenPGP digital signature
Re: Sponsorship requirements and copyright files
Manoj Srivastava sriva...@debian.org writes: , | 2. Redistributions in binary form must reproduce the above copyright |notice, this list of conditions and the following disclaimer in the |documentation and/or other materials provided with the distribution. ` Do we ever distribute just the binary on our archives? That would be illegal, yes. But, if in the *other materials* we distribute is the source tar ball, we a re all OK. Are we allowed to consider the source package materials we provide with the distribution? I was under the impression that we were not. (The GPL requirement, which I know we do satisfy, is somewhat weaker.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Emilio Pozuelo Monfort po...@ubuntu.com writes: And even if it was, there are binary packages whose /usr/share/doc/$pkg is a symlink, so they have no copyright. All such binaries have a hard dependency on a package that does include copyright, but that's a good point. I don't know if legally that hard dependency is stronger than the co-distribution of source packages in the same archive area. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 11:47:37AM +0100, Rene Engelhard wrote: Giacomo A. Catenazzi wrote: Joerg Jaspert wrote: The real problem here is that FTP masters require the list of copyright holders to be up-to-date each time the package goes through NEW. Whatever justification exists for this requirement, I???m starting to find it unacceptable. If a package has to go through NEW, it takes about twice as much time to update this list than to do the actual packaging work. Why is this list needed? Often the license requires it. For instance the BSD license says, Redistributions in binary form must reproduce the above copyright. *binary* But we do distribute binaries in the debs - and debian/copyright is not only for the source but also ends up in the deb. Actually, Policy does not make mandatory for the .deb file to contain a copyright file at all: `/usr/share/doc/package' may be a symbolic link to another directory in `/usr/share/doc' only if the two packages both come from the same source and the first package Depends on the second.[2] (I am not a fan of this particular paragraph of Policy, but that is irrelevant, and there is a number of packages taking advantage of that) Policy also allows package to refer to /usr/share/common-licenses (part of base-files) for actual license texts (for a limited set of license). So we already allow packages to reference other packages for license informations. Binary package referencing its source package for detailed license information is not quite a stretch. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 01:32:40PM -0700, Russ Allbery wrote: Emilio Pozuelo Monfort po...@ubuntu.com writes: And even if it was, there are binary packages whose /usr/share/doc/$pkg is a symlink, so they have no copyright. All such binaries have a hard dependency on a package that does include copyright, but that's a good point. And all such symlinks are on another binary from the same source. (see policy 12.3) stew signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 09:19:36PM +0100, Bill Allombert wrote: But we do distribute binaries in the debs - and debian/copyright is not only for the source but also ends up in the deb. Actually, Policy does not make mandatory for the .deb file to contain a copyright file at all: `/usr/share/doc/package' may be a symbolic link to another directory in `/usr/share/doc' only if the two packages both come from the same source and the first package Depends on the second.[2] (I am not a fan of this particular paragraph of Policy, but that is irrelevant, and there is a number of packages taking advantage of that) Policy also allows package to refer to /usr/share/common-licenses (part of base-files) for actual license texts (for a limited set of license). So we already allow packages to reference other packages for license informations. Binary package referencing its source package for detailed license information is not quite a stretch. There are some material differences that we should be sure of before blessing such a change in policy. So far, the exceptions preserve the invariant that if the package is installed, the license is present in /usr/share/doc/package/copyright or in a file referenced by that file. If we allow the license for our binary packages to be shipped in the source only, then: - Users who receive Debian preinstalled from the manufacturer will not have a copy of the license. - Users who receive Debian as binary-only media with an offer to provide source upon request will not have a copy of the license. - There will be a greater number of exceptions to the rule regarding what must be included in debian/copyright (since there are some licenses that do require specific information shipped with the binaries, and some that don't), bringing an increased risk of bugs. -- 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24 2009, Noah Slater wrote: On Tue, Mar 24, 2009 at 10:38:47AM +, Neil Williams wrote: I'm still not convinced that machine-parseable formats are genuinely useful or maintainable and I feel that machine-parseable requirements inevitably impair human readability of copyright files. That's not a win, AFAICT. Don't use it then, I guess. As Steve pointed out, we're working an a format that people can use voluntarily if they wish. We are not suggesting that this format become mandatory at this stage, at least not until it had seen widespread adoption. At this stage? If you are not willing to listen to feedback, that had better be never. If the intent is for this to be broadly adopted, the specification should be fixed as early as possible, and we should not adopt a flawed specification inder the guise that it is currently voluntary. Frankly, I think that the spec should have optional parts, and parts we need, and we should try to come to an consensus on the required part of the spec, and the optional parts should be clearly outlined in the specification. Even if only one person finds the format helpful, there has been benefit. For every additional person who finds this format helpful, even more benefit is had, and each packages shares a consistent, readable, and parseable structure. Nice sound bite. But a spec or a standard's big value comes if it is fixed to be widely accepted, even if it means that some parts of the standard are optional. manoj -- Westheimer's Discovery: A couple of months in the laboratory can frequently save a couple of hours in the library. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24 2009, Russ Allbery wrote: Manoj Srivastava sriva...@debian.org writes: , | 2. Redistributions in binary form must reproduce the above copyright |notice, this list of conditions and the following disclaimer in the |documentation and/or other materials provided with the distribution. ` Do we ever distribute just the binary on our archives? That would be illegal, yes. But, if in the *other materials* we distribute is the source tar ball, we a re all OK. Are we allowed to consider the source package materials we provide with the distribution? I was under the impression that we were not. (The GPL requirement, which I know we do satisfy, is somewhat weaker.) Debian can. But that is not being very nice to people who preinstall debian on machines, or who just distribute the binary CD's only. So, I am not opposed to people adding whatever they want to to the copyright file, but it is not, I think, a _requirement_ that we do so. We may want to do so to be nice to a subset of our downstream. There is a trade off involved in this trying to be nice to some downstreams and the time it takes away from working on actual problems in the package that affect _all_ downstream users. I'm happy to let my peer DD's determine where the line ought to be drawn for their packages. Also, I think if we are packaging something an upstream provides in binary form as well, we cna just look at what the binary package contains in terms of a copyright notice for a guideline. manoj -- The worst part of having success is trying to find someone who is happy for you. Bette Midler Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 04:26:43PM -0500, Manoj Srivastava wrote: At this stage? If you are not willing to listen to feedback, that had better be never. If the intent is for this to be broadly adopted, the specification should be fixed as early as possible, and we should not adopt a flawed specification inder the guise that it is currently voluntary. Frankly, I think that the spec should have optional parts, and parts we need, and we should try to come to an consensus on the required part of the spec, and the optional parts should be clearly outlined in the specification. We have been listening to feedback and commentary on the draft proposal for over a year now, responding and modifying things as appropriate. That process broke down some time ago, so we have opened dialogues on various mailing lists, and we are starting DEP 5 to gather feedback. Nice sound bite. But a spec or a standard's big value comes if it is fixed to be widely accepted, even if it means that some parts of the standard are optional. I hope that you will contribute your opinion when DEP 5 has a draft to review. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24 2009, Noah Slater wrote: Nice sound bite. But a spec or a standard's big value comes if it is fixed to be widely accepted, even if it means that some parts of the standard are optional. I hope that you will contribute your opinion when DEP 5 has a draft to review. I am expressing my opinion now, on a mailing list devoted to debian development. I have not been keeping up witht eh bureaucratic rigmarole that seems to be being wrapped around discussions, not after we got the notice that there was a topic to be discussed, but we should not discuss it since the red-tape software was broken. Whoever is drafting the draft ought to be paying attention to the feedback being generated now, and create a better draft to start with. manoj -- New Hampshire law forbids you to tap your feet, nod your head, or in any way keep time to the music in a tavern, restaurant, or cafe. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: So we already allow packages to reference other packages for license informations. With the important requirement that the referenced package that contains the license information must also be installed on every system where the referring package is installed (because of a ‘Depends’ relationship). Binary package referencing its source package for detailed license information is not quite a stretch. Since this loses the above relationship, it's a stretch too far. I consider it vital that *every* recipient of the package can easily find out the license terms, and that's best satisfied by having them installed as a predictably-located file along with the package in every instance. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but what if the hippopotamus won't wear the beach | _o__) thong?” —_Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24, 2009 at 05:50:26PM -0500, Manoj Srivastava wrote: I am expressing my opinion now, on a mailing list devoted to debian development. I have not been keeping up witht eh bureaucratic rigmarole that seems to be being wrapped around discussions, not after we got the notice that there was a topic to be discussed, but we should not discuss it since the red-tape software was broken. You used to be project secretary, and I am only a humble new maintainer. Seems a bit weird to be criticising the Debian way of doing things like this. Whoever is drafting the draft ought to be paying attention to the feedback being generated now, and create a better draft to start with. Of course we are. :) -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Manoj Srivastava sriva...@debian.org writes: At this stage? If you are not willing to listen to feedback, that had better be never. Feedback on the machine-parseable copyright specification is openly solicited (though it is currently inefficiently gathered and processed, and that needs to be addressed) and has driven the entire formation of the specification to date. If the intent is for this to be broadly adopted, the specification should be fixed as early as possible, and we should not adopt a flawed specification inder the guise that it is currently voluntary. I don't see what you're saying with this. Are you saying that it should not be adopted by *anyone* to see how it works, until it becomes mandatory? Or is there some specific “we” you're thinking of? Surely it's necessary for the specification to actually be implemented in various real circumstances (which I can only see as meeting the definition of “adopted” by those who choose to use it), to find and fix the wrinkles *before* making it mandatory. Frankly, I think that the spec should have optional parts, and parts we need, and we should try to come to an consensus on the required part of the spec, and the optional parts should be clearly outlined in the specification. Yes. I don't know anyone interested in this specification who has proposed otherwise. -- \ “I have had a perfectly wonderful evening, but this wasn't it.” | `\ —Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24 2009, Noah Slater wrote: On Tue, Mar 24, 2009 at 05:50:26PM -0500, Manoj Srivastava wrote: I am expressing my opinion now, on a mailing list devoted to debian development. I have not been keeping up witht eh bureaucratic rigmarole that seems to be being wrapped around discussions, not after we got the notice that there was a topic to be discussed, but we should not discuss it since the red-tape software was broken. You used to be project secretary, and I am only a humble new maintainer. Seems a bit weird to be criticising the Debian way of doing things like this. Oh, yes; you obviously know far better than I the Debian way of doing this. And it happens to be *not* discussing it on debian-devel? manoj -- union, n.: A dues-paying club workers wield to strike management. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Tue, Mar 24 2009, Ben Finney wrote: Manoj Srivastava sriva...@debian.org writes: At this stage? If you are not willing to listen to feedback, that had better be never. Feedback on the machine-parseable copyright specification is openly solicited (though it is currently inefficiently gathered and processed, and that needs to be addressed) and has driven the entire formation of the specification to date. If the intent is for this to be broadly adopted, the specification should be fixed as early as possible, and we should not adopt a flawed specification inder the guise that it is currently voluntary. I don't see what you're saying with this. Are you saying that it should not be adopted by *anyone* to see how it works, until it becomes mandatory? Or is there some specific “we” you're thinking of? If the spec is being bruited under the understanding that the flaws do not matter, only people who like it will adopt it, flaws and all, and at some later date it shall be made into policy (by somehow magically getting widely adopted), there is a logc flaw in there somewhere. So answering criticism of the current spec with well, it is not going to be policy any time soon, so just urn your attention elsewhere seems a little --- suboptimal. If that is not the intent, why answer criticisms of the unviability of the current mechanism with Oh, it is not going to be policy anytime soon? Surely it's necessary for the specification to actually be implemented in various real circumstances (which I can only see as meeting the definition of “adopted” by those who choose to use it), to find and fix the wrinkles *before* making it mandatory. There are wrinkles being pointed out already. One deas not need to eat the egg to know it is rotten. Ignoring what people are pointing out as major drawbacks, or dismissing these issues with well, you don't have to adopt it then rather than trying to fix it, leads to partial adoption of a bad spec. manoj -- If Machiavelli were a hacker, he'd have worked for the CSSG. Phil Lapsley Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Noah Slater wrote: On Tue, Mar 24, 2009 at 05:50:26PM -0500, Manoj Srivastava wrote: I am expressing my opinion now, on a mailing list devoted to debian development. I have not been keeping up witht eh bureaucratic rigmarole that seems to be being wrapped around discussions, not after we got the notice that there was a topic to be discussed, but we should not discuss it since the red-tape software was broken. You used to be project secretary, and I am only a humble new maintainer. Seems a bit weird to be criticising the Debian way of doing things like this. I'm curious... What do you think *is* the Debian way of doing things like this ? -- Steve McIntyre, Cambridge, UK.st...@einval.com Because heaters aren't purple! -- Catherine Pitt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Wed, Mar 25, 2009 at 12:39:46AM +, Steve McIntyre wrote: I'm curious... What do you think *is* the Debian way of doing things like this ? Manoj's email strongly implied that a DEP was needless bureaucracy. I'm hardly likely to argue with you about what constitutes the Debian way, but considering we've let a proposal stew on a wiki for over a year, have taken some discussion over to the mailing list and are now working on a DEP, I find it very confusing that it should be considered that we are somehow abusing the process. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Manoj Srivastava sriva...@debian.org writes: On Tue, Mar 24 2009, Ben Finney wrote: If the spec is being bruited under the understanding that the flaws do not matter Who's doing that? Of course the flaws matter. So answering criticism of the current spec with well, it is not going to be policy any time soon, so just urn your attention elsewhere If you got that impression, I can only say I don't think it's accurate. Try this: The machine-parseable copyright format is still in draft form and is not currently mandatory, so no-one is forced to use it. Those who don't like the form it's currently in are welcome to discuss it, once the discussion moves to a forum more amenable to actually building on what is discussed. I believe this is in progress with a DEP under way. Those who don't like the very *idea* of a machine-parseable format for ‘debian/copyright’ apparently exist, but I don't understand their position yet :-) There are wrinkles being pointed out already. Sure. I eagerly await the appearance of the DEP so the discussion can properly get underway; as it is, this is currently far more heat than light. -- \ “What we usually pray to God is not that His will be done, but | `\ that He approve ours.” —Helga Bergold Gross | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Wed, 25 Mar 2009 13:22:04 +1100 Ben Finney ben+deb...@benfinney.id.au wrote: ... Those who don't like the very *idea* of a machine-parseable format for .debian/copyright apparently exist, but I don't understand their position yet :-) I'd be one of those. Whenever you add new structural rules on a file it creates more things one needs to know, more things to get wrong, and more work. This is inevitable. To counter this, I see some very minor potential benefit. IANADD, so I don't get a vote, but if I did, I'd be against it. The cost/benefit ratio of the proposal is certainly open to reasonably varying opinions, so I don't expect arguing over different perceptions to have a lot of benefit. I do think it's worth (once) pointing out why I don't like the concept. I'll convert my packages when it's required by policy. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Scott Kitterman deb...@kitterman.com writes: On Wed, 25 Mar 2009 13:22:04 +1100 Ben Finney ben+deb...@benfinney.id.au wrote: ... Those who don't like the very *idea* of a machine-parseable format for .debian/copyright ? apparently exist, but I don't understand their position yet :-) I'd be one of those. Thank you for your explanation; after reading it, I would not actually classify your position as stated above :-) Whenever you add new structural rules on a file it creates more things one needs to know, more things to get wrong, and more work. This is inevitable. Yes. To counter this, I see some very minor potential benefit. IANADD, so I don't get a vote, but if I did, I'd be against it. Okay, so it's not that you're against having a machine-parseable format for the file, but that you don't yet see that the benefit outweighs the cost. The cost/benefit ratio of the proposal is certainly open to reasonably varying opinions, so I don't expect arguing over different perceptions to have a lot of benefit. I do think it's worth (once) pointing out why I don't like the concept. As I understand your position, it's not the concept that you don't like, but your perception of the cost:benefit ratio. Is that a fair restatement? I'll convert my packages when it's required by policy. Okay. Certainly I would hope there will be demonstrable (as opposed to the merely potential) benefits to such a format, before anyone considers making it mandatory. -- \ “I wrote a song, but I can't read music so I don't know what it | `\is. Every once in a while I'll be listening to the radio and I | _o__)say, ‘I think I might have written that.’” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Wed, 25 Mar 2009 15:44:20 +1100 Ben Finney ben+deb...@benfinney.id.au wrote: Scott Kitterman deb...@kitterman.com writes: On Wed, 25 Mar 2009 13:22:04 +1100 Ben Finney ben+deb...@benfinney.id.au wrote: ... Those who don't like the very *idea* of a machine-parseable format for .debian/copyright ? apparently exist, but I don't understand their position yet :-) I'd be one of those. Thank you for your explanation; after reading it, I would not actually classify your position as stated above :-) Whenever you add new structural rules on a file it creates more things one needs to know, more things to get wrong, and more work. This is inevitable. Yes. To counter this, I see some very minor potential benefit. IANADD, so I don't get a vote, but if I did, I'd be against it. Okay, so it's not that you're against having a machine-parseable format for the file, but that you don't yet see that the benefit outweighs the cost. Yes. I'm against adding requirements for work with a negative value. The cost/benefit ratio of the proposal is certainly open to reasonably varying opinions, so I don't expect arguing over different perceptions to have a lot of benefit. I do think it's worth (once) pointing out why I don't like the concept. As I understand your position, it's not the concept that you don't like, but your perception of the cost:benefit ratio. Is that a fair restatement? Yes, but given that I see the potential benefit (so far) as close to nil, I'm not particularly expecting this to change. There may be some great use case that really suprises me, but I'm not seeing it so far. I'll convert my packages when it's required by policy. Okay. Certainly I would hope there will be demonstrable (as opposed to the merely potential) benefits to such a format, before anyone considers making it mandatory. There are also inherent negatives to adding more strctural requirments. One that particularly concerns me about this one is that it adds to the mountain of stuff new developers have to learn. It's hard enough to teach people to accurately get all the currently required elements into debian/copyright that I don't relish adding to it No, that can't be a dash, it has to be a colon types of issues. In Debian (and Ubuntu) it's not rare for me to see enthusiastic new contributors get discouraged and give up over the existing mountain of requirements. I don't like adding more without a really good reason (yes, I know this isn't required anytime soon, but to be truly effective it will have to be eventually). I hope that clarifies my perspective. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Joerg Jaspert wrote: The real problem here is that FTP masters require the list of copyright holders to be up-to-date each time the package goes through NEW. Whatever justification exists for this requirement, I???m starting to find it unacceptable. If a package has to go through NEW, it takes about twice as much time to update this list than to do the actual packaging work. Why is this list needed? Often the license requires it. For instance the BSD license says, Redistributions in binary form must reproduce the above copyright. *binary* Even the GPL tells you to. § 4. Conveying Verbatim Copies (which is then mentioned in the source/binary paragraphs): --8schnipp-8--- You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program. --8schnapp-8--- *source code* (BTW the section about distribution of unmodified sources). so not for debian/copyright ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 12:49:12PM -0700, Russ Allbery wrote: Jonas Meurer jo...@freesources.org writes: On 21/03/2009 Mike Hommey wrote: On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote: Honestly, if you cant deal with listing the Authors/(C) holders - dont maintain a package. It is not much work to list them. (It might be a lot of work using the new format, but noone *requires* this format, especially not ftpmaster. It has *no* gain for us at all, we couldnt care less if you use it or not). You win. I hereby orphan xulrunner and iceape. As for iceweasel and webkit, there is a comaintainer on both, so that's up to them. I cannot believe that. Despite deeply appreciating your decision, it makes me very sad to see another complex and important package losing its competent and valuable maintainer. Joerg, please don't you see the consequences of your harsh discussion style? I've quite the feeling that with getting more and more important within debian you get more and more authoritarian as well. sorry for these straight words. it's not that i wouldn't appreciate your valuable work for debian, but please refrain from exploiting the power you got. Personally, I'm rather annoyed at both of them. There are people in the project who are willing to invest time and energy into finding mutually agreeable solutions and talking through problems, but if people explode as soon as the discussion gets heated and make drastic decisions before anyone even has a chance to mediate, what's the point? In the context of the current discussion, and in the context of my current work, I *do* have a good reason to explode, *now*. I just started to work on xulrunner 1.9.1, which will require an upload through NEW, and I now know that ftpmasters will REJECT the package on grounds of the debian/copyright file not containing copyright holders names, nor containing precise licensing information per file. And if they wouldn't reject it, then that would be pretty lame double-standards. I'm actually glad it happened now, before I spend tens of hours on that work. I do hope things will change, but until then, don't count on me for anything related to big packages. That will finally give me some time to finish those zfs-fuse packages... Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 2009-03-22 at 03:34 +, Noah Slater wrote: On Sat, Mar 21, 2009 at 08:07:23PM -0700, Russ Allbery wrote: NEW rejections are even stronger than an RC bug. Apart from questions of whether that's useful documentation for users, I have a hard time seeing either of your reasons stated above as being RC-level bugs. You don't think that possible DFSG problems are RC bugs? :/ Do you mean as in guilty until proven innocent? Cheers, Andrew. andrew (AT) morphoss (DOT) com+64(272)DEBIAN You are fairminded, just and loving. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 22 Mar 2009 02:53:51 + Noah Slater nsla...@tumbolia.org wrote: On Sat, Mar 21, 2009 at 09:42:35AM -0500, Manoj Srivastava wrote: Why do they have to? I know, the ftp team made it up. But there is no reason in policy or in copyright law for such copying to occur. But it would be nice to know why it is needed. I can think of a few desirable reasons: * To show the FTP masters that they have thoroughly checked the licensing. * To provide concise information for our users. That does not need a complete list, it merely needs a statement that this has been done. Either way, the result has to be taken on trust unless someone else spends the time to verify the result for each package upload - that is where the workload becomes an issue. People are complaining because these wishlist problems are being elevated to a severity higher than RC in packages that have thousands of contributors and where even upstream probably doesn't know exactly how many exist. What matters is not missing out any licences, missing out a few names and email addresses is minor. How many users are ever going to want this information *duplicating anything already in the source package*?? How many of those users are only complaining because it is their name that got left out? Is their vanity sufficiently important to block acceptance of the entire package? If there is an AUTHORS file in the source package and the debian packaging has a clear attribution, why is it necessary to list everyone else? It's a bug in the source package if it is a problem at all. (And if anyone files a bug like that against one of my source packages, it will be wishlist severity and no higher. I may even ignore it for a few upstream releases just to make the point.) Besides, various packages already include a statement like and anyone else I've forgotten in the AUTHORS file. I try to cover everyone in small to medium sized packages - it is just a nice thing to do but it is no more than that. Being nice to people does not require listing thousands and having packages REJECTED because one got missed - that isn't being nice to the maintainer. Actually, as this is a signed document verifiable as coming from me, I might as well state that if any package contains material that is under my copyright but has left my copyright details out of debian/copyright by accident or by intent, then that is fine, don't worry about it. If you feel like adding it later, that's fine by me. I will not make any list that attempts to be a complete list of projects in which I may have material under my copyright because I'm not sure I could remember (but it's not that many). If there is a statement somewhere in the source to the effect that the copyright includes other contributors whose names may have been forgotten, then I consider that as acceptable. However, if any package containing material under my copyright tries to change the licence or misses out the licence details or wilfully violates the licence or deliberately removes from the source code a copyright notice that I have manually inserted at an earlier date, then I reserve the right to insist on such an issue being fixed. I would expect that a lot of upstream contributors would feel similarly - retain the listings that the copyright holder has made themselves but do not assume that the copyright holder requires such attributions to be duplicated anywhere else. That is the rub - what matters are licences and licences are only enforceable by the copyright holders. As long as there is one copyright holder who is able to pursue licence violations then the list of copyright holders is sufficient. So why do we insist on names and email addresses? The only possible reason I can see is that Debian wants to be able to relicence stuff and needs to constantly retain an impossibly ambitious list of copyright holders that is self-evidently incomplete, just in case one of the thousands of source packages needs to be relicenced and we want to contact every copyright holder. Ummm, am I the only one who thinks that is going just a tad too far? Yes, we had problems with iceweasel, a certain package I won't mention and possibly other packages over time but those are individual cases and things get sufficiently involved during those episodes that there certainly *IS* time to thoroughly review the source code of the entire package in question in order to ascertain what we can only hope is as complete a list as we can manage. IMHO it is about not getting hung up on the process but considering the reasoning behind the process. AFAICT, there is no good reason to document every single copyright holder but there are very good reasons to document every applicable LICENCE. As a sponsor, I do *not* require that every single copyright holder is listed in debian/copyright. I *do* require that every file in the source package has been checked for the applicable LICENCE and that all such LICENCES are declared
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 02:47:04AM +, Noah Slater wrote: This has clear advantages for being able to post-process, check, search, and navigate copyright information using whatever tools the community decides would be profitable. I'm not quite clear as to why this is an advantage yet Currently, this seems to have been designed to provide interfaces for future tools to use, while not regarding whether or not people want those tools. Could you provide a use case or two to help clarify things? The main one I see is for an end user to look at a packages copyright file and say 'yes, I can use it for $foo', which is a case that's detracted from in the proposal. Neil -- blarson I use three different operating systems: Sarge, Etch, and Sid. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 22 Mar 2009 02:47:04 + Noah Slater nsla...@tumbolia.org wrote: On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote: Honestly, if you cant deal with listing the Authors/(C) holders - dont maintain a package. It is not much work to list them. (It might be a lot of work using the new format, but noone *requires* this format, especially not ftpmaster. It has *no* gain for us at all, we couldnt care less if you use it or not). I resent the implication in this remark. Then reconsider the remark. The proposed format is more work for many overworked maintainers, it presents no clear gain for those maintainers, it overly complicates the file and file handling. There is no point arguing about these facts, overworked maintainers have made their feelings clear and no amount of bleating from those supporting the proposal will now change their minds. Only a complete restart will be acceptable. I, for one, would rather see the entire proposal backported to revision 50 or thereabouts and left at that. I refuse to use later revisions as a basis for my own packages and I will not sponsor packages that, in my own view, overly complicate debian/copyright by using this proposal as a template for their own packages. The proposal, as it stands, is insane and anyone recommending it needs to review the reasons for recommending such a grandiose waste of my time. The copyright proposal is not complex, not verbose, and does not require any extra information from developers. The only thing it does is to mandate a machine readable format, in a similar vein as debian/control, for whatever information you might have already been using. No, the current proposal is overtly complex, unnecessarily verbose, requires enormous amounts of extra time from maintainers, the proposal itself still has no clear structure and is completely unusable. The machine readable format is not human readable and bears no comparison with the clarity of debian/control. This has clear advantages for being able to post-process, check, search, and navigate copyright information using whatever tools the community decides would be profitable. It has many clear disadvantages in wasting maintainer's time, unnecessarily complicating a free form file and making it harder for humans (i.e. us, the ones who need to understand copyright data in the package) to read the data. Machine readable copyright data is not the aim in and of itself. The aim has to be to make it easier to maintainers to maintain debian/copyright and easier to build tools that support such efforts. The current proposal makes that HARDER, not easier and it is not surprising that no such tools have been devised. IMNSHO, the only logical step for the progression of the current proposal is the conversion of debian/copyright to a binary file that needs a parser to be made human-readable as that illustrates just how insane the proposal has become. The proposal has been drowned in pointless edits and is unworthy of further consideration, IMHO. Either backport to a point where the idea is once again deemed sane by those maintainers who would most benefit from tools to support updates of debian/copyright or abandon the entire proposal as a good idea gone bad. Maybe someone else can look at it after Squeeze and raise version 2.0 from the ashes. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpVfSlmID6PH.pgp Description: PGP signature
Re: Sponsorship requirements and copyright files
First, let me apologize for my last mail in this thread, it had been a little too rude/harsh/direct. My fault, sorry. (We all should calm down, flaming won't help) On 11696 March 1977, Russ Allbery wrote: Joerg Jaspert jo...@debian.org writes: We require, and have seen nothing to convince us otherwise, that Debian maintainers need to do the basic work of listing each copyright holder in debian/copyright, as seen in the source files and AUTHORS list or equivalent (if any). So, the question being raised on this thread is why? What purpose does this work serve? Multiple, honestly. One is that there is one place where to look for that information. Thats a minor thing, really, but one. Then there is following Debians policy. And then we also follow the licenses, especially those that require it. Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let SPI get us some lawyers input on the question. Thats probably the best course. The argument against doing it is that it takes increased time over just verifying the licenses of every file and requires ongoing maintenance that could be spent on tasks more directly related to improving the software. You do have to check every file anyway, otherwise you can't be sure about your copyright file listing all the licenses your package uses. And I sincerely hope noone will contest the need to list the various licenses a package uses? If the argument in favor is just that Policy says something along those lines, well, as discussed in this thread, I want to revise that Policy section anyway. Feel free to. :) Is the reason that you feel most licenses require preservation of the copyright notice and it's easier to enforce it uniformly for all copyright files? Is there some other larger reason why is this important for the project? (Please note that I'm not assuming that you have no reason. I just don't understand, from the discussion so far, what it is. We can't really have a meaningful discussion until we're all on the same page) Yes, thats definitely part of the reason. Also, if people would look at how NEW had been handled in the past up to now, instead of purely exaggerating and taking actions from there, they would have found out that we are usually pretty lenient with this enforcement. We do mention it when we see it and whenever we do have a reject anyway, like when people forgot to mention a license at all. Rejection solely based on missing (C) notices might (have) happen(ed), but should be seldom and when there are lots of them with a license requiring them. Also, if just a small set is missing and nothing else would block accepting the package, we quite often accept the package and send a comment to the maintainer saying that the following couple of lines should be added at the next upload. -- bye, Joerg Some AM after a mistake: Sigh. One shouldn't AM in the early AM, as it were. grin pgpVldCkf57Ku.pgp Description: PGP signature
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 08:13:54PM +1300, Andrew McMillan wrote: On Sun, 2009-03-22 at 03:34 +, Noah Slater wrote: On Sat, Mar 21, 2009 at 08:07:23PM -0700, Russ Allbery wrote: NEW rejections are even stronger than an RC bug. Apart from questions of whether that's useful documentation for users, I have a hard time seeing either of your reasons stated above as being RC-level bugs. You don't think that possible DFSG problems are RC bugs? :/ Do you mean as in guilty until proven innocent? No, because that's a horrendous framing of the issue. However, with licensing and the DFSG, things are a little different. It is our responsibility to thoroughly check a package before we upload it, and that usually means checking every single file. I would like to think that no one is uploading packages with the *hope* that they are DFSG free. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 08:42:12PM -0700, Russ Allbery wrote: Could you explain to me how the lack of those two things is a possible DFSG problem? I assume that this is based on the first, but that seems like quite a stretch to me. The same assurance, for what good there is in it, could be drived from a statement in debian/copyright saying I checked every file in this package for DFSG licensing problems. Okay, just to get it straight. I have made it clear that the copyright proposal makes no pronouncements about how it should be used. We are only discussing the orthogonal topic of how much information to include in this file, regardless of whatever format the package uses. I am not convinced either way, because my packages are probably relatively small compared to some. This has been an interesting discussion primarily because we have had the opportunity to shake out arguments from both sides. Having said that, I am thinking that fully documenting the license of each file provides a handy way to ensure that developers are thoroughly checking the package for licensing problems. It is not inconceivable that we could add a lintian check which does some fuzzy guesswork to see if it can spot any probably missed files based on parsing the debian/copyright file. It could also prove handy to the FTP masters who wish to check the quality of work. Also, no, I definitely do not think that a possible DFSG problem is an RC bug. I think that an *actual* DFSG problem is an RC bug. A possible DFSG problem is only a possible RC bug. Surely this is obvious? Sure thing. My point was that not checking every file seems like sloppy work to me, for a distribution that places such an emphasis on licensing, and can lead to many problems. I have been the unfortunate victim of my own laziness in this regard, so at least I am speaking from guilty experience. Regardless of format, caveat a machine readable format being available to lintian for some rudimentary checks, a requirement for developers to document the licensing checks in debian/copyright could (not would) go a long way towards preventing DFSG problems in future uploads. Preventative measures seem a lot better than reactionary ones in this regard. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21, 2009 at 08:45:55PM -0700, Russ Allbery wrote: Given that many people have already said that it is, perhaps this is the point where you should just accept that they're not lying to you and instead you're suffering from a failure of imagination? I know from personal experience (having done this as an experiment for several packages of mine, including some fairly large ones) that it is indeed quite a bit of extra effort. This is for several reasons, including the simple fact that I read a lot faster than I type. Sure, I accept your points, and I apologise for my sloppy wording. Firmly in my mind is the cost/benefit of this extra effort. If we succeed in integrating debian/copyright checks into lintian, or dpkg and it's front-ends, it seems reasonable to imagine that this effort would be a good trade-off. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:35:02AM +, Neil Williams wrote: IMHO it is about not getting hung up on the process but considering the reasoning behind the process. AFAICT, there is no good reason to document every single copyright holder but there are very good reasons to document every applicable LICENCE. As a sponsor, I do *not* require that every single copyright holder is listed in debian/copyright. I *do* require that every file in the source package has been checked for the applicable LICENCE and that all such LICENCES are declared in debian/copyright along with clear identification of which files use which licence. Where there is a clear division between copyright holders and licences, I would expect that the sections of debian/copyright dealing with files under that licence specify that the files are Copyright foo rather than Copyright bar that applies elsewhere. If some names and / or email addresses fall through the gaps, so be it. This seems entirely reasonable. If we can include copyright holder names without much trouble then I think we should out of courtesy, but I shouldn't imagine that it must be a requirement. There is no reason why you couldn't adopt this approach with the proposal. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 22 Mar 2009 12:56:06 +0100 Joerg Jaspert jo...@debian.org wrote: First, let me apologize for my last mail in this thread, it had been a little too rude/harsh/direct. My fault, sorry. (We all should calm down, flaming won't help) /me calms down too. On 11696 March 1977, Russ Allbery wrote: Joerg Jaspert jo...@debian.org writes: We require, and have seen nothing to convince us otherwise, that Debian maintainers need to do the basic work of listing each copyright holder in debian/copyright, as seen in the source files and AUTHORS list or equivalent (if any). So, the question being raised on this thread is why? What purpose does this work serve? Multiple, honestly. One is that there is one place where to look for that information. Thats a minor thing, really, but one. True, minor. Then there is following Debians policy. which can be modified if necessary And then we also follow the licenses, especially those that require it. Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let SPI get us some lawyers input on the question. Thats probably the best course. So we need clarity on precisely which licences require the list of copyright holders but we also need clarity on whether such requirements mean: 1. the list of copyright holders that upstream make available in AUTHORS or similar files, or 2. some wider list that is constantly harvested from the source code by some means not used by upstream which may or may not include or duplicate existing information elsewhere in the upstream source, and 3. whether the list must be absolutely and 100% complete at all times, even if such completeness is not easily achievable. We also need clarity on why debian/copyright should have a higher level of scrutiny than the upstream itself. Debian does not hold copyright on most upstream source packages, why do we second-guess upstream teams? If there have been instances in the past, do those (presumably few instances) warrant the imposition of unnecessary work onto all packages? (Unnecessary in the sense that there is no evidence that the upstream listings are actually incomplete.) It is the expectation that debian/copyright be continuously updated with names and email addresses independent of changes made by upstream to files like AUTHORS that is irksome. Is it acceptable to mimic the actual copyright holders and say: and anyone else we might have forgotten? If not, why not? The argument against doing it is that it takes increased time over just verifying the licenses of every file and requires ongoing maintenance that could be spent on tasks more directly related to improving the software. You do have to check every file anyway, otherwise you can't be sure about your copyright file listing all the licenses your package uses. And I sincerely hope noone will contest the need to list the various licenses a package uses? Agreed - except copyright holder details change *far* more frequently than licences. That is a key point for me. The entire source package does need to be checked for LICENCE details, I don't think anyone disputes that. What does become a problem is *then* requiring that after the licences are checked, that the entire list of copyright holders is run through a separate parsing process to work out who isn't listed in which section of debian/copyright. It is a separate process - it has to be if debian/copyright is to remain sane. We can't simply copy the entire copyright section of every source file, there has to be some form of uniqueness sorting, some filtering of duplicates and repetition. (Upstreams have a noticeable tendency to wrap and modify copyright statements in such ways as to make regular expression matching across the entire set of source packages in Debian almost impossible and frequently unreliable). Ally that with the frequent additions of new copyright holders to some source files and not to others and you have a vast increase in the workload for subsequent versions, despite absolutely no changes in the actual licences being used or to the listing of which files use which licences. Is the reason that you feel most licenses require preservation of the copyright notice and it's easier to enforce it uniformly for all copyright files? Is there some other larger reason why is this important for the project? (Please note that I'm not assuming that you have no reason. I just don't understand, from the discussion so far, what it is. We can't really have a meaningful discussion until we're all on the same page) Yes, thats definitely part of the reason. Also, if people would look at how NEW had been handled in the past up to now, instead of purely exaggerating and taking actions from there, they would have found out that we are usually pretty lenient with this enforcement. We do mention it when we see it and whenever we do have a reject anyway, like when people forgot to mention a license at all.
Re: Sponsorship requirements and copyright files
On Sun, 22 Mar 2009 12:16:10 + Noah Slater nsla...@tumbolia.org wrote: On Sun, Mar 22, 2009 at 11:35:02AM +, Neil Williams wrote: IMHO it is about not getting hung up on the process but considering the reasoning behind the process. AFAICT, there is no good reason to document every single copyright holder but there are very good reasons to document every applicable LICENCE. As a sponsor, I do *not* require that every single copyright holder is listed in debian/copyright. I *do* require that every file in the source package has been checked for the applicable LICENCE and that all such LICENCES are declared in debian/copyright along with clear identification of which files use which licence. Where there is a clear division between copyright holders and licences, I would expect that the sections of debian/copyright dealing with files under that licence specify that the files are Copyright foo rather than Copyright bar that applies elsewhere. If some names and / or email addresses fall through the gaps, so be it. This seems entirely reasonable. If we can include copyright holder names without much trouble then I think we should out of courtesy, but I shouldn't imagine that it must be a requirement. There is no reason why you couldn't adopt this approach with the proposal. At last, some sanity. Thanks. By allowing for the listings of names and email addresses to be based on a) clear divisions between licences and b) courtesy for the rest, we can avoid the majority of the workload for maintainers of large packages where the licence changes infrequently but the contributors change frequently. In the vast majority of cases, the AUTHORS file will be packaged anyway and if a copyright holder isn't listed in AUTHORS, it is up to the copyright holder to decide whether that is something he/she wants to raise with upstream, not with Debian. In practice, at least as far as my own experience, an explicit listing in AUTHORS is *granted* by your peers in the upstream team, not requested, usually on the basis of the scope and importance of your contribution(s). Hence the rider at the end including anyone else not specifically listed already. I really do think Debian should leave such decisions to the upstream team - we don't really have a need to add new listings to what already exists in the upstream package and listing people who are not considered as core developers or who upstream do not consider to have made significant amounts of copyrighted contributions, is pointless effort for no gain. (Other than the vanity of those people, but then they are better off making more contributions upstream so that they earn a listing in AUTHORS directly.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpavs6DWjEBU.pgp Description: PGP signature
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:42:29AM +, Neil McGovern wrote: I'm not quite clear as to why this is an advantage yet Currently, this seems to have been designed to provide interfaces for future tools to use, while not regarding whether or not people want those tools. Could you provide a use case or two to help clarify things? The main one I see is for an end user to look at a packages copyright file and say 'yes, I can use it for $foo', which is a case that's detracted from in the proposal. Listing the licences (not necessarily copyright holders) in a machine readable format would allow lintian checks to be developed, and maybe even automatic license compatibility checks to be performed. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:54:49AM +, Neil Williams wrote: Then reconsider the remark. The proposed format is more work for many overworked maintainers, it presents no clear gain for those maintainers, it overly complicates the file and file handling. There is no point arguing about these facts, overworked maintainers have made their feelings clear and no amount of bleating from those supporting the proposal will now change their minds. Only a complete restart will be acceptable. Remember that the format can be used however we decide is best for Debian, even if that includes the recent discussion on omitting full copyright holder details. As a machine readable format, that allows us to potentially integrate this into lintian, and any number of dpkg tools that might want to perform license compatibility checks. You seem to be arguing that most people dislike the format, perhaps as a concept and not in its current grotesque incarnation, which I would contend given it's large, and voluntary, uptake. I, for one, would rather see the entire proposal backported to revision 50 or thereabouts and left at that. I refuse to use later revisions as a basis for my own packages and I will not sponsor packages that, in my own view, overly complicate debian/copyright by using this proposal as a template for their own packages. The proposal, as it stands, is insane and anyone recommending it needs to review the reasons for recommending such a grandiose waste of my time. Yes, the proposal is pretty absurd at the moment. I believe this has been mentioned already in this thread. At some point, the benefits of the wiki process were overshadowed by the problems it created coordinating the effort. As a result, many of the core drivers (myself included) backed away from doing any repair work, and have been waiting until after Lenny to restart the effort using a proper method and mailing list for communication. I too use an old version for my packages, because I dislike the current one. No, the current proposal is overtly complex, unnecessarily verbose, requires enormous amounts of extra time from maintainers, the proposal itself still has no clear structure and is completely unusable. The machine readable format is not human readable and bears no comparison with the clarity of debian/control. I think this is going over the top, a little. But for the most part I agree. Like we've previous stated, we do not want the current proposal evaluated. We have plans to restart the effort, collaborating via reasoned discussion on some mailing list, and then present a polished version for wider discussion. The aim of this proposal, at least from my perspective, was achieving machine readability in a similar vein to debian/control in the least possible intrusive way. The current proposal falls short of this by a large margin. As you seem to have considered this in some depth, it would be great to get your collaboration when we take a hatchet to it for version 2 as you put it. The proposal has been drowned in pointless edits and is unworthy of further consideration, IMHO. Either backport to a point where the idea is once again deemed sane by those maintainers who would most benefit from tools to support updates of debian/copyright or abandon the entire proposal as a good idea gone bad. Maybe someone else can look at it after Squeeze and raise version 2.0 from the ashes. It seems we are in violent agreement. Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 01:45:18PM +, Noah Slater wrote: On Sun, Mar 22, 2009 at 11:42:29AM +, Neil McGovern wrote: I'm not quite clear as to why this is an advantage yet Currently, this seems to have been designed to provide interfaces for future tools to use, while not regarding whether or not people want those tools. Could you provide a use case or two to help clarify things? The main one I see is for an end user to look at a packages copyright file and say 'yes, I can use it for $foo', which is a case that's detracted from in the proposal. Listing the licences (not necessarily copyright holders) in a machine readable format would allow lintian checks to be developed, and maybe even automatic license compatibility checks to be performed. Perhaps this is where we're not quite seeing eye-to-eye. I know that machine readable copyright files would allow lintian checks. But what would those checks be, and what would be the point of them? All I've personally seen so far is 'it makes data mining easier', which although could be a goal in itself, doesn't improve the quality of packages. Neil -- twb I don't see why anyone would want to cyber with a 16yo. IME none of them can spell, and they probably haven't had the relevant experience to write convincing prose. It's not like their ASCII is going to be any more supple for them being sixteen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 22 Mar 2009, Noah Slater wrote: I'm not quite clear as to why this is an advantage yet Currently, this seems to have been designed to provide interfaces for future tools to use, while not regarding whether or not people want those tools. Could you provide a use case or two to help clarify things? The main one I see is for an end user to look at a packages copyright file and say 'yes, I can use it for $foo', which is a case that's detracted from in the proposal. Listing the licences (not necessarily copyright holders) in a machine readable format would allow lintian checks to be developed, and maybe even automatic license compatibility checks to be performed. The way this process should work is that you (or somebody) writes those tools. Then, if DDs see that those tools are useful they will convert their debian/copyright files to take advantage of those tools all by themselves. No one will have to force them. If people don't consider those new tools useful enough to invest the work into converting then this means that those tools probably are not of sufficient help and no amount of proof by authority or handwaving will change this. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
* Noah Slater: If you're telling me that the FTP masters would be happy with blanket license statements for a package, what is stopping you from using the existing format to say something along the lines of: Files: * Copyright: Copyright 2008, Damien Katz dam...@apache.org Copyright 2008, Jan Lehnardt j...@apache.org Copyright 2008, Christopher Lenz cml...@apache.org Copyright 2008, Noah Slater nsla...@apache.org License: Apache-2.0 On Debian systems the full text of the Apache License (Version 2) can be found in the `/usr/share/common-licenses/Apache-2.0' file. Files: share/www/script/json.js License: PD In the public domain. This file does not exist. The file NOTICE contains this hint: | This product includes software developed at | The Apache Software Foundation (http://www.apache.org/). I'm wondering if this should be reflected in the copyright file (and if the NOTICE file should be installed in the binary package, in case the binary package ends up on different media than the sources). I don't think this is a significant problem, but it probably means that the machine-readable copyright file format is, in itself, not a solution. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Le Sunday 22 March 2009 14:45:18 Noah Slater, vous avez écrit : Could you provide a use case or two to help clarify things? The main one I see is for an end user to look at a packages copyright file and say 'yes, I can use it for $foo', which is a case that's detracted from in the proposal. Listing the licences (not necessarily copyright holders) in a machine readable format would allow lintian checks to be developed, and maybe even automatic license compatibility checks to be performed. I find it somehow ironic that you overlook the human trust between developpers but would follow automated test done by a machine. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 03:47:39PM +0100, Romain Beauxis wrote: Le Sunday 22 March 2009 14:45:18 Noah Slater, vous avez écrit : Could you provide a use case or two to help clarify things? The main one I see is for an end user to look at a packages copyright file and say 'yes, I can use it for $foo', which is a case that's detracted from in the proposal. Listing the licences (not necessarily copyright holders) in a machine readable format would allow lintian checks to be developed, and maybe even automatic license compatibility checks to be performed. I find it somehow ironic that you overlook the human trust between developpers but would follow automated test done by a machine. Please don't put words into my mouth. I never said I overlooked anything, only that it might be nice to augment things. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 03:35:13PM +0100, Florian Weimer wrote: Files: share/www/script/json.js License: PD In the public domain. This file does not exist. Yes, it seems the file is: share/www/script/jso2.js The file NOTICE contains this hint: | This product includes software developed at | The Apache Software Foundation (http://www.apache.org/). I'm wondering if this should be reflected in the copyright file (and if the NOTICE file should be installed in the binary package, in case the binary package ends up on different media than the sources). The ASF does not take copyright assignments, so it's unimportant. If you find problems in my packages, please file bugs. I don't think this is a significant problem, but it probably means that the machine-readable copyright file format is, in itself, not a solution. I hardly see that me making a typo constitutes a failure of the format. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 02:13:20PM +, Neil McGovern wrote: Perhaps this is where we're not quite seeing eye-to-eye. I know that machine readable copyright files would allow lintian checks. But what would those checks be, and what would be the point of them? I believe there has been so discussion of this already. I invite whomever has looked at this to speak up abut their plans. All I've personally seen so far is 'it makes data mining easier', which although could be a goal in itself, doesn't improve the quality of packages. But could improve the quality/utility of Debian as a whole, right? -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 03:27:46PM +0100, Peter Palfrader wrote: The way this process should work is that you (or somebody) writes those tools. Then, if DDs see that those tools are useful they will convert their debian/copyright files to take advantage of those tools all by themselves. No one will have to force them. If people don't consider those new tools useful enough to invest the work into converting then this means that those tools probably are not of sufficient help and no amount of proof by authority or handwaving will change this. Sounds like a fine idea to me. Please note, no one is suggesting that the copyright proposal be enforced either as it currently stands or immediately. The purpose of us rebooting the effort is to make the existing mess sane again, and to get some tooling developed around it exactly as you suggest. Only then would we put it forward for proper consideration. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Florian Weimer f...@deneb.enyo.de writes: The file NOTICE contains this hint: | This product includes software developed at | The Apache Software Foundation (http://www.apache.org/). I'm wondering if this should be reflected in the copyright file (and if the NOTICE file should be installed in the binary package, in case the binary package ends up on different media than the sources). For packages that are covered by the Apache 2.0 license, I always install the NOTICE file in every generated binary package. I believe this is required by the Apache 2.0 license: (d) If the Work includes a NOTICE text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. I could see an argument that putting the contents of NOTICE into debian/copyright satisfies the second possibility -- within the ... documentation, if provided along with the Derivative works -- but I think just installing the NOTICE file is more obviously safe. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, 2009-03-21 at 15:58 +0100, Joerg Jaspert wrote: Honestly, if you cant deal with listing the Authors/(C) holders - dont maintain a package. Is this you volunteering to maintain X? Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 11:35:26AM -0700, Russ Allbery wrote: I could see an argument that putting the contents of NOTICE into debian/copyright satisfies the second possibility -- within the ... documentation, if provided along with the Derivative works -- but I think just installing the NOTICE file is more obviously safe. CouchDB should be doing a 0.9 this week, so I'll take a look. Thanks. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On 2009-03-22, Noah Slater nsla...@tumbolia.org wrote: On Sun, Mar 22, 2009 at 04:31:58AM +0100, Josselin Mouette wrote: Le dimanche 22 mars 2009 à 02:58 +, Noah Slater a écrit : Again, while the documentation of individual licenses may not be policy, it is certainly policy for each package to be thoroughly checked for licensing issues. As this necessarily involves looking at each file, I don't see why it should be considered that much extra effort documenting the process. Ensuring DFSG compatibility is hardly administrative fluff. Please read what people write, otherwise it???s getting pretty insulting. No one here is questioning the importance and the usefulness of the licensing check. I don't understand the disconnect here. A license check must, by definition, involve each file in the package. As re-quoted from the quote you previously quoted: I don't see why it should be considered that much extra effort documenting the process. Best, Please try it then. take the kdelibs source package, start with taking time on how long it takes to verify that everything is gpl compatible and then afterwards try list every single copyright holder and put it in the proposed copyright file and also measure the time spent on that. It *does* *not* scale. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Jonas Meurer jo...@freesources.org (21/03/2009): Joerg, please don't you see the consequences of your harsh discussion style? You can cross out “discussion” here. Mraw, KiBi. signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
Noah Slater nsla...@tumbolia.org writes: Having said that, I am thinking that fully documenting the license of each file provides a handy way to ensure that developers are thoroughly checking the package for licensing problems. Did you mean copyright here? No one is disputing the need to document the license of every file that goes into forming the contents of the binary package. I have a serious conceptual problem with requiring work in order to ensure that people are doing some other piece of work that's only partly related. The actual *requirement* here is that packages be audited for license problems. For me at least, copying and pasting copyright notices to create a collective notice for packages that track separate copyright for all contributors takes at least three times longer than just checking each file for unexpected licensing. I can more easily do the audit without doing that work. I'm really not enthused at the idea of having to do a bunch of copy and paste work just to prove to someone that I've looked at every file. It feels like the sort of make-work assignment that I had to tolerate in grade school. One nice thing about being an adult is that I don't have to put up with that sort of thing any more. :) It is not inconceivable that we could add a lintian check which does some fuzzy guesswork to see if it can spot any probably missed files based on parsing the debian/copyright file. It could also prove handy to the FTP masters who wish to check the quality of work. In all of the packages for which I've implemented the new copyright format, which is more than a dozen now, I've always used a catch-all stanza with the main package license. I have a hard time imagining when I ever *wouldn't* do that. This means that such a Lintian check is going to be pretty worthless in practice, unless I'm missing some approach that's more than just making sure each file in the source tree has a matching stanza in copyright. Sure thing. My point was that not checking every file seems like sloppy work to me, for a distribution that places such an emphasis on licensing, and can lead to many problems. I have been the unfortunate victim of my own laziness in this regard, so at least I am speaking from guilty experience. I'm finding it a bit frustrating that your wording here seems to treat copying and pasting all the copyright files as if it's synonymous with checking every file and seems to assume that people who don't do the copying and pasting aren't checking every file. They truly are not the same thing. Regardless of format, caveat a machine readable format being available to lintian for some rudimentary checks, a requirement for developers to document the licensing checks in debian/copyright could (not would) go a long way towards preventing DFSG problems in future uploads. We already *do* require that developers document the results of the *license* audit. I don't think anyone is disputing that (although it's painfully tedious for large packages, and it would be really nice if the people who are deeply concerned that Debian always do this would volunteer to help the Iceweasel, Linux kernel, KDE, and X maintainers, among others, with doing this work). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Joerg Jaspert jo...@debian.org writes: Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let SPI get us some lawyers input on the question. Thats probably the best course. Yes. I'm wholeheartedly in favor of this, and I think we should hold any resolution of this discussion for the results of that. There are a surprising number of gotchas hidden in licenses that people think are straightforward and read past, and it would be nice to know what our basic legal requirements are. I agree that we need to duplicate the copyright statement that's written above a BSD-style license that contains a clause like: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [...] 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. or: Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, [...] subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. If the license is stated in those files, then it applies to the copyright notice in that file and hence we have to duplicate it. I'd like to get an answer about what we have to do with GPL notices. Hopefully we can get a legal evaluation for that. (I'm curious whether we can safely combine copyright notices -- merging together ones with disjoint dates, for instance -- and still satisfy this requirement.) However, there are a lot of upstreams that stick copyright notices in files but don't duplicate license terms or that just stick authorship information in files without making it a copyright notice and then just have a single license notice somewhere, like README. Those are the cases where I don't see a legal need for duplicating the copyright statements. You do have to check every file anyway, otherwise you can't be sure about your copyright file listing all the licenses your package uses. And I sincerely hope noone will contest the need to list the various licenses a package uses? Well, the one thing that I think we need to clarify here is whether we need to list the licenses for files that aren't source code for what goes into the binary distribution, such as the build system. The files from Autoconf and Automake have a bunch of different licenses and documenting them is a fair bit of work for each package. Looking at one of mine where I did that work, I have four different sections for every package using Autoconf and Automake: one for Makefile.in and aclocal.m4, one for configure, one for config.* and some Automake and libtool helpers, and one for install-sh. They all have different licenses. If I had to include only the exact copyright notice that's in each file, that would quickly turn into about ten different sections since there are slightly different years listed. This is pretty annoying work. Clearly, all build support files have to be under a DFSG-free license. But as long as that's the case, I'm not sure we should be requiring people to document the licenses of files used only in the build system or in bits of software that aren't included in the final binaries (such as the test suite, which even in FSF software sometimes includes tons of different copyright holders since the FSF doesn't always require copyright assignment for test suites). But I don't think anyone is contesting that we have to document the license of every file that goes into the binary software that we're distributing in the *.deb package. If the argument in favor is just that Policy says something along those lines, well, as discussed in this thread, I want to revise that Policy section anyway. Feel free to. :) Okay, I may propose some tentative text in the next few days, with the caveat that it may change based on the resolution of the legal investigation. Yes, thats definitely part of the reason. Also, if people would look at how NEW had been handled in the past up to now, instead of purely exaggerating and taking actions from there, they would have found out that we are usually pretty lenient with this enforcement. We do mention it when we see it and whenever we do have a reject anyway, like when people forgot to mention a license at all. Rejection solely based on missing (C) notices might (have) happen(ed), but should be seldom and when there are lots of them with a license requiring them. Also, if just a small set is missing and nothing else would block accepting the package, we quite often accept the package and send a comment to the maintainer saying that the following couple of lines should
Re: Sponsorship requirements and copyright files
Neil Williams codeh...@debian.org writes: We also need clarity on why debian/copyright should have a higher level of scrutiny than the upstream itself. Debian does not hold copyright on most upstream source packages, why do we second-guess upstream teams? It's worth noting here that most upstreams distribute only source, and hence rely on the fact that the source carries the licenes and the copyright statement and they don't have to do anything special with it. When we compile that software and distribute only the binaries as a separate package, we've stripped off, say, a BSD license statement and its corresponding copyright statement from where upstream put it, and we do, under the license, have to preserve that somewhere in our derived work, including the corresponding copyright notice. If upstream has a bunch of files under various varients of the BSD license, we are required by those licenses to preserve all of those notices in the binary package. This much is a very valid point which I was vaguely aware of but hadn't really thought about before this thread. Yes, in practice, it's very unlikely that anyone's going to sue anyone over this, and it's probably not *that* big of a deal if we don't do it, but I do agree that we should follow licenses as written even if no one's going to sue us if we don't. Is it acceptable to mimic the actual copyright holders and say: and anyone else we might have forgotten? If not, why not? I do agree that if upstream distributes a file with a license statement like (from INN): Copyright (c) 2004, 2005, 2006, 2007, 2008, 2009 by Internet Systems Consortium, Inc. (ISC) Copyright (c) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003 by The Internet Software Consortium and Rich Salz This code is derived from software contributed to the Internet Software Consortium by Rich Salz. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED AS IS AND ISC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. we can just copy that notice, ignoring the fact that ISC doesn't do copyright assignment and the actual copyrights are held by way more different people than are explicitly mentioned there. I don't think there's any utility in duplicating the INN CONTRIBUTORS file in debian/copyright. Agreed - except copyright holder details change *far* more frequently than licences. Yes. That's a lot of what makes accumulating copyright notices so annoying. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 07:10:46PM +, Sune Vuorela wrote: A license check must, by definition, involve each file in the package. As re-quoted from the quote you previously quoted: I don't see why it should be considered that much extra effort documenting the process. Best, Please try it then. take the kdelibs source package, start with taking time on how long it takes to verify that everything is gpl compatible and then afterwards try list every single copyright holder and put it in the proposed copyright file and also measure the time spent on that. Two errors here: * I didn't include the time of checking each file, which you should be doing anyway. No doubt this can take a long time sometimes. I was only talking about the additional work of noting each license down. * I have made it perfectly clear that noting copyright holders was not something I was talking about. Please do not mangle my position like this. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 2009-03-22 at 12:11 +, Noah Slater wrote: Firmly in my mind is the cost/benefit of this extra effort. If we succeed in integrating debian/copyright checks into lintian, or dpkg and it's front-ends, it seems reasonable to imagine that this effort would be a good trade-off. I have been reading this discussion a bit and I've been wondering what use-case you actually have for machine-readable debian/copyright files. FTP masters have indicated that they don't care about the format. This seems logical because they don't trust what the maintainer put in debian/copyright and need to review the source by hand anyway. As a package maintainer I don't see much benefit for my work with this new format. My packages are extremely simple when copyright is concerned though. As a user I hardly ever look at /usr/share/doc/*/copyright. If the package is in main I consider that enough information for just using it. If I'm developing software and I want to use another piece of software (e.g. library, framework or component) I check the license (I don't care about the copyright holders btw.) and perhaps sometimes I check the copyright file but most of the time I just check what upstream put on their website. For these seldom uses a common format or tools wouldn't help me much. So for me debian/copyright is mostly a write-only file. I can understand there may be benefits of a parsable format but I don't directly see enough gain. On the other hand there seems to be a lot of (perceived) cost involved (maintainer work). This means that if you want to introduce a new format you have to convince the maintainer of a package that there is some benefit, be it in tools that make their life easier or some concrete benefit for our users. Anyway, thanks for the work on the format. To me it seems to probably be a good thing. I hope this mail wasn't too negative. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 12:29:37PM -0700, Russ Allbery wrote: Noah Slater nsla...@tumbolia.org writes: Having said that, I am thinking that fully documenting the license of each file provides a handy way to ensure that developers are thoroughly checking the package for licensing problems. Did you mean copyright here? No one is disputing the need to document the license of every file that goes into forming the contents of the binary package. No, I meant license. It seems people ARE disputing that licenses be fully documented. I have a serious conceptual problem with requiring work in order to ensure that people are doing some other piece of work that's only partly related. The actual *requirement* here is that packages be audited for license problems. For me at least, copying and pasting copyright notices to create a collective notice for packages that track separate copyright for all contributors takes at least three times longer than just checking each file for unexpected licensing. I can more easily do the audit without doing that work. I have already made it explicit that I was not talking about copyright holders. I'm really not enthused at the idea of having to do a bunch of copy and paste work just to prove to someone that I've looked at every file. It feels like the sort of make-work assignment that I had to tolerate in grade school. One nice thing about being an adult is that I don't have to put up with that sort of thing any more. :) In the context of documenting licenses, it's more for our own sake than anything else. Like unit tests for code to make sure everything is in order. This would be more clear if we had developed lintian checks already. In all of the packages for which I've implemented the new copyright format, which is more than a dozen now, I've always used a catch-all stanza with the main package license. I have a hard time imagining when I ever *wouldn't* do that. This means that such a Lintian check is going to be pretty worthless in practice, unless I'm missing some approach that's more than just making sure each file in the source tree has a matching stanza in copyright. Me too. Perhaps there is a way of catching boilerplate patterns and checking to see if they are matched in debian/copyright. It wouldn't be an exact science, but it might be helpful in some way. Sure thing. My point was that not checking every file seems like sloppy work to me, for a distribution that places such an emphasis on licensing, and can lead to many problems. I have been the unfortunate victim of my own laziness in this regard, so at least I am speaking from guilty experience. I'm finding it a bit frustrating that your wording here seems to treat copying and pasting all the copyright files as if it's synonymous with checking every file and seems to assume that people who don't do the copying and pasting aren't checking every file. They truly are not the same thing. I'm not sure I follow, sorry. Regardless of format, caveat a machine readable format being available to lintian for some rudimentary checks, a requirement for developers to document the licensing checks in debian/copyright could (not would) go a long way towards preventing DFSG problems in future uploads. We already *do* require that developers document the results of the *license* audit. I don't think anyone is disputing that (although it's painfully tedious for large packages, and it would be really nice if the people who are deeply concerned that Debian always do this would volunteer to help the Iceweasel, Linux kernel, KDE, and X maintainers, among others, with doing this work). Well, there seems to be some confusion then. I have made it explicit in this thread that I don't really see it as necessary that each copyright holder be listed, and that we only do it where necessary. It is my understanding that people have still raised objections about documenting every license in debian/copyright, for example Autoconf and other generated files. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 12:55:58PM -0700, Russ Allbery wrote: I think part of the problem right now is that people aren't sure what to expect and are feeling like this review is somewhat unpredictable. This is what I'm hoping to be able to help with by revising the Policy section. If we can break this down into must, should, and best practice, then people can understand that they'll get a reject for breaking a must, maybe a reject for being particularly sloppy about shoulds, and just get notes about best practices, as with most of the other things in NEW review. And once this is complete, the proposed copyright format would sit on top of that nicely, assuming it is accepted by the community. I want to keep all policy decisions away from the format proposal. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 01:02:22PM -0700, Russ Allbery wrote: we can just copy that notice, ignoring the fact that ISC doesn't do copyright assignment and the actual copyrights are held by way more different people than are explicitly mentioned there. I don't think there's any utility in duplicating the INN CONTRIBUTORS file in debian/copyright. +1 -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:00:34PM +0100, Arthur de Jong wrote: I can understand there may be benefits of a parsable format but I don't directly see enough gain. On the other hand there seems to be a lot of (perceived) cost involved (maintainer work). Implicit in your email is the idea that the copyright proposal is complicated. Files: * Licence: BSD I can imagine that being valid syntax for the final format. Hardly a chore! This means that if you want to introduce a new format you have to convince the maintainer of a package that there is some benefit, be it in tools that make their life easier or some concrete benefit for our users. Agreed. Clearly, given the successful uptake of the proposal given it's draft nature, people are already seeing value. Perhaps like me, one of those values is having a consistent way of laying out the file, without having to worry about inventing your own consistent formatting style. Maybe that's just my mild OCD speaking though. Heh. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 02:47:04 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 02:53:51 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 02:55:47 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 02:58:56 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 03:02:51 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 03:34:35 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 03:35:40 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 03:36:55 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 12:03:23 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 12:09:54 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 12:11:50 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 12:16:10 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 13:45:18 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 13:55:42 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 15:42:00 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 15:44:40 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 15:46:04 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 15:47:28 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 18:58:04 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 20:05:33 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 20:11:15 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 20:14:34 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 20:15:38 +, Noah Slater wrote: On Sun, Mar 22, 2009 at 20:19:56 +, Noah Slater wrote: may I suggest you stop doing that? Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, 22 Mar 2009 21:24:51 +0100, Julien Cristau wrote: On Sun, Mar 22, 2009 at 02:47:04 +, Noah Slater wrote: [21 times] On Sun, Mar 22, 2009 at 20:19:56 +, Noah Slater wrote: may I suggest you stop doing that? What's wrong with properly replying without breaking threads? Yes, he could've sent one mail quoting different texts, but that's weird IMVHO. David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Sponsorship requirements and copyright files
On Sun, 22 Mar 2009, David Paleino wrote: On Sun, 22 Mar 2009 21:24:51 +0100, Julien Cristau wrote: On Sun, Mar 22, 2009 at 02:47:04 +, Noah Slater wrote: [21 times] On Sun, Mar 22, 2009 at 20:19:56 +, Noah Slater wrote: may I suggest you stop doing that? What's wrong with properly replying without breaking threads? Yes, he could've sent one mail quoting different texts, but that's weird IMVHO. He is monopolizing the discussion. He should let some time pass between replies to take into account the opinions of others. Furthermore, by replying too fast he is actively making the discussion non-followable by many persons that don't want to spend an afternoon on this topic. Having a constructive discussion is difficult and requires everybody to sit back and let others take part in it. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:55:10PM +0100, Raphael Hertzog wrote: He is monopolizing the discussion. He should let some time pass between replies to take into account the opinions of others. Furthermore, by replying too fast he is actively making the discussion non-followable by many persons that don't want to spend an afternoon on this topic. Am I the cat's mother? I'm not sure which is more rude, replying to emails faster than other people or criticising someone's behaviour in a public forum. If you think I reply to emails too fast, please do so in private in the future. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:08:54PM +, Noah Slater wrote: Am I the cat's mother? I'm not sure which is more rude, replying to emails faster than other people or criticising someone's behaviour in a public forum. If you think I reply to emails too fast, please do so in private in the future. Please TELL me in private, heh. -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Joerg Jaspert wrote: No. It is not up to the Debian maintainer to decide that some contributor has written enough of the code to also be mentioned in the (C) lines in a particular file. But as soon as upstream lists them either in a file header or the AUTHORS file the Debian maintainer has to copy that information into debian/copyright. This is an absolute waste of time. As your mail is. Honestly, if you cant deal with listing the Authors/(C) holders - dont maintain a package. It is not much work to list them. Of course it is, take for an example #486340, which took 3-4 hours. And the Intel-Xserver is tiny in comparison to xulrunner or KDE. You fail to give a rationale why it's actually needed. In the above example even a company-driven upstream (Intel, VA Linux, Tungsten) didn't bother to collect copyright information, so WTF should we do it? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Le dimanche 22 mars 2009 à 20:11 +, Noah Slater a écrit : Did you mean copyright here? No one is disputing the need to document the license of every file that goes into forming the contents of the binary package. No, I meant license. It seems people ARE disputing that licenses be fully documented. Who? I haven’t seen a single message disputing this in the current discussion. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Sponsorship requirements and copyright files
Peter Palfrader wea...@debian.org writes: On Sun, 22 Mar 2009, Noah Slater wrote: Listing the licences (not necessarily copyright holders) in a machine readable format would allow lintian checks to be developed, and maybe even automatic license compatibility checks to be performed. The way this process should work is that you (or somebody) writes those tools. In the absence of a format? Please remember that, for most of its lifetime, the proposed format has been undergoing changes that would invalidate such tools; it's still a draft proposal. Then, if DDs see that those tools are useful they will convert their debian/copyright files to take advantage of those tools all by themselves. No one will have to force them. Certainly, no one has proposed forcing use of the machine-parseable format in anything like the foreseeable future. One constant on the page for the draft proposal is the statement that it is *not* yet a proposal to change policy. To repeat what Noah has said elsewhere: Please separate any talk of policy requirements about “what information must go into the ‘debian/copyright’ file”, from work on making that file machine-parseable. The two issues are orthogonal. -- \ “The best is the enemy of the good.” —Voltaire, _Dictionnaire | `\Philosophique_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sun, Mar 22, 2009 at 09:00:34PM +0100, Arthur de Jong wrote: On Sun, 2009-03-22 at 12:11 +, Noah Slater wrote: Firmly in my mind is the cost/benefit of this extra effort. If we succeed in integrating debian/copyright checks into lintian, or dpkg and it's front-ends, it seems reasonable to imagine that this effort would be a good trade-off. I have been reading this discussion a bit and I've been wondering what use-case you actually have for machine-readable debian/copyright files. I find debian/copyright in general be useful if the package has no Homepage: line in control yet. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, 21 Mar 2009 15:00:00 -0700 Steve Langasek vor...@debian.org wrote: No. It is not up to the Debian maintainer to decide that some contributor has written enough of the code to also be mentioned in the (C) lines in a particular file. But as soon as upstream lists them either in a file header or the AUTHORS file the Debian maintainer has to copy that information into debian/copyright. So it's not up to the Debian maintainer, but it is up to the ftp team? Why? I'm not ftpmaster, but I can guess. You yourself have said there is not Debian entity, which means that ftpmaster is *personally* liable for legal actions take as a result of problems with the archive. As the ones personally liable they make any final decision about what goes in the archive and what doesn't. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature
Re: Sponsorship requirements and copyright files
On Sat, 2009-03-21 at 16:24 +0100, Josselin Mouette wrote: Le samedi 21 mars 2009 à 15:58 +0100, Joerg Jaspert a écrit : Honestly, if you cant deal with listing the Authors/(C) holders - dont maintain a package. It is not much work to list them. Bullshit. The last time FTP masters REJECTed a package because of that, I spent more than an hour to get the list right, for a package that took only a few minutes to update. I can hardly imagine how fun it must be for a big package. FWIW, ~3 hours of intensive work on webkit last time I did it -- Gustavo Noronha k...@debian.org Debian Project -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 11:33:32PM -0500, Manoj Srivastava wrote: Now, some of the objections you have heard is because of the hard line you have been taking in this discussion about looking for and adding copyright holders is not, as far as I can see, reflected in current policy. And telling people they are doing a bad job and need to either shape up or change policy does not actually seem to be corroborated by policy, unless I am missing chunks. Yeah, I apologise for this. This had been my understanding. Sorry. BTW, to your list of solutions, I can add another one: + realize this is busy work with little value in the common case, and prefer to spend time otherwise improving the package. On the other hand, I think this needs to be clarified. I only maintain a small number of packages, but even then, I have regularly found files contained within those packages which were included for various reasons by upstream under a different license. In the case of planet-venus, I remove a not insignificant number of these for the DFSG. Clearly, some amount of checking each file is a good thing, so why not be explicit about what is required of a developer for this? Best, -- Noah Slater, http://tumbolia.org/nslater -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Hi Manoj, Manoj Srivastava wrote: o) It should name the original authors -- which, in my view, is distinct from every subsequent contributor. This can bea matter of subjective interpretation, though. Allow me to disagree. While in common language original can be used in the sense of initial as your interpretation seems to suggest, this is clearly and consistently not the case in the context of copyright. In fact, original author is a something of a technical term in this domain. A definition capturing the common meaning of this term can be found e.g. in the CC licenses. In CC 3.0 it starts with Original Author means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work ... The works Debian distributes are more often than not the result of a collaborative effort. As such, anyone with a (original, i.e. creative) contribution to the work is an original author, and not just whoever started a project. Debian sees increased enforcement of properly documenting copyright status because the people who recently joined the FTP team were instructed to check for this and pointed to the publicly available reject faq and the two announcements on debian-devel-announce that explicitly state that copyright notices must be listed and have not been met with opposition when they were posted five and again three years ago. Properly documenting the copyright license well includes listing the licensor and the basis of the license, i.e. including the copyright notice. If Debian absolutely wants to decide it does not care about who grants the copyright license, then it has to do so. It might not, however, be quite necessary to pretend that the ftp team who try to diligently do the job that has been entrusted to them, including (manually, mostly, not that much less tedious as compiling them) double-check that the stuff put on Debian mirrors is prima facie legally distributable is getting fun out of making up reject reasons. I do not envy anyone to have to wade through things to collect these notices and looking at hundreds of license boilerplates but having found stuff like proprietary property of IBM in openjdk (probably vetted by people paid to know what they are doing) or KDE themes with an PNGs from a KDE icon collection and the express clarification that GPL requires distributing SVG source with any pixel formats, I can assure you that if Debian is interested in credibly attempting to ensure that the stuff put on mirrors is legal to distribute someone has to look at every file in the tarballs. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
The real problem here is that FTP masters require the list of copyright holders to be up-to-date each time the package goes through NEW. Whatever justification exists for this requirement, I???m starting to find it unacceptable. If a package has to go through NEW, it takes about twice as much time to update this list than to do the actual packaging work. Why is this list needed? Often the license requires it. For instance the BSD license says, Redistributions in binary form must reproduce the above copyright. Even the GPL tells you to. § 4. Conveying Verbatim Copies (which is then mentioned in the source/binary paragraphs): --8schnipp-8--- You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program. --8schnapp-8--- To me, it seems like since one has to go through all of the source files anyway, creating a list of copyright holders while you are doing it is a trivial task. I don't see why making this list takes any time at all really. Unless you are not actually looking at the code you upload, which would worry me for other reasons as well. I think it means what is says. The *ABOVE* copyright notice must be reproduced. That does not mean you have to hunt down every person with a Signed-Off-By header in the log, or every person who made an more than 10 line (non-trivial) patch submission to the project (and yes, most of these people also hold copyright -- how are you gonna find out all such names?) No. It is not up to the Debian maintainer to decide that some contributor has written enough of the code to also be mentioned in the (C) lines in a particular file. But as soon as upstream lists them either in a file header or the AUTHORS file the Debian maintainer has to copy that information into debian/copyright. Frankly, at this point, I am not seeing a need to track down or verify the completeness of my list of copyright holders, since it is almost impossible to do so, or very time consuming, and I see limited returns for time invested. We do not require people to wade through $VCS commit logs or mailinglist threads to find out who wrote each single line of code. We require, and have seen nothing to convince us otherwise, that Debian maintainers need to do the basic work of listing each copyright holder in debian/copyright, as seen in the source files and AUTHORS list or equivalent (if any). -- bye, Joerg I. What would you do if a package has no sane default configuration? (There is *no* default configuration that works on most systems!) The best thing to do would be to add such a default configuration. [... ARGS ...] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
la, 2009-03-21 kello 15:04 +0100, Joerg Jaspert kirjoitti: We require, and have seen nothing to convince us otherwise, that Debian maintainers need to do the basic work of listing each copyright holder in debian/copyright, as seen in the source files and AUTHORS list or equivalent (if any). It would, of course, help, if at least most upstreams would adopt some systematic way of marking such. Could we push the machine-readable debian/copyright file upstream? :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
Le samedi 21 mars 2009 à 15:04 +0100, Joerg Jaspert a écrit : No. It is not up to the Debian maintainer to decide that some contributor has written enough of the code to also be mentioned in the (C) lines in a particular file. But as soon as upstream lists them either in a file header or the AUTHORS file the Debian maintainer has to copy that information into debian/copyright. This is an absolute waste of time. Lots of time. Valuable time. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Sponsorship requirements and copyright files
On Sat, Mar 21 2009, Thomas Viehmann wrote: Hi Manoj, Manoj Srivastava wrote: o) It should name the original authors -- which, in my view, is distinct from every subsequent contributor. This can bea matter of subjective interpretation, though. Allow me to disagree. While in common language original can be used in the sense of initial as your interpretation seems to suggest, this is clearly and consistently not the case in the context of copyright. In fact, original author is a something of a technical term in this domain. A definition capturing the common meaning of this term can be found e.g. in the CC licenses. In CC 3.0 it starts with Original Author means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work ... The works Debian distributes are more often than not the result of a collaborative effort. As such, anyone with a (original, i.e. creative) contribution to the work is an original author, and not just whoever started a project. Had Debian policy been written by copyright lawyers, you might have had a point. The wording in policy was vetted by us non-lawyers; and, in fact, was last modified in a commit made by me, on 2005-06-16. I certainly did not mean the original in the sense you say it means in copyright law. Putting busy work into a publicly available and documented policy makes it no less busy work, and a partial list of copyright owners (since the list of copyright owners is largter thatn the ones in the copyright notices on files) serves little purpose, apart from hand wavy ones that applaud us for putting in extra, albeit mostly useless, effort. manoj -- An exception TESTS a rule; it NEVER proves it. -- Edmund C. Berkeley Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21 2009, Noah Slater wrote: I only maintain a small number of packages, but even then, I have regularly found files contained within those packages which were included for various reasons by upstream under a different license. In the case of planet-venus, I remove a not insignificant number of these for the DFSG. Clearly, some amount of checking each file is a good thing, so why not be explicit about what is required of a developer for this? I do a license check, yes. But that does not mean I record the author names, no. So, making sure that you cover all licenses the package comes with is required, but there is no reason to create a partial list of copyright holders --- until there is need to. manoj -- Loyalty to petrified opinion never broke a chain or freed a human soul. Mark Twain Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Sat, Mar 21 2009, Thomas Viehmann wrote: Hi Manoj, Manoj Srivastava wrote: o) It should name the original authors -- which, in my view, is distinct from every subsequent contributor. This can bea matter of subjective interpretation, though. Allow me to disagree. While in common language original can be used in the sense of initial as your interpretation seems to suggest, this is clearly and consistently not the case in the context of copyright. In fact, original author is a something of a technical term in this domain. A definition capturing the common meaning of this term can be found e.g. in the CC licenses. In CC 3.0 it starts with Original Author means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work ... The works Debian distributes are more often than not the result of a collaborative effort. As such, anyone with a (original, i.e. creative) contribution to the work is an original author, and not just whoever started a project. Had Debian policy been written by copyright lawyers, you might have had a point. The wording in policy was vetted by us non-lawyers; and, in fact, was last modified in a commit made by me, on 2005-06-16. I certainly did not mean the original in the sense you say it means in copyright law. Putting busy work into a publicly available and documented policy makes it no less busy work, and a partial list of copyright owners (since the list of copyright owners is largter thatn the ones in the copyright notices on files) serves little purpose, apart from hand wavy ones that applaud us for putting in extra, albeit mostly useless, effort. manoj -- An exception TESTS a rule; it NEVER proves it. -- Edmund C. Berkeley Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
