Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Package: debian-policy Followup-For: Bug #649530 Hi all, I just noticed that SPDX have released a new version of their spec that agrees with what I was trying to propose originally here: See [1] "Deprecated License" and [2] Appendix IV: SPDX License Expressions: | Simple License Expressions | | An SPDX License List Short Form Identifier with a unary"+" operator suffix to represent the current | version of the license or any later version. For example: GPL-2.0+ May we restart discussing updating debian's copyright-format to be consistent with this? To recap, in case people have forgotten: Currently the format 1.0 specifies (and lintian warns) if I have GPL-3 and GPL-3+ licensed files in my package, but I only have a GPL-3 License stanza (and not another "GPL-3+" stanza). My argument was that this is pointless redundancy, counterarguments complained that "+" was not well-defined, but then one could re-counter that "and" and "or" was also not well-defined. Anyway it looks like SPDX now agrees with me, and probably got fed up of this redundancy themselves. Concretely, what would need to be changed in copyright-format 1.1 would be similar to what SPDX have done, i.e.: a) define + an operator, similar to "or" and "and" that already exist b) drop the GPL-2+ et al "short names" c) define a "with
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Apologies for the late reply; somehow this email ended up in my spam folder.
On 25/12/12 18:28, Russ Allbery wrote:
Ximin Luo infini...@gmx.com writes:
This feels very much like delay tactics, and makes me feel very
frustrated as someone who is trying to contribute to Debian.
You should consider the possibility that no one is trying to delay
anything, but rather that we simply aren't convinced by the changes that
you're proposing.
Well, more criticism would be appreciated rather than silence. The
counter-arguments made so far haven't been very strong; I can't read people's
minds see criticism beyond this. There is no motivation document for this
spec either so it's not like I can infer this too.
Having a formal grammar for license names that recognizes the version
component was something that was done in an earlier draft of this document
and then abandoned due to the complexity. Personally, having written
files to both the earlier and current grammar, I really don't miss it. It
makes the specification more formally robust, but at a cost to both
complexity and understanding when just casually applying the
specification.
I think most people are going to just look up their specific license in
the list of licenses that have pre-assigned keywords, use one if there is
one there, and make one up otherwise. I don't think having the grammar be
more formal about syntax and versioning is that helpful to that process.
My proposal does not make anything more formal. The two main changes are
{moving one concept into another section} and {restricting the definition for a
section}.
This is because people misunderstand what a License is; my changes will
help communicate and correct this mistake.
Different BSD-3-Clause licenses have the *same terms*; that is what
makes them BSD-3-Clause. However, as commonly written, people add
author- and software-specific information to their statement of the
license. We cannot do this in debian/copyright because that would be
logically inconsistent, since:
If a package contains files under different BSD-3-Clause licenses, each
with different owners, but the terms are the same, (according to my
changes) the owners would be stripped out and put in the relevant Files:
paragraphs, and the common terms would be put in *one* stand-alone
License: paragraph. Currently, it is impossible to merge these; you
would have to give the licenses each different names.
You've expressed this opinion before, and I understand what you're saying
and why you believe this. I just don't agree that this is a good change.
The serious problem with what you propose is that the exact text of the
upstream license is no longer reproduced in debian/copyright. I consider
that the baseline requirement for that file, and therefore consider that
to be a fatal problem.
Compared to losing the verbatim text, I think having multiple license
blocks for the variations of the license is a minor problem.
OK, this is a new point that hasn't been made before in this thread, thank you
for communicating it.
Why is it essential for the verbatim text to be in debian/copyright, when the
source package should already contain this? We could alternatively add a
Location: field to point to the verbatim license in /usr/share/doc or the base
directory of the source package, rather than duplicating information?
What I would find useful is some way to standardize the short names of the
variations of those licenses so that one can use distinguished short names
for the different variations within a file but still make it clear to
automated parsers that they're following the base license template. That
gains some of the benefit of your proposal in terms of making the file
clearer and allowing use of the standard license short names, without
losing the verbatim text of the license.
I'm not sure I understand this. How is this different from the current case
where you can specify multiple License fields (in different Files paragraphs)
with the same short name (e.g. BSD-3-Clause) but different full text (e.g.
containing copyright year, authors)?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo infini...@gmx.com writes:
On 25/12/12 18:28, Russ Allbery wrote:
You should consider the possibility that no one is trying to delay
anything, but rather that we simply aren't convinced by the changes
that you're proposing.
Well, more criticism would be appreciated rather than silence. The
counter-arguments made so far haven't been very strong; I can't read
people's minds see criticism beyond this. There is no motivation
document for this spec either so it's not like I can infer this too.
I'm fairly sure that either I or someone else made these points in the
original 2011 thread that preceded the Debian Policy bug, and Charles
makes the same point about the BSD license text in:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649530#35
Anyway, it doesn't really matter. Debian is good at discussing things
repeatedly. :) And it's been a long thread split across two (well, now
three) years, so I don't expect anyone to remember all of it.
My proposal does not make anything more formal. The two main changes
are {moving one concept into another section} and {restricting the
definition for a section}.
Yes, I said that very poorly. I apologize.
I agree that you're not going all the way back to having a formal
specification for the version number, like we had in the past, but making
the license exception a separate entity still feels like movement towards
making the format more structured and somewhat more complicated. Anyway,
this is a minor point; I wouldn't reject the proposal for this reason, so
it's probably not worth discussing in any great depth. It's more of a gut
reaction than a considered opinion.
The main point that I'm getting at here is that I'd like to see a specific
case where splitting the license exceptions out into separate paragraphs
makes the debian/copyright file either substantially shorter or
substantially easier to read. I'm not seeing it right now.
I re-read the discussion of the difference between the license notice and
the license, specifically for the GPL cases, and I do see your point
there. However, I'm also nervous about dropping the upstream license
notice entirely. We could add a new field to hold the license notice, but
now again we're getting into places where I'm not sure the additional
complexity really saves anyone much time or effort compared to just having
multiple License sections, one for each substantial variation of the
licensing terms. The GPL notice and pointer to common-licenses is pretty
short. Basically, I agree with Steve at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649530#65
although I don't feel as strongly about it as he did at the time.
Why is it essential for the verbatim text to be in debian/copyright,
when the source package should already contain this? We could
alternatively add a Location: field to point to the verbatim license in
/usr/share/doc or the base directory of the source package, rather than
duplicating information?
Why do we have debian/copyright at all when the source package already
contains the licensing information? There are a bunch of reasons, one of
which being that it's common for licensing text to require that the
license accompany any derivative work, such as a binary package.
What I would find useful is some way to standardize the short names of
the variations of those licenses so that one can use distinguished
short names for the different variations within a file but still make
it clear to automated parsers that they're following the base license
template. That gains some of the benefit of your proposal in terms of
making the file clearer and allowing use of the standard license short
names, without losing the verbatim text of the license.
I'm not sure I understand this. How is this different from the current
case where you can specify multiple License fields (in different Files
paragraphs) with the same short name (e.g. BSD-3-Clause) but different
full text (e.g. containing copyright year, authors)?
The current specification requires that short names be unique within a
given copyright file:
First line: an abbreviated name for the license, or expression giving
alternatives (see the Short name section for a list of standard
abbreviations). If there are licenses present in the package without
a standard short name, an arbitrary short name may be assigned for
these licenses. These arbitrary names are only guaranteed to be
unique within a single copyright file.
That's not exactly unambiguous, but I always assumed that meant that you
shouldn't reuse the same short name for different license texts.
If we intend to permit using BSD-3-Clause for any license of that form
regardless of the proper names embedded in it, we should really say that
explicitly. However, the other problem with doing that is that if there
are several different files covered by the same variant of that BSD
license, but other files in the package covered by
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Russ Allbery wrote: It might be worthwhile to recognize some sort of syntax similar to license exceptions so that one can tag the license as BSD-3-Clause by copyright holder or the like. That would let one use standalone license paragraphs for those licenses without the ambiguity problem, while still making it clear for automated license analysis that the license in question is the BSD-3-Clause license (which using something like BSD-3-Clause-holder doesn't do). It's worse than that, I think. Pedantically speaking, 3-clause BSD-style licenses require reproducing the warranty disclaimer verbatim, along with the permission notice and list of copyright holders. The list of copyright holders is adequately preserved in the Copyright field. But the warranty disclaimer varies from project to project: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND [...] THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND THIS SOFTWARE IS PROVIDED BY COPYRIGHT HOLDER ''AS IS'' AND THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND THIS SOFTWARE IS PROVIDED BY GEOFF KUENNING AND CONTRIBUTORS AS IS AND The next sentence IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE also varies, and not always in the same way as the first. Common practice seems to vary from package to package: * Some ignore this detail and cite /usr/share/common-licenses despite the license not matching. I suspect that violates both policy and copyright-format. * Some reproduce all variants of the warranty notice used, giving all variants the short name BSD-3-Clause. I'm not sure whether the copyright-format permits this --- it would be nice to clarify how rigid the definitions in the Meaning column for license short names are meant to be. * Some give each variant a different short name. This is clearly allowed by the spec, though it would presumably make automated analysis harder. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: It might be worthwhile to recognize some sort of syntax similar to license exceptions so that one can tag the license as BSD-3-Clause by copyright holder or the like. That would let one use standalone license paragraphs for those licenses without the ambiguity problem, while still making it clear for automated license analysis that the license in question is the BSD-3-Clause license (which using something like BSD-3-Clause-holder doesn't do). It's worse than that, I think. Pedantically speaking, 3-clause BSD-style licenses require reproducing the warranty disclaimer verbatim, along with the permission notice and list of copyright holders. The list of copyright holders is adequately preserved in the Copyright field. But the warranty disclaimer varies from project to project: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER(S) ``AS IS'' AND [...] THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND THIS SOFTWARE IS PROVIDED BY COPYRIGHT HOLDER ''AS IS'' AND THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND THIS SOFTWARE IS PROVIDED BY GEOFF KUENNING AND CONTRIBUTORS AS IS AND The next sentence IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE also varies, and not always in the same way as the first. I think you may have missed my point. :) I believe that all of those variants should, as is currently required, be separately represented in the debian/copyright file. The one change that I want to make is to allow them to all have the same short name for the aid of automated analysis. There isn't any way to do that right now since there isn't any way to indicate a License paragraph for the specific license text without changing the short name. This new syntax would allow using the correct short name but still giving each distinct License paragraph a unique name that can then be referred to in Files paragraphs. I do think it's reasonable to give all those variants the same short name as long as there's some other way to mark them uniquely. Common practice seems to vary from package to package: * Some ignore this detail and cite /usr/share/common-licenses despite the license not matching. I suspect that violates both policy and copyright-format. Agreed. * Some reproduce all variants of the warranty notice used, giving all variants the short name BSD-3-Clause. I'm not sure whether the copyright-format permits this --- it would be nice to clarify how rigid the definitions in the Meaning column for license short names are meant to be. As I stated in my message, I believe the current wording does not allow for this since it requires that the short name be unique within the copyright file, but indeed it could use some clarification. * Some give each variant a different short name. This is clearly allowed by the spec, though it would presumably make automated analysis harder. I believe this is the only acceptable thing to do when declaring the copyright file compliant with version 1.0. Hence the above proposal for a version 1.1. For a specific example of a package with this problem, see: http://packages.debian.org/changelogs/pool/main/r/remctl/current/copyright and note the MIT-Kula and MIT-Martinez license short names. It would be better to be able to note these licenses are versions of a standard, well-known license. (I use the copyright format for both the upstream LICENSE file and the debian/copyright file. It's mechanically constructed from the license notices in each file via a script.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo wrote: Why is it essential for the verbatim text to be in debian/copyright, when the source package should already contain this? We could alternatively add a Location: field to point to the verbatim license in /usr/share/doc or the base directory of the source package, rather than duplicating information? Here's one scenario, which I think motivated this in olden times. Suppose someone gives me a Debian CD. It comes with a written offer for a source CD from the commercial distributor I bought it from, but I haven't actually bothered to send in for that --- all I need is binaries for now. Now I want to give a copy of the CD to my friend. I can review the terms under which I am allowed to copy it, which binary packages I am allowed to modify, etc, without having a copy of the source CD. Moreover, I have a copy of the license terms that I *thought* I was agreeing to (even if the packagers screwed up) for my records, which can avoid some anger and confusion if I turn out to have misunderstood the copyright holders. So it's all about keeping the legal rights visible, concrete, and easy to find. And that information is right here, on the same physical medium as the binaries, instead of on the web where it could change. Of course some licenses also require including the license terms with binaries, but Russ already covered that. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Russ Allbery wrote: Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: It might be worthwhile to recognize some sort of syntax similar to license exceptions so that one can tag the license as BSD-3-Clause by copyright holder or the like. [...] The next sentence IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE also varies, and not always in the same way as the first. I think you may have missed my point. :) I believe that all of those variants should, as is currently required, be separately represented in the debian/copyright file. If we change the syntax a little to allow arbitrary identifiers for each variant, à la BSD-3-Clause, MIT variant #1, then I think I was just taking a long time to agree completely with your proposed change. ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: Jonathan Nieder jrnie...@gmail.com writes: Russ Allbery wrote: It might be worthwhile to recognize some sort of syntax similar to license exceptions so that one can tag the license as BSD-3-Clause by copyright holder or the like. [...] The next sentence IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE also varies, and not always in the same way as the first. I think you may have missed my point. :) I believe that all of those variants should, as is currently required, be separately represented in the debian/copyright file. If we change the syntax a little to allow arbitrary identifiers for each variant, à la BSD-3-Clause, MIT variant #1, then I think I was just taking a long time to agree completely with your proposed change. ;-) Oh, yes, that would work. I missed that my proposed by syntax implied that the only thing that changed was the copyright holder. Maybe variant would be a better keyword, taking an arbitrary label. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 26/12/12 23:39, Jonathan Nieder wrote:
Charles Plessy wrote:
If experimentations are blocked because the current specification does not
allow unspecified types of paragraphs, how about considering to relax it ?
I honestly think that License-Exception stanzas already are a
fundamental enough change that they would have to be permitted in the
standard before actual copyright files. And that's not weird at all
--- it's normal for new features to involve changes to a spec.
Maybe I am missing something basic? Am I wrong to think that factoring
out license exceptions would be useful as a way of making copyright
files more readable, or do they have some glaring downside that I've
failed to notice?
Jonathan
I'm a little surprised that the License-Exception paragraph is getting more
attention than my other proposed changes. :p
As I understand it yes, the current spec does not allow new paragraphs, but
even if it were relaxed to allow these (as Charles suggests), other parts of
the spec will forbid a useful License-Exception paragraph.
This is because the current spec treats short names as combinations of {X,
X+, X-with-Y-exception, X+-with-Y-exception} for each X and Y. The current spec
only allows you to quote the full text of a short name as a whole, not its
individual components. So you would not be able to split the full text of
GPL-2+ with OpenSSL exception into separate License and License-Exception
paragraphs.
By contrast, my proposed changes re-defines short names to be {X} only, and
pushes the + and with-exception operators into the same level as and/or
operators. Then GPL-2+ with OpenSSL exception is a composite license rather
than a short name, and you are allowed to split the full text of its components.
(I do not see any downside to this.)
X
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On Thu, Dec 27, 2012 at 08:00:33AM +0900, Charles Plessy wrote: Unfortunately that would involve violating the spec. The current specification requires that every paragraph be a header paragraph, a Files paragraph, or a License paragraph. License-Exception paragraphs are not allowed. Besides, when the License field in a Files paragraph refers to a license exception, either the field must include the full text of the license or a pointer to common-licenses or the short name followed by a license exception must be defined in a License paragraph --- defining the short name and license exception in separate standalone paragraphs is not allowed. Sorry for the confusion between new field and new paragraph. Still, I think that we are spending a lot of time discussing refinements that need to demonstrate their usefulness by being adopted independantly by a broad number of package maintainers. If experimentations are blocked because the current specification does not allow unspecified types of paragraphs, how about considering to relax it ? We already had the same issue for proposed paragraphs about removed files. There's no reason experimenting should be blocked. You can put anything you want to in debian/copyright, in any format you like - you just can't call it copyright-format 1.0. Changing the header to not claim that it *is* copyright-format 1.0 is a simple requirement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Charles Plessy wrote: Sorry for the confusion between new field and new paragraph. Still, I think that we are spending a lot of time discussing refinements that need to demonstrate their usefulness by being adopted independantly by a broad number of package maintainers. Stepping back a little, do I understand correctly that you mean No, I do not think License-Exception paragraphs would be useful? That's useful feedback and surprising to me. More details would be welcome. Context: I have no interest in diverging from the standard copyright-format in packages I maintain. But I would use a License-Exception construct if it existed, and at least one copyright file would become shorter. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Jonathan Nieder jrnie...@gmail.com writes: Charles Plessy wrote: Sorry for the confusion between new field and new paragraph. Still, I think that we are spending a lot of time discussing refinements that need to demonstrate their usefulness by being adopted independantly by a broad number of package maintainers. Stepping back a little, do I understand correctly that you mean No, I do not think License-Exception paragraphs would be useful? That's useful feedback and surprising to me. More details would be welcome. I don't think they're particularly useful, mostly because I don't see a serious problem with the current syntax and therefore don't see a good reason to make it more complicated. There is an annoying corner case (multiple licenses that use the same exception but which aren't in common-licenses and therefore have to be quoted in their entirety) where not having this feature could result in serious copyright file bloat. However, I think this is rare. Most license exceptions are used with the GPL, which is in common-licenses, so the License blocks are short and duplicating them is not much wasted space. The argument against them is that a license with a license exception is only two separable components if the license says that it is. In most cases (such as GPL v2 with an exception), it's really a brand new license that happens to share a lot of characteristics with the base license. Separating out the language so that it's presented in separate paragraphs, which I think is the key point of having this feature, runs the risk of not correctly reproducing the *actual* license text in the copyright file. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Tue, Dec 25, 2012 at 01:36:32PM -0800, Jonathan Nieder a écrit : For example, I think the idea of a License-exception stanza is uncontroversial and valuable. Hi Jonathan and Ximin, given that the current specification does not forbid unpecified fields, I would recommend to test the proposed License-Exception field in real, by convincing package maintainers and parser providers to use and support it. This can be tracked by a opening a separate bug, so that the propositions can be considered independantly, unless it would be pointless to introduce a new field for license exceptions without introducing a syntax for license short names. Cheers, -- Charles Plessy Illkirch-Graffenstaden, France -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Hi Charles, Charles Plessy wrote: Le Tue, Dec 25, 2012 at 01:36:32PM -0800, Jonathan Nieder a écrit : For example, I think the idea of a License-exception stanza is uncontroversial and valuable. given that the current specification does not forbid unpecified fields, I would recommend to test the proposed License-Exception field in real, by convincing package maintainers and parser providers to use and support it. Unfortunately that would involve violating the spec. The current specification requires that every paragraph be a header paragraph, a Files paragraph, or a License paragraph. License-Exception paragraphs are not allowed. Besides, when the License field in a Files paragraph refers to a license exception, either the field must include the full text of the license or a pointer to common-licenses or the short name followed by a license exception must be defined in a License paragraph --- defining the short name and license exception in separate standalone paragraphs is not allowed. Hoping that clarifies, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Wed, Dec 26, 2012 at 11:03:20AM -0800, Jonathan Nieder a écrit : Charles Plessy wrote: Le Tue, Dec 25, 2012 at 01:36:32PM -0800, Jonathan Nieder a écrit : For example, I think the idea of a License-exception stanza is uncontroversial and valuable. given that the current specification does not forbid unpecified fields, I would recommend to test the proposed License-Exception field in real, by convincing package maintainers and parser providers to use and support it. Unfortunately that would involve violating the spec. The current specification requires that every paragraph be a header paragraph, a Files paragraph, or a License paragraph. License-Exception paragraphs are not allowed. Besides, when the License field in a Files paragraph refers to a license exception, either the field must include the full text of the license or a pointer to common-licenses or the short name followed by a license exception must be defined in a License paragraph --- defining the short name and license exception in separate standalone paragraphs is not allowed. Sorry for the confusion between new field and new paragraph. Still, I think that we are spending a lot of time discussing refinements that need to demonstrate their usefulness by being adopted independantly by a broad number of package maintainers. If experimentations are blocked because the current specification does not allow unspecified types of paragraphs, how about considering to relax it ? We already had the same issue for proposed paragraphs about removed files. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Charles Plessy wrote: If experimentations are blocked because the current specification does not allow unspecified types of paragraphs, how about considering to relax it ? I honestly think that License-Exception stanzas already are a fundamental enough change that they would have to be permitted in the standard before actual copyright files. And that's not weird at all --- it's normal for new features to involve changes to a spec. Maybe I am missing something basic? Am I wrong to think that factoring out license exceptions would be useful as a way of making copyright files more readable, or do they have some glaring downside that I've failed to notice? Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 24/12/12 10:31, Charles Plessy wrote: Le Tue, Dec 18, 2012 at 11:53:21PM +, Ximin Luo a écrit : https://github.com/infinity0/debian-policy/compare/bug649350-infinity0 I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. I'm trying to follow the principle that the commit messages should already contain enough justification for the changes, but if any of them are unclear, please do ask me for further detail. (Further potential additions, which I've omitted for simplicity, include License-Exception: fields, and Location: fields to formalise the concept of a pointer to a License.) Dear Ximin, It was nice to split the patch and document the chunks, but I am still not convinced that the changes you propose are useful. In particular, I do not see the benefit from using a syntax for the license short names, especially that SPDX and other projects do not have one (for instance GPL-2 and GPL-2+ are seen as separate short names). Also, creating a syntax is a complex project that I think is beyond the scope of our machine-readable format. There are corner cases, for instance BSD-3-Clause is not the upgrade from BSD-2-Clause, or MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+, etc. If you would like to work on a robust syntax, I propose you do it as an independant specification that can later be proposed for adoption not ony to use, but also to SPDX, OSI, ADMS.F/OSS, etc. - GPL-2 and GPL-2+ are seen as separate short names [by SPDX] - this does not mean my suggestion is a bad idea, nor that my syntax is inconsistent. - BSD-3-Clause is not the upgrade from BSD-2-Clause - there is no contradiction with what I suggest here. - MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+ - this is incorrect and due to people *misusing the term MPL-1.1, which my changes *will help communicate and correct*. If you look at MPL-1.1[1] you will notice it makes *no mention* of or later version. The vast majority of MPL-1.1 uses should actually be MPL-1.1+, consistent with my proposed changes. [1] http://www.mozilla.org/MPL/1.1/index.txt Another change that you propose and that I disagree with is to forbid author- and software-specific information in stand-alone paragaphs. A lot of derivatives from the BSD licenses contain such information. Despite we link to a SPDX page where the BSD license terms are generic, I do not think that the intent in Debian's machine-readable format to is consider them all the same. At least in my copyright files I only use BSD-3-Clause if the copyright owners are the regents of the university of California. This is because people misunderstand what a License is; my changes will help communicate and correct this mistake. Different BSD-3-Clause licenses have the *same terms*; that is what makes them BSD-3-Clause. However, as commonly written, people add author- and software-specific information to their statement of the license. We cannot do this in debian/copyright because that would be logically inconsistent, since: If a package contains files under different BSD-3-Clause licenses, each with different owners, but the terms are the same, (according to my changes) the owners would be stripped out and put in the relevant Files: paragraphs, and the common terms would be put in *one* stand-alone License: paragraph. Currently, it is impossible to merge these; you would have to give the licenses each different names. Example: | Files: X | Copyright: A | License: BSD-3-Clause | Copyright 2012 A | terms etc | | Files: Y | Copyright: B | License: BSD-3-Clause | Copyright 2012 B | terms etc This is obviously absurd. My changes would instead force this: | Files: X | Copyright: A | License: BSD-3-Clause | | Files: Y | Copyright: B | License: BSD-3-Clause | | License: BSD-3-Clause | terms etc Cheers, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 25/12/12 12:34, Ximin Luo wrote: On 24/12/12 10:31, Charles Plessy wrote: Le Tue, Dec 18, 2012 at 11:53:21PM +, Ximin Luo a écrit : https://github.com/infinity0/debian-policy/compare/bug649350-infinity0 I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. I'm trying to follow the principle that the commit messages should already contain enough justification for the changes, but if any of them are unclear, please do ask me for further detail. (Further potential additions, which I've omitted for simplicity, include License-Exception: fields, and Location: fields to formalise the concept of a pointer to a License.) Dear Ximin, It was nice to split the patch and document the chunks, but I am still not convinced that the changes you propose are useful. In particular, I do not see the benefit from using a syntax for the license short names, especially that SPDX and other projects do not have one (for instance GPL-2 and GPL-2+ are seen as separate short names). Also, creating a syntax is a complex project that I think is beyond the scope of our machine-readable format. There are corner cases, for instance BSD-3-Clause is not the upgrade from BSD-2-Clause, or MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+, etc. If you would like to work on a robust syntax, I propose you do it as an independant specification that can later be proposed for adoption not ony to use, but also to SPDX, OSI, ADMS.F/OSS, etc. This feels very much like delay tactics, and makes me feel very frustrated as someone who is trying to contribute to Debian. You imply that the syntax I propose is not robust, but I have answered all the claimed flaws you bring up. My suggestions come from an abstract model of the basic types of information contained in software license (who/author, what/software, terms), and this will fit any license for any package. If you can find a real flaw, you should be able to describe how my model breaks down for that example. Additionally, for SPDX, the debian copyright format already states the two formats have different aims, and so the formats are different, so your suggestion seems strange to me, if I assume you are treating me seriously. - GPL-2 and GPL-2+ are seen as separate short names [by SPDX] - this does not mean my suggestion is a bad idea, nor that my syntax is inconsistent. - BSD-3-Clause is not the upgrade from BSD-2-Clause - there is no contradiction with what I suggest here. - MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+ - this is incorrect and due to people *misusing the term MPL-1.1, which my changes *will help communicate and correct*. If you look at MPL-1.1[1] you will notice it makes *no mention* of or later version. The vast majority of MPL-1.1 uses should actually be MPL-1.1+, consistent with my proposed changes. [1] http://www.mozilla.org/MPL/1.1/index.txt Another change that you propose and that I disagree with is to forbid author- and software-specific information in stand-alone paragaphs. A lot of derivatives from the BSD licenses contain such information. Despite we link to a SPDX page where the BSD license terms are generic, I do not think that the intent in Debian's machine-readable format to is consider them all the same. At least in my copyright files I only use BSD-3-Clause if the copyright owners are the regents of the university of California. This is because people misunderstand what a License is; my changes will help communicate and correct this mistake. Different BSD-3-Clause licenses have the *same terms*; that is what makes them BSD-3-Clause. However, as commonly written, people add author- and software-specific information to their statement of the license. We cannot do this in debian/copyright because that would be logically inconsistent, since: If a package contains files under different BSD-3-Clause licenses, each with different owners, but the terms are the same, (according to my changes) the owners would be stripped out and put in the relevant Files: paragraphs, and the common terms would be put in *one* stand-alone License: paragraph. Currently, it is impossible to merge these; you would have to give the licenses each different names. Example: | Files: X | Copyright: A | License: BSD-3-Clause | Copyright 2012 A | terms etc | | Files: Y | Copyright: B | License: BSD-3-Clause | Copyright 2012 B | terms etc This is obviously absurd. My changes would instead force this: | Files: X | Copyright: A | License: BSD-3-Clause | | Files: Y | Copyright: B | License: BSD-3-Clause | | License: BSD-3-Clause | terms etc Cheers, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 25/12/12 12:34, Ximin Luo wrote: On 24/12/12 10:31, Charles Plessy wrote: Le Tue, Dec 18, 2012 at 11:53:21PM +, Ximin Luo a écrit : https://github.com/infinity0/debian-policy/compare/bug649350-infinity0 I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. I'm trying to follow the principle that the commit messages should already contain enough justification for the changes, but if any of them are unclear, please do ask me for further detail. (Further potential additions, which I've omitted for simplicity, include License-Exception: fields, and Location: fields to formalise the concept of a pointer to a License.) Dear Ximin, It was nice to split the patch and document the chunks, but I am still not convinced that the changes you propose are useful. In particular, I do not see the benefit from using a syntax for the license short names, especially that SPDX and other projects do not have one (for instance GPL-2 and GPL-2+ are seen as separate short names). Also, creating a syntax is a complex project that I think is beyond the scope of our machine-readable format. There are corner cases, for instance BSD-3-Clause is not the upgrade from BSD-2-Clause, or MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+, etc. If you would like to work on a robust syntax, I propose you do it as an independant specification that can later be proposed for adoption not ony to use, but also to SPDX, OSI, ADMS.F/OSS, etc. - GPL-2 and GPL-2+ are seen as separate short names [by SPDX] - this does not mean my suggestion is a bad idea, nor that my syntax is inconsistent. - BSD-3-Clause is not the upgrade from BSD-2-Clause - there is no contradiction with what I suggest here. - MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+ - this is incorrect and due to people *misusing the term MPL-1.1, which my changes *will help communicate and correct*. If you look at MPL-1.1[1] you will notice it makes *no mention* of or later version. The vast majority of MPL-1.1 uses should actually be MPL-1.1+, consistent with my proposed changes. [1] http://www.mozilla.org/MPL/1.1/index.txt I've written my reasons for this patch, and its tangible benefits that you dismiss, in a bit more depth here: https://github.com/infinity0/debian-policy/wiki It turns out I was wrong about the MPL-1.1 not explicitly allowing re-licensing, but this is a minor issue. To that document, I've added a proposal that deals with this. After seeing the SPDX license list[1] in more detail, I can understand a bit better why you are reluctant to accept my patch. I guess you see the short names list in the copyright-format as a minor tweak of SPDX. However I don't think my changes deviate from this in any significant way; and the and/or syntax of copyright-format is on a similar level to the changes I propose here. [1] http://spdx.org/licenses/ Another change that you propose and that I disagree with is to forbid author- and software-specific information in stand-alone paragaphs. A lot of derivatives from the BSD licenses contain such information. Despite we link to a SPDX page where the BSD license terms are generic, I do not think that the intent in Debian's machine-readable format to is consider them all the same. At least in my copyright files I only use BSD-3-Clause if the copyright owners are the regents of the university of California. This is because people misunderstand what a License is; my changes will help communicate and correct this mistake. Different BSD-3-Clause licenses have the *same terms*; that is what makes them BSD-3-Clause. However, as commonly written, people add author- and software-specific information to their statement of the license. We cannot do this in debian/copyright because that would be logically inconsistent, since: If a package contains files under different BSD-3-Clause licenses, each with different owners, but the terms are the same, (according to my changes) the owners would be stripped out and put in the relevant Files: paragraphs, and the common terms would be put in *one* stand-alone License: paragraph. Currently, it is impossible to merge these; you would have to give the licenses each different names. I believe the fact that SPDX itself replaces WHAT/WHO information with variable placeholders (e.g. [2]) lends more weight to my position, too. [2] http://spdx.org/licenses/BSD-3-Clause Example: | Files: X | Copyright: A | License: BSD-3-Clause | Copyright 2012 A | terms etc | | Files: Y | Copyright: B | License: BSD-3-Clause | Copyright 2012 B | terms etc This is obviously absurd. My changes would instead force this: | Files: X | Copyright: A | License: BSD-3-Clause | | Files: Y | Copyright: B | License: BSD-3-Clause | | License: BSD-3-Clause | terms etc Cheers,
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo infini...@gmx.com writes: This feels very much like delay tactics, and makes me feel very frustrated as someone who is trying to contribute to Debian. You should consider the possibility that no one is trying to delay anything, but rather that we simply aren't convinced by the changes that you're proposing. Having a formal grammar for license names that recognizes the version component was something that was done in an earlier draft of this document and then abandoned due to the complexity. Personally, having written files to both the earlier and current grammar, I really don't miss it. It makes the specification more formally robust, but at a cost to both complexity and understanding when just casually applying the specification. I think most people are going to just look up their specific license in the list of licenses that have pre-assigned keywords, use one if there is one there, and make one up otherwise. I don't think having the grammar be more formal about syntax and versioning is that helpful to that process. This is because people misunderstand what a License is; my changes will help communicate and correct this mistake. Different BSD-3-Clause licenses have the *same terms*; that is what makes them BSD-3-Clause. However, as commonly written, people add author- and software-specific information to their statement of the license. We cannot do this in debian/copyright because that would be logically inconsistent, since: If a package contains files under different BSD-3-Clause licenses, each with different owners, but the terms are the same, (according to my changes) the owners would be stripped out and put in the relevant Files: paragraphs, and the common terms would be put in *one* stand-alone License: paragraph. Currently, it is impossible to merge these; you would have to give the licenses each different names. You've expressed this opinion before, and I understand what you're saying and why you believe this. I just don't agree that this is a good change. The serious problem with what you propose is that the exact text of the upstream license is no longer reproduced in debian/copyright. I consider that the baseline requirement for that file, and therefore consider that to be a fatal problem. Compared to losing the verbatim text, I think having multiple license blocks for the variations of the license is a minor problem. What I would find useful is some way to standardize the short names of the variations of those licenses so that one can use distinguished short names for the different variations within a file but still make it clear to automated parsers that they're following the base license template. That gains some of the benefit of your proposal in terms of making the file clearer and allowing use of the standard license short names, without losing the verbatim text of the license. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Hi, Ximin Luo wrote: On 24/12/12 10:31, Charles Plessy wrote: In particular, I do not see the benefit from using a syntax for the license short names, [...] If you would like to work on a robust syntax, I propose you do it as an independant specification that can later be proposed for adoption not ony to use, but also to SPDX, OSI, ADMS.F/OSS, etc. This feels very much like delay tactics, and makes me feel very frustrated as someone who is trying to contribute to Debian. I am probably most to blame here. When I some good changes in your proposal, my reaction was to sent encouragement instead of picking them out and filing new bugs or looking at the proposal as a whole. In my opinion, to develop a standardized syntax for short names, it makes most sense to develop it within Debian's copyright format and only later, if there's interest, to extract the spec for reuse by others. In the short term, SPDX et al would be relevant in that (1) they have some expertise on the subject, so it could be worth getting their advice, and (2) their license names currently can be easily mapped to and from Debian's, without changing names most of the time, and that is an attribute worth preserving. I suspect Charles's suggestion was meant to take advantage of (1), but there are other ways to ask for a body's advice. I'll send my feedback on your patches in a separate mail. Thanks again for your work. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo wrote: I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. Thanks. I'm used to getting patch series in the mail, but I can adapt. | d6892294 - strip trailing whitespace Ack. | 4b752126 - change tri-license example to be the more common MPL-1.1 | or GPL-2+ or LGPL-2.1+ With that patch, the example doesn't follow the spec any more because short names used in a Files: stanza (GPL-2+, LGPL-2.1+) without license text have no corresponding License: stanza. That's a regression, so nack. | 5fe35fbe - S1: Define the synopsis more formally; license | expression will be defined in a later commit I'm stopping here. The advantage, from the point of view of a reviewer like me, of splitting a patch into a series is that I can start reading at the first patch and, without reading the later ones, understand well enough to decide whether that first patch is worthwhile and safe to apply to the package. That way I don't have to invest a huge time commitment to start making progress on incorporating someone's changes. That only works if the first patch, alone, is already a valid change, and likewise for the first two patches, first three, etc. Without that property I'd rather just read one monolithic diff. Is it possible to extract a less-controversial subset from your spec that could be applied first? That would make life easier for busy and lazy folks like me, would create momentum for polishing and applying the rest, and can be a good way to move to a consensus on the basic idea without the distraction of other potential large, possibly disruptive changes. For example, I think the idea of a License-exception stanza is uncontroversial and valuable. Defining it might (or might not) bring out the need to define the structure of license names more precisely, which could in turn make it easier to later make the spec more accurately model that licenses like GPL-2 or GPL-3+ and GPL-2+ are equivalent. Summary: This series is too much for me to think about at once! My feeble mind wants a smaller subset to bite off before it will be able to swallow the whole set of changes. Sorry for the fuss, and hope that helps. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 25/12/12 21:36, Jonathan Nieder wrote: Ximin Luo wrote: I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. Thanks. I'm used to getting patch series in the mail, but I can adapt. | d6892294 - strip trailing whitespace Ack. | 4b752126 - change tri-license example to be the more common MPL-1.1 | or GPL-2+ or LGPL-2.1+ With that patch, the example doesn't follow the spec any more because short names used in a Files: stanza (GPL-2+, LGPL-2.1+) without license text have no corresponding License: stanza. That's a regression, so nack. | 5fe35fbe - S1: Define the synopsis more formally; license | expression will be defined in a later commit I'm stopping here. The advantage, from the point of view of a reviewer like me, of splitting a patch into a series is that I can start reading at the first patch and, without reading the later ones, understand well enough to decide whether that first patch is worthwhile and safe to apply to the package. That way I don't have to invest a huge time commitment to start making progress on incorporating someone's changes. That only works if the first patch, alone, is already a valid change, and likewise for the first two patches, first three, etc. Without that property I'd rather just read one monolithic diff. Is it possible to extract a less-controversial subset from your spec that could be applied first? That would make life easier for busy and lazy folks like me, would create momentum for polishing and applying the rest, and can be a good way to move to a consensus on the basic idea without the distraction of other potential large, possibly disruptive changes. For example, I think the idea of a License-exception stanza is uncontroversial and valuable. Defining it might (or might not) bring out the need to define the structure of license names more precisely, which could in turn make it easier to later make the spec more accurately model that licenses like GPL-2 or GPL-3+ and GPL-2+ are equivalent. Summary: This series is too much for me to think about at once! My feeble mind wants a smaller subset to bite off before it will be able to swallow the whole set of changes. Sorry for the fuss, and hope that helps. Thanks for the feedback Jonathan! I will think about how to restructure my patches so they are easier to understand. In the meantime, if you (or anyone else) has some time, you could try to read that series in the following order? It may help to cover the issues you just mentioned. The commits basically fall into three groups. https://github.com/infinity0/debian-policy/commit/5cb480335c3eb65b465d08bb7eb656c8dbabaaf1 https://github.com/infinity0/debian-policy/commit/c9f42df1dda13f706bef17aaf1f994dda9046730 https://github.com/infinity0/debian-policy/commit/bf041429517cef46de0d1bdd8397c32c72abf4f9 These above commits re-define the License synopsis so that it treats short-names as a sort of unit with and/or/+/with-exception as operators acting on these units. I could probably add something that states this explicitly. https://github.com/infinity0/debian-policy/commit/5fe35fbe4e231da3eb6f53b4188f5722e3a79bd4 https://github.com/infinity0/debian-policy/commit/794b9531fbfb85ff7bf268132d1786a22caef795 These above commits re-define the License field so that it's possible to factor out more fine-tuned parts into stand-alone License stanzas, and adds the WHAT/WHO restriction. https://github.com/infinity0/debian-policy/commit/4b75212695e92730278cf7866aeb89a36f6ac542 This commit is now legal in the context of the other commits. (If this re-ordering makes more sense, let me know, since this will allow me to simply re-order the commits rather than thinking about how to restructure them.) Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Tue, Dec 18, 2012 at 11:53:21PM +, Ximin Luo a écrit : https://github.com/infinity0/debian-policy/compare/bug649350-infinity0 I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. I'm trying to follow the principle that the commit messages should already contain enough justification for the changes, but if any of them are unclear, please do ask me for further detail. (Further potential additions, which I've omitted for simplicity, include License-Exception: fields, and Location: fields to formalise the concept of a pointer to a License.) Dear Ximin, It was nice to split the patch and document the chunks, but I am still not convinced that the changes you propose are useful. In particular, I do not see the benefit from using a syntax for the license short names, especially that SPDX and other projects do not have one (for instance GPL-2 and GPL-2+ are seen as separate short names). Also, creating a syntax is a complex project that I think is beyond the scope of our machine-readable format. There are corner cases, for instance BSD-3-Clause is not the upgrade from BSD-2-Clause, or MPL-1.1 can be upgraded to MPL-2.0 despite its short name is not MPL-1.1+, etc. If you would like to work on a robust syntax, I propose you do it as an independant specification that can later be proposed for adoption not ony to use, but also to SPDX, OSI, ADMS.F/OSS, etc. Another change that you propose and that I disagree with is to forbid author- and software-specific information in stand-alone paragaphs. A lot of derivatives from the BSD licenses contain such information. Despite we link to a SPDX page where the BSD license terms are generic, I do not think that the intent in Debian's machine-readable format to is consider them all the same. At least in my copyright files I only use BSD-3-Clause if the copyright owners are the regents of the university of California. Cheers, -- Charles Plessy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
https://github.com/infinity0/debian-policy/compare/bug649350-infinity0 I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. I'm trying to follow the principle that the commit messages should already contain enough justification for the changes, but if any of them are unclear, please do ask me for further detail. (Further potential additions, which I've omitted for simplicity, include License-Exception: fields, and Location: fields to formalise the concept of a pointer to a License.) Ximin On 14/12/12 03:37, Jonathan Nieder wrote: Hi Ximin, Ximin Luo wrote: I had been using the SVN for DEP as a baseline for patches, but now I guess the source code for this is somewhere else - could one of you please point me to it? Sure. It's at git://git.debian.org/git/dbnpolicy/policy.git. Also, shall I continue on this bug report, or shall I start a thread on debian-devel@ or debian-projects@? This bug (which sends mail to debian-policy@) is fine. Do I remember correctly that this report was about introducing a License-Exception stanza type? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Correction: https://github.com/infinity0/debian-policy/compare/bug649530-infinity0 On 18/12/12 23:53, Ximin Luo wrote: [deleted incorrect url] I've split up my previous patch into more manageable chunks, and added extra explanations in the commit messages. I'm trying to follow the principle that the commit messages should already contain enough justification for the changes, but if any of them are unclear, please do ask me for further detail. (Further potential additions, which I've omitted for simplicity, include License-Exception: fields, and Location: fields to formalise the concept of a pointer to a License.) Ximin On 14/12/12 03:37, Jonathan Nieder wrote: Hi Ximin, Ximin Luo wrote: I had been using the SVN for DEP as a baseline for patches, but now I guess the source code for this is somewhere else - could one of you please point me to it? Sure. It's at git://git.debian.org/git/dbnpolicy/policy.git. Also, shall I continue on this bug report, or shall I start a thread on debian-devel@ or debian-projects@? This bug (which sends mail to debian-policy@) is fine. Do I remember correctly that this report was about introducing a License-Exception stanza type? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 14/12/12 03:37, Jonathan Nieder wrote: Hi Ximin, Ximin Luo wrote: I had been using the SVN for DEP as a baseline for patches, but now I guess the source code for this is somewhere else - could one of you please point me to it? Sure. It's at git://git.debian.org/git/dbnpolicy/policy.git. Thanks! Also, shall I continue on this bug report, or shall I start a thread on debian-devel@ or debian-projects@? This bug (which sends mail to debian-policy@) is fine. Do I remember correctly that this report was about introducing a License-Exception stanza type? Not primarily; that was a minor optional detail derived from the main issues. I'll try to explain it again when I have some more time. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Hi all, now that copyright-format 1.0 has been formally released as Debian policy, I would like to restart the discussion about getting this issue fixed. I had been using the SVN for DEP as a baseline for patches, but now I guess the source code for this is somewhere else - could one of you please point me to it? Also, shall I continue on this bug report, or shall I start a thread on debian-devel@ or debian-projects@? Thanks, Ximin On 11/02/12 16:41, Ximin Luo wrote: Updated patch to apply against recent changes made by plessy - attached version applies against r274 in SVN (Sat 11 Feb 2012 12:44:26 GMT). Is there somewhere else you guys are discussing this? Some other mailing list, or an IRC channel? Thanks, Ximin On 03/02/12 10:53, Ximin Luo wrote: On 03/02/12 01:39, Charles Plessy wrote: Dear Ximin, the patch you proposed moves a lot of text without changing it, which makes it difficult to review. Moreover, I think that there is a long-standing consensus to not change the normative parts of this format unless unavoidable. I have refrained from commenting until you pinged the bug, because I know that it is faster to write negative comments, and I wanted to give a chance to others to write supportive comments first. However, no feedback came. For me it underlines that the patch you sent is not creating consensus or enthousiasm. Every Debian developers have write access to the DEP Subversion repository, but the purpose is to let all DDs create new DEPs. For modifications of the drafts there needs consensus. At the current point, I strongly object to changes that will invalidate existing Debian copyright files, and I strongly suggest to stop perfecting the document unless there is a general agreement that some parts are too difficult to understand. Seeing many people doing the same mistake is usually a good metric for this. In our case, while it can be debated what is optimal to put or not put in stand-alone license files, the Debian copyright files following the current version of the specification already fit well their purpose. Let's defer further complifications – or simplifications – to future releases. Have a nice day, The patch *does not invalidate* existing copyright files. It moves (iirc) only two sections, and I wrote a quite lengthy explanation of all of the changes. It is not perfecting the document, it's addressing the core problem of this bug. It's really not that significant a change. Seeing many people doing the same mistake - have you actually done a study of this or are you just assuming nobody filed a bug therefore there's no problem? Well, *I* filed *this* bug, and it's based on *real experience* in trying to use this specification. Some parts suck, parts which most maintainers probably wouldn't come across because licenses generally aren't as complex as MPL-1.1 or GPL-2+ or LGPL-2.1+. Do you have some specific comments about the contents of the patch? It should not take more than about 10 minutes to skim over, to see that I haven't done anything completely insane. Then, after this initial investment, it shouldn't be that hard to see whether the details are watertight or not. I should think my language is pretty straightforward. X P.S. have a look at about:license in a mozilla browser, which does exactly what I'm trying to get this specification to allow - i.e. quote GPL-2 verbatim, rather than GPL-2+ verbatim (since that is NOT A LICENSE). -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Hi Ximin, Ximin Luo wrote: I had been using the SVN for DEP as a baseline for patches, but now I guess the source code for this is somewhere else - could one of you please point me to it? Sure. It's at git://git.debian.org/git/dbnpolicy/policy.git. Also, shall I continue on this bug report, or shall I start a thread on debian-devel@ or debian-projects@? This bug (which sends mail to debian-policy@) is fine. Do I remember correctly that this report was about introducing a License-Exception stanza type? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Charles Plessy wrote: Le Wed, Feb 08, 2012 at 06:15:55PM -0600, Jonathan Nieder a écrit : para Remaining lines: if left blank here, the file -emphasismust/emphasis include one or morelink +emphasismust/emphasis include a link linkend=stand-alone-license-paragraphstand-alone License -paragraphs/link matching the first line's license short +paragraph/link matching each of the first line's license short names, with their exception if any. Otherwise, this field should either include the full text of the license(s) or include a pointer to the Hi Jonathan, I am not sure that using the singular makes the instructions clearer. Couldn't one argue that it does not allow to have two standalone License paragraphs for one dual license statement from a Files paragraph ? Ah, thanks for mentioning this. I should have explained it. The problem is that the text include one or more paragraphs matching the license short names is somewhat ambiguous. To my ears, the reading that jumps out is (1) I might want to provide one, two, or even more standalone paragraphs, according to my preference, and (2) each one of those paragraphs should simultaneously match all license names from the Files paragraph. Clearly that is wrong, so I wanted to disambiguate. Therefore I wrote: include a paragraph matching each of the license short names which is intended to convey that for each license short name mentioned in this Files paragraph, there must be (at least) one standalone license paragraph. Now based on your response, I suspect you misread each to mean all. Can you suggest an alternate wording? For example, maybe something in this spirit would work: If there are no remaining lines, then all of the short names or short names followed by license exceptions making up the first line must be described in standalone license paragraphs. Thanks for looking it over. Sincerely, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Sat, Feb 11, 2012 at 03:23:42AM -0600, Jonathan Nieder a écrit : Now based on your response, I suspect you misread each to mean all. Can you suggest an alternate wording? For example, maybe something in this spirit would work: If there are no remaining lines, then all of the short names or short names followed by license exceptions making up the first line must be described in standalone license paragraphs. Very good ! I committed this plus your other suggestion, where I replaced instead of once for each by instead of repeating it in each. Here is the full patch. --- copyright-format.xml(révision 273) +++ copyright-format.xml(copie de travail) @@ -325,10 +325,12 @@ section id=stand-alone-license-paragraph titleStand-alone License Paragraph (optional, repeatable)/title para -Where a set of files are covered by multiple licenses, or one -license occurs multiple times, you can use a single-line -varnameLicense/varname field and standalone -varnameLicense/varname paragraphs to expand the license short names. +Stand-alone varnameLicense/varname paragraphs can be used to +provide the full license text for a given license once, instead of +repeating it in each varnameFiles/varname paragraph that refers to +it. The first line of the varnameLicense/varname field must be a +single license short name or a short name followed by a license +exception. /para para The following fields may be present in a standalone License @@ -468,12 +470,11 @@ single copyright file. /para para -Remaining lines: if these are omitted, the file -emphasismust/emphasis include a link +If there are no remaining lines, then all of the short names +or short names followed by license exceptions making up the +first line must be described in link linkend=stand-alone-license-paragraphstandalone License -paragraph/link matching each license short -name listed on the first line. -Otherwise, this field should either +paragraphs/link. Otherwise, this field should either include the full text of the license(s) or include a pointer to the license file under filename/usr/share/common-licenses/filename. This field should include all text needed in order to fulfill both I will keep this bug open because this patch does not address the core of Ximin's question. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Updated patch to apply against recent changes made by plessy - attached version applies against r274 in SVN (Sat 11 Feb 2012 12:44:26 GMT). Is there somewhere else you guys are discussing this? Some other mailing list, or an IRC channel? Thanks, Ximin On 03/02/12 10:53, Ximin Luo wrote: On 03/02/12 01:39, Charles Plessy wrote: Dear Ximin, the patch you proposed moves a lot of text without changing it, which makes it difficult to review. Moreover, I think that there is a long-standing consensus to not change the normative parts of this format unless unavoidable. I have refrained from commenting until you pinged the bug, because I know that it is faster to write negative comments, and I wanted to give a chance to others to write supportive comments first. However, no feedback came. For me it underlines that the patch you sent is not creating consensus or enthousiasm. Every Debian developers have write access to the DEP Subversion repository, but the purpose is to let all DDs create new DEPs. For modifications of the drafts there needs consensus. At the current point, I strongly object to changes that will invalidate existing Debian copyright files, and I strongly suggest to stop perfecting the document unless there is a general agreement that some parts are too difficult to understand. Seeing many people doing the same mistake is usually a good metric for this. In our case, while it can be debated what is optimal to put or not put in stand-alone license files, the Debian copyright files following the current version of the specification already fit well their purpose. Let's defer further complifications – or simplifications – to future releases. Have a nice day, The patch *does not invalidate* existing copyright files. It moves (iirc) only two sections, and I wrote a quite lengthy explanation of all of the changes. It is not perfecting the document, it's addressing the core problem of this bug. It's really not that significant a change. Seeing many people doing the same mistake - have you actually done a study of this or are you just assuming nobody filed a bug therefore there's no problem? Well, *I* filed *this* bug, and it's based on *real experience* in trying to use this specification. Some parts suck, parts which most maintainers probably wouldn't come across because licenses generally aren't as complex as MPL-1.1 or GPL-2+ or LGPL-2.1+. Do you have some specific comments about the contents of the patch? It should not take more than about 10 minutes to skim over, to see that I haven't done anything completely insane. Then, after this initial investment, it shouldn't be that hard to see whether the details are watertight or not. I should think my language is pretty straightforward. X P.S. have a look at about:license in a mozilla browser, which does exactly what I'm trying to get this specification to allow - i.e. quote GPL-2 verbatim, rather than GPL-2+ verbatim (since that is NOT A LICENSE). -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 diff --git a/web/deps/dep5/copyright-format.xml b/web/deps/dep5/copyright-format.xml index 35812b6..6f0ec4f 100644 --- a/web/deps/dep5/copyright-format.xml +++ b/web/deps/dep5/copyright-format.xml @@ -354,7 +354,7 @@ License: GPL-2+/programlisting programlistingFiles: src/js/editline/* Copyright: 1993, John Doe 1993, Joe Average -License: MPL-1.1 or GPL-2 or LGPL-2.1 +License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 [LICENSE TEXT] @@ -452,37 +452,48 @@ License: MPL-1.1 section id=license-field titlevarnameLicense/varname/title para -Formatted text, with synopsis. In the header paragraph, this field -gives the license information for the package as a whole, which may -be different or simplified from a combination of all the per-file -license information. In a Files paragraph, this field gives the -licensing terms for the files listed in the varnameFiles/varname -field for this paragraph. In a standalone License paragraph, it -gives the licensing terms for those paragraphs which reference it. - /para - para -First line: an abbreviated name for the license, or expression -giving alternatives (see link linkend=license-short-nameShort -names/link section for a list of standard abbreviations). If -there are licenses present in the package without a standard short -name, an arbitrary short name may be assigned for these licenses. +Formatted text, with synopsis in the form of a link linkend=license-syntaxlicense expression/link. +If there are licenses present in the package without a standard short +name, an arbitrary short name may be assigned for these licenses. These arbitrary names are only guaranteed to be unique
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Sat, Feb 11, 2012 at 04:41:28PM +, Ximin Luo a écrit : Is there somewhere else you guys are discussing this? Some other mailing list, or an IRC channel? Dear Ximin, in practice, discussions take place where they started, that is usually debian-project@, debian-devel@, debian-policy@ and debian-mentors@. Important points are CCed to debian-project@, since it is the list where it was decided originally that discussion should happen. For IRC, I do not know as I never connect there. After the 1.0 release, discussion will follow the Policy process, so the discussions will take place on that list through the bug records. Of course, it is good to seek comments on debian-devel@ or debian-projects@ when proposing changes that would affect a large number of developers or packages. I recommend you to make sure that each patch you send is focused on one and only one proposition. Reformatting, movements of paragraphs, etc. can be done after agreeing on the key changes. In my understanding, the key changes in your patch are the following. + para +Description text (License paragraphs): gives the licensing terms for +those paragraphs which reference it. (Other extra-license information, +which is software- or author-specific, should instead be given in the +appropriate Files paragraph, either in the License or Comment fields. +For example, the MPL-1.1 requirement to state the initial developers of +a particular piece of software, or any copyright notices explicitly +mentioning authorship. + /para + para +It is recommended that standalone License paragraphs only reference +irreducible link linkend=license-short-nameshort names/link of +published licenses, e.g. GPL-2 rather than GPL-2+, since this allows +maximum re-use. This is currently not enforced, but may be in a later +version of this specification. /para I think that they are too disruptive to be integrated before releasing version 1.0. 1) With the current DEP, it is possible to have software- or author-specific information in the standalone License paragraphs, and I do not want to send signals that maintainers should change this in their Debian copyright files as a best practice for version 1.0. 2) Using a standalone License paragraph for representing two different redistribution terms is not currently supported. Regardless my personnal opinion on that feature, such a normative change can not be done be done in the last minute, and I really hope to mark the DEP accepted next week. Also, I do not want the current text to speculate on the contents of the next versions in the absence of a clear consensus that a change will be applied. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Wed, Feb 08, 2012 at 06:15:55PM -0600, Jonathan Nieder a écrit : para Remaining lines: if left blank here, the file -emphasismust/emphasis include one or morelink +emphasismust/emphasis include a link linkend=stand-alone-license-paragraphstand-alone License -paragraphs/link matching the first line's license short +paragraph/link matching each of the first line's license short names, with their exception if any. Otherwise, this field should either include the full text of the license(s) or include a pointer to the Hi Jonathan, I am not sure that using the singular makes the instructions clearer. Couldn't one argue that it does not allow to have two standalone License paragraphs for one dual license statement from a Files paragraph ? Perhaps others can comment ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Sat, Feb 04, 2012 at 11:26:33AM +0900, Charles Plessy a écrit : Le Fri, Feb 03, 2012 at 01:16:08PM -0600, Jonathan Nieder a écrit : I believe this should be a blocker --- it is an instance of the document and actual practice clearly contradicting one another. I wouldn't mind if it is resolved by forbidding stand-alone license sections for license exceptions, though, if that's the only way to get something released. (Of course I would prefer the opposite resolution.) I think that the document overlooks rather than forbids the case of standalone paragraphs for licence with exceptions. In that sense I do not see a contradiction, and indeed, I found multiple copyright files in the Lintian lab that use such standalone paragraphs. Dear Jonathan, Ximin, and everybody, would the following changes solve the problem with license exceptions ? --- copyright-format.xml(révision 266) +++ copyright-format.xml(copie de travail) @@ -327,10 +327,10 @@ section id=stand-alone-license-paragraph titleStand-alone License Paragraph (Optional, Repeatable)/title para -Where a set of files are dual (tri, etc) licensed, or when the same -license occurs multiple times, you can use a single-line -varnameLicense/varname field and stand-alone -varnameLicense/varname paragraphs to expand the license short names. +Stand-alone varnameLicense/varname paragraphs expand license short +names, optionally followed by an exception statement, and are useful +in particular with sets of files that are dual (tri, etc) licensed, or +when the same license occurs multiple times. /para para The following fields may be present in a stand-alone License @@ -471,10 +471,10 @@ /para para Remaining lines: if left blank here, the file -emphasismust/emphasis include a link +emphasismust/emphasis include one or morelink linkend=stand-alone-license-paragraphstand-alone License -paragraph/link matching each license short -name listed on the first line. +paragraphs/link matching the first line's license short +names, with their exception if any. Otherwise, this field should either include the full text of the license(s) or include a pointer to the license file under filename/usr/share/common-licenses/filename. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Charles Plessy wrote: would the following changes solve the problem with license exceptions ? Here's some tweaks for application on top. With these tweaks, I'm happy with it. copyright-format/copyright-format.xml | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/copyright-format/copyright-format.xml b/copyright-format/copyright-format.xml index 3ae033dc..e125f705 100644 --- a/copyright-format/copyright-format.xml +++ b/copyright-format/copyright-format.xml @@ -323,10 +323,12 @@ License: GPL-2+/programlisting section id=stand-alone-license-paragraph titleStand-alone License Paragraph (Optional, Repeatable)/title para -Stand-alone varnameLicense/varname paragraphs expand license short -names, optionally followed by an exception statement, and are useful -in particular with sets of files that are dual (tri, etc) licensed, or -when the same license occurs multiple times. +Stand-alone varnameLicense/varname paragraphs can be used to +provide the full license text for a given license once, instead of +once for each varnameFiles/varname paragraph that refers to it. +The first line of the varnameLicense/varname field must be a +single license short name or a short name followed by a license +exception. /para para The following fields may be present in a stand-alone License @@ -467,9 +469,9 @@ License: MPL-1.1 /para para Remaining lines: if left blank here, the file -emphasismust/emphasis include one or morelink +emphasismust/emphasis include a link linkend=stand-alone-license-paragraphstand-alone License -paragraphs/link matching the first line's license short +paragraph/link matching each of the first line's license short names, with their exception if any. Otherwise, this field should either include the full text of the license(s) or include a pointer to the -- 1.7.9 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 03/02/12 01:39, Charles Plessy wrote: Dear Ximin, the patch you proposed moves a lot of text without changing it, which makes it difficult to review. Moreover, I think that there is a long-standing consensus to not change the normative parts of this format unless unavoidable. I have refrained from commenting until you pinged the bug, because I know that it is faster to write negative comments, and I wanted to give a chance to others to write supportive comments first. However, no feedback came. For me it underlines that the patch you sent is not creating consensus or enthousiasm. Every Debian developers have write access to the DEP Subversion repository, but the purpose is to let all DDs create new DEPs. For modifications of the drafts there needs consensus. At the current point, I strongly object to changes that will invalidate existing Debian copyright files, and I strongly suggest to stop perfecting the document unless there is a general agreement that some parts are too difficult to understand. Seeing many people doing the same mistake is usually a good metric for this. In our case, while it can be debated what is optimal to put or not put in stand-alone license files, the Debian copyright files following the current version of the specification already fit well their purpose. Let's defer further complifications – or simplifications – to future releases. Have a nice day, The patch *does not invalidate* existing copyright files. It moves (iirc) only two sections, and I wrote a quite lengthy explanation of all of the changes. It is not perfecting the document, it's addressing the core problem of this bug. It's really not that significant a change. Seeing many people doing the same mistake - have you actually done a study of this or are you just assuming nobody filed a bug therefore there's no problem? Well, *I* filed *this* bug, and it's based on *real experience* in trying to use this specification. Some parts suck, parts which most maintainers probably wouldn't come across because licenses generally aren't as complex as MPL-1.1 or GPL-2+ or LGPL-2.1+. Do you have some specific comments about the contents of the patch? It should not take more than about 10 minutes to skim over, to see that I haven't done anything completely insane. Then, after this initial investment, it shouldn't be that hard to see whether the details are watertight or not. I should think my language is pretty straightforward. X P.S. have a look at about:license in a mozilla browser, which does exactly what I'm trying to get this specification to allow - i.e. quote GPL-2 verbatim, rather than GPL-2+ verbatim (since that is NOT A LICENSE). -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Fri, Feb 03, 2012 at 10:53:45AM +, Ximin Luo a écrit : It is not perfecting the document, it's addressing the core problem of this bug. It's really not that significant a change. Hello again, I read again the whole bug discussion. For most of the propositions, all the participants, you included, agreed that they are not in the scope of the version 1.0 that we really want to publish soon. For other points, for instance that stand-alone license sections can also accept short names accompanied by their license exception, a clarification would not hurt; but I do not consider this a blocking problem. Unfortunately, you have included at least one normative change, the recommendation to collate short names that are identical except for a terminal “plus” character, that has direct consequences on parsing and is therefore not acceptable for the version 1.0. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Hi Charles, Charles Plessy wrote: For other points, for instance that stand-alone license sections can also accept short names accompanied by their license exception, a clarification would not hurt; but I do not consider this a blocking problem. I believe this should be a blocker --- it is an instance of the document and actual practice clearly contradicting one another. I wouldn't mind if it is resolved by forbidding stand-alone license sections for license exceptions, though, if that's the only way to get something released. (Of course I would prefer the opposite resolution.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Fri, Feb 03, 2012 at 01:16:08PM -0600, Jonathan Nieder a écrit : Charles Plessy wrote: For other points, for instance that stand-alone license sections can also accept short names accompanied by their license exception, a clarification would not hurt; but I do not consider this a blocking problem. I believe this should be a blocker --- it is an instance of the document and actual practice clearly contradicting one another. I wouldn't mind if it is resolved by forbidding stand-alone license sections for license exceptions, though, if that's the only way to get something released. (Of course I would prefer the opposite resolution.) I think that the document overlooks rather than forbids the case of standalone paragraphs for licence with exceptions. In that sense I do not see a contradiction, and indeed, I found multiple copyright files in the Lintian lab that use such standalone paragraphs. In parallel, I note that parsers do not refuse standalone paragraph even when they refer to a license listed only once in a Files field. For instance: Files: * Copyright: upstream License: foo Files: */contrib Copyright: somebody else License: bar License: foo The text for foo. License: bar The text for bar. Would you or Ximin like to propose a patch, focused on clarifying that stand-alone license paragraphs are allowed even for mono-licensed works and for licenses with exception ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 13/01/12 01:14, Ximin Luo wrote: On 10/01/12 00:41, Ximin Luo wrote: On 08/01/12 05:30, Steve Langasek wrote: On Sun, Dec 18, 2011 at 03:22:04PM -0600, Jonathan Nieder wrote: Ximin Luo wrote: OK, understood. I will take a look at creating a patch for copyright-format.xml like you did. However, I think I would prefer using an explicit grammar instead (e.g. the sort that programming language specifications use), because that leads to clearer thinking and less ambiguity. Which would you prefer? That's up to Steve, since he's the editor of the document. I am personally of two minds --- on one hand, I would like to see the copyright-format released quickly, which means making only minimal changes to the document. On the other hand, an explicit grammar would indeed make the details of the spec easier to understand. I guess if I were in your shoes, I'd keep a grammar in mind and make sure the text specifies it unambiguously but use plain text so as to make the changes not too invasive. It would be nice to have a formal grammar down the line, but that's also too large of a change for 1.0. Alright, I've set aside some time to work on this. I've checked out the SVN, installed the build-deps (docbook-utils tidy), will send a patch soon. X Patch attached. I moved some stuff around as well, but not that much; hopefully the description is clear enough to explain everything. X Hello again! Does anyone have any comments on this? I see Charles Plessy has made some extra changes to DEP5 in SVN since I created this patch, on 2012-02-02 (yesterday). Those changes don't conflict with this patch, but could people have a look at it before any future changes do? I could commit this directly to SVN if you guys prefer? (I've not tried yet, since I don't know if I have access, and I don't want something to go wrong.) X -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Dear Ximin, the patch you proposed moves a lot of text without changing it, which makes it difficult to review. Moreover, I think that there is a long-standing consensus to not change the normative parts of this format unless unavoidable. I have refrained from commenting until you pinged the bug, because I know that it is faster to write negative comments, and I wanted to give a chance to others to write supportive comments first. However, no feedback came. For me it underlines that the patch you sent is not creating consensus or enthousiasm. Every Debian developers have write access to the DEP Subversion repository, but the purpose is to let all DDs create new DEPs. For modifications of the drafts there needs consensus. At the current point, I strongly object to changes that will invalidate existing Debian copyright files, and I strongly suggest to stop perfecting the document unless there is a general agreement that some parts are too difficult to understand. Seeing many people doing the same mistake is usually a good metric for this. In our case, while it can be debated what is optimal to put or not put in stand-alone license files, the Debian copyright files following the current version of the specification already fit well their purpose. Let's defer further complifications – or simplifications – to future releases. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 10/01/12 00:41, Ximin Luo wrote: On 08/01/12 05:30, Steve Langasek wrote: On Sun, Dec 18, 2011 at 03:22:04PM -0600, Jonathan Nieder wrote: Ximin Luo wrote: OK, understood. I will take a look at creating a patch for copyright-format.xml like you did. However, I think I would prefer using an explicit grammar instead (e.g. the sort that programming language specifications use), because that leads to clearer thinking and less ambiguity. Which would you prefer? That's up to Steve, since he's the editor of the document. I am personally of two minds --- on one hand, I would like to see the copyright-format released quickly, which means making only minimal changes to the document. On the other hand, an explicit grammar would indeed make the details of the spec easier to understand. I guess if I were in your shoes, I'd keep a grammar in mind and make sure the text specifies it unambiguously but use plain text so as to make the changes not too invasive. It would be nice to have a formal grammar down the line, but that's also too large of a change for 1.0. Alright, I've set aside some time to work on this. I've checked out the SVN, installed the build-deps (docbook-utils tidy), will send a patch soon. X Patch attached. I moved some stuff around as well, but not that much; hopefully the description is clear enough to explain everything. X -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 From ebf53e0a334df9da3288a48c8d19b3244de97ddc Mon Sep 17 00:00:00 2001 From: Ximin Luo infini...@gmx.com Date: Fri, 13 Jan 2012 01:11:49 + Subject: [PATCH] DEP5: several structure changes section Paragraphs/standalone License - change tri-license example to be the more common MPL-1.1 or GPL-2+ or LGPL-2.1+ section Fields/License: - move the requirement to include all text needed to fulfill policy 12.5 [etc] into the case of header/Files paragraph ONLY - header/Files paragraph: rather than all or nothing approach, allow any component of a license to be individually delegated to standalone paragraph - License paragraph: forbid author- and software-specific information - License paragraph: recommend to use only irreducible license component (new definition of short-name, without +/exception) chapter License spec: - move syntax section to the top of the chapter, since that describes the overall structure section License spec/short names: - move +/with * exception into the syntax section instead, so it's at the same level as and/or - move list of exception names into its own section, so it's at the same level as short names - remove full text of the example GPL-2+ with OpenSSL exception; the new structure makes its redundancy more obvious notes: - the public-domain section was not changed, despite the diff's appearance --- web/deps/dep5/copyright-format.xml | 293 1 files changed, 133 insertions(+), 160 deletions(-) diff --git a/web/deps/dep5/copyright-format.xml b/web/deps/dep5/copyright-format.xml index 2420631..30a078a 100644 --- a/web/deps/dep5/copyright-format.xml +++ b/web/deps/dep5/copyright-format.xml @@ -350,7 +350,7 @@ License: GPL-2+/programlisting programlistingFiles: src/js/editline/* Copyright: 1993, John Doe 1993, Joe Average -License: MPL-1.1 or GPL-2 or LGPL-2.1 +License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 [LICENSE TEXT] @@ -448,38 +448,48 @@ License: MPL-1.1 section id=license-field titlevarnameLicense/varname/title para -Formatted text, with synopsis. In the header paragraph, this field -gives the license information for the package as a whole, which may -be different or simplified from a combination of all the per-file -license information. In a Files paragraph, this field gives the -licensing terms for the files listed in the varnameFiles/varname -field for this paragraph. In a stand-alone License paragraph, it -gives the licensing terms for those paragraphs which reference it. - /para - para -First line: an abbreviated name for the license, or expression -giving alternatives (see link linkend=license-short-nameShort -names/link section for a list of standard abbreviations). If -there are licenses present in the package without a standard short -name, an arbitrary short name may be assigned for these licenses. +Formatted text, with synopsis in the form of a link linkend=license-syntaxlicense expression/link. +If there are licenses present in the package without a standard short +name, an arbitrary short name may be assigned for these licenses. These arbitrary names are only guaranteed to be unique within a single copyright file. /para para -Remaining lines: if left blank here, the file -emphasismust/emphasis include a link -
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 08/01/12 05:30, Steve Langasek wrote: On Sun, Dec 18, 2011 at 03:22:04PM -0600, Jonathan Nieder wrote: Ximin Luo wrote: OK, understood. I will take a look at creating a patch for copyright-format.xml like you did. However, I think I would prefer using an explicit grammar instead (e.g. the sort that programming language specifications use), because that leads to clearer thinking and less ambiguity. Which would you prefer? That's up to Steve, since he's the editor of the document. I am personally of two minds --- on one hand, I would like to see the copyright-format released quickly, which means making only minimal changes to the document. On the other hand, an explicit grammar would indeed make the details of the spec easier to understand. I guess if I were in your shoes, I'd keep a grammar in mind and make sure the text specifies it unambiguously but use plain text so as to make the changes not too invasive. It would be nice to have a formal grammar down the line, but that's also too large of a change for 1.0. Alright, I've set aside some time to work on this. I've checked out the SVN, installed the build-deps (docbook-utils tidy), will send a patch soon. X -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On Sun, Dec 18, 2011 at 03:22:04PM -0600, Jonathan Nieder wrote: Ximin Luo wrote: OK, understood. I will take a look at creating a patch for copyright-format.xml like you did. However, I think I would prefer using an explicit grammar instead (e.g. the sort that programming language specifications use), because that leads to clearer thinking and less ambiguity. Which would you prefer? That's up to Steve, since he's the editor of the document. I am personally of two minds --- on one hand, I would like to see the copyright-format released quickly, which means making only minimal changes to the document. On the other hand, an explicit grammar would indeed make the details of the spec easier to understand. I guess if I were in your shoes, I'd keep a grammar in mind and make sure the text specifies it unambiguously but use plain text so as to make the changes not too invasive. It would be nice to have a formal grammar down the line, but that's also too large of a change for 1.0. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Sun, Dec 18, 2011 at 08:44:16PM +, Ximin Luo a écrit : I think your example above is not the best way to represent license exceptions. Roughly, the specification of a license can be described by this sort of grammar: CompositeLicense :: AND ( CompositeLicense1 CompositeLicense2 ... ) :: OR ( CompositeLicense1 CompositeLicense2 ... ) :: CompositeLicense with LicenseException :: PublishedLicense or later :: PublishedLicense Dear Ximin, frankly, I do not think that we need a grammar. Note that the early draft of DEP 5 contained an EBNF grammar and we removed it. http://lists.alioth.debian.org/pipermail/dep-commits/2009-April/37.html I even do not think anymore that we need a system for declaring license exceptions. Exceptions, version numbers, and permissions to upgrade can all be represented as separate licenses with a single short name. Projects interested in tracking relationships and interactions between licenses can attach their own metadata to the published short names – and of course, share it. Have a nice day, -- Charles Plessy Illkirch-Graffenstaden, France -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 21/12/11 12:05, Charles Plessy wrote:
Le Sun, Dec 18, 2011 at 08:44:16PM +, Ximin Luo a écrit :
I think your example above is not the best way to represent license
exceptions.
Roughly, the specification of a license can be described by this sort of
grammar:
CompositeLicense
:: AND ( CompositeLicense1 CompositeLicense2 ... )
:: OR ( CompositeLicense1 CompositeLicense2 ... )
:: CompositeLicense with LicenseException
:: PublishedLicense or later
:: PublishedLicense
Dear Ximin,
frankly, I do not think that we need a grammar. Note that the early draft of
DEP 5 contained an EBNF grammar and we removed it.
http://lists.alioth.debian.org/pipermail/dep-commits/2009-April/37.html
I even do not think anymore that we need a system for declaring license
exceptions. Exceptions, version numbers, and permissions to upgrade can all
be
represented as separate licenses with a single short name. Projects
interested
in tracking relationships and interactions between licenses can attach their
own metadata to the published short names – and of course, share it.
Have a nice day,
I see the grammar you removed was for the nitty-gritty details of various data
types, such as license short names. I was talking more about a grammar for the
file as a whole. I agree it's not necessary to specify everything down to the
smallest detail, but a formal structure for the significant semantic units at
least, simplifies things considerably.
I assume your reasoning for not wanting a grammar, is to not over-complicate
things. But I don't think yours is a good approach, because
- at the moment a lot of the complexity is in the *TEXT*. A formal grammar
would simplify things considerably, allowing more powerful features.
- DEP5 currently already prevents the simplifications I mentioned elsewhere in
this thread. You would be trading simplicity of specification, for complexity
of debian/copyright for packages with multiple licenses.
If we continue down your line of logic, of simplifying the spec, we would get
rid of the License: stanza completely. That would solve the inconsistency
issues I mentioned. But this has the same problems I just mentioned - it makes
{packages with complex licenses} have *very* complex copyright files.
The main issue is that for each License: field specified, DEP5 places
inconsistent restrictions on the License: stanzas that can exist in the file,
which interferes with projects interested in tracking relationships [etc].
Also, having actually tried to write a DEP5 parser that is advanced enough to
do useful stuff like answer can package X be considered to be licensed under
A, I think the grammar is vital, if you want to get any proper semantics out
of the spec. Otherwise it's just a glorified shopping list.
TL;DR: I just want to be able to do this:
| File: X
| License: A+ with exception B and C
| Notice: (relevant text from upstream)
|
| File: Y
| License: A or C
| Notice: (relevant text from upstream)
|
| License: A
|
| License-Exception: B
|
| License: C
|
--
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0
signature.asc
Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On Sun, Dec 18, 2011 at 12:24:03AM -0600, Jonathan Nieder wrote: I disagree strongly. The cost of giving maintainers *different* ways to represent the license status is much higher than the cost of requiring maintainers to separately reproduce license headers for components that are GPL-2 licensed vs. GPL-2+. Reading this in the context of the text you are replying to, I fear I don't understand. I didn't mention multiple licenses or multiple ways to represent license status at all, so this reply feels like a non-sequitor. While it's useful to see that you disagree strongly, I'm not sure what you disagree strongly with. In your message, you said that you didn't think it should be required to split the license notice into a comment field but that it should be allowed, and you offered a patch addressing this. Allowed means the author of the file has a choice about which way to do it, and that's not appropriate. However, I don't think there is anything to act on immediately in this report, except clarifying one detail: Since standalone license paragraphs are used to expand license short names and GPL-2+ with OpenSSL exception is not a short name but a short name with an exception, do I understand correctly that license exceptions cannot be put in stand-alone License paragraphs? I don't believe that's the intent at all. I think this is perfectly valid: Files: * Copyright: The Man in the Moon, 2007 License: GPL-2+ with OpenSSL exception License: GPL-2+ with OpenSSL exception This program is free software [...] as a special exception, [...] On Debian systems, [...] Perhaps the spec should be clarified to make this more explicit? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Steve Langasek wrote: I think this is perfectly valid: Files: * Copyright: The Man in the Moon, 2007 License: GPL-2+ with OpenSSL exception License: GPL-2+ with OpenSSL exception This program is free software [...] as a special exception, [...] On Debian systems, [...] Perhaps the spec should be clarified to make this more explicit? Yep, that would be welcome. Thanks for looking at it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 18/12/11 17:52, Steve Langasek wrote: On Sun, Dec 18, 2011 at 12:24:03AM -0600, Jonathan Nieder wrote: I disagree strongly. The cost of giving maintainers *different* ways to represent the license status is much higher than the cost of requiring maintainers to separately reproduce license headers for components that are GPL-2 licensed vs. GPL-2+. Reading this in the context of the text you are replying to, I fear I don't understand. I didn't mention multiple licenses or multiple ways to represent license status at all, so this reply feels like a non-sequitor. While it's useful to see that you disagree strongly, I'm not sure what you disagree strongly with. In your message, you said that you didn't think it should be required to split the license notice into a comment field but that it should be allowed, and you offered a patch addressing this. Allowed means the author of the file has a choice about which way to do it, and that's not appropriate. However, I don't think there is anything to act on immediately in this report, except clarifying one detail: Since standalone license paragraphs are used to expand license short names and GPL-2+ with OpenSSL exception is not a short name but a short name with an exception, do I understand correctly that license exceptions cannot be put in stand-alone License paragraphs? I don't believe that's the intent at all. I think this is perfectly valid: Files: * Copyright: The Man in the Moon, 2007 License: GPL-2+ with OpenSSL exception License: GPL-2+ with OpenSSL exception This program is free software [...] as a special exception, [...] On Debian systems, [...] Perhaps the spec should be clarified to make this more explicit? Yes, the current DEP5 supports this and has it as an explicit example. Just to be clear though, we've been talking about a proposal to change the spec, and much of the discussion here has been within the context of this proposal, *not* the current DEP5. I think your example above is not the best way to represent license exceptions. Roughly, the specification of a license can be described by this sort of grammar: CompositeLicense :: AND ( CompositeLicense1 CompositeLicense2 ... ) :: OR ( CompositeLicense1 CompositeLicense2 ... ) :: CompositeLicense with LicenseException :: PublishedLicense or later :: PublishedLicense I think License: stanzas should only refer to PublishedLicenses, rather than CompositeLicenses such as GPL2+ with OpenSSL exception. The reason is to make re-use easy, and also to make parsing easy. For example: allowed by current DEP5 | Files: X | License: SomePL2 | | License: SomePL2 | [FULL TEXT] | | Files: Y | License: SomePL2+ with OpenSSL Exception | | License: SomePL2+ with OpenSSL Exception | [FULL TEXT] | [Exception notice] could be re-written as: allowed by new proposal | Files: X | License: SomePL2 | | Files: Y | License: SomePL2+ with OpenSSL Exception | Comment: [clarifying this complex license, if deemed necessary] | | License: SomePL2 | [FULL TEXT] | | License-Exception: OpenSSL Exception to the SomePL | [Exception notice] Now obviously this is only useful for very complex packages, most of the time you should just be able to bundle everything into the License: *field* of the File: stanza, like this: | Files: X | License: SomePL2+ with OpenSSL Exception | [FULL TEXT] | [Exception notice] -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo wrote: the current DEP5 supports this and has it as an explicit example. Relevant wording: Section Paragraphs, subsection Stand-alone License Paragraph says: Where a set of files are dual (tri, etc) licensed, or when the same license occurs multiple times, you can use a single-line License field and stand-alone License paragraphs to expand the license short names. Problems: - the wording only permits stand-alone License paragraphs describing license short names, not short names with exceptions appended - the wording only permits stand-alone License paragraphs when a set of files has a complex license or the same license occurs multiple times, contradicting common practice of using stand-alone License paragraphs when convenient in simpler situations, too. Section Fields, subsection License says: Remaining lines: if left blank here, the file must include a stand-alone License paragraph matching each license short name listed on the first line. Problem: - the wording only permits stand-alone License paragraphs describing license short names. Section License specification, subsection Syntax includes an example of a License field for the license GPL-2+ with OpenSSL exception. It does not make it clear whether this example is suitable for Files paragraphs and stand-alone License paragraphs, or only one of the two. Hope that helps. Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo wrote: OK, understood. I will take a look at creating a patch for copyright-format.xml like you did. However, I think I would prefer using an explicit grammar instead (e.g. the sort that programming language specifications use), because that leads to clearer thinking and less ambiguity. Which would you prefer? That's up to Steve, since he's the editor of the document. I am personally of two minds --- on one hand, I would like to see the copyright-format released quickly, which means making only minimal changes to the document. On the other hand, an explicit grammar would indeed make the details of the spec easier to understand. I guess if I were in your shoes, I'd keep a grammar in mind and make sure the text specifies it unambiguously but use plain text so as to make the changes not too invasive. Thanks much, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 18/12/11 20:56, Jonathan Nieder wrote: Ximin Luo wrote: the current DEP5 supports this and has it as an explicit example. Relevant wording: Section Paragraphs, subsection Stand-alone License Paragraph says: Where a set of files are dual (tri, etc) licensed, or when the same license occurs multiple times, you can use a single-line License field and stand-alone License paragraphs to expand the license short names. Problems: - the wording only permits stand-alone License paragraphs describing license short names, not short names with exceptions appended - the wording only permits stand-alone License paragraphs when a set of files has a complex license or the same license occurs multiple times, contradicting common practice of using stand-alone License paragraphs when convenient in simpler situations, too. Section Fields, subsection License says: Remaining lines: if left blank here, the file must include a stand-alone License paragraph matching each license short name listed on the first line. Problem: - the wording only permits stand-alone License paragraphs describing license short names. Section License specification, subsection Syntax includes an example of a License field for the license GPL-2+ with OpenSSL exception. It does not make it clear whether this example is suitable for Files paragraphs and stand-alone License paragraphs, or only one of the two. Hope that helps. Jonathan OK, understood. I will take a look at creating a patch for copyright-format.xml like you did. However, I think I would prefer using an explicit grammar instead (e.g. the sort that programming language specifications use), because that leads to clearer thinking and less ambiguity. Which would you prefer? Or should I do both (it would take much more time)? X -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Sorry for the late reply, I had forgotten about this. On 22/11/11 14:29, Charles Plessy wrote: Le Mon, Nov 21, 2011 at 11:08:44PM +, Ximin Luo a écrit : The fundamental problem: DEP5 is unclear about what is meant by a license. Dear Ximin, thank you for your comments and for pointing out that the examples in the current draft are not consistent with the draft's syntax. I will file a bug about this later. Um, I was not aware that I had made this point. What I was trying to argue however, is that - License: paragraphs are not defined in a good way - because of this bad/unclear definition, DEP5 uses license notices as examples for License: stanzas, which I argued is wrong. I don't think this is an inconsistency as such, but I do think DEP5 needs to be fixed to address this. I would like to re-frame the discussion and remind that, at the base of the DEP, there are the requirements of the Debian policy, of the Debian archive administrators, and the common practice. In the case of the (L)GPL, it is common practice to use the license notices as found in headers of files as if they were the actual license text. First because the Policy §12.5 specifies that the copyright file should point at /usr/share/common-licenses instead of quoting these licenses, and second because the Archive administrators require us to include these headers (http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html) I am arguing that the common practise is incorrect. The first reason does not hold: pointing to a license file is different to including a license notice because a license notice is NOT a *license*, it often contains extra information (like authors and which software). The second reason also does not hold: That email you quoted is about the copyright file as a whole, whereas I am only arguing against the License: stanza. Of course the file as a whole must contain information equivalent to a license notice. But the License: stanza must not, as I argued before. I believe this is quite well summarised in the DEP iself, but your suggestions for improvement are most welcome. See http://dep.debian.net/deps/dep5/#license-files-field Because the license notices differ between GPL-n and GPL-n+, I think that it is consistent to not accept to factorise them with the same stand-alone license paragraph. I am arguing that this is inconsistent. GPL-2+ is equivalent to (GPL-2 or GPL-3 or ...) but for other similar cases, such as (MPL or GPL), DEP5 currently forces me to split them into separate License: paragraphs. To be consistent, you must pick one of these two: - License: paragraphs can't be split - they specify the entire terms for a given set of files. MPL or LGPL or GPL is separate license from LGPL or GPL and they each need separate License: paragraphs - License: paragraphs can be split into common components, and relicensing comments be pushed back into the File: paragraph, and disallowed to be in the License: paragraph. This forbids many many license notices which often contain such information. I also think that license notices should just be barred outright from License: paragraphs since they also often contain authorship/software information, which could conflict with other File: paragraphs that want to use the same License. Allowing conflict-less cases but barring conflicting cases would just be untidy. In the case of the BSD-family licenses, my feeling is that indeed, they all differ as soon as the wording changes, in particular when the persons or institutions whose name “must not be used to endorse usage…” differ. This said I think that in most countries, this clause is redundant with laws protecting the usage of other's names, which makes the BSD variants discussed here practically equivalent. Accordingly, SPDX.org is collating them under the same short name. The case of the MPL, and the other long licenses with variable notices or exhibit (or however they are called), is more difficult as one would have to include the exhibit in the Files paragraph and the full, invarable text in the stand-alone License paragraph. While the DEP does not disallow to do that, it opens difficult questions on how to represent the information. In the case of the MPL, a workaround could be to include its full text in /usr/share/common-licenses. This said, I expect that the first uses cases of machine-reading DEP-5 copyright files will focus on the license short names. For the rest, I think that we would benefit of first observing if there is convergence in people's practice. The parsers used to edit, validate or display the copyright files will for sure be influential on this convergence. In that context, I think that suggestions like license exception paragraph are more relevant for a 1.1 revision. If needed I would agree to modify the DEP to not disallow them. For instance: “Parsers may recognise extra types paragraphs, but this
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 12/12/11 01:19, Jonathan Nieder wrote: Charles Plessy wrote: I would like to re-frame the discussion and remind that [...] In the case of the (L)GPL, it is common practice to use the license notices as found in headers of files as if they were the actual license text. For what it's worth, I disagree, while I agree with Ximin Luo that current format is somewhat inefficient in the cases mentioned. Perhaps a source of confusion is something Joerg wrote five years ago[1]: | There are license headers, like the one used for GPL in the example below, you | should use those. I continue to believe that what he meant is that such pre-made license headers are good at covering their bases and that it is advisable to take advantage of the work that was already done in writing them. For example, the typical license headers explicitly mention that _you_ may redistribute and modify the software, and they tend to include a disclaimer of warranty. By contrast, a statement like | | On Debian systems, the complete text of the GNU General Public License | | can be found in the `/usr/share/common-licenses/GPL' file. does not actually say that that license applies to the software at all! Sorry, I didn't understand your point here. Are you saying it's better to include license notice as the actual text? I don't think does not actually say that [..] applies [..] at all is a problem - the File: stanza already takes care of that. For me, License: stanza is just a declaration of terms. The job of stating which terms actually apply to which WHO/WHAT (to use my original email's words) is for the File: stanza to take care of. Everything else that we've been discussing then follows naturally from this principle. However, if I'm the only one that read the email that way, then I would be happy to see this clarified in policy. (Well, I would be unhappy actually, since it would mean a lot of work for me preserving all the variations on license notices in packages I work with.) The rest of the use cases described should be easier to address: - In the current copyright-format, if you say License: GPL-2+ or License: GFDL-1.1+, you have to say what that means. That is probably worth changing in the future, for example by only requiring the presence of at least one standalone paragraph satisfying the license version constraint (e.g., License: GPL-2 or License: GFDL-1.2). I think it would be fine to delay that to copyright-format 1.1. - The current copyright-format is unclear about how to document what a license exception means in a standalone paragraph. I think that should be fixed before release, for example by requiring a standalone paragraph describing the license together with the exception (e.g., License: GPL-2+ with Font exception). In a later release, a new License-Exception paragraph type could be introduced. - Current practice is not to treat the list of copyright holders as part of the license. I see no reason to explicitly document that or change it. I think it's important to document it at least, so that people don't mistakenly add WHO/WHAT information to the License: stanza. - Copyright holders can be listed in the Copyright field. Other authors can be listed in a Comment field when desirable. They can be collated and do not need to be separated by file when a Files stanza describes multiple files (unless some license requirement says so, of course). I see no reason to change this. Sane? [1] http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo wrote: On 12/12/11 01:19, Jonathan Nieder wrote: Perhaps a source of confusion is something Joerg wrote five years ago[1]: [...] I continue to believe that what he meant is that such pre-made license headers are good at covering their bases and that it is advisable to take advantage of the work that was already done in writing them. [...] Sorry, I didn't understand your point here. Are you saying it's better to include license notice as the actual text? I don't think does not actually say that [..] applies [..] at all is a problem - the File: stanza already takes care of that. For me, License: stanza is just a declaration of terms. Ah, thanks for your patience in clarifying. I misunderstood both you and Charles before. So, the main change in practice that you are proposing is that when reformatting a copyright file describing a project under the GPL, packagers should not be allowed to write License: GPL-2 This file 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, version 2. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. . On Debian systems, the text of the GNU General Public License version 2 can be found at /usr/share/common-licenses/GPL-2. Instead, packagers would write something like this: Comments: This file 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, version 2. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. License: GPL-2 On Debian systems, the text of the GNU General Public License version 2 can be found at /usr/share/common-licenses/GPL-2. I don't see any compelling reason to _mandate_ that style immediately, since as Charles mentioned, it does not much current practice. But I don't see anything wrong with permitting it. That would mean removing the sentence This field should include all text needed in order to fulfill both Debian Policy's requirement for including a copy of the software's distribution license (12.5), and any license requirements to include warranty disclaimers or other notices with the binary package. As you said, it does not match existing practice in the case of BSD-style licenses anyway (for which a part of the required notices tends to go in the Copyright field, not the License field). Illustrative patch follows. Sorry to have been so dense. diff --git i/copyright-format.xml w/copyright-format.xml index 1f6c041b..069b022c 100644 --- i/copyright-format.xml +++ w/copyright-format.xml @@ -474,12 +474,6 @@ License: MPL-1.1 Otherwise, this field should either include the full text of the license(s) or include a pointer to the license file under filename/usr/share/common-licenses/filename. -This field should include all text needed in order to fulfill both -Debian Policy's requirement for including a copy of the software's -distribution license (ulink - url=http://www.debian.org/doc/debian-policy/ch-docs#s-copyrightfile;12.5/ulink), -and any license requirements to include warranty disclaimers or -other notices with the binary package. /para /section -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Thanks for quick response :) On 17/12/11 21:45, Jonathan Nieder wrote: Ximin Luo wrote: On 12/12/11 01:19, Jonathan Nieder wrote: Perhaps a source of confusion is something Joerg wrote five years ago[1]: [...] I continue to believe that what he meant is that such pre-made license headers are good at covering their bases and that it is advisable to take advantage of the work that was already done in writing them. [...] Sorry, I didn't understand your point here. Are you saying it's better to include license notice as the actual text? I don't think does not actually say that [..] applies [..] at all is a problem - the File: stanza already takes care of that. For me, License: stanza is just a declaration of terms. Ah, thanks for your patience in clarifying. I misunderstood both you and Charles before. So, the main change in practice that you are proposing is that when reformatting a copyright file describing a project under the GPL, packagers should not be allowed to write License: GPL-2 This file 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, version 2. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. . On Debian systems, the text of the GNU General Public License version 2 can be found at /usr/share/common-licenses/GPL-2. Under my proposal, I think the above is just about acceptable, but I'd recommend against it, since it doesn't represent GPL2 by itself - it contains extra information. However, I *would* forbid/discourage the equivalent text for GPL2+, because that explicitly mentions relicensing, which I think is more appropriately done in the File: stanza. I don't think this is the main point of my proposal :p the main point is to allow people to re-use License: paragraphs more effectively. I.e. not having to repeat themselves when some stuff is GPL2 and other stuff is GPL2+. Instead, packagers would write something like this: Comments: This file 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, version 2. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. License: GPL-2 On Debian systems, the text of the GNU General Public License version 2 can be found at /usr/share/common-licenses/GPL-2. I don't see any compelling reason to _mandate_ that style immediately, since as Charles mentioned, it does not much current practice. But I don't see anything wrong with permitting it. For this example, GPL-2, I don't think it's a big deal whether to mandate this. However for the GPL-2+ case (and possibly others), I do think this should be the preferred approach - possibly even forbid License: stanzas for GPL-2+ and instead use GPL-2 with Comment: to clarify the relicensing under later versions. That would mean removing the sentence This field should include all text needed in order to fulfill both Debian Policy's requirement for including a copy of the software's distribution license (12.5), and any license requirements to include warranty disclaimers or other notices with the binary package. As you said, it does not match existing practice in the case of BSD-style licenses anyway (for which a part of the required notices tends to go in the Copyright field, not the License field). Illustrative patch follows. Sorry to have been so dense. Looks good to me :) No need to apologise! There may be further changes to be made, I could look through in more detail when I have some more time. diff --git i/copyright-format.xml w/copyright-format.xml index 1f6c041b..069b022c 100644 --- i/copyright-format.xml +++ w/copyright-format.xml @@ -474,12 +474,6 @@ License: MPL-1.1 Otherwise, this field should either include the full text of the license(s) or
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On Sat, Dec 17, 2011 at 03:45:03PM -0600, Jonathan Nieder wrote: So, the main change in practice that you are proposing is that when reformatting a copyright file describing a project under the GPL, packagers should not be allowed to write License: GPL-2 This file 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, version 2. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. . On Debian systems, the text of the GNU General Public License version 2 can be found at /usr/share/common-licenses/GPL-2. Instead, packagers would write something like this: Comments: This file 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, version 2. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. License: GPL-2 On Debian systems, the text of the GNU General Public License version 2 can be found at /usr/share/common-licenses/GPL-2. I don't see any compelling reason to _mandate_ that style immediately, since as Charles mentioned, it does not much current practice. But I don't see anything wrong with permitting it. I disagree strongly. The cost of giving maintainers *different* ways to represent the license status is much higher than the cost of requiring maintainers to separately reproduce license headers for components that are GPL-2 licensed vs. GPL-2+. I also disagree with the refactoring originally requested by this bug report. Having stand-alone license paragraphs whose first line *doesn't match* the license field of the Files: paragraph it corresponds to means that parsers must embed all kinds of esoteric knowledge about which license names imply other licenses, and that kind of logic does not belong in a parser. The intent of DEP5 is not to ensure that a consistent block of text is used for the stand-alone license paragraph across all packages; it's to ensure that consistent names are used for describing the licenses so that they can be mechanically understood *regardless* of the text included there. Illustrative patch follows. Sorry to have been so dense. diff --git i/copyright-format.xml w/copyright-format.xml index 1f6c041b..069b022c 100644 --- i/copyright-format.xml +++ w/copyright-format.xml @@ -474,12 +474,6 @@ License: MPL-1.1 Otherwise, this field should either include the full text of the license(s) or include a pointer to the license file under filename/usr/share/common-licenses/filename. -This field should include all text needed in order to fulfill both -Debian Policy's requirement for including a copy of the software's -distribution license (ulink - url=http://www.debian.org/doc/debian-policy/ch-docs#s-copyrightfile;12.5/ulink), -and any license requirements to include warranty disclaimers or -other notices with the binary package. /para /section I am opposed to this change ever being included in the copyright-format standard. And in the meantime, I definitely don't consider it appropriate for inclusion in version 1.0, which is in standardization-bugfix-only mode. I'll leave the bug report open, for the policy maintainers to decide what to do with after copyright-format has gone 1.0. On Sat, Dec 17, 2011 at 02:22:57PM +, Ximin Luo wrote: - License: paragraphs are not defined in a good way - because of this bad/unclear definition, DEP5 uses license notices as examples for License: stanzas, which I argued is wrong. The use of license notices in License: stanzas is deliberate and will not be changed for 1.0. However, if you think the language is unclear, I'm certainly open to seeing it improved: we don't want the requirements of DEP5 to be ambiguous. I would like to re-frame the discussion and remind that, at the
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Steve Langasek wrote: I disagree strongly. The cost of giving maintainers *different* ways to represent the license status is much higher than the cost of requiring maintainers to separately reproduce license headers for components that are GPL-2 licensed vs. GPL-2+. Reading this in the context of the text you are replying to, I fear I don't understand. I didn't mention multiple licenses or multiple ways to represent license status at all, so this reply feels like a non-sequitor. While it's useful to see that you disagree strongly, I'm not sure what you disagree strongly with. However, I don't think there is anything to act on immediately in this report, except clarifying one detail: Since standalone license paragraphs are used to expand license short names and GPL-2+ with OpenSSL exception is not a short name but a short name with an exception, do I understand correctly that license exceptions cannot be put in stand-alone License paragraphs? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Charles Plessy wrote: I would like to re-frame the discussion and remind that [...] In the case of the (L)GPL, it is common practice to use the license notices as found in headers of files as if they were the actual license text. For what it's worth, I disagree, while I agree with Ximin Luo that current format is somewhat inefficient in the cases mentioned. Perhaps a source of confusion is something Joerg wrote five years ago[1]: | There are license headers, like the one used for GPL in the example below, you | should use those. I continue to believe that what he meant is that such pre-made license headers are good at covering their bases and that it is advisable to take advantage of the work that was already done in writing them. For example, the typical license headers explicitly mention that _you_ may redistribute and modify the software, and they tend to include a disclaimer of warranty. By contrast, a statement like | | On Debian systems, the complete text of the GNU General Public License | | can be found in the `/usr/share/common-licenses/GPL' file. does not actually say that that license applies to the software at all! However, if I'm the only one that read the email that way, then I would be happy to see this clarified in policy. (Well, I would be unhappy actually, since it would mean a lot of work for me preserving all the variations on license notices in packages I work with.) The rest of the use cases described should be easier to address: - In the current copyright-format, if you say License: GPL-2+ or License: GFDL-1.1+, you have to say what that means. That is probably worth changing in the future, for example by only requiring the presence of at least one standalone paragraph satisfying the license version constraint (e.g., License: GPL-2 or License: GFDL-1.2). I think it would be fine to delay that to copyright-format 1.1. - The current copyright-format is unclear about how to document what a license exception means in a standalone paragraph. I think that should be fixed before release, for example by requiring a standalone paragraph describing the license together with the exception (e.g., License: GPL-2+ with Font exception). In a later release, a new License-Exception paragraph type could be introduced. - Current practice is not to treat the list of copyright holders as part of the license. I see no reason to explicitly document that or change it. - Copyright holders can be listed in the Copyright field. Other authors can be listed in a Comment field when desirable. They can be collated and do not need to be separated by file when a Files stanza describes multiple files (unless some license requirement says so, of course). I see no reason to change this. Sane? [1] http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Le Mon, Nov 21, 2011 at 11:08:44PM +, Ximin Luo a écrit : The fundamental problem: DEP5 is unclear about what is meant by a license. Dear Ximin, thank you for your comments and for pointing out that the examples in the current draft are not consistent with the draft's syntax. I will file a bug about this later. I would like to re-frame the discussion and remind that, at the base of the DEP, there are the requirements of the Debian policy, of the Debian archive administrators, and the common practice. In the case of the (L)GPL, it is common practice to use the license notices as found in headers of files as if they were the actual license text. First because the Policy §12.5 specifies that the copyright file should point at /usr/share/common-licenses instead of quoting these licenses, and second because the Archive administrators require us to include these headers (http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html) I believe this is quite well summarised in the DEP iself, but your suggestions for improvement are most welcome. See http://dep.debian.net/deps/dep5/#license-files-field Because the license notices differ between GPL-n and GPL-n+, I think that it is consistent to not accept to factorise them with the same stand-alone license paragraph. In the case of the BSD-family licenses, my feeling is that indeed, they all differ as soon as the wording changes, in particular when the persons or institutions whose name “must not be used to endorse usage…” differ. This said I think that in most countries, this clause is redundant with laws protecting the usage of other's names, which makes the BSD variants discussed here practically equivalent. Accordingly, SPDX.org is collating them under the same short name. The case of the MPL, and the other long licenses with variable notices or exhibit (or however they are called), is more difficult as one would have to include the exhibit in the Files paragraph and the full, invarable text in the stand-alone License paragraph. While the DEP does not disallow to do that, it opens difficult questions on how to represent the information. In the case of the MPL, a workaround could be to include its full text in /usr/share/common-licenses. This said, I expect that the first uses cases of machine-reading DEP-5 copyright files will focus on the license short names. For the rest, I think that we would benefit of first observing if there is convergence in people's practice. The parsers used to edit, validate or display the copyright files will for sure be influential on this convergence. In that context, I think that suggestions like license exception paragraph are more relevant for a 1.1 revision. If needed I would agree to modify the DEP to not disallow them. For instance: “Parsers may recognise extra types paragraphs, but this is not required to comply to this specification”. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Hi, Ximin Luo wrote: When packaging mozilla extensions I ran some problems with DEP5. I talked this issue over on #645696 which eventually resulted in encouragement to move forward with a proposal for a change to be made. I think this report contains multiple proposals. Let me try to summarize (and please correct me where I go wrong). First, the problem being addressed: a debian/copyright file like this: Files: * Copyright: - etc License: GPL-2+ License: GPL-2 etc or this: Files: * Copyright: - etc License: GPL-2 with Font exception License: GPL-2 etc is not considered valid because there is no License: GPL-2+ or License: GPL-2 with Font exception paragraph. Right? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 21/11/11 23:21, Jonathan Nieder wrote: Hi, Ximin Luo wrote: When packaging mozilla extensions I ran some problems with DEP5. I talked this issue over on #645696 which eventually resulted in encouragement to move forward with a proposal for a change to be made. I think this report contains multiple proposals. Let me try to summarize (and please correct me where I go wrong). First, the problem being addressed: a debian/copyright file like this: Files: * Copyright: - etc License: GPL-2+ License: GPL-2 etc or this: Files: * Copyright: - etc License: GPL-2 with Font exception License: GPL-2 etc is not considered valid because there is no License: GPL-2+ or License: GPL-2 with Font exception paragraph. Right? Correct, and that's the symptom that I first came across, but I think all of the symptoms that I described in the latter half of my last email, are part of the same design problem. X -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0 signature.asc Description: OpenPGP digital signature
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
Ximin Luo wrote: On 21/11/11 23:21, Jonathan Nieder wrote: Files: * Copyright: - etc License: GPL-2+ License: GPL-2 etc [...] Files: * Copyright: - etc License: GPL-2 with Font exception License: GPL-2 etc [...] Correct, and that's the symptom that I first came across, but I think all of the symptoms that I described in the latter half of my last email, are part of the same design problem. Right. My small brain copes better with only one primary use case at a time, though. In the examples above, a natural approach might be to make the standalone license paragraphs more modular somehow. For example: Files: * Copyright: - etc License: GPL-2+ License: GPL-2 etc License: GPL-3 etc The or later licenses are particularly problematic because it is not clear which version the reader is going to choose, and so it is not clear which set of license terms is actually relevant. The best way to deal with or later terms is not obvious to me. License exceptions are easier. Files: * Copyright: - etc License: GPL-2 with Font exception License: GPL-2 etc License-Exception: Font etc I would be glad to see a change to allow such a syntax (modulo wording), especially if targeted at copyright-format 1.1. Another problem involves licenses that require preserving the list of copyright holders. Is the list of copyright holders part of the license? Copyright (c) The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without [...] Common practice in debian/copyright files I have seen is to say, no, so the License: BSD-3-clause paragraph begins with Redistribution and use and the copyright notice it mentions is in the Copyright: line of each Files stanza. That sounds fine, but it does not work as well for programs licensed under the MPL, which involves some notices other than the list of copyright holders. * The Original Code is mozilla.org code. * * The Initial Developer of the Original Code is * Netscape Communications Corporation. * Portions created by the Initial Developer are Copyright (C) 1998 * the Initial Developer. All Rights Reserved. * * Contributor(s): * Original Author: David W. Hyatt (hy...@netscape.com) * Gagan Saksena ga...@netscape.com * Benjamin Smedberg benja...@smedbergs.us I believe something like the following would be ok, according to the current copyright-format. Files: * Copyright: 1998 Netscape Communications Corporation Comment: The Original Code is mozilla.org code. . The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by the Initial Developer are Copyright (C) 1998 the Initial Developer. All Rights Reserved. . Contributor(s): Original Author: David W. Hyatt (hy...@netscape.com) Gagan Saksena ga...@netscape.com Benjamin Smedberg benja...@smedbergs.us License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 1. Definitions. etc License: GPL-2+ etc License: LGPL-2.1+ etc The Comment could even be dropped, as far as I can tell. A person interested in the list of Contributors can look at the source, and the license does not seem to require reproducing this list when distributing binaries. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification
On 22/11/11 00:06, Jonathan Nieder wrote: Ximin Luo wrote: On 21/11/11 23:21, Jonathan Nieder wrote: Files: * Copyright: - etc License: GPL-2+ License: GPL-2 etc [...] Files: * Copyright: - etc License: GPL-2 with Font exception License: GPL-2 etc [...] Correct, and that's the symptom that I first came across, but I think all of the symptoms that I described in the latter half of my last email, are part of the same design problem. Right. My small brain copes better with only one primary use case at a time, though. In the examples above, a natural approach might be to make the standalone license paragraphs more modular somehow. For example: Files: * Copyright: - etc License: GPL-2+ License: GPL-2 etc License: GPL-3 etc The or later licenses are particularly problematic because it is not clear which version the reader is going to choose, and so it is not clear which set of license terms is actually relevant. The best way to deal with or later terms is not obvious to me. Typically, people don't bundle copies of GPL3 when the license is GPL2+, and I don't see why we should feel like we need to for debian/copyright. This is a side issue from this topic anyway, and it applies to every piece of software that uses this sort of license. Usually people just bundle the lowest version. License exceptions are easier. Files: * Copyright: - etc License: GPL-2 with Font exception License: GPL-2 etc License-Exception: Font etc I would be glad to see a change to allow such a syntax (modulo wording), especially if targeted at copyright-format 1.1. I was going to suggest the Exception stanza as well, but I thought it would be too much for one email. I support it though :) Another problem involves licenses that require preserving the list of copyright holders. Is the list of copyright holders part of the license? Copyright (c) The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without [...] Common practice in debian/copyright files I have seen is to say, no, so the License: BSD-3-clause paragraph begins with Redistribution and use and the copyright notice it mentions is in the Copyright: line of each Files stanza. I think it makes sense if you see License stanzas as being a way to re-use common bits of full-text. The only sane way you can implement this re-use, is if the thing being re-used is neutral to the (many possible) things that reference it. In this case, License full-texts should be neutral to WHO and WHAT information, which should be in the File stanza. That sounds fine, but it does not work as well for programs licensed under the MPL, which involves some notices other than the list of copyright holders. * The Original Code is mozilla.org code. * * The Initial Developer of the Original Code is * Netscape Communications Corporation. * Portions created by the Initial Developer are Copyright (C) 1998 * the Initial Developer. All Rights Reserved. * * Contributor(s): * Original Author: David W. Hyatt (hy...@netscape.com) * Gagan Saksena ga...@netscape.com * Benjamin Smedberg benja...@smedbergs.us I believe something like the following would be ok, according to the current copyright-format. Files: * Copyright: 1998 Netscape Communications Corporation Comment: The Original Code is mozilla.org code. . The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by the Initial Developer are Copyright (C) 1998 the Initial Developer. All Rights Reserved. . Contributor(s): Original Author: David W. Hyatt (hy...@netscape.com) Gagan Saksena ga...@netscape.com Benjamin Smedberg benja...@smedbergs.us License: MPL-1.1 or GPL-2+ or LGPL-2.1+ License: MPL-1.1 1. Definitions. etc License: GPL-2+ etc License: LGPL-2.1+ etc The Comment could even be dropped, as far as I can tell. A person interested in the list of Contributors can look at the source, and the license does not seem to require reproducing this list when distributing binaries. Some people prefer to keep this information (at this level of verbosity too) in debian/copyright, and apparently this is also required by the ftp masters. I do think it's beneficial to provide a central place for this information, although one could argue that the Copyright: and License: fields already provide the same thing but in a shorter format. One other thing is that I would push, is to require (or at least encourage)
