[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: