Markus Koschany wrote: > freeorion: [1] > > Rather sophisticated game GPL-2 licensed but with various contributions > / incorporations under different licenses. So I can't just write Files: > * -> GPL-2. I have to list all licenses with separate paragraphs and > there is no way to change that without sacrificing accuracy. But > d/copyright would be a lot more readable if I did not have to quote some > of those licenses verbatim.
Using 'Files: *' when different files are under different licenses sacrifices precision, but it doesn't sacrifice accuracy. You can say Files: * License: GPL-2 and Permissive-License-1 and Permissive-License-2 and ... Or you can even write Files: * License: Freeorion and clarify what the terms are in the license text. At least that was my understanding of the intent behind copyright-format. Looking at the latest clarifications to copyright-format, I see Files: * Copyright: 1975-2010 Ulla Upstream License: GPL-2+ In this example, copyright in all files is held by the upstream, and that copyright holder grants license under the GPL, version 2 or later. which I fear is ambiguous. If the copyright field names multiple copyright holders, do all files have to be copyright by all of them, or can the copyright to some files be held by some of them and to others by the other? The latter is the only tenable way this can work in practice but the text could use some clarification (in a separate bug). > bullet: [2] > > C++ library under a permissive license with various contributions > licensed under different licenses. I became fed up with checking the > data and examples directories with each upstream release because of the > various licenses and copyright holders in those directories. Fortunately > we don't need those for a functioning library but it would have been > nice for someone who wants to build demos and examples on a local > system. -> forced trade-off between usefulness, d/copyright and my > maintenance time. Nothing upstream could help us with. Can't upstream help by hosting a LICENSE file that you and other distributors share the work of maintaining? If they prefer to treat the data and examples directories as independent components, they can put a LICENSE file in each, so that all that would be left on the Debian side to do is (1) concatenate them and (2) remove any directories that don't have a LICENSE file yet. > ufoai-maps: [3] > > ~5000 files, a lot of CC licensed files. Only manageable because > upstream provides a copyright file in their own format. I had to write > my own little parser to make it suitable for d/copyright. Checking this > all by hand would be a nightmare. Nothing upstream could help us with. > From their point of view they have provided all legally required > information. copyright-format 1.0 is not mandatory. Why not ship upstream's copyright file as is? > netbeans: [4] > > ~80000 files with dozens of licenses and hundreds of contributors. This > is only maintainable copyright-wise because I remove lots of files when > repacking the tarball. *nod* This is a similar case to bullet. Upstream is likely not interested in creating a LICENSE file but they could be interested in accepting it as a contribution, especially if you set them up with a licensecheck-like workflow to keep it from bitrotting. > From my perspective every simplification of d/copyright helps. If you > think my workflow is to blame here, I'm all ears now how I could be more > efficient in maintaining just these four packages. ;) Some of the pain is essential pain due to the way copyright works and the complexity of conveying authors' wishes. But other parts are self-imposed. I agree with your goal of removing self-imposed pain. :) Thanks, Jonathan
