On 21/12/11 12:05, Charles Plessy wrote: > Le Sun, Dec 18, 2011 at 08:44:16PM +0000, 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/000037.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
