Andrey Rahmatullin writes:
> On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote:
>> I always use this as one argument when it comes to "Why should be care
>> about Debian? Our users use something else", that packaging includes a
>> careful review and documentation of the copyright.
> Us
Quoting Andreas Tille (2016-08-17 10:55:01)
> On Tue, Aug 16, 2016 at 10:13:30PM +0500, Andrey Rahmatullin wrote:
> > On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote:
> > > I always use this as one argument when it comes to "Why should be care
> > > about Debian? Our users use somethi
On Tue, Aug 16, 2016 at 10:13:30PM +0500, Andrey Rahmatullin wrote:
> On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote:
> > I always use this as one argument when it comes to "Why should be care
> > about Debian? Our users use something else", that packaging includes a
> > careful revi
Quoting Andrew Shadura (2016-08-16 19:57:05)
>
>
> On 16 August 2016 at 14:32, Ian Jackson
> wrote:
> > Jonas Smedegaard writes ("Re: copyright precision"):
> >> Quoting Markus Koschany (2016-08-15 23:02:06)
> >> > So yes, copyright files are ha
On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote:
> I always use this as one argument when it comes to "Why should be care
> about Debian? Our users use something else", that packaging includes a
> careful review and documentation of the copyright.
Usually only for the initial upload,
On Tue, Aug 16, 2016 at 03:25:24PM +0100, Ian Jackson wrote:
> Normally what a potential user needs to know is the effective licence
> of the whole thing.
Note that we don't even try to declare the license of *binaries we are
shipping* and, unless I'm mistaken, the license of a library you are goin
Quoting Ian Jackson (2016-08-16 15:32:55)
> Jonas Smedegaard writes ("Re: copyright precision"):
>> Quoting Markus Koschany (2016-08-15 23:02:06)
>>> So yes, copyright files are hard and unfun but why should we
>>> continue to write them the way we do if w
On 16/08/16 16:21, Jonas Smedegaard wrote:
Quoting Ian Jackson (2016-08-16 15:32:19)
Ghostscript packaged for Debian has a debian/copyright file with ~400
lines enumerating which source files are covered by which license (and
then another ~800 lines covering the actual licenses verbatim).
Fedo
Jonas Smedegaard writes ("Re: copyright precision"):
> Quoting Ian Jackson (2016-08-16 15:32:19)
> > In the end up looked at the package's upstream web pages, which
> > contained a clear answer to the question.
>
> How was the approach¹ not successful? Didn&#x
Quoting Ian Jackson (2016-08-16 15:32:19)
> Andreas Tille writes ("Re: copyright precision"):
>> On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote:
>>> It's at least worth a discussion whether nitpicking at d/copyright
>>> is really helpi
Jonas Smedegaard writes ("Re: copyright precision"):
> Quoting Markus Koschany (2016-08-15 23:02:06)
> > So yes, copyright files are hard and unfun but why should we continue
> > to write them the way we do if we are not legally bound to do so?
>
> Same reason
Andreas Tille writes ("Re: copyright precision"):
> On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote:
> > It's at least worth a discussion whether nitpicking at d/copyright is
> > really helping the package quality at all, and if it's wort
Andrey Rahmatullin writes:
> It's at least worth a discussion whether nitpicking at d/copyright is
> really helping the package quality at all, and if it's worth it.
I see here another reason -- and an argument actually *for* Debian
packaging (being different from, f.e. MacPorts or Conda):
Detai
Scott Kitterman writes:
> Personally, I think the bulk of the reason we should care about
> debian/copyright is to achieve license compliance.
For this, IMO the licensing information is not just enough, since it
does not document how our binaries are licensed.
For example, a source package may
On Tue, Aug 16, 2016 at 11:30:34AM +0200, Andreas Tille wrote:
> > > Not because we are legally bound to do so, but because we want to do our
> > > job as distributors properly. We appreciate good quality packaging!
> > It's at least worth a discussion whether nitpicking at d/copyright is
> > rea
Quoting Andrey Rahmatullin (2016-08-16 07:59:09)
> On Tue, Aug 16, 2016 at 01:10:42AM +0200, Jonas Smedegaard wrote:
>>> So yes, copyright files are hard and unfun but why should we
>>> continue to write them the way we do if we are not legally bound to
>>> do so?
>>
>> Same reason that we should
On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote:
> > Not because we are legally bound to do so, but because we want to do our
> > job as distributors properly. We appreciate good quality packaging!
> It's at least worth a discussion whether nitpicking at d/copyright is
> really
On Tue, Aug 16, 2016 at 01:10:42AM +0200, Jonas Smedegaard wrote:
> > So yes, copyright files are hard and unfun but why should we continue
> > to write them the way we do if we are not legally bound to do so?
>
> Same reason that we should continue to care about ability to install
> multiple ma
Quoting Markus Koschany (2016-08-15 23:02:06)
> So yes, copyright files are hard and unfun but why should we continue
> to write them the way we do if we are not legally bound to do so?
Same reason that we should continue to care about ability to install
multiple major versions of a library conc
On 15.08.2016 21:50, Scott Kitterman wrote:
> On Monday, August 15, 2016 05:59:43 PM Simon McVittie wrote:
>> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
>>> The problem we're having here is clearly about *tooling*. If we had a
>>> good toolchain to compile and audit machine-re
On Monday, August 15, 2016 05:59:43 PM Simon McVittie wrote:
> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
> > The problem we're having here is clearly about *tooling*. If we had a
> > good toolchain to compile and audit machine-readable debian/copyright
> > files without sweat
On Mon, Aug 15, 2016 at 05:59:43PM +0100, Simon McVittie wrote:
> * If we had a good toolchain to compile and audit this stuff, people
> and companies who want to know the copyright holders could just use
> that to inspect the upstream source code and cut out the middle-man.
I've comment on th
On Mon, Aug 15, 2016 at 10:53:53AM -0700, Nikolaus Rath wrote:
> > * If we had a good toolchain to compile and audit this stuff, people
> > and companies who want to know the copyright holders could just use
> > that to inspect the upstream source code and cut out the middle-man.
>
> I think e
On Aug 15 2016, Simon McVittie wrote:
> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
>> The problem we're having here is clearly about *tooling*. If we had a
>> good toolchain to compile and audit machine-readable debian/copyright
>> files without sweating, nobody would complai
On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote:
> The problem we're having here is clearly about *tooling*. If we had a
> good toolchain to compile and audit machine-readable debian/copyright
> files without sweating, nobody would complain.
I have three slightly devil's-advocate r
On Fri, Aug 12, 2016 at 02:19:43AM +0200, gregor herrmann wrote:
> AFAIK there are plans around sources.d.n to use the d/copyright files
> in Copyright-Format 1.0. Currently they are browsable at
> https://sources.debian.net/copyright/ but IIRC some more analysis is
> planned.
We do have downstre
Hi Joachim and Simon,
On Thu, Aug 11, 2016 at 01:25:14PM -0400, Joachim Breitner wrote:
>
> I question the value of precise debian/copyright files, or at least
> question the effort-to-value ratio. The legal situation is generally
> not affected by whether we have course or fine copyright files,
Simon McVittie writes ("Re: copyright precision"):
> On Wed, 10 Aug 2016 at 22:51:47 +0100, Ian Jackson wrote:
> > I certainly don't feel I personally want to put doing this
> > work anywher enear the top of my personal Debian todo list list
>
> I think what y
On Fri, Aug 12, 2016 at 5:42 AM, Dmitry Bogatov wrote:
> [2016-08-11 21:09] Moritz Mühlenhoff
>>
>> Simon McVittie schrieb:
>> > In particular, if this thread comes to the conclusion that more needs to
>> > be done than what maintainers currently do, then it should be something
>> > actionable;
>>
On Thu, 11 Aug 2016 13:25:14 -0400, Joachim Breitner wrote:
> And to
> the best of my knowledge, our copyright files are not used in any
> systematic way. (If they were, this would add value and add motivation
> to work on this, and with machine-readable copyright files, it might
> happen some day
[2016-08-11 21:09] Moritz Mühlenhoff
>
> Simon McVittie schrieb:
> > In particular, if this thread comes to the conclusion that more needs to
> > be done than what maintainers currently do, then it should be something
> > actionable;
>
> Or we could rather automate the generation of debian/copyri
Simon McVittie schrieb:
> In particular, if this thread comes to the conclusion that more needs to
> be done than what maintainers currently do, then it should be something
> actionable;
Or we could rather automate the generation of debian/copyright entirely
by letting fossology detect all the co
On Wed, 10 Aug 2016 at 22:51:47 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Re: copyright precision"):
> > Self-imposed policy of documenting copyright information:
>
> Personally, I think it would be much better if binary packages had
> accurate centrally
Hi,
Am Mittwoch, den 10.08.2016, 17:30 +0100 schrieb Simon McVittie:
> For software with a reasonably helpful upstream and a reasonably sane
> build system, I've often found that jumping through the necessary
> hoops to write debian/copyright takes about as long as the rest of the
> packaging put
On Wed, Aug 10, 2016 at 5:21 AM, Paul Wise wrote:
> On Wed, Aug 10, 2016 at 6:34 AM, Helmut Grohne wrote:
>
>> Other packages that don't build from source by default include bash,
>> dash, debianutils, dpkg, e2fsprogs, findutils, fribidi, gmp, jemalloc,
>> libatomic-ops, libbsd, libtasn1-6, lzo2,
Simon McVittie writes ("Re: copyright precision"):
> I'm sure this is a very interesting academic exercise, but pragmatically,
> why do we want to require ourselves to go to all that effort? For that
> matter, is everything we require *now* necessary or desirable?
T
On Wed, 10 Aug 2016 at 11:12:55 +0800, Paul Wise wrote:
> The only possible way to solve this in general terms is, accurate
> document the copyright/license of the source package using the
> machine-readable format and during builds, track the transformation of
> input files in the source package t
Helmut Grohne writes ("Re: copyright precision"):
> On Tue, Aug 09, 2016 at 06:37:37PM +0100, Ian Jackson wrote:
> > Perl's Configure is not a very useful example and has IMO some
> > justification. I think it's poor engineering to have edited the
> > ou
Helmut Grohne writes ("Re: copyright precision"):
> On Tue, Aug 09, 2016 at 07:45:16PM +0200, Thorsten Alteholz wrote:
> > So if there is a problem, shouldn't we start to solve it instead of just
> > ignoring it? Wouldn't it be better to set high stand
Hi,
Quoting Paul Wise (2016-08-10 05:12:55)
> The only possible way to solve this in general terms is, accurate document
> the copyright/license of the source package using the machine-readable format
> and during builds, track the transformation of input files in the source
> package to output fi
On Wed, Aug 10, 2016 at 6:34 AM, Helmut Grohne wrote:
> Other packages that don't build from source by default include bash,
> dash, debianutils, dpkg, e2fsprogs, findutils, fribidi, gmp, jemalloc,
> libatomic-ops, libbsd, libtasn1-6, lzo2, ncurses, nettle, patch,
> readline6, and sed.
I would ad
On Wed, Aug 10, 2016 at 1:14 AM, Helmut Grohne wrote:
> But it is actually worse than that. We don't even list copyright for
> what is contained in binary packages.
It isn't hard to do for packages that don't copy anything from other
binary packages, I did this for libicns:
https://sources.debia
On Tue, Aug 09, 2016 at 06:37:37PM +0100, Ian Jackson wrote:
> > But it is actually worse than that. We don't even list copyright for
> > what is contained in binary packages. For instance, libjs-sphinxdoc
>^^
> Did you mean to write "source" ?
Yes, thanks.
> > It seem
On Tue, Aug 09, 2016 at 07:45:16PM +0200, Thorsten Alteholz wrote:
> So if there is a problem, shouldn't we start to solve it instead of just
> ignoring it? Wouldn't it be better to set high standards instead of being
> guided by convenience?
Documenting problems only makes sense when there is a r
On Tue, 9 Aug 2016, Helmut Grohne wrote:
Dropping most of the Cc list as we move to general handling of similar
issues.
On Tue, Aug 09, 2016 at 01:30:39PM +0100, Ian Jackson wrote:
ISTM that in situations where Built-Using is arguably relevant, there
is also often a requirement to make sure
Helmut Grohne writes ("copyright precision"):
> Dropping most of the Cc list as we move to general handling of similar
> issues.
>
> On Tue, Aug 09, 2016 at 01:30:39PM +0100, Ian Jackson wrote:
> > ISTM that in situations where Built-Using is arguably relevant, there
> > is also often a requiremen
46 matches
Mail list logo
