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

Bug#487201: MPL in common-licenses and convenience of packaging mozilla extensions



On 01/09/11 07:15, Ben Finney wrote:
> 
> Ximin Luo <infinity0@gmx.com> writes:
> 
>> At the cost of some complexity in code, we can eliminate a lot of
>> complexity in our data.
> 
> There is redundancy, yes. Is that what you're calling complexity? Or is
> there some significant complexity in the data of the ‘debian/copyright’
> file that you've got in mind?
> 
>> With pointers, it is easier for maintainers to create simple
>> debian/copyright files.
> 
> At the cost of actually making the package more brittle: when taking
> parts of a package, it is easier to omit a file than to omit part of a
> file. So a reference is more complex, and prone to failure, than simply
> keeping all the license information in one place.
> 
> Now, we compromise that flexibility, in the case of *very* common
> licenses which are well-known. But I don't see you making a good case
> for allowing that complexity to increase.
> 

I don't see you or anyone else making a good case for not allowing that
complexity. It's all hand-waving.

Your "more brittle" point isn't true, it's easier for humans to check pointers
since they don't need to scroll through a huge swathe of text, and easier to
code a program to check original unformatted license texts since we don't need
to bother with parsing to a canonical form.

>> Since there are thousands of packages and there only needs to be a few
>> DEP-5 parsers (ideally, one), the choice seems obvious to me.
> 
> Another point of disagreement. I think that multiple competing parser
> implementations for a standardised data format is healthier and more
> robust than a single implementation.
> 
>> Sure, it's "easy" to format licenses into DEP-5 long-text format, but
>> each new maintainer needs to do this for themselves.
> 
> That formatting is no different from the formatting they must already
> learn for the ‘Description’ field in ‘debian/control’. Do you think
> using the same formatting for another field is a significant increase in
> complexity?
> 

License texts can be quite long. You don't want to have a standard that
requires humans to handle long pieces of text, especially widely-distributed
license texts.

Description fields are short paragraphs and each package has a different one.
License texts are the exact opposite.

>> In fact I might go write the tool I mentioned before and learn some
>> perl in the process... that's what a lot of Debian devscripts is
>> written in, right?
> 
> Formatting a passage of text to that format would be useful, I agree,
> since it could be used for the multiple metadata fields that have that
> format.
> 

That would be really really ugly pointless code and I'm not going to do that.
Much easier to cp $LICENSE and cat $LICENSE.

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: