Hi folks, I've finally updated the CommonPackagingMistakes section of the debian wiki. This time the topic is "Keeping the archive legal or the importance of debian/copyright". You can find it at
https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/DebianCopyright Please fix any errors and omissions ;). Here is the article in its current form. Cheers, Stefan aka sistpoty. = Keeping the archive legal or the importance of debian/copyright = == Prelude == When reviewing packages, one major common error I find is that the copyright file is missing some information. However with debian/copyright wrong or incomplete, you'll get a veto from me for sure. The reason is simple: If something is missing in debian/copyright, that's a violation of the involved licenses which makes the package per se undistributable. == The importance of debian/copyright == The most important thing of debian/copyright is, that it holds the copyright information for the binary package. Apart from that, it's also useful to give a summary for the sourcepackage. Finally it contains the copyright of the packaging work. If the information in debian/copyright doesn't fulfill all the licenses involved within the package or the libraries the package links against, this means that we don't have any valid license for the given package. Thus we mustn't distribute the package. That said, it's absolutely vital to have debian/copyright right. == What needs to be listed == === Rule of thumb == The rule of thumb is: Look at copyright definitions in the sourcecode, the accompaning COPYING/AUTHORS file and at the involved licenses. There is no such thing as a general rule of thumb to get it right: Different licenses have different requirements for redistribution. While a public domain license may even state that you can do everything with the sourcecode (which would mean that you needn't put anything into debian/copyright, or could even choose your own "may be distributed in cd form only on rainy saturday's"-license), other licenses will impose certain restrictions like including the copyright statement and/or authors and making it clear if the sourcecode is altered from its original form. Sometimes the involved licenses even conflict with each other (e.g. GPL and OpenSSL-license), which means that the resulting binary package cannot be distributed. === Example 1: GPL === The GPL requires that the complete license text is distributed (you can refer to /usr/share/common-licenses/GPL, which is always there on debian/ubuntu systems), the authors and the short disclaimer of warranty (which you should include into debian/copyright). An example is in the license itself, but I'll post it here again for clarity: <one line to give the program's name and a brief idea of what it does.> Copyright (C) <year> <name of author> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in the /usr/share/common-licenses/GPL file. Please also note, that upstream may also choose to restrict the license to one specific version of the GPL, then you'll need to modify the text above. Usually that very disclaimer can be found in the sourcecode of a package. Then you can simply paste it to debian/copyright. == Example 2: GPL with different GPL derived files from a different author == The gist of OSS is to reuse already done work. Many projects do this, but not always they fill in their copyright notices correct. Always 'grep' for the word copyright, this might reveal other persons, whose work has been reused in a project. Your debian/copyright needs to list each of these additional authors and wether the file is altered or not. Usual approach is: * src/foo.c: (C) 2004-2005 by Cracky Coder. * src/bar.c: Based on foobar (C) 2001 by Harry Hacker. === Example 2: GPL + different license === Combining GPL and another license will always make the combined work to be GPL or undistributable if the licenses conflict. What licenses can be combined can be found at [http://www.gnu.org/licenses/license-list.html] Usually you'll need to list the different licenses as well in debian/copyright. A good way to do this, is to list files with a different license together with the license in question. Wether you'll actually need to list the different licenses depends solely on the license involved. What you don't need to mention is licenses from libraries against which the package links. They are accompanied by their own copyright file and the package in question can never be installed w.o. the library in question. Of course there are exceptions which impose different restrictions, like the OpenSSL license which requires a disclaimer to be present in debian/copyright if it's used (as in linked against) in a project. But these additional restriction mean, that the used library is incompatible with the GPL. === Final words === While usually most of the projects don't have any legal issues, it's very simple to introduce these with inaccurate copyright-files. Finally there is a rule of thumb: Better safe than sorry - be verbose and list everything which you are not sure if it should go into debian/copyright or not.
pgpHkSHZhptcx.pgp
Description: PGP signature
-- Ubuntu-motu mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
