Hi,
On Sun, Dec 17, 2017 at 12:34:24PM +0100, Gert Wollny wrote:
> ...
> Unless there is a legally binding reason to add individual copyrights
> to d/copyright, I'd vote for only a summary statement that lists all
> contributors for a package.
I agree to the point that in *some* cases I dealt wi
Am Samstag, den 16.12.2017, 13:20 +0100 schrieb Jonas Smedegaard:
>
> If it is "not worth [your] time" to cover _all_ sources for the
> project you are maintaining then perhaps you should team up with
> someone who does find it worthwhile to do that part of the packaging
> maintenance - because th
Quoting Steve Robbins (2017-12-16 05:35:25)
> Ben Finney writes:
>> Simon McVittie writes:
>>> On Wed, 13 Dec 2017 at 23:10:51 +1100, Ben Finney wrote:
expecting to find “complete copyright holder information” such that
we can be confident it *is* complete, solely in the upstream sourc
Ben Finney writes:
> Simon McVittie writes:
> > On Wed, 13 Dec 2017 at 23:10:51 +1100, Ben Finney wrote:
> > > expecting to find “complete copyright holder information” such
> > > that we can be confident it *is* complete, solely in the upstream source
> > > is a folly, in my experience.
> >
> >
Simon McVittie writes:
> On Wed, 13 Dec 2017 at 23:10:51 +1100, Ben Finney wrote:
> > expecting to find “complete copyright holder information” such
> > that we can be confident it *is* complete, solely in the upstream source
> > is a folly, in my experience.
>
> Given that, on what basis can a u
Hi Steve,
> > it does not seem a terribly logical defense that "it is been like that
> > for some time." (So what? :p)
>
> That is one interpretation of what I wrote.
We get the "but it's been like that for a while" reply to REJECTs fairly
often, so apologies for jumping to that :)
Best wishes
On Wed, 13 Dec 2017 at 23:10:51 +1100, Ben Finney wrote:
> expecting to find “complete copyright holder information” such
> that we can be confident it *is* complete, solely in the upstream source
> is a folly, in my experience.
Given that, on what basis can a user of the package gain value from
o
Steve Robbins writes:
> On Sunday, December 10, 2017 11:11:20 PM CST gregor herrmann wrote:
> > My understanding is that a license without any information who puts
> > the software under this license (i.e. who is the copyright holder
> > who can grant these rights) is incomplete.
>
> OK, but sure
On Sunday, December 10, 2017 11:11:20 PM CST gregor herrmann wrote:
> On Sun, 10 Dec 2017 12:44:52 -0600, Steve Robbins wrote:
> > However, the consensus voiced in this thread (as was the case of the same
> > in 2016) is that while license summarizing (which can include, if the
> > license has lang
On Wed, Dec 13, 2017 at 12:28:16AM -0600, Steve Robbins wrote:
> So all I can present is that it was accepted for a long time and then
> suddenly not accepted.
Accepted or just not checked?
--
WBR, wRAR
signature.asc
Description: PGP signature
On Sunday, December 10, 2017 8:09:16 PM CST Chris Lamb wrote:
> I would also point out that regardless of the merits of some particular
> interpretation, if a perceived violation of it was potentially discovered,
> it does not seem a terribly logical defense that "it is been like that
> for some t
Excerpts from Ian Jackson's message of 2017-12-12 15:38:29 +:
> The work of reviewing each source file, first by the maintainer, and
> then by ftpmaster when auditing, would still have to be done, I think.
>
> Or do you think we can avoid both the maintainer and then ftpmaster
> looking at eve
Am 12.12.2017 um 21:00 schrieb Mattia Rizzolo:
> On Fri, Dec 08, 2017 at 01:42:54AM +0100, Markus Koschany wrote:
>> Why don't we add all DFSG-free licenses to /usr/share/common-licenses or
>> /usr/share/free-licenses instead? It would save a lot of developer and
>> maintenance time if we could jus
On Fri, Dec 08, 2017 at 01:42:54AM +0100, Markus Koschany wrote:
> Why don't we add all DFSG-free licenses to /usr/share/common-licenses or
> /usr/share/free-licenses instead? It would save a lot of developer and
> maintenance time if we could just reference those licenses on a standard
> Debian sy
th me in my language, if you see what I mean. If that's
possible.
Steve Langasek writes ("Re: Has Copyright summarizing outlived its
usefulness?"):
> On Thu, Dec 07, 2017 at 05:28:12PM +, Ian Jackson wrote:
> > From what I've seen of the ftp review process, t
On Thu, Dec 07, 2017 at 05:28:12PM +, Ian Jackson wrote:
> Simon McVittie writes ("Re: Has Copyright summarizing outlived its
> usefulness?"):
> > I've written about this before, for example in
> > <https://lists.debian.org/debian-devel/2016/08/msg00181.ht
On Sun, 10 Dec 2017 12:44:52 -0600, Steve Robbins wrote:
> However, the consensus voiced in this thread (as was the case of the same in
> 2016) is that while license summarizing (which can include, if the license
> has
> language such as Russ identified, also listing copyrights) is valuable,
>
On Sunday, December 10, 2017 8:09:16 PM CST Chris Lamb wrote:
> However, I just wanted to add that whilst I can understand the frustration
> of your package being rejected after spending some time in NEW, it would
> be unfair to characterise that as "leaving" or neglecting it. Attributing
> malice
Hi Steve,
> It's a shame the FTP masters are not participating in the discussion.
I apologise. I have been following reading this thread, but just not
responding as I can't commit the time right now to seriously respond
to any input of my own.
However, I just wanted to add that whilst I can un
Hi Ian,
As a preface to my comments: I am *only* complaining about collecting
copyright notices. I agree that collecting together a comprehensive license
statement(s) is necessary. The caveats of Russ Alberry [1] aside, these are
two distinct tasks in my eyes.
[1] https://lists.debian.org/de
Quoting Ben Finney :
If I understand correctly, the justification of putting a file there
must include that it is overwhelmingly more likely to save *storage
space* overall (by reducing the space in a corresponding number of
‘/usr/share/doc/…/copyright’ files), especially on machines that have
lo
Quoting Markus Koschany :
Why don't we add all DFSG-free licenses to /usr/share/common-licenses or
/usr/share/free-licenses instead? It would save a lot of developer and
maintenance time
...
IMHO using links and
references is just common sense and reduces unnecessary make work.
+1 with "all D
Wookey writes:
> On 2017-12-08 01:42 +0100, Markus Koschany wrote:
> > Why don't we add all DFSG-free licenses to
> > /usr/share/common-licenses or /usr/share/free-licenses instead?
>
> I would second this. It seems odd that we only have a small subset in
> common-licences so I often end up findi
On 2017-12-08 01:42 +0100, Markus Koschany wrote:
>
> Why don't we add all DFSG-free licenses to /usr/share/common-licenses or
> /usr/share/free-licenses instead?
I would second this. It seems odd that we only have a small subset in
common-licences so I often end up finding/copying in a copy to t
Am 30.11.2017 um 06:46 schrieb Steve Robbins:
[...]
> Has copyright summarizing outlived its usefulness for large sources? Why
> shouldn't we have some way to say "Copyright by the Boost authors"?
>
I completely agree with your rationale and there is even more room f
Ian Jackson writes:
> From what I've seen of the ftp review process, the file-by-file
> information is invaluable to ftpmaster review. As in, the ftpmaster
> review would probably be impractical without it. ftpmaster review
> necessarily focuses on the contents of the source package.
It is also
Simon McVittie writes ("Re: Has Copyright summarizing outlived its
usefulness?"):
> I've written about this before, for example in
> <https://lists.debian.org/debian-devel/2016/08/msg00181.html>, and I'd be
> very glad to see an "official" response fr
On 2017-12-06 23:12:19 -0600 (-0600), Steve Robbins wrote:
[...]
> Perhaps we should deprecate debian/copyright and just create
> debian/license instead!
[...]
Free software licenses are, ultimately, licenses of copyright and so
while the filename may seem mildly confusing, it is not entirely
inco
On Thu, 07 Dec 2017 at 13:33:12 +0800, Boyuan Yang wrote:
> Of course if the
> file is under a different license (different from th license of whole
> project)
> or some authors had their names written inside source code *explicitly*(e.g.,
> in the comment), it must be listed out in a separate
g ways, there's no reasonable
doubt wrt these files being pure kosher GPL, but any attempts to list
individual authors are utterly doomed.
I wonder how to describe these two files then.
==
> Has copyright summarizing ou
Boyuan Yang <073p...@gmail.com> writes:
> Howerver, what we, the distribution maintainers, really care is that
> these files do not conflict with our guideline aka DFSG. In this
> situation it is the license that matters, not copyright holders. For
> large software like linux kernel or libboost, w
在 2017年12月6日星期三 CST 下午11:12:19，Steve Robbins 写道：
> On Thursday, November 30, 2017 11:26:31 AM CST Simon McVittie wrote:
> > On Wed, 29 Nov 2017 at 23:46:00 -0600, Steve Robbins wrote:
> > > On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > > > Hi,
> > > >
> > > > Sorry for the rej
On Thursday, November 30, 2017 11:26:31 AM CST Simon McVittie wrote:
> On Wed, 29 Nov 2017 at 23:46:00 -0600, Steve Robbins wrote:
> > On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > > Hi,
> > >
> > > Sorry for the rejection but "Copyright: See individual source files"
> > > unf
On Thursday, 30 November 2017 11:26:31 CET Simon McVittie wrote:
> For a large package, gathering the list of copyright holders from
> the source into debian/copyright is clearly a lot of work.
For what it's worth, the amount of work can be reduced using 'cme update dpkg-
copyright' [1] (other too
On Wed, 29 Nov 2017 at 23:46:00 -0600, Steve Robbins wrote:
> On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > Hi,
> >
> > Sorry for the rejection but "Copyright: See individual source files"
> > unfortunatley does not meet the high standards we strive for within Debian.
>
> [Fo
summarizing copyrights. Boost has nearly 55000 files in the
source distribution. What could one possibly achieve by summarizing this?
How would anyone even read and make sense of it?
Has copyright summarizing outlived its usefulness for large sources? Why
shouldn't we have some way to
36 matches
Mail list logo
