Am 28.12.2017 um 20:39 schrieb Jonathan Nieder: > Markus Koschany wrote: >> Am 28.12.2017 um 11:21 schrieb Bill Allombert: >>> On Wed, Dec 27, 2017 at 01:56:44PM -0800, Russ Allbery wrote: >>>> Jonathan Nieder <jrnieder@gmail.com> writes: > >>>>> Seconded. >>>> >>>> license-count says this makes sense: >>>> >>>> SIL OFL 1.0 12 >>>> SIL OFL 1.1 159 >>>> >>>> via the historic criteria of more usage than the least popular license >>>> already in common-licenses (GFDL 1.3 at 138 packages). > [...] >>> The usual threshold for inclusion was much higher than 138. > [...] >> We really should move away from making a distinction between popular and >> non-popular DFSG licenses. Nowadays nobody in the project can tell >> within seconds how many DFSG-free licenses there are. Under my original >> proposal we would add _all_ licenses which were accepted by the FTP team >> to /usr/share/common-licenses. > > I am confident that we lack consensus for that original proposal. Agreed. At the moment I would already be happy if we could find consensus for the few licenses I have filed bugs for. > I have some sympathy for moving to a different threshold or a > different criterion for inclusion in common-licenses. But let me just > say now to avoid wasted time: I am not going to be supportive of > turning base-files into a compendium of all DFSG licenses. There are > multiple reasons that I don't think that's in users' best interests. > I've already discussed some of them and haven't heard any convincing > new points in response. Maybe this is the reason why we haven't found consensus yet. Why do you think that adding all DFSG licenses to /usr/share/common-licenses is not in our users best interests? I recall the following arguments against this proposal: 1. Waste of disk space (especially for embedded systems) I think we have already debunked this myth and it appears to me that at least Sean and you agree that this is actually not an issue for this specific target group and in fact we would _save_ disk space because some of those licenses are present in very important and popular packages. 2. A license can only be included when a certain threshold is reached First of all nobody seems to know what this threshold actually is. Apparently it is something between gut feeling and the popularity of our least preferred license in common-licenses. What negative impact is expected when we just add all DFSG licenses? At least you seem to agree that "included in number of packages" is an imperfect criterion. 3. Very short licenses should not be included This was mentioned by Russ for the MIT and zlib licenses because it "adds indirection to no real purpose and won't really save maintainers significant time." Why do we add the BSD license to common-licenses but not MIT and zlib? At the moment we have a situation where we can reference some licenses but have to quote others verbatim. I believe this is the real indirection here. It would be much simpler (and more natural) to introduce a rule to reference every DFSG license text than requiring to check whether a license is a so called common license or not. >> Also the criterion of popularity does not take into account that some >> licenses are more frequently used in specific fields of endeavor. If you >> don't maintain a lot of -data or documentation packages with fonts, >> images or other media files, this is probably not an issue for you. But >> the current state surely is annoying for contributors who are interested >> to develop parts of Debian where the OFL or CC licenses are very popular >> and common. > > As I've already said multiple times, if you are using copyright-format > 1.0 to maintain multiple packages and it is getting in your way, > please please please, fix your workflow and improve documentation so > others can benefit from the same workflow changes. Work with upstream > to ensure they have high quality license documentation that you can > use as-is (or that you can use after some mechanical transformations > --- e.g. I've heard of R module packagers having some success with > that approach). Changing the list of licenses in base-files does not > change this at all. I don't understand what you mean by changing my workflow. Bill also suggested that I just should not use copyright format 1.0. What would that change? I still have to quote license texts verbatim. The only "advantage" of the old format is that I can format d/copyright more freely but the same information must be present anyway. It is simply not feasible to educate all upstreams in existence to write a Debian-like copyright file. They rightly say that it is not their problem how downstreams process and treat their copyright information. Though if you allowed to reference a license text on the local system instead of quoting it verbatim this would allow myself and others to save time in producing the Debian specific copyright file. In no way is this related to upstream. > All that said, I still support including the SIL OFL 1.1 in > common-licenses. I also agree with you that number of packages is an > imperfect criterion --- the OFL 1.1 is not only used by a large number > of packages but many of those packages are popular, so the resource > savings (archive space in partial mirrors, bandwidth, CD size, etc) is > greater than it might seem at first glance. Yes, I'm happy that you support the inclusion of SIL OFL 1.1. > Thanks, > Jonathan Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature