[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 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
> 


Reply to: