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

Bug#884228: debian-policy: please add OFL-1.1 to common licenses



On Sat, Dec 30, 2017 at 12:24:19AM +0000, Simon McVittie wrote:
> On Fri, 29 Dec 2017 at 22:24:23 +0100, Markus Koschany wrote:
> > Am 29.12.2017 um 00:06 schrieb Jonathan Nieder:
> > I had to split the game into four digestible pieces (which are in total
> > 1.2 GB large). My original idea was to duplicate the copyright file for
> > all three data packages but back then this proposal has been harshly
> > rejected on debian-mentors (when I wasn't a DD yet) because the
> > copyright file would have mentioned files which are not part of a
> > specific source package.
> 
> For what it's worth, when I discussed splitting openarena-data with the
> ftp team (and then uploaded the split parts through NEW), they didn't
> object to the copyright files being identical, with each source package
> listing some copyright holders and licenses that actually only exist
> in the other source packages from the same group.
> 
> However, I can see that d-mentors wouldn't like that: people sponsoring
> random packages (that they themselves aren't necessarily involved or
> interested in) will tend to assume that this particular package doesn't
> deserve to be a special case, because 95% of the time it doesn't. Making
> pragmatic decisions like "this is not what I'd usually do, but in this
> case it makes more sense" requires enough context to understand the
> costs and benefits that apply.

Yes, cost/benefit should be considered (and was in this case).  But
please, one should not only evaulate _their_ cost but also the cost this
creates on other parties. The goal should be to reduce the overall
cost-sum.

For example, this particular issue was causing literally thouesands of
lintian stuff, so basically rasing the noise level far above the signal.
And it would have been easily fixed, as d/copyright was script-generated
and the script could have a check implemented to filter the output to
the respective packages.

>     smcv
> 


Reply to: