Re: Sponsorship requirements and copyright files
Ben Finney
> After a discussion on #debian-mentors and other places, I will not
> sponsor packages using the copyright file format described on
> http://wiki.debian.org/Proposals/CopyrightFormat
For those who weren't present when you were having that IRC
discussion, can you point us to archived discussions so that we can
see the points raised and discussed?
> It is a too complex, overengineered solution to a very minor issue.
I find it very surprising that someone can be a Debian developer and
consider copyright of works to be “a very minor issue” in Debian.
Perhaps I've misinterpreted this statement. What do you mean by that?
> It is not easy readables for humans
> It is ugly
Can you point to a proposal (on another page) for an alternate format
that you feel passes these tests?
> Too time consuming to write and check
I find the structure makes it far easier to write and check than the
free-form chaos of many existing files. What would you have removed
from the format to reduce the time for writing and checking it?
> No real gain.
This allows any proposed gains to then be excluded under “not a real
gain”, of course [0]. What gains have you seen proposed, that are not
real gains by your standard? What *would* be a real gain by your
standard?
> Discussions about this is welcome, but I think debian-devel is a
> better forum for that.
Agreed; followup fields set.
[0] http://www.infidels.org/library/modern/mathew/logic.html#scots
--
\ “How many people here have telekenetic powers? Raise my hand.” |
`\ —Emo Philips |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Neil Williams
Ben Finney <ben+d...@benfinney.id.au> wrote:
> Sune Vuorela <nos...@vuorela.dk> writes:
>
> > After a discussion on #debian-mentors and other places, I will not
> > sponsor packages using the copyright file format described on
> > http://wiki.debian.org/Proposals/CopyrightFormat
>
> For those who weren't present when you were having that IRC
> discussion, can you point us to archived discussions so that we can
> see the points raised and discussed?
I don't have a log, I'm afraid - don't know whether anyone else kept it.
I've updated my own sponsoring requirements:
http://people.debian.org/~codehelp/#copyright
> > It is a too complex, overengineered solution to a very minor issue.
>
> I find it very surprising that someone can be a Debian developer and
> consider copyright of works to be “a very minor issue” in Debian.
The minor issue is the machine-operable format - I don't think Suno or
any other sponsor considers debian/copyright itself as minor in any
way. The format of debian/copyright is a minor issue, in so far as it
does not impinge on accuracy. Where the format reduces human
readability, I consider that a fault that I would rather avoid.
> Can you point to a proposal (on another page) for an alternate format
> that you feel passes these tests?
A point during the early stage of that wiki page, something similar to
what I currently use for one of my own packages (tslib).
The wiki is probably the main problem - the objective has been lost in
the subsequent edits.
It surprised me just how far back I had to go to see what I thought was
the version I was using:
http://wiki.debian.org/Proposals/CopyrightFormat?action=recall&rev=50
I may actually have been using a version earlier than that by the looks
of it too.
(Current revision is somewhere > 500)
> > Too time consuming to write and check
>
> I find the structure makes it far easier to write and check than the
> free-form chaos of many existing files. What would you have removed
> from the format to reduce the time for writing and checking it?
I completely disagree - the current version of the wiki page is
utterly incomprehensible and inconsistent. It's no wonder that
maintainers coming to debian-mentors are confused.
> > Discussions about this is welcome, but I think debian-devel is a
> > better forum for that.
Agreed.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Ben Finney
> On Fri, 20 Mar 2009 08:33:41 +1100
> Ben Finney <ben+d...@benfinney.id.au> wrote:
>
> > I find the structure [in the proposed copyright file format] makes
> > it far easier to write and check than the free-form chaos of many
> > existing files. What would you have removed from the format to
> > reduce the time for writing and checking it?
>
> I completely disagree - the current version of the wiki page is
> utterly incomprehensible and inconsistent.
That's a non sequitur; the morass of discussion on that wiki page
*obscures* the format for someone trying to read it, but is not *part
of* the format. The format itself has (IMO) the properties I
described.
> It's no wonder that maintainers coming to debian-mentors are
> confused.
Certainly, but only (I argue) because the wiki page is currently a
mess.
The page mentions, in several places now, the desire to set up a
discussion forum to continue the discussion away from the page; once
that's set up I'll be happy to pitch in and clear the weeds from that
page.
--
\ “Always code as if the guy who ends up maintaining your code |
`\ will be a violent psychopath who knows where you live.” —John |
_o__) F. Woods |
Ben Finney
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Neil Williams
Ben Finney <ben+d...@benfinney.id.au> wrote:
> Neil Williams <code...@debian.org> writes:
>
> > On Fri, 20 Mar 2009 08:33:41 +1100
> > Ben Finney <ben+d...@benfinney.id.au> wrote:
> >
> > > I find the structure [in the proposed copyright file format] makes
> > > it far easier to write and check than the free-form chaos of many
> > > existing files. What would you have removed from the format to
> > > reduce the time for writing and checking it?
> >
> > I completely disagree - the current version of the wiki page is
> > utterly incomprehensible and inconsistent.
>
> That's a non sequitur; the morass of discussion on that wiki page
> *obscures* the format for someone trying to read it, but is not *part
> of* the format. The format itself has (IMO) the properties I
> described.
Without being able to read and understand the page, the format is
completely invisible. Therefore, the structure in the proposed file
format makes it impossible to write or check copyright files because
the format itself is invisible. I disagree that the structure is easier
to write or check than the free-form existing files because there is no
structure that I can identify. There is no clear, concise and usable
description of "properties" that is identifiable in the current page or
anywhere else I've found so far. It's been lost in the edits.
> > It's no wonder that maintainers coming to debian-mentors are
> > confused.
>
> Certainly, but only (I argue) because the wiki page is currently a
> mess.
The wiki page is all anyone has right now. It would probably be better
to remove it and do whatever work is still required offline (or at
least off the wiki) until those who profess to understand it can come up
with a different document that the rest of us can actually read.
> The page mentions, in several places now, the desire to set up a
> discussion forum to continue the discussion away from the page; once
> that's set up I'll be happy to pitch in and clear the weeds from that
> page.
In the meantime, I think that the whole idea has been drowned in
wiki-overload.
Sune Vuorela
>> It is a too complex, overengineered solution to a very minor issue.
>
> I find it very surprising that someone can be a Debian developer and
> Perhaps I've misinterpreted this statement. What do you mean by that?
PLease read again. I'm not anywhere discussing the *content* of the
copyright file, but the *format*.
one of the issues the format should solve is "automatic detection of
license incompabilities", which is not a big issue today.
>> It is not easy readables for humans
>> It is ugly
>
> Can you point to a proposal (on another page) for an alternate format
> that you feel passes these tests?
I like the current "free for all" format, where you can adapt the format
to the requirements and differences of the packages.
>> Too time consuming to write and check
>
> I find the structure makes it far easier to write and check than the
> free-form chaos of many existing files. What would you have removed
> from the format to reduce the time for writing and checking it?
Try do it with a bit larger package. it does not scale.
I agree that it might not be a big difference on small packages with a
few copyright holders and a simple license situation, but we should
*not* advocate ways of doing things that doesn't scale.
A simple package with a 4 copyright holders and everything gpl takes a
few minutes with "free text format" and maybe 10% more if there is a
specific format to follow.
I think when uploading kde4.2 to unstable, at least 60 developer hours
was put into working on the copyright files, even with loads of help
from various scripts.
Is this the right way to spend developer time? as far as I see it,
developer time is our most valuable resource, and should not be treated
as such.
>> No real gain.
>
> This allows any proposed gains to then be excluded under ???not a real
> gain???, of course [0]. What gains have you seen proposed, that are not
> real gains by your standard? What *would* be a real gain by your
> standard?
A real gain would be something that made tedious work less tedious.
Copyright files are tedious to write. making it more complex will not
improve this.
- and patches to kdebase-workspace/experimental copyright file is most
welcome if it is incorrect.
/Sune
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Josselin Mouette
> I think when uploading kde4.2 to unstable, at least 60 developer hours
> was put into working on the copyright files, even with loads of help
> from various scripts.
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? No other distribution is doing it, it’s useless
for users and it’s a giant waste of developer time. If the only purpose
is to follow American law, well thank you, but I’m not bound by other
laws than those of EU and France, and that makes already many.
I don’t think I’m going to spend any more minute to update this crap.
The next time I see a package REJECTed because of this frivolous reason,
you’ll have to find another mug to do this useless work.
Note: I’m not contesting the need for the license check. This one is
useful, and strictly checking the accuracy of licenses in
debian/copyright is clearly needed. But I don’t think there’s any use
having an up-to-date list of copyright holders in there.
--
.''`. 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.
Ben Finney
> The page mentions, in several places now, the desire to set up a
> discussion forum to continue the discussion away from the page; once
> that's set up I'll be happy to pitch in and clear the weeds from
> that page.
I have cleared away the discussions anyway (to a separate page), and
noted the current lack of a discussion forum. Hopefully the
specification is now less cluttered, at least.
--
\ “Politics is not the art of the possible. It consists in |
`\ choosing between the disastrous and the unpalatable.” —John |
_o__) Kenneth Galbraith, 1962-03-02 |
Ben Finney
> On 2009-03-19, Ben Finney <ben+d...@benfinney.id.au> wrote:
> >> It is a too complex, overengineered solution to a very minor issue.
> >
> > I find it very surprising that someone can be a Debian developer and
> > consider copyright of works to be ???a very minor issue??? in Debian.
> > Perhaps I've misinterpreted this statement. What do you mean by that?
>
> PLease read again. I'm not anywhere discussing the *content* of the
> copyright file, but the *format*.
>
> one of the issues the format should solve is "automatic detection of
> license incompabilities", which is not a big issue today.
That would be a minor issue. I haven't seen anyone propose it.
What I have seen is the proposal that this file should be
automatically *parseable*. This is IMO a big issue, because it means
the difference between hunting manually through unstructured copyright
information that can get hideously complex (as you describe below),
versus the potential with automatically-parsed information to
structure, index, search, and otherwise manage the information more
powerfully and efficiently, thus saving valuable human time.
> I like the current "free for all" format, where you can adapt the
> format to the requirements and differences of the packages.
Do you feel this benefit outweighs the lack of dependable structure,
that currently imposes all the work of filtering and parsing the file
on the human reading it?
> > I find the [proposed format] structure makes it far easier to
> > write and check than the free-form chaos of many existing files.
> > What would you have removed from the format to reduce the time for
> > writing and checking it?
>
> Try do it with a bit larger package. it does not scale.
This surely applies even more to a free-format dump area for copyright
information.
> I think when uploading kde4.2 to unstable, at least 60 developer
> hours was put into working on the copyright files, even with loads
> of help from various scripts.
You are of the opinion, then, that it would be *harder* to work with
the masses of copyright information for that package if the
information was in a regular, well-specified structure?
I'm not saying that the current draft of the specification meets that
description; but I can't see how what you say is anything but an
argument *for* a well-structured copyright file format.
> Is this the right way to spend developer time? as far as I see it,
> developer time is our most valuable resource, and should not be
> treated as such.
Certainly, the time of people is valuable. I would like to see a
format that is structured such that it's easier than free-format text
to navigate, and makes it possible to write tools to automate many of
the associated tasks that you say take up too much time.
> A real gain would be something that made tedious work less tedious.
> Copyright files are tedious to write. making it more complex will
> not improve this.
I argue that a well-designed structure significantly *reduces* the
natural tendency for free-format text to become even more complex.
--
\ “To me, boxing is like a ballet, except there's no music, no |
`\ choreography, and the dancers hit each other.” —Jack Handey |
_o__) |
Ben Finney
Ben Finney
> Note: I’m not contesting the need for the license check. This one is
> useful, and strictly checking the accuracy of licenses in
> debian/copyright is clearly needed. But I don’t think there’s any
> use having an up-to-date list of copyright holders in there.
You don't think the correct copyright status information should be in
the package at all? Or you don't think it should be in a single
documented location?
--
\ “Pinky, are you pondering what I'm pondering?” “I think so, but |
`\ where will we find an open tattoo parlor at this time of |
_o__) night?” —_Pinky and The Brain_ |
Ben Finney
Russ Allbery
>> Note: I’m not contesting the need for the license check. This one is
>> useful, and strictly checking the accuracy of licenses in
>> debian/copyright is clearly needed. But I don’t think there’s any use
>> having an up-to-date list of copyright holders in there.
> You don't think the correct copyright status information should be in
> the package at all? Or you don't think it should be in a single
> documented location?
I'm not sure it needs to be anywhere at all, except for those notices that
are legally required by the license to be preserved. In some cases, that
does include the copyright statements, but it doesn't always. If the
upstream license doesn't require that we preserve the copyright statement
(or if upstream doesn't have them), I'm not sure we need to be requiring
that they be collected into debian/copyright.
I could be missing something, though.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ben Finney
> If the upstream license doesn't require that we preserve the
> copyright statement (or if upstream doesn't have them), I'm not sure
> we need to be requiring that they be collected into
> debian/copyright.
I am working from the assumption that we need, at least in principle,
to maintain an accurate knowledge of the copyright status of the works
we distribute in Debian. I base that assumption on the necessity of
that information when evaluating claims (made against the Debian
project) of copyright infringement in those works.
If ignorance of the copyright status of a work were a valid defense,
that would certainly obviate the burden for a distributor to actively
maintain accurate copyright status knowledge in the works they
distribute. I don't think that's true, though.
--
\ “Two possibilities exist: Either we are alone in the Universe |
`\ or we are not. Both are equally terrifying.” —Arthur C. Clarke, |
_o__) 1999 |
Ben Finney
Russ Allbery
>> If the upstream license doesn't require that we preserve the copyright
>> statement (or if upstream doesn't have them), I'm not sure we need to
>> be requiring that they be collected into debian/copyright.
> I am working from the assumption that we need, at least in principle, to
> maintain an accurate knowledge of the copyright status of the works we
> distribute in Debian. I base that assumption on the necessity of that
> information when evaluating claims (made against the Debian project) of
> copyright infringement in those works.
Why? Serious question -- as I say, I could be missing something.
I can't imagine when the debian/copyright file would ever be useful in
that respect. If someone actually threatens litigation, surely we'd have
to look at the specific files and review the notices therein, and outside
of that, I don't see why it ever matters to us which named people or
organizations hold the copyright on files as long as there's a clear
license. But maybe I'm having a failure of imagination?
(Also, there's no such thing as a claim against the Debian project per se,
since there is no legal entity corresponding to "the Debian project," but
that's a side point.)
> If ignorance of the copyright status of a work were a valid defense,
> that would certainly obviate the burden for a distributor to actively
> maintain accurate copyright status knowledge in the works they
> distribute. I don't think that's true, though.
I don't really follow the logic. Copyright notices are pretty much
irrelevant for copyright claims, at least in Berne countries, so far as I
understand it. They only affect damages in the US, for instance, and then
only in really unusual circumstances. What matters is knowledge of the
license the work is released under.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Steve Langasek
> > Can you point to a proposal (on another page) for an alternate format
> > that you feel passes these tests?
> A point during the early stage of that wiki page, something similar to
> what I currently use for one of my own packages (tslib).
> The wiki is probably the main problem - the objective has been lost in
> the subsequent edits.
It is a significant problem, and indeed the text of the wiki page makes it
explicit that the current formulation is not grounded in consensus - there
are multiple comments requesting a revert to the overall approach used prior
to revision #253.
I'm in the process of attempting to address this by migrating this messy
discussion into a DEP, as was proposed last December on debian-devel.
Results of this should be available in a couple of days.
This doesn't at all imply that I'm happy with the current state of the draft
in the wiki, I think it needs some drastic improvement before it's going to
be widely adopted within Debian. But AFAICS the proposed format has
remained largely unchanged even though the wiki draft has gone all pear
shaped, and I think that format generally serves the purpose it's supposed
to, i.e., to be machine-parseable and human-readable.
--
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 Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Romain Beauxis
> > Is this the right way to spend developer time? as far as I see it,
> > developer time is our most valuable resource, and should not be
> > treated as such.
>
> Certainly, the time of people is valuable. I would like to see a
> format that is structured such that it's easier than free-format text
> to navigate, and makes it possible to write tools to automate many of
> the associated tasks that you say take up too much time.
Was there any intent of writting such a tool at some point ?
Most of the specifications also deduce from an actual implementation, which
also helps people who don't want to follow the multiple revisions to check
and convert their files..
I always have been waiting from some sort of validation tools from the people
that want to push for this before considering converting my files...
Romain
Ben Finney
> Ben Finney <ben+d...@benfinney.id.au> writes:
> > I am working from the assumption that we need, at least in
> > principle, to maintain an accurate knowledge of the copyright
> > status of the works we distribute in Debian. I base that
> > assumption on the necessity of that information when evaluating
> > claims (made against the Debian project) of copyright infringement
> > in those works.
>
> Why? Serious question -- as I say, I could be missing something.
I'm not sure what your “why” specifically refers to. I'll assume
it's entirely covered by your following paragraph.
> I can't imagine when the debian/copyright file would ever be useful
> in that respect. If someone actually threatens litigation, surely
> we'd have to look at the specific files and review the notices
> therein
Yes, and that necessity is entirely predictable when we begin
packaging the work, and while we maintain newer releases of that work.
> and outside of that, I don't see why it ever matters to us which
> named people or organizations hold the copyright on files as long as
> there's a clear license. But maybe I'm having a failure of
> imagination?
The point is that, since we can predict the need for this information,
we have the choice of assuming the information is there when we
distribute and never looking for it until the need arises in the face
of such a threat, or looking for it in advance of distribution and
hence in advance of exposure to that threat. I think it's clear that
the latter option is preferable.
On that basis, it would be foolish having *already* checked carefully
that the copyright status is accurately known to then discard that
information rather than recording it in a single documented location
for others to verify.
The only alternatives that seems to be on offer are either not
checking the copyright information is accurate before distributing, or
not recording what we learn in that check for later verification that
the check was done at all. I argue that both of those are inferior to
doing the check before distributing, and recording the result of that
check in a single documented location.
> > If ignorance of the copyright status of a work were a valid
> > defense, that would certainly obviate the burden for a distributor
> > to actively maintain accurate copyright status knowledge in the
> > works they distribute. I don't think that's true, though.
>
> I don't really follow the logic. Copyright notices are pretty much
> irrelevant for copyright claims, at least in Berne countries, so far
> as I understand it.
Yes. That only leads to the ludicrous, but entirely real, situation
that we are in: it is incumbent on any distributor of a work to
establish that they have license to do what they're doing from the
copyright holders, which necessarily means knowing who *are* the
copyright holders in the work.
> What matters is knowledge of the license the work is released under.
Which necessitates knowledge of who is empowered to grant that
license: i.e. the full set of copyright holders in the work.
Collecting copyright notices isn't a requirement under copyright law:
works that are copyright-restricted continue to be so with or without
the notice. But unless we have the information typically contained in
such notices, we are operating completely in the dark as to who is
empowered to restrict distribution or grant it.
--
\ “It is well to remember that the entire universe, with one |
`\ trifling exception, is composed of others.” —John Andrew Holmes |
_o__) |
Ben Finney
Steve Langasek
> Russ Allbery <r...@debian.org> writes:
> > If the upstream license doesn't require that we preserve the
> > copyright statement (or if upstream doesn't have them), I'm not sure
> > we need to be requiring that they be collected into
> > debian/copyright.
> I am working from the assumption that we need, at least in principle,
> to maintain an accurate knowledge of the copyright status of the works
> we distribute in Debian. I base that assumption on the necessity of
> that information when evaluating claims (made against the Debian
> project) of copyright infringement in those works.
We have 13,000 packages in the archive. A trivial subset of these packages
are ever the subject of concerns over copyright infringement. Why would we
want to do the work up front for all the packages instead of doing it
as-needed for a handful of packages, if this is the only benefit? Using
this format for debian/copyright is *not* the same thing as auditing the
copyright, it's simply recording what we know about the copyright, which is
essentially "what upstream tells us". Putting it in a different format
doesn't significantly affect the likelihood of someone claiming their
copyright has been infringed and forcing us to do more research.
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.
--
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 Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Russ Allbery
> The point is that, since we can predict the need for this information,
> we have the choice of assuming the information is there when we
> distribute and never looking for it until the need arises in the face of
> such a threat, or looking for it in advance of distribution and hence in
> advance of exposure to that threat. I think it's clear that the latter
> option is preferable.
Er, I'm certainly not going to pay any attention who the copyright holders
are for various files in something I'm packaging. I care about the
license; why should I care in the slightest whether the listed copyright
holder is one name or some other name?
I certainly don't have the resources to verify personally that the person
who is listed as the copyright holder is actually the legal copyright
holder or has the legal right to distribute the work under that license.
In practice, we basically always do simple checks and react to reported
problems and otherwise take upstream at their word.
> On that basis, it would be foolish having *already* checked carefully
> that the copyright status is accurately known to then discard that
> information rather than recording it in a single documented location for
> others to verify.
Why? Seriously, who cares?
Given how rare a legal issue is, I can't imagine ever not going back to
the source and reviewing the source files, no matter how debian/copyright
is maintained. I don't see how accumulated copyright information in
debian/copyright would ever be useful or used in that case.
> The only alternatives that seems to be on offer are either not checking
> the copyright information is accurate before distributing,
I definitely do not check whether the copyright information in source
files for my packages is accurate before distributing. I don't know how I
could even do such a thing.
For example, GNU Backgammon's gtkgame.c file says that it is:
* by Gary Wong <g...@gnu.org>, 2000, 2001, 2002.
I have absolutely no idea if that is true. I don't, so far as I know,
have any way of checking whether that is true or not. If I copy that
information into debian/copyright, I'm doing so mechanically. I'm not
adding any value to just searching through the source tree for such
strings.
In fact this particular file does not have a valid copyright notice under
US law. I don't see any reason to believe that's a problem (nor do I even
see any reason to bother upstream about it -- such notices are recommended
when applying the GPL, but they're not required under US law and are
largely irrelevant for copyright law). The package as a whole displays a
copyright notice on startup:
Copyright, 1999-2004 by Gary Wong, 2004-2008 GNU Backgammon is the
legal property of its authors.
which is, of course, preserved following the requirements of the GPL.
> Yes. That only leads to the ludicrous, but entirely real, situation that
> we are in: it is incumbent on any distributor of a work to establish
> that they have license to do what they're doing from the copyright
> holders, which necessarily means knowing who *are* the copyright holders
> in the work.
See above. I don't believe that we do that except in a few rare cases,
and I don't believe anyone else who distributes free software does
either. To a first approximation, everyone just takes upstream's word for
it.
> Collecting copyright notices isn't a requirement under copyright law:
> works that are copyright-restricted continue to be so with or without
> the notice. But unless we have the information typically contained in
> such notices, we are operating completely in the dark as to who is
> empowered to restrict distribution or grant it.
I fail to see how collecting strings from the source files leaves us any
less in the dark about whether the claimed authors are legally empowered
to license it.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Ben Finney
> Ben Finney <ben+d...@benfinney.id.au> writes:
>
> > The point is that, since we can predict the need for this
> > information, we have the choice of assuming the information is
> > there when we distribute and never looking for it until the need
> > arises in the face of such a threat, or looking for it in advance
> > of distribution and hence in advance of exposure to that threat. I
> > think it's clear that the latter option is preferable.
>
> Er, I'm certainly not going to pay any attention who the copyright
> holders are for various files in something I'm packaging. I care
> about the license; why should I care in the slightest whether the
> listed copyright holder is one name or some other name?
The name isn't important, so long as it names a legal entity that you
have reason to believe is a copyright holder in the work.
You seem to be arguing against the distributor confirming whether what
upstream claims to be the set of copyright holders is actually true;
that's not what I'm saying needs to be done.
> > The only alternatives that seems to be on offer are either not
> > checking the copyright information is accurate before
> > distributing,
>
> I definitely do not check whether the copyright information in
> source files for my packages is accurate before distributing. I
> don't know how I could even do such a thing.
The “check whether the copyright information is accurate” that I
refer to is only checking that what the redistributor *thinks* is the
set of copyright holders matches with what upstream *says* is the set
of copyright holders.
I'm certainly not advocating redistributors must investigate the truth
of every copyright statement. I'm arguing only that a redistributor
has the burden under the law of obtaining a redistribution license
from the copyright holders, and therefore has the burden of knowing
who *are* the copyright holders in order that the license has come
from them.
That information, of course, comes from whoever we call upstream,
which may be the copyright holders themselves, or could be another
redistributor, or could be come more complex set. Those sets *change
over time*. The information of who are the copyright holders *for a
particular release* will often be different from the previous release:
pieces of a work of differing copyright holders are removed or added,
and thus the set of copyright holders in that work changes its
members.
The point being that upstream informs us of who the copyright holders
are; if they don't what reason have we to believe they have right to
redistribute to us? Having received that information, we have a
documented place to record it so it can be verified as a question
answered.
Steve Langasek <vor...@debian.org> writes:
> Using this format for debian/copyright is *not* the same thing as
> auditing the copyright, it's simply recording what we know about the
> copyright, which is essentially "what upstream tells us".
I hope it's clear that I agree with this entirely.
--
\ “Software patents provide one more means of controlling access |
`\ to information. They are the tool of choice for the internet |
_o__) highwayman.” —Anthony Taylor |
Ben Finney
Mike O'Connor
> 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.
>
> 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".
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.
stew
Daniel Moerner
> 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 agree. The thing that I like about creating packages with the
wiki.d.o specification is that it forces you to actually examine the
copyrights of all the parts of a new package, instead of just use a
lazy link to /usr/share/common-licenses/foo. This is especially
important for packages that have many different hidden scripts or
architecture-independent libraries that might have different licenses.
With the kind of copyright file generated by dh_make, it seems like
new maintainers often ignore the risk of a package with a tainted,
unredistributable license problem.
In shorter words: I think something should be done about the copyright
file to encourage developers to actually perform an audit of the
license status of files in their packages before they upload. The
current copyright template doesn't really encourage this; I like the
machine-parseable system because it makes it easy to organize such an
audit.
Daniel
--
Daniel Moerner <dmoe...@gmail.com>
Sune Vuorela
> 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.
It is a very trivial, but very time consuming task to document the
copyright holders.
$ find . -name '*.cpp' | wc --lines
923
$ find . -name '*.h' | wc --lines
1001
find all the well formed copyright holder headers:
$ grep -rhi Copyright * | grep "@"| sed 's/\*//g;s/#//g;s,/,,g;s/
//g;s/^ //' | sort -u | wc --lines
444
and then there is all the not well formed ones who needs to be manually
found, and ordered into a copyright file of any format.
And this is just looking at one of my source packages.
Trying to take another example, a bit bigger, but one who until now get
special treatment by ftp team copyright file wise:
linux-2.6-2.6.28$ find . -name '*.h' | wc --lines
9654
$ find . -name '*.c' | wc --lines
10807
$ grep -rhi Copyright * | grep "@"| sed 's/\*//g;s/#//g;s,/,,g;s/
//g;s/^ //' | sort -u | wc --lines
3066
"not any time at all" ...
Mike Hommey
> On Thu, Mar 19, 2009 at 10:19 PM, Mike O'Connor <st...@debian.org> wrote:
> > 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 agree. The thing that I like about creating packages with the
> wiki.d.o specification is that it forces you to actually examine the
> copyrights of all the parts of a new package, instead of just use a
> lazy link to /usr/share/common-licenses/foo. This is especially
> important for packages that have many different hidden scripts or
> architecture-independent libraries that might have different licenses.
> With the kind of copyright file generated by dh_make, it seems like
> new maintainers often ignore the risk of a package with a tainted,
> unredistributable license problem.
>
> In shorter words: I think something should be done about the copyright
> file to encourage developers to actually perform an audit of the
> license status of files in their packages before they upload. The
> current copyright template doesn't really encourage this; I like the
> machine-parseable system because it makes it easy to organize such an
> audit.
Try doing that on iceweasel or xulrunner. Hint: there are about 30000
files and a real lot of copyright holders.
It's already a PITA with webkit, which is about 3000 files and quite a
lot of copyright holders (the copyright file, which I'm pretty sure is
not accurate is 809 lines and growing at each new release).
On top of listing copyright holders, I must say listing the individual
files for each license in the copyright file is also a major PITA. While
wildcards can be used, a huge mix of license like webkit is makes it
really painful to update. OTOH, I really don't care what files are under
what licence. I *do* know that there is a mix of BSD-2, BSD-3 and LGPL
code, plus some extra libraries embedded, and that any addition to
webkit is licensed under BSD or LGPL because upstream does enforce that
(except, obviously, embedded libraries, but we already have to check if
any is added to avoid duplication and build against the system one
whenever possible)
Mike
Manoj Srivastava
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?)
So, I just reproduce that copyright notice in the binary
package, which is all that one is required to do. I might also add
other obvious contributor names, if the appear in other files in the
package, but this is mostly the first time I package stuff. I might
miss names added or new files in a new version, though I try.
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.
manoj
--
He who takes nothing in the world that has not been given him, long or
short, big or small, attractive or that is what I call a brahmin. 409
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Ben Finney
> On 2009-03-20, Mike O'Connor <st...@debian.org> wrote:
> > 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.
>
> It is a very trivial, but very time consuming task to document the
> copyright holders.
>
> $ find . -name '*.cpp' | wc --lines
> 923
> $ find . -name '*.h' | wc --lines
> 1001
>
> find all the well formed copyright holder headers:
> $ grep -rhi Copyright * | grep "@"| sed 's/\*//g;s/#//g;s,/,,g;s/
> //g;s/^ //' | sort -u | wc --lines
> 444
>
> and then there is all the not well formed ones who needs to be
> manually found, and ordered into a copyright file of any format.
>
> And this is just looking at one of my source packages.
All of what you've demonstrated is part of what Mike covered with
“one has to go through all of the source files anyway”, is it not?
The point I got from his message is that, having *already* accepted
the burden of going through all the files, one can then record the
copyright status while doing that.
> > Unless you are not actually looking at the code you upload, which
> > would worry me for other reasons as well.
Are you proposing some third option?
--
\ “Our products just aren't engineered for security.” —Brian |
`\ Valentine, senior vice-president of Microsoft Windows |
_o__) development |
Ben Finney
Mike O'Connor
> On Fri, Mar 20 2009, Mike O'Connor wrote:
>
> >>
> >> 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".
> >
> 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?)
>
Yes, Manoj, thanks for the clarification. I didn't intend to imply that
I believed that this statement in the license is a requirement to hunt
down all contributors. I agree that it rather clearly indicates "ABOVE"
copyright statements. I meant to point out to Joss, who was seeming to
imply that copyright notices shouldn't be required at all in
debian/copyright, that there are clear cases when they are required.
stew
Lars Wirzenius
> Was there any intent of writting such a tool at some point ?
> Most of the specifications also deduce from an actual implementation, which
> also helps people who don't want to follow the multiple revisions to check
> and convert their files..
>
> I always have been waiting from some sort of validation tools from the people
> that want to push for this before considering converting my files...
I'm writing a Python library that will make it easy to write tools to
use copyright files. Once Steve gets DEP-5 going, I'll share my ideas
for the library.
Sune Vuorela
> All of what you've demonstrated is part of what Mike covered with
> The point I got from his message is that, having *already* accepted
> the burden of going through all the files, one can then record the
> copyright status while doing that.
So far, comaintainers of gnome, kde, webkit, xulrunner and firefox are
saying that this is a major extra burden.
The kernel team seems to have a full waiver for listing copyright
holders.
So please listen to the packagers of "big" packages what is a burden and
what is not.
Trying to look over Ben Finney's packages, the most complex package is
"gracie", where Ben is upstream. It is a python package consisting of
1000 lines of sourcecode + 3000 lines of test code. (according to
sloccount). Except a single file in the test code, everything is by Ben.
Trying to look over some of Mike O'Connor's packages, kxstitch and rosegarden,
Kxstitch with one upstream author and bunches of autogenerated
files. (the sources are available and the generated tools are GPL, so no
real problem, but just not 'good style'). The copyright file does
mention this one author.
Rosegarden is having many copyright holders, only 3 is mentioned in the
copyright file. Most files have a copyright header stating "Copyright is
Rosegarden development team", so all in all not that complex from a
copyright file point of view. Still, there is many copyright holders
missing from debian/copyright.
If anyone wants to actually try working with copyright files for one of
those "bigger" packages, Mike O'Connor helpfulyl just opened #520485 to
track one of them. Patches are welcome.
/Sune
Ben Finney
> On 2009-03-20, Ben Finney <ben+d...@benfinney.id.au> wrote:
> > All of what you've demonstrated is part of what Mike covered with
> > ???one has to go through all of the source files anyway???, is it
> > not? The point I got from his message is that, having *already*
> > accepted the burden of going through all the files, one can then
> > record the copyright status while doing that.
>
> So far, comaintainers of gnome, kde, webkit, xulrunner and firefox
> are saying that this is a major extra burden.
What is “this” that you refer to, though? Going through the files
that one is proposing to distribute? Or recording their copyright
status as one goes? That's a key distinction that I'm not seeing
addressed in your objection.
--
\ “I met my girlfriend in Macy's; she was buying clothes, and I |
`\ was putting Slinkies on the escalators.” —Steven Wright |
_o__) |
Ben Finney
Mike Hommey
>
> Copyright (\([cC]\)|©) Year[-Year] Name Email
>
> It shouldn't be too hard to write a tool to scan the whole source tree
> and spit out a completely generated summary of copyright holders. If
> this could be added to an existing tool, such as licensecheck, this
> would save everyone from reimplementing it in their package (I was
> considering doing this).
Licensecheck already checks that, though you have to give it an option
for that, but it fails to catch anything that doesn't match such pattern,
and I can tell you there are a lot... I invite you to take a look at a few
.cpp files from xulrunner or iceweasel, you'll see you won't get much with
your pattern, and that you can't reliably get these holders with a pattern.
Roger Leigh
Given that copyrights are usually in a standard format, such as
Copyright (\([cC]\)|©) Year[-Year] Name Email
It shouldn't be too hard to write a tool to scan the whole source tree
and spit out a completely generated summary of copyright holders. If
this could be added to an existing tool, such as licensecheck, this
would save everyone from reimplementing it in their package (I was
considering doing this).
Of course, this does depend on the files being completely up-to-date,
otherwise this is useless. As an upstream, I would say that while I do
make an effort to keep these up to date, not every contributor does an
so information will be missing. This is ultimately all stored in the
git commits, so trawling though the repo might be needed to actually
make an accurate header in each file.
Regards,
Roger
Charles Plessy
Le Thu, Mar 19, 2009 at 04:40:33PM +0000, Sune Vuorela a écrit :
> http://wiki.debian.org/Proposals/CopyrightFormat
>
> It is a too complex, overengineered solution to a very minor issue.
> It is not easy readables for humans
> It is ugly
> Too time consuming to write and check
> No real gain.
Hi Sune,
Ugliness was already reported earlier by Christoph Berg, and I think that the
only reason why his points have not been integrated in the wiki page is because
his comments came after a consensus emerged that the page was overloaded and
that we would first change the discussion medium before resuming discussions
and modifications.
I am quite confident that readability can be much improved. See for instance
the copyrignt file of the perl packages created with recent versions of
dh-make-perl, like the following one:
In my opinion, it is already quite nice and readable compared to dh-make's
template, that starts by dealing about "debianization" before going to the most
important: the main license of the package. Nevertheless, we could probably
slim the machine-readable version down to something like:
------------------------
Name: File-Find-Object
Maintainer: Olivier Thauvin <shl...@iglu.org.il>
Source: http://search.cpan.org/dist/File-Find-Object/
Copyright: © 2009, Olivier Thauvin <shl...@iglu.org.il>
License: Artistic or GPL-1+
License: Artistic
This program is free software; you can redistribute it and/or modify
it under the terms of the Artistic License, which comes with Perl.
On Debian GNU/Linux systems, the complete text of the Artistic License
can be found in `/usr/share/common-licenses/Artistic'
License: GPL-1+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 1, or (at your option)
any later version.
On Debian GNU/Linux systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL'
Files: debian/*
Copyright: 2009, Alejandro Garrido Mota <garri...@gmail.com>
License: Artistic or GPL-1+
Format-Specification: Machine-readable copyright declaration version 1
------------------------
Do not hesitate to make suggestions, there is no doubt the proposal can be
impoved !
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Josselin Mouette
> If anyone wants to actually try working with copyright files for one of
> those "bigger" packages, Mike O'Connor helpfulyl just opened #520485 to
> track one of them. Patches are welcome.
How thoughtful of his.
Hint: you can open such a bug on each and every GNOME package that
hasn’t gone through NEW in the 2.24 cycle.
--
.''`. 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.
Romain Beauxis
> Le vendredi 20 mars 2009 à 08:28 +0000, Sune Vuorela a écrit :
> > If anyone wants to actually try working with copyright files for one of
> > those "bigger" packages, Mike O'Connor helpfulyl just opened #520485 to
> > track one of them. Patches are welcome.
>
> How thoughtful of his.
>
> Hint: you can open such a bug on each and every GNOME package that
> hasn’t gone through NEW in the 2.24 cycle.
There was at some point a discussion about a collaborative copyright
proofread.
I think this would be a great improvement in our workflow. What was the
conclusion of this proposal ?
Romain
Noah Slater
> On 2009-03-20, Ben Finney <ben+d...@benfinney.id.au> wrote:
> > All of what you've demonstrated is part of what Mike covered with
> > ???one has to go through all of the source files anyway???, is it not?
> > The point I got from his message is that, having *already* accepted
> > the burden of going through all the files, one can then record the
> > copyright status while doing that.
>
> So far, comaintainers of gnome, kde, webkit, xulrunner and firefox are
> saying that this is a major extra burden.
>
> The kernel team seems to have a full waiver for listing copyright
> holders.
>
> So please listen to the packagers of "big" packages what is a burden and
> what is not.
No one is saying it isn't a chore.
As a maintainer, it is your duty to make sure that everything you upload is DFSG
free, which means checking every single file. As you have to do this anyway, it
makes sense to record that information in debian/copyright. If you maintain a
very large package, then you should *expect* this to take a long time.
If that's too much effort for your, get a co-maintainer or a different package.
--
Noah Slater, http://tumbolia.org/nslater
Noah Slater
> > In shorter words: I think something should be done about the copyright
> > file to encourage developers to actually perform an audit of the
> > license status of files in their packages before they upload. The
> > current copyright template doesn't really encourage this; I like the
> > machine-parseable system because it makes it easy to organize such an
> > audit.
>
> Try doing that on iceweasel or xulrunner. Hint: there are about 30000
> files and a real lot of copyright holders.
It behoves us as distributors to check, no matter how hard it is.
If you think that sounds like too much work, maintain a different package.
> On top of listing copyright holders, I must say listing the individual
> files for each license in the copyright file is also a major PITA. While
> wildcards can be used, a huge mix of license like webkit is makes it
> really painful to update. OTOH, I really don't care what files are under
> what licence. I *do* know that there is a mix of BSD-2, BSD-3 and LGPL
> code, plus some extra libraries embedded, and that any addition to
> webkit is licensed under BSD or LGPL because upstream does enforce that
> (except, obviously, embedded libraries, but we already have to check if
> any is added to avoid duplication and build against the system one
> whenever possible)
You might not care, but the package users might do.
--
Noah Slater, http://tumbolia.org/nslater
Noah Slater
> Ben Finney <ben+d...@benfinney.id.au> writes:
>
> > The point is that, since we can predict the need for this information,
> > we have the choice of assuming the information is there when we
> > distribute and never looking for it until the need arises in the face of
> > such a threat, or looking for it in advance of distribution and hence in
> > advance of exposure to that threat. I think it's clear that the latter
> > option is preferable.
>
> Er, I'm certainly not going to pay any attention who the copyright holders
> are for various files in something I'm packaging. I care about the
> license; why should I care in the slightest whether the listed copyright
> holder is one name or some other name?
Of course, this isn't just about the legal issues.
Including the copyright statement is a form of attribution, and is good manners.
I also see that the copyright file is primarily useful to end users who may want
a convenient way of browsing the copyright and licence information.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Josselin Mouette
> As a maintainer, it is your duty to make sure that everything you upload is DFSG
> free, which means checking every single file. As you have to do this anyway, it
> makes sense to record that information in debian/copyright. If you maintain a
> very large package, then you should *expect* this to take a long time.
>
> If that's too much effort for your, get a co-maintainer or a different package.
Fine. Do you have co-maintainers on sale?
Josselin Mouette
> Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit :
> > Fine. Do you have co-maintainers on sale?
>
> different task.
Do you really think we can find an unlimited amount of volunteers
willing to continuously read thousands of files to find the list of
copyright holders?
Romain Beauxis
> > package.
>
> Fine. Do you have co-maintainers on sale?
It is not about co-maintaining, but about co-reviewing which is a totally
different task.
Romain
Noah Slater
> Le vendredi 20 mars 2009 à 13:02 +0100, Romain Beauxis a écrit :
> > Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit :
> > > Fine. Do you have co-maintainers on sale?
> >
> > It is not about co-maintaining, but about co-reviewing which is a totally
> > different task.
>
> Do you really think we can find an unlimited amount of volunteers
> willing to continuously read thousands of files to find the list of
> copyright holders?
Nobody said anything about needing an unlimited amount of collaborators.
However, it is required that we check every single file we upload to the Debian
archives, so this task has to be done in some form or another. If you feel like
your current packages are too much effort, maybe you should look for
collaborators on them to ease the ask.
If we cannot do this simple thing, maybe we shouldn't be distributing software.
--
Noah Slater, http://tumbolia.org/nslater
Romain Beauxis
> > It is not about co-maintaining, but about co-reviewing which is a totally
> > different task.
>
> Do you really think we can find an unlimited amount of volunteers
> willing to continuously read thousands of files to find the list of
> copyright holders?
I mean that asking for co-mainenance is a different thing than asking for a
review of the copyright stuff.
If you ask me for co-maintaining one of your package, I might surely say no
because I don't want to be involved in the long term, but on the contrary
reviewing copyright stuff can be a one shot.
Besides, there is no technical requirement to do this, not even to understand
the build system or what the software is about..
This idea of a public reviewing page for NEWly uploaded packages really looked
appealing to me.
Mike Hommey
> On Fri, Mar 20, 2009 at 01:07:44PM +0100, Josselin Mouette wrote:
> > Le vendredi 20 mars 2009 à 13:02 +0100, Romain Beauxis a écrit :
> > > Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit :
> > > > Fine. Do you have co-maintainers on sale?
> > >
> > > It is not about co-maintaining, but about co-reviewing which is a totally
> > > different task.
> >
> > Do you really think we can find an unlimited amount of volunteers
> > willing to continuously read thousands of files to find the list of
> > copyright holders?
>
> Nobody said anything about needing an unlimited amount of collaborators.
>
> However, it is required that we check every single file we upload to the Debian
> archives, so this task has to be done in some form or another. If you feel like
> your current packages are too much effort, maybe you should look for
> collaborators on them to ease the ask.
Do you know how many calls for help have been thrown on the BTS, debian-devel
and other places for mozilla, kde, openoffice and other big packages ?
We, big-packages maintainers, are still waiting for collaborators...
Sometimes, I wonder if the only way for that to happen wouldn't be to stop
updating the package at all. (and apparently, it, sadly, kind of worked with
iceape, though I still have to contact the volunteer)
Mike
Mike Hommey
> Le Friday 20 March 2009 13:07:44 Josselin Mouette, vous avez écrit :
> > > It is not about co-maintaining, but about co-reviewing which is a totally
> > > different task.
> >
> > Do you really think we can find an unlimited amount of volunteers
> > willing to continuously read thousands of files to find the list of
> > copyright holders?
>
> I mean that asking for co-mainenance is a different thing than asking for a
> review of the copyright stuff.
>
> If you ask me for co-maintaining one of your package, I might surely say no
> because I don't want to be involved in the long term, but on the contrary
> reviewing copyright stuff can be a one shot.
>
> Besides, there is no technical requirement to do this, not even to understand
> the build system or what the software is about..
>
>
> This idea of a public reviewing page for NEWly uploaded packages really looked
> appealing to me.
On the other hand, when you look at projets such as Mozilla or Webkit, there
are people already doing that upstream, or ensuring things are done properly
at commit time. Why should we duplicate that effort, especially considering
how much work it represents for teams that are already undermanned.
Mike
Romain Beauxis
> > This idea of a public reviewing page for NEWly uploaded packages really
> > looked appealing to me.
>
> On the other hand, when you look at projets such as Mozilla or Webkit,
> there are people already doing that upstream, or ensuring things are done
> properly at commit time. Why should we duplicate that effort, especially
> considering how much work it represents for teams that are already
> undermanned.
I don't mean duplicate work.
To me, the essence of copyright reviewing remains in the level of trust that
you put in the guys that did the job. If you think your upstream is doing
this seriously, then it could be fine.
But, more generaly, when dealing with trust, the only suitable way to pretend
that you are seriously adressing an issue is to have a process which is
openly reviewable. You do not pretend that each interested collaborator is
going review it any time, but you publicaly challenge anyone to check your
work.
At least that is how I understand "we will not hide our issues".
Why shouldn't this work also for copyright reviewing in debian packages ? If
you think of it, when people commit a patch to a project, it is acked by some
guys and then considered as reviewed. That is also how it works in my work
(research) when we publish papers.
Why couldn't it exists a public page for reviewing copyright, for which
interested developpers could send a signed ACK claiming they have reviewed
the copyright file and that it is ok for them (or not...), including the
ftpmasters themselves.
This could of course be mitigated by some degree of trust, like considering
that ftpmasters are more reliable in checking details for a particular
uncommon license.
But for the vast majority of packages, this would be sufficent to decide on
the acceptation or not of a NEW package.
Romain
Mike Hommey
> On Fri, Mar 20, 2009 at 07:46:11AM +0100, Mike Hommey wrote:
> > > In shorter words: I think something should be done about the copyright
> > > file to encourage developers to actually perform an audit of the
> > > license status of files in their packages before they upload. The
> > > current copyright template doesn't really encourage this; I like the
> > > machine-parseable system because it makes it easy to organize such an
> > > audit.
> >
> > Try doing that on iceweasel or xulrunner. Hint: there are about 30000
> > files and a real lot of copyright holders.
>
> It behoves us as distributors to check, no matter how hard it is.
>
> If you think that sounds like too much work, maintain a different package.
If you don't stop writing crap like this, I really think I *will* stop
maintaining these packages.
Mike
Noah Slater
> > It behoves us as distributors to check, no matter how hard it is.
> >
> > If you think that sounds like too much work, maintain a different package.
>
> If you don't stop writing crap like this, I really think I *will* stop
> maintaining these packages.
I don't see what your problem is.
If we were suggesting some totally arbitrary and time consuming task, then I
could understand your concerns. However, you should be checking each file as a
part of your packaging, all that is being requested is that you document this
for the FTP masters and our users.
The focus here should be on producing quality software, with a rigorous and open
process, so that people can be confident that what we're shipping is totally
free software. Cutting corners to save a bit of time, simply because a package
is large, does not seem to fit well with this goal. Hence my suggestion that if
a package you are maintaining seems like too much work, perhaps it would make
sense to collaboratively maintain it.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Josselin Mouette
> If we were suggesting some totally arbitrary and time consuming task, then I
> could understand your concerns. However, you should be checking each file as a
> part of your packaging, all that is being requested is that you document this
> for the FTP masters and our users.
>
> The focus here should be on producing quality software, with a rigorous and open
> process, so that people can be confident that what we're shipping is totally
> free software. Cutting corners to save a bit of time, simply because a package
> is large, does not seem to fit well with this goal. Hence my suggestion that if
> a package you are maintaining seems like too much work, perhaps it would make
> sense to collaboratively maintain it.
What is your problem? Do you want to see whether Mike can become violent
if you press him hard enough, or is it another kind of experiment?
Mike Hommey
> On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote:
> > > It behoves us as distributors to check, no matter how hard it is.
> > >
> > > If you think that sounds like too much work, maintain a different package.
> >
> > If you don't stop writing crap like this, I really think I *will* stop
> > maintaining these packages.
>
> I don't see what your problem is.
>
> If we were suggesting some totally arbitrary and time consuming task, then I
> could understand your concerns. However, you should be checking each file as a
> part of your packaging, all that is being requested is that you document this
> for the FTP masters and our users.
>
> The focus here should be on producing quality software, with a rigorous and open
> process, so that people can be confident that what we're shipping is totally
> free software. Cutting corners to save a bit of time, simply because a package
> is large, does not seem to fit well with this goal. Hence my suggestion that if
> a package you are maintaining seems like too much work, perhaps it would make
> sense to collaboratively maintain it.
No, look at the text I quoted : you suggested to maintain a different package.
Now, as I said earlier in this thread, there have been several calls for
help on those big packages that *are* a problem to do the scan you would
like to see on all packages, yet, nobody joined teams as a result.
Following your advice, we should stop maintaining openoffice, iceweasel,
xulrunner, kde, and who knows what other packages because nobody cares
enough to scan tens of thousands of source files for copyright holders.
That does sound like a plan.
Mike
Noah Slater
> Le vendredi 20 mars 2009 à 14:02 +0000, Noah Slater a écrit :
> > If we were suggesting some totally arbitrary and time consuming task, then I
> > could understand your concerns. However, you should be checking each file as a
> > part of your packaging, all that is being requested is that you document this
> > for the FTP masters and our users.
> >
> > The focus here should be on producing quality software, with a rigorous and open
> > process, so that people can be confident that what we're shipping is totally
> > free software. Cutting corners to save a bit of time, simply because a package
> > is large, does not seem to fit well with this goal. Hence my suggestion that if
> > a package you are maintaining seems like too much work, perhaps it would make
> > sense to collaboratively maintain it.
>
> What is your problem? Do you want to see whether Mike can become violent
> if you press him hard enough, or is it another kind of experiment?
Why do you find it necessary to be so aggressive with me?
I fail to see which part of my argument you think is inflammatory or ridiculous:
* It is already your responsibility as a Debian package maintainer to
thoroughly check each and every file for copyright and licensing issues.
* If you maintain a large package, this must already be a burden for you.
* Documenting this process in a text file does not seem like much extra work.
* Complaining that you would have to check every single file implies that you
don't already check every single file, which you should be doing.
* Therefor, complaining that this is hard work and collaborators are hard to
come by, seems like a completely orthogonal issue to the copyright proposal.
This doesn't mean that I am doubting how much work the bigger packages are, or
that it isn't hard finding collaborators. I have a lot of respect for the people
who offer there time to get this job done. On the other hand, this rationally
has nothing to do with the copyright proposal, presuming that everyone is
already following policy.
Noah Slater
> No, look at the text I quoted : you suggested to maintain a different package.
Yes, out of several emails I sent to the list, you selected a single sentence.
I apologise if you got the wrong message from what I had written, it was not
meant as a personal attack. On the other hand, saying that maintaining packages
can be time consuming seems like such an obvious thing, I wonder why people are
bringing it up - unless they mean to suggest that we should cut corners when
rigorously checking free software made available for distribution.
> Now, as I said earlier in this thread, there have been several calls for
> help on those big packages that *are* a problem to do the scan you would
> like to see on all packages, yet, nobody joined teams as a result.
I appreciate the difficulties you might be experiencing here.
The distinction I was trying to draw is that this matter is totally unrelated to
the copyright documentation we keep in the packages. Considering that it is
already our mandate to check every single file, this is already a problem for
you. Sure, you have a lot to deal with, and finding collaborators is hard, but
using this as a flimsy reason to disregard the copyright proposal seems absurd.
> Following your advice, we should stop maintaining openoffice, iceweasel,
> xulrunner, kde, and who knows what other packages because nobody cares
> enough to scan tens of thousands of source files for copyright holders.
You selectively chose one thing I had written, please don't do that.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Raphael Hertzog
> On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote:
> > > It behoves us as distributors to check, no matter how hard it is.
> > >
> > > If you think that sounds like too much work, maintain a different package.
> >
> > If you don't stop writing crap like this, I really think I *will* stop
> > maintaining these packages.
>
> I don't see what your problem is.
You are requesting work from other volunteers and it's bad taste to do so.
> If we were suggesting some totally arbitrary and time consuming task, then I
> could understand your concerns. However, you should be checking each file as a
> part of your packaging, all that is being requested is that you document this
> for the FTP masters and our users.
Those checks have not always been part of the requirements. And I'm not
convinced they are always needed.
We should document the various licenses used in the source package, we
should maybe also document the default license for new code added upstream
but I don't see the point of collecting a list of copyright holders and
keeping it up-to-date.
We should be able to trust by default upstream authors on the license
claim, maintainers should be encouraged to audit their packages when
possible but we should not blame them for not having it done. After all we
have ftpmasters who are doing it anyway. Of course, if you know you have a
bad upstream you might want to be more careful than one that is very
strict in its patch integration policy.
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/
Mike Hommey
> On Fri, Mar 20, 2009 at 03:13:29PM +0100, Mike Hommey wrote:
> > No, look at the text I quoted : you suggested to maintain a different package.
>
> Yes, out of several emails I sent to the list, you selected a single sentence.
That you actually felt stroing enough to type twice, which pissed me off.
See <2009032011...@tumbolia.org> if you don't remember suggesting
to maintain a different package.
Mike
Ben Finney
> On Fri, Mar 20, 2009 at 12:20:14PM +0000, Noah Slater <nsl...@tumbolia.org> wrote:
> > However, it is required that we check every single file we upload
> > to the Debian archives, so this task has to be done in some form
> > or another. If you feel like your current packages are too much
> > effort, maybe you should look for collaborators on them to ease
> > the ask.
>
> Do you know how many calls for help have been thrown on the BTS,
> debian-devel and other places for mozilla, kde, openoffice and other
> big packages ?
>
> We, big-packages maintainers, are still waiting for collaborators...
Noah Slater <nsl...@tumbolia.org> writes:
> I don't see what your problem is.
It seems that the problem is that “look for collaborators” is what
they're already doing, without apparent impact on the problem at hand
(the workload involved in copyright auuditing of the package), so
presenting it as a novel course of action isn't helpful.
> Hence my suggestion that if a package you are maintaining seems like
> too much work, perhaps it would make sense to collaboratively
> maintain it.
That doesn't appear to be in dispute at all. Yet, by Mike's account,
these packages continue to lack sufficient collaborators.
--
\ “All progress has resulted from people who took unpopular |
`\ positions.” —Adlai Stevenson |
_o__) |
Ben Finney
Noah Slater
> On Fri, 20 Mar 2009, Noah Slater wrote:
> > On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote:
> > > > It behoves us as distributors to check, no matter how hard it is.
> > > >
> > > > If you think that sounds like too much work, maintain a different package.
> > >
> > > If you don't stop writing crap like this, I really think I *will* stop
> > > maintaining these packages.
> >
> > I don't see what your problem is.
>
> You are requesting work from other volunteers and it's bad taste to do so.
I accept your point, but I think that this is a bad framing.
People have been complaining about the copyright proposal costing too much time.
Aside from pointing out that this is presumably time you were already spending
checking each file, a good solution is collaborative maintenance.
Not sure what else you expect someone to respond with apart from throwing their
hands up and conceding that we should adopt policy to conform with peoples wish
to avoid additional work.
--
Noah Slater, http://tumbolia.org/nslater
Mike Hommey
> On Fri, Mar 20, 2009 at 03:14:36PM +0100, Josselin Mouette wrote:
> > Le vendredi 20 mars 2009 à 14:02 +0000, Noah Slater a écrit :
> > > If we were suggesting some totally arbitrary and time consuming task, then I
> > > could understand your concerns. However, you should be checking each file as a
> > > part of your packaging, all that is being requested is that you document this
> > > for the FTP masters and our users.
> > >
> > > The focus here should be on producing quality software, with a rigorous and open
> > > process, so that people can be confident that what we're shipping is totally
> > > free software. Cutting corners to save a bit of time, simply because a package
> > > is large, does not seem to fit well with this goal. Hence my suggestion that if
> > > a package you are maintaining seems like too much work, perhaps it would make
> > > sense to collaboratively maintain it.
> >
> > What is your problem? Do you want to see whether Mike can become violent
> > if you press him hard enough, or is it another kind of experiment?
>
> Why do you find it necessary to be so aggressive with me?
>
> I fail to see which part of my argument you think is inflammatory or ridiculous:
>
> * It is already your responsibility as a Debian package maintainer to
> thoroughly check each and every file for copyright and licensing issues.
>
> * If you maintain a large package, this must already be a burden for you.
>
> * Documenting this process in a text file does not seem like much extra work.
>
> * Complaining that you would have to check every single file implies that you
> don't already check every single file, which you should be doing.
If all the above were true, no package of xulrunner, iceweasel, openoffice,
kde and others would have *EVER* entered the archive, since there has
*NEVER* been such work done on these packages, and until this funky new
copyright showed up, that did bother *NOONE*, including the ftpmasters.
> * Therefor, complaining that this is hard work and collaborators are hard to
> come by, seems like a completely orthogonal issue to the copyright proposal.
If you want those copyright files to be thourough, I invite you to download
one of the packages above's source, and start checking those tens of
thousands of files. See you in three months to see where you are at it,
and throw you some more new upstream releases.
> This doesn't mean that I am doubting how much work the bigger packages are, or
> that it isn't hard finding collaborators. I have a lot of respect for the people
> who offer there time to get this job done. On the other hand, this rationally
> has nothing to do with the copyright proposal, presuming that everyone is
> already following policy.
It has all to do with it, since you are suggesting that the copyright
proposal is sane even for big packages, changes nothing to the current
status quo, which, as I said above is far from being true, and that
$SOMEPEOPLE should do their homework or move to other packages.
Mike
Noah Slater
> > I don't see what your problem is.
>
> It seems that the problem is that “look for collaborators” is what
> they're already doing, without apparent impact on the problem at hand
> (the workload involved in copyright auuditing of the package), so
> presenting it as a novel course of action isn't helpful.
Well, that is great then. Obviously, I was not aware of this.
My argument still stands though. This has nothing to do with the new copyright
proposal. All this proposal does is cement what is already policy, and what
packagers should already be doing. If the community thinks that policy is at
fault, this should be discussed as a separate matter.
As it stands, I see that people are effectively arguing that the copyright
proposal should be abandoned because it is enforcing an aspect of policy that
people don't wish to follow. All I am doing is suggesting that either we throw
out this argument, or fix the policy.
--
Noah Slater, http://tumbolia.org/nslater
Mike Hommey
> On Sat, Mar 21, 2009 at 01:46:51AM +1100, Ben Finney wrote:
> > > I don't see what your problem is.
> >
> > It seems that the problem is that “look for collaborators” is what
> > they're already doing, without apparent impact on the problem at hand
> > (the workload involved in copyright auuditing of the package), so
> > presenting it as a novel course of action isn't helpful.
>
> Well, that is great then. Obviously, I was not aware of this.
>
> My argument still stands though. This has nothing to do with the new copyright
> proposal. All this proposal does is cement what is already policy, and what
> packagers should already be doing. If the community thinks that policy is at
> fault, this should be discussed as a separate matter.
>
> As it stands, I see that people are effectively arguing that the copyright
> proposal should be abandoned because it is enforcing an aspect of policy that
> people don't wish to follow. All I am doing is suggesting that either we throw
> out this argument, or fix the policy.
Point me to the paragraph in the policy that says that the copyright file
must list all copyright holders and licensing info for all individual files
in the source package.
Let me help you: there is no such paragraph.
Mike
Noah Slater
> That you actually felt stroing enough to type twice, which pissed me off.
> See <2009032011...@tumbolia.org> if you don't remember suggesting
> to maintain a different package.
Well, there are only three solutions, and I have suggested them all.
If you find the current work a burden, you could maintain a different package,
try to find collaborators, or lobby to get policy changed. I wasn't suggesting
any were preferable, or that you hadn't tried. I really don't care either way.
My goal was to draw the focus away from the copyright proposal, which is only
codifying existing policy.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Noah Slater
> Point me to the paragraph in the policy that says that the copyright file
> must list all copyright holders and licensing info for all individual files
> in the source package.
>
> Let me help you: there is no such paragraph.
So what on earth has this to do with the copyright proposal?
If you wish to make blanket statements using the copyright proposal, what is
stopping you? All we wanted to do is develop a format so that copyright
information was both machine and human readable. If the FTP masters are happy
with your current work, there should be no reason why you can't express what you
are already doing with the new copyright proposal.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Noah Slater
> > * Complaining that you would have to check every single file implies that you
> > don't already check every single file, which you should be doing.
>
> If all the above were true, no package of xulrunner, iceweasel, openoffice,
> kde and others would have *EVER* entered the archive, since there has
> *NEVER* been such work done on these packages, and until this funky new
> copyright showed up, that did bother *NOONE*, including the ftpmasters.
> If you want those copyright files to be thourough, I invite you to download
> one of the packages above's source, and start checking those tens of
> thousands of files. See you in three months to see where you are at it,
> and throw you some more new upstream releases.
>
> > This doesn't mean that I am doubting how much work the bigger packages are, or
> > that it isn't hard finding collaborators. I have a lot of respect for the people
> > who offer there time to get this job done. On the other hand, this rationally
> > has nothing to do with the copyright proposal, presuming that everyone is
> > already following policy.
>
> It has all to do with it, since you are suggesting that the copyright
> proposal is sane even for big packages, changes nothing to the current
> status quo, which, as I said above is far from being true, and that
> $SOMEPEOPLE should do their homework or move to other packages.
Actually, the copyright proposal is just a text format, not a policy document.
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 <nsl...@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.
Note, this is an actual snipped from the couchdb package.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Manoj Srivastava
> No one is saying it isn't a chore.
>
> As a maintainer, it is your duty to make sure that everything you
> upload is DFSG free, which means checking every single file. As you
> have to do this anyway, it makes sense to record that information in
> debian/copyright. If you maintain a very large package, then you
> should *expect* this to take a long time.
I don't care for copyright notices, really. I care for license
statements; and I take the upstream on trust that the license attached
to the work is valid (since it is hard to determine every copyright
holder -- people who have contributed more than, say, 10 lines of code,
unless we trust the upstream to mention them).
Even otherwise, I would find recording the names in the
copyright notices a partial rendering, irrelevant in a copyright
challenge, and too much work for what it is worth.
> If that's too much effort for your, get a co-maintainer or a different
> package.
Frankly, for such lack of collegiality, one could arguably
suggest you seek another project, neh? However, to keep this civil, I
will just say:
Patches welcome, as long as they come with a verification toll
as well.
In the meanwhile, I'll record Licenses and file to which they
apply, and copyright holders will be opportunistically captured.
manoj
--
[Babe] Ruth made a big mistake when he gave up pitching. Tris Speaker,
1921
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Michael Banck
> On Fri, Mar 20, 2009 at 04:12:37PM +0100, Mike Hommey wrote:
> > Point me to the paragraph in the policy that says that the copyright file
> > must list all copyright holders and licensing info for all individual files
> > in the source package.
> >
> > Let me help you: there is no such paragraph.
>
> So what on earth has this to do with the copyright proposal?
I guess people think the new copyright proposal mandates mentioning the
copyright holders etc. in a much more verbose way than Policy does so
far.
So people consider it a regression with respect to their routine.
disclaimer: I have not reviewed the new copyright proposal.
Michael
Steve Langasek
> The distinction I was trying to draw is that this matter is totally
> unrelated to the copyright documentation we keep in the packages.
> Considering that it is already our mandate to check every single file,
No, it isn't.
On Fri, Mar 20, 2009 at 11:16:58AM +0000, Noah Slater wrote:
> As a maintainer, it is your duty to make sure that everything you upload
> is DFSG free, which means checking every single file.
No, it doesn't.
If I have a good upstream and am confident that the work has been correctly
licensed, there's no reason for me to go through the software file-by-file
just to double-check this.
--
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 Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Noah Slater
> I guess people think the new copyright proposal mandates mentioning the
> copyright holders etc. in a much more verbose way than Policy does so
> far.
>
> So people consider it a regression with respect to their routine.
Great, so it seems we have made progress!
If the consensus is that broad-brush copyright information is suitable for
Debian, we should make it clear in the copyright proposal that people are free
to make that judgement call.
I apologise if I came across as too aggressive, I was only disheartened by what
seemed to be a conflation of separate issues. I see the copyright proposal as a
format, not policy, document. If people want to formalise the granularity of our
copyright information, then so be it, but let's do that as a separate effort.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Noah Slater
> No, it doesn't.
>
> If I have a good upstream and am confident that the work has been correctly
> licensed, there's no reason for me to go through the software file-by-file
> just to double-check this.
As I have been corrected, so apologies are in order.
However, there have been times when I have realised after some time that the
copyright information in the upstream is woefully incomplete or inaccurate. I
had similarly doing blanked declarations in debian/copyright which turned out to
be wrong because I had not checked.
When I found this, I sent the issue upstream:
And I was fortunate that they did a massive overhaul and a re-release.
Best,
--
Noah Slater, http://tumbolia.org/nslater
Josselin Mouette
> I don't care for copyright notices, really. I care for license
> statements; and I take the upstream on trust that the license attached
> to the work is valid (since it is hard to determine every copyright
> holder -- people who have contributed more than, say, 10 lines of code,
> unless we trust the upstream to mention them).
That is clearly the reasonable line to follow. However it has not been
the line of FTP masters for at least a few months now.
Russ Allbery
> Le vendredi 20 mars 2009 à 10:39 -0500, Manoj Srivastava a écrit :
>> I don't care for copyright notices, really. I care for license
>> statements; and I take the upstream on trust that the license attached
>> to the work is valid (since it is hard to determine every copyright
>> holder -- people who have contributed more than, say, 10 lines of
>> code, unless we trust the upstream to mention them).
>
> That is clearly the reasonable line to follow. However it has not been
> the line of FTP masters for at least a few months now.
Policy doesn't provide much guidance here. Currently, you could read
Policy as saying that you have to reproduce all of the copyright notices
from the source (or read it several other ways; it's not very specific).
The requirements in the current REJECT FAQ are not in Policy and should be
if that's what we're enforcing.
Maybe the best resolution to this is to have a broader discussion that
leads to a rewording of Policy 12.5 that makes the requirements explicit,
with ftp-master buy-in on what the requirements are? Then we can all be
on the same page and everyone will know what the requirements really are,
whereas right now there's a lot of grey area. (For example, up until I
started experimenting with the new copyright file format, I never
documented the license or copyright information for any of the
Autotools-generated files, and I never heard a peep of concern about
that.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Kalle Kivimaa
> started experimenting with the new copyright file format, I never
> documented the license or copyright information for any of the
> Autotools-generated files, and I never heard a peep of concern about
> that.)
Currently the ftpmasters don't require those copyrights to be listed
in the debian/copyright.
--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *
Romain Beauxis
> Maybe the best resolution to this is to have a broader discussion that
> leads to a rewording of Policy 12.5 that makes the requirements explicit,
> with ftp-master buy-in on what the requirements are?
> whereas right now there's a lot of grey area.
But do you think this is possible ?
> (For example, up until I
> started experimenting with the new copyright file format, I never
> documented the license or copyright information for any of the
> Autotools-generated files, and I never heard a peep of concern about
> that.)
That's one of the grey corners. So far, my understanding is that they are not
listed because they are only in the source tarball, and also autogenerated.
The usual understanding seems that the licenses of these build scripts are
documented in the corresponding auto* package and that should be sufficient.
As for myself, I don't think we can reach a strict consensus through the
policy, but more likely have some sort of case law that is publicaly
discussed and settled.
Much like the reject FAQ, but where we discuss the motivations all together.
Romain
Romain Beauxis
> > But do you think this is possible ?
>
> after all, and we have a clear authority that does the enforcement
> (ftp-master), so it seems likely that we can reach a clear policy that we
> can document.
Sorry, but there was also an argument below in my message.
The point is that there are possibly a lot of corner cases, such as the
autotools case, for which we can't really decide and list every single issue
or produce a general rational.
Since the vast majority of the packages fall into a regular copyright and
licensing, this would also mean overload the policy with stuff that is only
relevant in a very small number of cases in proportion.
Russ Allbery
>> started experimenting with the new copyright file format, I never
>> documented the license or copyright information for any of the
>> Autotools-generated files, and I never heard a peep of concern about
>> that.)
> Currently the ftpmasters don't require those copyrights to be listed
> in the debian/copyright.
I had a suspicion, but this is exactly the sort of thing that I'd like to
have written down somewhere. (For example, I went and documented them
since I wasn't sure whether it was a good thing to do or not, and I
figured that while I was using the new copyright format, I should give it
a fair shake and try using it literally as written, and there's nothing in
it saying to skip those files.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Russ Allbery
> Le Friday 20 March 2009 19:12:02 Russ Allbery, vous avez écrit :
>> Maybe the best resolution to this is to have a broader discussion that
>> leads to a rewording of Policy 12.5 that makes the requirements
>> explicit, with ftp-master buy-in on what the requirements are? on the
>> same page and everyone will know what the requirements really are,
>> whereas right now there's a lot of grey area.
> But do you think this is possible ?
Sure. Resolving this sort of thing is the point of the Policy process,
after all, and we have a clear authority that does the enforcement
(ftp-master), so it seems likely that we can reach a clear policy that we
can document.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Emilio Pozuelo Monfort
> Le Friday 20 March 2009 19:38:34 Russ Allbery, vous avez écrit :
>>> But do you think this is possible ?
>> Sure. Resolving this sort of thing is the point of the Policy process,
>> after all, and we have a clear authority that does the enforcement
>> (ftp-master), so it seems likely that we can reach a clear policy that we
>> can document.
>
> Sorry, but there was also an argument below in my message.
>
> The point is that there are possibly a lot of corner cases, such as the
> autotools case, for which we can't really decide and list every single issue
> or produce a general rational.
>
> Since the vast majority of the packages fall into a regular copyright and
> licensing, this would also mean overload the policy with stuff that is only
> relevant in a very small number of cases in proportion.
If copyright holder listing isn't needed at all, there's no special-casing
needed for autofoo stuff (wrt copyright listing, not wrt licenses though).
Romain Beauxis
> > Since the vast majority of the packages fall into a regular copyright and
> > licensing, this would also mean overload the policy with stuff that is
> > only relevant in a very small number of cases in proportion.
>
> If copyright holder listing isn't needed at all, there's no special-casing
> needed for autofoo stuff (wrt copyright listing, not wrt licenses though).
But this is also problematic for license !
Even in the case in which we accept my above rational, it is still possible
that the configure.ac contains custom macros with a bad license...
Hence, if we were to decide on a general basis, it would be either to check
for all configure.ac or for no one.. Do you think one of these possibilities
is reasonable ?
Romain Beauxis
> Not sure what else you expect someone to respond with apart from throwing
> their hands up and conceding that we should adopt policy to conform with
> peoples wish to avoid additional work.
You know, if you get some agressive answers to your messages, it is because
you are throwing a moral judgement on the people that do not follow your
views.
I strongly agree with them, I feel upset by this judgement. I do not consider
myself as better than any other packager and I did mistakes when going
through copyright and license check. And thank the ftpmaster for spotting
some of them.
You shouldn't insinuate such claims but try to understand why they think it is
not reasonable.
And it is not reasonable since all of this is about trust. If there were no
trust between us, we wouldn't upload packages to a common pool nor release an
OS. If there were no trust between us and our users, they would download and
check themselves each and every package's sources for copyright and license
compliance.
What those people are telling you is that they proceed the same way with their
upstream, and assume it is a serious statement from them when they claim for
license and copyright.
So, really, nothing about wanting to avoid additional work... Or else, you
checked youself for source availability and license compliance of each and
every free software you installed in your machine... Did you ?
Romain
Russ Allbery
> Sorry, but there was also an argument below in my message.
>
> The point is that there are possibly a lot of corner cases, such as the
> autotools case, for which we can't really decide and list every single
> issue or produce a general rational.
>
> Since the vast majority of the packages fall into a regular copyright
> and licensing, this would also mean overload the policy with stuff that
> is only relevant in a very small number of cases in proportion.
Oh, yes, I agree. However, I think Policy should say what to do about
Autotools at least, since that's a very common case.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Steve Langasek
> On Freitag, 20. März 2009, Sune Vuorela wrote:
> > The kernel team seems to have a full waiver for listing copyright
> > holders.
> AFAIK linux-kbuild-2.6.28 was rejected from NEW for this very reason.
That's not entirely clear. The reject message mentions missing copyright
holders, but also the fact that debian/copyright claims the wrong license
for the package; I'm pretty sure the latter point is considered a blocker,
dunno about the former.
http://lists.debian.org/debian-kernel/2009/02/msg00567.html
--
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 Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Charles Plessy
Le Fri, Mar 20, 2009 at 05:45:11PM +0100, Michael Banck a écrit :
>
> disclaimer: I have not reviewed the new copyright proposal.
Don't, it is not ready. The plan is to submit a DEP "real soon now", in which
the proposal has been proofread and written in a form that is really ment to be
read by a broad audience wihout wasting their time, and to be acceptable as is.
And to confirm one thing: to my knowledge, nobody is planning to make any
change about what is mandatory to include in the Debian copryright file.
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Manoj Srivastava
> On Fri, Mar 20, 2009 at 03:55:30PM +0100, Mike Hommey wrote:
>> That you actually felt stroing enough to type twice, which pissed me off.
>> See <2009032011...@tumbolia.org> if you don't remember suggesting
>> to maintain a different package.
>
> Well, there are only three solutions, and I have suggested them all.
> If you find the current work a burden, you could maintain a different
> package, try to find collaborators, or lobby to get policy changed. I
> wasn't suggesting any were preferable, or that you hadn't tried. I
> really don't care either way. My goal was to draw the focus away from
> the copyright proposal, which is only codifying existing policy.
I have reviewed what current policy says. If I am not mistaken,
the bulk of it is below. Now, we have two terms:
o) copyright and distribution license --- which I do not see as calling
upon us to name every copyright holder;
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.
Now, none of the current policy states anything about trawling
through every file and trying to ascertain who might be a copyright
holder, and listing them in ./debian/copyright. I have some files where
comments have evidence of changes made by people, who left their name
in the comments to claim responsibility, I guess. While reading every
comment in every file to get the name of the author of a snippet might
be laudable, it is not very practical.
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.
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.
manoj
Every package must be accompanied by a verbatim copy of its copyright
and distribution license in the file
`/usr/share/doc/<package>/copyright'. This file must neither be
compressed nor be a symbolic link.
In addition, the copyright file must say where the upstream sources
(if any) were obtained. It should name the original authors of the
package and the Debian maintainer(s) who were involved with its
creation.
Packages in the _contrib_ or _non-free_ archive areas should state in
the copyright file that the package is not part of the Debian
GNU/Linux distribution and briefly explain why.
A copy of the file which will be installed in
`/usr/share/doc/<package>/copyright' should be in `debian/copyright'
in the source package.
`/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. These rules are
important because copyrights must be extractable by mechanical means.
Packages distributed under the UCB BSD license, the Apache license
(version 2.0), the Artistic license, the GNU GPL (version 2 or 3), the
GNU LGPL (versions 2, 2.1, or 3), and the GNU FDL (version 1.2) should
refer to the corresponding files under
`/usr/share/common-licenses',[1] rather than quoting them in the
copyright file.
You should not use the copyright file as a general `README' file. If
your package has such a file it should be installed in
`/usr/share/doc/<package>/README' or `README.Debian' or some other
appropriate place.
--
Two cars in every pot and a chicken in every garage.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Noah Slater
> 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
Thomas Viehmann
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/
Joerg Jaspert
>>> 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):
--8<------------------------schnipp------------------------->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.
--8<------------------------schnapp------------------------->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 ...]
Lars Wirzenius
> 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? :)
Josselin Mouette
> 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.
Manoj Srivastava
> 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 <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> 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 <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> 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 <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Joerg Jaspert
>> 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. (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).
--
bye, Joerg
<pasc> man
<pasc> the AMD64 camp is not helped by the list of people supporting it
<pasc> when nerode is on your side, you know you're doing something wrong
Manoj Srivastava
>>>> 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):
> --8<------------------------schnipp------------------------->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.
> --8<------------------------schnapp------------------------->8---
In each copy of the source code we have the license notices
already, without it ever being in debian/copyright.
The verbatim copy of the programs source code have the copyright
notice, so we meet that. Breinging that into this discussion is a red
herring, and derails discussion on what is required in debian/copyright;
nothing in the GPL ever requires a debian/copyright file at all.
Trust me. Lots of people in the world distribute programs, and
they often do not have debian/copyright files. Copyright law is not
just valid if you are a Debian derivative.
>>> 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.
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.
Now, it might be perfectly fine for the ftp team to impose such
restrictions on packages, and create their own policy; but please at
least say so, and do not hide being hand waving of either copyright law
requiring it (it does not) or Debian policy saying so (which it does
not either).
>> 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).
Why do you think this work is needed? You must have had some
rationale, since you made up this policy.
manoj
--
Hempstone's Question: If you have to travel on the Titanic, why not go
first class?
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Roger Leigh
> 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? :)
I think a standardised machine-readable copyright and licence header
for every source file would be desirable. I do this for all my code.
Most upstreams do use a semi-standard list of copyright holders
followed by licence boilerplate, so it would hopefully only be a case
of fixing up files where a formatting screwup breaks the format.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Josselin Mouette
> 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.
When you spend more time on administrative stuff that no one will ever
care about than on actual packaging stuff, something is very wrong. As I
have already explained, I won’t spend any more time doing that. If you
feel like REJECTing packages because of that, fine. We’ll surely find
some NMs to disgust by doing administrative trivia, and in the meantime
packages will be found on a repository on alioth.
Furthermore, I noticed a few times some wrong *license* statements that
passed through NEW and that I fixed later. I just wish you spent less
time nitpicking on copyright holders if you don’t have the time to check
things that actually matter.
Thanks,
Romain Beauxis
> Now, it might be perfectly fine for the ftp team to impose such
> restrictions on packages, and create their own policy; but please at
> least say so, and do not hide being hand waving of either copyright law
> requiring it (it does not) or Debian policy saying so (which it does
> not either).
If it is not required by a law such policy should be decided by the
developpers as a whole and not only ftpmasters through the policy indeed.
Even though, it is questionable when the legal requirements are only for a
specific legislation.
Romain
Mike Hommey
>
> >> 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. (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.
Mike
Sandro Tosi
Hash: SHA1
On Sat, Mar 21, 2009 at 18:42, Mike Hommey <m...@glandium.org> wrote:
> On Sat, Mar 21, 2009 at 03:58:34PM +0100, 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. (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.
Sadly, we are all losing here.
You're a fscking great maintainer, as I was able to experiment with
our interaction on some bugs, and it's a loss for the WHOLE Debian
you're demotivated to maintain those important packages.
Hope in some days/weeks, when the situation will cool a bit, you might
reconsider your decision.
Cheers,
Sandro
/me still has to understand what's the point in shooting on
ourselves... we are losing! every time a maintainer (being a DD or
not) reaches his limit of patience for the sake of nothing.
- --
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.4)
iEYEARECAAYFAknFK8YACgkQAukwV0RN2VD08wCdHNbguc2DdBEPp3RWRomtSOYz
Wf0AnRfRskMVq2cwe4TWDL0PdLJr3z04
=2hwQ
-----END PGP SIGNATURE-----
Holger Levsen
> Sadly, we are all losing here.
yes. *sigh*
> /me still has to understand what's the point in shooting on
> ourselves... we are losing!
I think it's following binary logic to the end. Which we got trained by using
computers but what is very wrong in social interactions.
regards,
Holger
Russ Allbery
> 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?
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.
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.
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)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Emilio Pozuelo Monfort
> Le Friday 20 March 2009 19:55:29 Emilio Pozuelo Monfort, vous avez écrit :
>>> Since the vast majority of the packages fall into a regular copyright and
>>> licensing, this would also mean overload the policy with stuff that is
>>> only relevant in a very small number of cases in proportion.
>> If copyright holder listing isn't needed at all, there's no special-casing
>> needed for autofoo stuff (wrt copyright listing, not wrt licenses though).
>
> But this is also problematic for license !
>
> Even in the case in which we accept my above rational, it is still possible
> that the configure.ac contains custom macros with a bad license...
>
> Hence, if we were to decide on a general basis, it would be either to check
> for all configure.ac or for no one.. Do you think one of these possibilities
> is reasonable ?
I dunno, but that is not the point. The point is about not requiring copyright
holders, which wouldn't need special casing.
Emilio
Russ Allbery
> 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?
The problem doesn't have to be solved yesterday. We're early in the
squeeze development cycle, nothing is currently happening that can't wait
a little bit, and there's time to talk through it and let initial
positions moderate and people calm down. Can we PLEASE not escalate every
heated discussion immediately? If you're really upset about something,
take a few days away from it and think about it for a while. Write the
heated message, file it somewhere, and decide whether you still want to
send it tomorrow.
For that matter, you're certainly welcome to mail me directly and either
let off steam or ask that a point be represented in public that you're too
steamed to make. I expect there are others who would volunteer to do the
same.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Jonas Meurer
> >
> > >> 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. (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.
I really start to ask myself whether we do have a social problem with
the debian developers community. people who're important for the project
often tend to authoritarian discussion style. i don't know what and
whether at all they compensate anything with this behaviour, but at
least they don't realize how they hurt the complete project with doing
so.
greetings,
jonas