What does disclaiming a copyright mean?
Dear debian-legal subscribers, As I am not a native speaker, I face difficulty of understanding the following sentence: Burkhard Morgenstern hereby disclaims all copyright interest in DIALIGN, written by Burkhard Morgenstern and Said Abdeddaim. It is from the licence of the dialign program, which you can read here: http://charles-miroir.plessy.org/debian/dialign-2.1.1/license/LICENSE.TXT Does in mean that B. Morgenstern abandons his rights to S. Abdeddaim ? Thank you a lot for your help, -- Charles Plessy Wako, Saitama, Japon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
non-free application linked to Qt.
Dear debian-legal, A non-free program for which I maintain a package has changed its UI toolkit from lesstif to Qt. The program is free for non-commercial use, and upstream payed for a Qt licence. I understand that producing binaries within Debian would be an infringement of the Qt licence. Upstream has asked me if it would be possible to distribute the program as a source package only, à la 'pine'. Can you confirm that it is the case? Also, we are wondering if it is the first time this kind of problem happens. Upstream sells licences of its program for commercial use, so it is difficult for them to free their code. The program exists in a graphical version and a command line version. Both can operate independantly and the command-line version is widely used on workstations. Would I be legally wrong if I advised Upstream to separate the GUI code from the algorithms, double-license the GUI under non-commercial or GPL terms, and make it call the command-line version independantly (no C linking)? In that case, I think that it would preserve their revenue model: people who want to use the GUI for commercial use would have to buy a licence for the commercial use of the command-line version anyway. But I do not know if it would be fair to Trolltech. Or maybe the licence of the command-line version could mandate that if the program is used through the Qt GUI, a Qt license has to be bought? The goal of this is to keep a gratis and open source access to the program and its GUI to academic users, and require a commercial licence from industrial users. [Please CC me, I am not subscribed] Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Help needed for bug 507579 (AGPL issue).
Dear debian-legal, yocto-reader is a package licenced under the AGPL, and due to the novelties of this license there is divergence of interpretation on wether this package is fit for the release or not. Can you have a look to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507579 and help to resolve the issue? The bug is quite short so I hope there is no need to make a summary. The main issues are: - Wether the Debian package is a modification of upstream work that fails to provide access to the diff and the build environment. - Wether it is acceptable to have html pages that include a link to a remote non-free Google javascript. Thanks a lot for your help ! (and please CC me) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Suggested removal: yocto-reader (RC bug, depends on remote scripts).
Dear release team, yocto-reader has a RC bug that was filed for multiple licensing issues. After discussing with the bug reporter and getting advice from debian-legal (thanks for the input), it seems that at least one of the issues is a clear violation of our Policy (I will not discuss others in this email, you can read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507579 for more details). Le Thu, Dec 04, 2008 at 10:12:30PM -0800, Walter Landry a écrit : Charles Plessy [EMAIL PROTECTED] wrote: Can you have a look to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507579 and help to resolve the issue? (…) - Wether it is acceptable to have html pages that include a link to a remote non-free Google javascript. If I understand correctly, the Google javascript is required in order for the page to work properly. In Debian parlance, this means that yocto-reader depends on the Google javascript. So at a minimum yocto-reader would have to go into contrib. My first objection was that if yocto-reader is a server, then the dependance of the Google javascript happens privatley on a remote computer and is not an issue for Debian. However, people may also want to install yocto-reader on their machine through the Debian package to use it locally. In that case, relying on the download of a remote component makes the package unfit for Debian. I checked that commenting the script section that downloads the Google javascript breaks yocto-reader. Since yocto-reader was not distributed in Etch, is a leaf package and has a Popcon score of 5, I suggest to remove the pakcage from Lenny in the absence its the maintainer. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS usertag with an userid that is not an email address.
Le Tue, Dec 09, 2008 at 12:33:12AM +0900, Paul Wise a écrit : On Mon, Dec 8, 2008 at 11:44 PM, Charles Plessy [EMAIL PROTECTED] wrote: I am doing some pilot tagging to implement my idea of peer review for the `debian/copyright' file. How about using user debian-legal@lists.debian.org, usertag copyright-review-requested for this purpose? Hello debian-legal, I am thinking about a usertag system to request peer reviews of debian/copyright files. Apparently it is not possible to use usertags without providing an email address. Would you mind if I use debian-legal@lists.debian.org for this purpose? As far as I understand there is no functionality in the BTS to send emails to the user based on his tags, so it should not increase the traffic on the list. Have a nice day, and thanks Paul for the idea, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
License requiring to reproduce copyrights in binary distributions.
Dear all, It appeared in various discussions about either DEP5 or the NEW queue that licenses vary in their requirement for reproducing the authors copyrights in binary distributions. In order to start clarifying the situation, I propose to list for the most common licenses when they require to reproduce copyright statements. The final goal is to help packagers to keep the debian/copyright file simple while respecting license terms. I propose to make this list on the Debian wiki, and created a draft page: http://wiki.debian.org/CopyrightNotices For the moment, the list has three easy entries as example: - The WTFPL, that allows everything, therefore to not cite copyrights anywhere. - The GPL, that assumes that the source is always available, and therefore does not have special requirements for binary distributions. - The Expat license, that requires copyright notices to be included in all copies or substantial portions of the software, and therefore somewhere, typically debian/copyright, in binary distributions. If you are intersted, you are welcome to join this documentation effort that will help Debian to better understand what is the minimal requirement for copyright documentation. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License requiring to reproduce copyrights in binary distributions.
Le Wed, Jul 01, 2009 at 07:03:03PM +0200, Francesco Poli a écrit : On Wed, 1 Jul 2009 23:57:28 +0900 Charles Plessy wrote: http://wiki.debian.org/CopyrightNotices Could you please explicitly state (in the wiki page itself) the license under which the wiki page is released? All my contributions on this wiki can be treated as if they were in the public domain, as stated on my personal page: http://wiki.debian.org/CharlesPlessy For this page, since the discussion on the wiki relicensing has not beared fruits yet, I would something permissive that would not hinder the work or our wiki admins when they will sort licencing issues out. Also, since this page stems from the impression that it is sometimes impractical to reproduce all copyright statements, I would like to pick one that allows to not do so. I know that people on this list object on license proliferation, but may I suggest the BOLA license, that is a politically correct version of the WTFPL? http://blitiri.com.ar/p/bola/ Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Does the ISC license require to reproduce copyrights in debian/copyright ?
Le Wed, Jul 01, 2009 at 11:57:28PM +0900, Charles Plessy a écrit : It appeared in various discussions about either DEP5 or the NEW queue that licenses vary in their requirement for reproducing the authors copyrights in binary distributions. In order to start clarifying the situation, I propose to list for the most common licenses when they require to reproduce copyright statements. The final goal is to help packagers to keep the debian/copyright file simple while respecting license terms. I propose to make this list on the Debian wiki, and created a draft page: http://wiki.debian.org/CopyrightNotices Dear all, let's start with the Internet Software Consortium license: Copyright © 2004-2009 by Internet Systems Consortium, Inc. (ISC) Copyright © 1995-2003 by Internet Software Consortium Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED AS IS AND ISC DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. (from ‘https://www.isc.org/software/license’) Does this concern binary distribution: is a compiled version a “copy”? If yes, it seems that the copyright notice should be reproduced in our binary packages, typically in debian/copyright. But let's remember that in the case of works distributed under the terms of the GPL, we consider that the binary packages are only one piece of a bigger cake, that includes the source package. In that case, the ISC license would also be satisfied if debian/copyright would not contain the copyright notice. What is your opinion? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License requiring to reproduce copyrights in binary distributions.
Le Thu, Jul 02, 2009 at 03:52:40PM +0200, Cyril Brulebois a écrit : | | There is no such thing as “putting a work in the public domain”, you | America-centered, Commonwealth-biased individual. Public domain varies | with the jurisdictions, and it is in some places debatable whether | someone who has not been dead for the last seventy years is entitled to | put his own work in the public domain. (Sources for last two quotes: http://sam.zoy.org/wtfpl/) Replacing “Public Domain” by “Public Domain” (which to me is what BOLA is about) sounds hmmm broken? I can re-release under the BOLA license with a WTFPL exemption: ‘To all effects and purposes, this work is to be considered Public Domain, but if you do not agree this is possible, then just DO WHAT THE FUCK YOU WANT TO.’ This said, license proliferation is not Buena Onda… -- Charles -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License requiring to reproduce copyrights in binary distributions.
Le Fri, Jul 03, 2009 at 09:10:10AM +0100, MJ Ray a écrit : Charles Plessy ple...@debian.org wrote: It appeared in various discussions about either DEP5 or the NEW queue that licenses vary in their requirement for reproducing the authors copyrights in binary distributions. [...] I wonder if the licence requirements are the deciding factor. With the increasing criminalisation of copyright infringement worldwide, users may need to show their local police or state agent that they have a valid copyright licence for any copies. How can users do that reliably if the binary distributions aren't reproducing the authors' copyrights? Definitely, licence requirements are not the only deciding factor, but they provide the boundaries, that I would like to document better. In many of the upstream original distribution of our programs, the coverage of all the copyright statements does not reach a 100 % accuracy, and for some of the other binary Linux distributions, this does not seem to be problematic. In our attempt to be perfect, we actually put ourselves into a troublesome situation where if for a version A, debian/copyright is 100 % accurate and for a version B it is missing one name, then we are disinforming our users because we made them rely on us instead on Upstream. What we have to do is to comply with the license, for sure, but to what extent do we want to substitute with Upstream's duties? Do we really want to maintain our own list of all the Linux, KDE and Mozilla contributors? Arent'we taking a responsability that we could avoid by not doing this if the license allows? If Upstream maintains an AUTHORS file, I think that it would be better to ship it and only use debian/copyright as a license summary. And of course, we can sent patches upstream if we find people missing… Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License requiring to reproduce copyrights in binary distributions.
Le Fri, Jul 03, 2009 at 10:02:42PM +0200, Francesco Poli a écrit : If you are convinced that a public-domain-like situation is actually desirable, then, AFAIK, the best way to achieve it is the Creative Commons public domain dedication [1], or possibly CC0 [2]. [1] http://creativecommons.org/licenses/publicdomain/ [2] http://creativecommons.org/publicdomain/zero/1.0/legalcode Hi Francesco, since CC0 is recommended over the PD dedication, I will use CC0. http://wiki.creativecommons.org/CC0 -- Charles -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Does the ISC license require to reproduce copyrights in debian/copyright ?
On Thu, 2 Jul 2009 09:19:29 +0900 Charles Plessy wrote: Does this concern binary distribution: is a compiled version a “copy”? Le Fri, Jul 03, 2009 at 10:10:29PM +0200, Francesco Poli a écrit : Why not? I personally think that a compiled copy of the software is indeed a copy. What other term would you use to describe the compiled thing? It is my understanding that a compiled version of the software is a copy of the software (in compiled form). Le Sat, Jul 04, 2009 at 09:45:39AM +1000, Ben Finney a écrit : I think of it more as a translation into another language. It's an automated, mechanical translation though, so unlike most human-language translated works, there's no creativity in the translation step. I am quite undecided between the possible interpretations. But maybe this question was already judged somewhere ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License requiring to reproduce copyrights in binary distributions.
Le Wed, Jul 08, 2009 at 07:00:23AM +0200, Florian Weimer a écrit : * Charles Plessy: - The GPL, that assumes that the source is always available, and therefore does not have special requirements for binary distributions. This is incorrect. If the binary includes copyright statements to display them, you may not remove them (see §5 (d) in the GPL version 3). In addition to license terms, you have to take moral rights into account. In many countries, software authors have an inalienable right to be named as authors, like any other author. Hi Florian, Reading the paragraph 5.d, I have rather the impression that it says that if the program we redistribute does not display copyright notices, the GPL does not require us to fix this: 5. Conveying Modified Source Versions. [..] d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. The moral rights is another issue… Most of the heat in the discussions about debian/copyright stem from the fact that Upstream does not document copyrights perfectly. Otherwise, writing this file would be trivial. Do I undertand correctly that your comment is: If a copyright notice is present in the source but not in the binary version nor its accompaning documentation, it can be a violation of autors inalienable rights in some countries. Then we return to the original question: if it is acceptable that Debian distributes the source and binary forms of works licensed under the GPL in separate packages, does that mean that there is no need to reproduce copyright statements from the source code to the debian/copyright file in the binary package for works licensed under other terms, unless the license specifically requires to do so? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Verifying licence for packaging
Le Mon, Jul 20, 2009 at 01:48:47AM +0300, Michael Gvirtzman a écrit : 1. Could you please review the below Licence of the [1]Golden Rules Organizer freeware for suiting Debian rules: [2]http://www.golden-rules.org/LICENSE.txt Hello Michael, Debian would need a written permission from you to redistribute your software, and I do not know if it would allow secondary mirrors to copy it. To be honest, your proposision of distributing your organiser in Debian seems to be motivated by promoting your own work rather than helping users to migrate towards a more free system, so I doubt you will find a Debian developer who will sposor the package, because it does not fit with our priorities: our users and free software. This said, you probably can distribute a binary package in Debian format on your website. You can refer to the following documentation to setup a local repository that your users can add in their source list. http://wiki.debian.org/HowToSetupADebianRepository Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: License question for new package
Le Sun, Oct 18, 2009 at 01:23:26PM +1100, Ben Finney a écrit : Obnoxious advertising requirement: IMO this restriction makes the work non-free for the same reasons the similar requirement in the original BSD license makes a work non-free. Hello everybody, works licenced with advertisement clauses are accepted in Debian by our archive administrators. See for instance http://packages.debian.org/changelogs/pool/main/j/jhdf/jhdf_2.5-3/libjhdf5-jni.copyright Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: spim
Le Mon, Oct 19, 2009 at 06:42:31PM +1100, Ben Finney a écrit : Paul Wise p...@debian.org writes: http://packages.debian.org/changelogs/pool/non-free/s/spim/current/copyright Not only that, it isn't an explicit statement from the copyright holder at all; it's someone else reporting in their own words: Note: James Larus has clarified his license in regards to how it relates to packaging and redistribution. He welcomes the packaging and redistribution via other media, as long as his copyright is retained and source code is distributed. That's far from what we normally require: explicit written license in the copyright holder's own words. I do not know who ‘we’ are in this story, but the fact that the above URL stems from packages.debian.org demonstrates that the statement was enough for the package to be accepted in the Debian archive. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: bsd modified bsd clarification
Le Thu, Nov 05, 2009 at 04:00:45PM +0100, Penny Leach a écrit : Furthermore, the new debian/copyright policy [1] doesn't mention Modified BSD at all - it just references BSD, NetBSD and FreeBSD. Dear Penny, first of all let me just clarify that DEP-5 is only a proposal now, and that it can be subjected to many changes before it is accepted. One of the changes that I would like to propose when I have enough time to draft a patch, is to introduce a syntax for licenses ‘similar to’ other licenses, when they were derived from a very common license by only changing some people, company or brand names. As Don explained, there is only one BSD license, the one where the regents of the university of California are coyright holders. And since they used their copy rights to change the license in the past, there is no program that is licensed under the ‘old BSD’ license. Nevertheless, there are some that have license similar to it, and were not affected by the removal of the advertisement clause because the copyright holder is not the same. Whichever solution is adopted in DEP-5 to underline that license A is derived from license B, unless your program is part of the BSD distribution and is copyright by the regents of the university of California, you can not use the copy in /usr/share/common-license and have to include it verbatim. Luckily, it is short :) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: POV-Ray 3.7 beta in experimental, but non-redistributable
Le Sat, Jan 02, 2010 at 01:55:18AM -0300, Nicolas Alvarez a écrit : Today I found that POV-Ray 3.7 is packaged in experimental: http://packages.debian.org/experimental/povray This seems to violate the beta license in *every possible way*. Here are the restrictions, taken from one of the source files from the upstream source tarball: * NOTICE * * This file is part of a BETA-TEST version of POV-Ray version 3.7. It is not * final code. Use of this source file is governed by both the standard POV-Ray * licences referred to in the copyright header block above this notice, and the * following additional restrictions numbered 1 through 4 below: * * 1. This source file may not be re-distributed without the written permission * of Persistence of Vision Raytracer Pty. Ltd. Dear Nicolas, indeed, the Debian copyright file of the povray does not mention written permissions from Persistence of Vision Raytracer Pty. Ltd. I think that this is enough to open a Serious bug on the Debian povray package (version 3.7.0~beta29-1). If the povray package maintainers get the permission to distribute and disable the timeout, or simply forgot to mention that they already got it, they can close the bug with an upload that corrects the Debian copyright file, and otherwise the bug can be reassigned to ftp.debian.org as a request for removal. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Difference between license in files and in COPYING file
Le Fri, Feb 12, 2010 at 11:18:57PM +0100, Joachim Wiedorn a écrit : /*WebDownloader for X-Window * *Copyright (C) 1999-2002 Koshelev Maxim *This Program is free but not GPL!!! You can't modify it *without agreement with author. You can't distribute modified *program but you can distribute unmodified program. * *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. */ Dear Joachim, it looks to me like the erroneous author's summary of the Artistic licence, that forbids to redistibute modified versions of the program under the same name without the approbation of the author unless some special actions are done. But while I do not think this makes the package non-free, that it is abandonned upstream gives another good reason to remove the package. Does it provide functionalities that are not found in other packages? (the answer to this question is off-topic on debian-legal, so if necessary continuing that part of the discussion in the bug report would be preferable). Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214232732.ga9...@kunpuu.plessy.org
Re: Re: opencascade license in squeeze
Le Fri, Mar 05, 2010 at 08:09:45PM -0500, Adam C Powell IV a écrit : * The statement that the copyright license is not a trademark license is not in conflict with the GPL, and explicitly stated as an option in GPL-3. I don't think anyone believes GPL-3 is incompatible with GPL-2... Dear Adam, I have not followed the issue so I can not help you to solve it, however I just would like to correct one thing that you wrote above: the GPLs version 2 and 3 are incompatible. You can find more detailed explanations on the FSF website: http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100306015340.gc12...@kunpuu.plessy.org
Re: EPL + LGPL compatiblity?
Le Tue, Mar 09, 2010 at 02:03:31AM -0500, Pablo Duboue a écrit : We seek some advice regarding #572982 [1] (azureus, a well-known torrent client, combines source licensed under incompatible licenses). From Niels quoted sources, there is no doubt about the incompatibility of GPL and EPL. But LGPL and EPL might be a different matter and Google has proved quite unfriendly on this regard. Any advice on the matter will be highly appreciated. Dear Pablo, It looks like Aelitis/Vuze is the copyright owner of most of the GPL'ed code, so the quickest way to solve the problem may be to ask them to add a license exception to allow combining their code with the co-distributed EPL and CPL-licensed sources. I hope others will correct me if I am wrong, but it seems that the CPL does not forbid the program to be linked with works under other licenses, so exception is only needed on the GPL side. According to debian/copyright, this leaves two files to either replace or get relicensed by their authors: Files: com/aelitis/azureus/core/peermanager/utils/BTPeerIDByteDecoder.java Copyright: 2003-2006, Aelitis 2002-2004, Alon Rohter License: GPL-2+ Files: org/gudy/azureus2/core3/util/BrokenMd5Hasher.java Copyright: 2005, jMuleGroup License: GPL-2 Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309111524.ga28...@kunpuu.plessy.org
Re: msntp license
[CC Jakub Drnec because I correct one statement I made earlier this year about the MSNTP license] Le Mon, Mar 15, 2010 at 07:44:11PM +0100, Florian Weimer a écrit : * Charles Plessy: I think that Clause 1 disallows for-profit distribution. Can a redistributor burn a CD and sell it with financial benefit without express written consent of the copyright holders of MSNTP? You can't do that with software released under the Artistic license, either, that's why the situation is a bit complicated. I am not sure if you are proposing to keep MSNTP or remove packages with contents redistributed under the Artistic License 1.0 only… In the case of MSNTP, the removal was anyway blessed by the package maintainer for other QA considerations. For the Artistic License in general, well, some other projects like Fedora are removing works distributed under the Artistic Licence version 1.0 only. This would be doable here, but if such a proposition is made and accepted, I strongly recommend to make it in the form of a release goal for the next release. This said, I realised that the Artistic and MSNTP licenses permits to sell Debian CDs for profit: “You may also distribute MSNTP along with any other product for sale, provided that the cost of the bundled package is the same regardless of whether MSNTP is included or not” “you may distribute this Package in aggregate with other (possibly commercial) programs as part of a larger (possibly commercial) software distribution”. I was perhaps wrong when I wrote that MSNTP is not free (20100302115733.gb30...@kunpuu.plessy.org), since we tolerate similar clauses for other works. But I if anybody is tempted to adopt and upload the package with the necessary corrections and updates, I recommend to think twice since upstream does not show signs of activity for a long time (at least using the Google search enging). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100315234533.ga25...@kunpuu.plessy.org
Re: GPL3 compatible?
Le Sat, Mar 20, 2010 at 03:45:51PM -0700, Ludovico Cavedon a écrit : Hi, I was wondering whether this license statement is DFSG/GPL3 compatible. /* Copyright (C) 1997-2001 Ken Turkowski. turk_at_computer.org * * All rights reserved. * * Warranty Information * Even though I have reviewed this software, I make no warranty * or representation, either express or implied, with respect to this * software, its quality, accuracy, merchantability, or fitness for a * particular purpose. As a result, this software is provided as is, * and you, its user, are assuming the entire risk as to its quality * and accuracy. * * This code may be used and freely distributed as long as it includes * this copyright notice and the above warranty information. */ The statement does not explicitly state that modifications are allowed, but just says that the code is freely distributable. How should this be considered wrt DFSG? Moreover the upstream author of RawTherapee re-licensed the file under GPL3 (keeping the above statement, but adding a GPL3 header). AFAIK he cannot do that, but the file has to keep only its original license... correct? Dear Ludovico, it looks like you are discussing the file rtengine/cubic.cc in RawTherapee: http://code.google.com/p/rawtherapee/source/browse/trunk/rtengine/cubic.cc I will answer to your last question first. If the RawTherapee authors obtained the agreement of Ken Turkowski to relicense his work, then there is no problem to have it licensed under the GPL and the above custom license. The GPL gives the freedoms that are necessary for Debian and are not explicitely written in the original license, and the original license does not withdraw freedoms given by the GPL. If you have doubts that the relicensing was permitted, then it is better to contact both parties before proposing a RawTherapee package to Debian. The original license cubic.cc is vague by todays standards, and it would be preferable to check with the original author that he really meant that he does not want his source code to be modified. rtengine/cubic.cc is not very long and implements an algebra forumla that was discovered centuries ago. If it is confirmed that there are license issues, for instance if the original author is not reachable, then replacing the file can be the easiest solution to the problem. Have a nice sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100321014305.ga31...@kunpuu.plessy.org
Vagueness of what is ‘sub stantial’ in the Expat license.
Le Sun, Mar 21, 2010 at 10:56:33AM +1100, Ben Finney a écrit : The apparent intent of the author would be well served by the widely-understood and wholly free-software Expat license terms URL:http://www.jclark.com/xml/copying.txt. As it stands, only the copyright holders in the work can make that change. Dear Ben and everybody, I would like to make a small comment about the “Expat” license, that personally I would not recommend when proposing a relicensing, because of the following sentence: ‘The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.’ It is not easy to guess what each author will expect to be “substantial”. Some other licenses are more explicit, for instance by requesting to reproduce the copyright notice in source and binary distribution, or in contrary only in the source: http://www.freebsd.org/copyright/freebsd-license.html Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. http://www.boost.org/LICENSE_1_0.txt The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100321015722.gb31...@kunpuu.plessy.org
Re: The Software shall be used for Good, not Evil.
Le Fri, Mar 26, 2010 at 11:56:44PM -0500, Joe Neal a écrit : http://wonko.com/post/jsmin-isnt-welcome-on-google-code Hi Joe, have you seen the comment of Joey Hess, that it ‘Looks like the jsmin.py in libv8 is now a reimplementation with a standard license.’ Have a nice week-end, -- Charles -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327060419.ga28...@kunpuu.plessy.org
Re: Does this license meet DSFG?
Le Thu, Apr 08, 2010 at 09:05:39PM -0300, Dererk a écrit : I was asked to verify that the license below does meet DFSG, before releasing the software itself, so I would like you to take a look at this text and tell me what your opinions are, before getting rejected on the NEW queue :-) Altought IANAL, It appears to me that it meets the requirements, but, as I mentioned, I would like your advice about it. Hello Derek, in summary, the work can be distributed under the GPLv2 or superior, or under the GPLv3 or superior with an exemption that lifts the incompatibility with the OpenSSL license (but that can not be used to accept new incompatible clauses that would be added after March 2010). This exemption can be removed, provided of course that the program is not linked anymore with OpenSSL. I do not see either something that would contradict the DFSG. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409003426.ga28...@kunpuu.plessy.org
Re: logo license with debian - no warranty missing?
Le Wed, Jun 30, 2010 at 08:31:52AM +1000, Ben Finney a écrit : I assume “how could that happen” there refers to the legal confusion. I don't pretend to be an expert, but “The Debian project is a major copyright holder in this work which caused damage to our systems, and there's no warranty disclaimer” isn't particularly implausible. Such a situation would predictably (not inevitably) lead to a court battle over who caused the damage; even if the Debian project knows that it's blameless, that could be expensive to prove in a court case. Hi Ben and Pompee, it would be much more productive if this scenario would be accompanied with some data and facts about which law in which country make the non-warranty disclaimer necessary, exemplified by cases where these laws have successfully been used in court by the plaintiff. In the absence of such an analysis, the discussion is purely about fear, uncertainty and doubt. While it is true that most of the major players in the free software world have opted for having non-warranty disclaimers in their license, I think that we should do our best to base our actions on our understanding, not on the imitation of the others. It is the addition of extra clauses and vague disclaimers that sometimes make licenses non-free (clauses like ‘do not kill people with my software’), so let's resist to temptation of making our license statements longer than what is necessary. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629235934.ga6...@kunpuu.plessy.org
Re: SWIG license change to GPLv3, wording of debian/copyright?
Le Wed, Aug 11, 2010 at 11:26:43PM +0200, Torsten Landschoff a écrit : http://svn.debian.org/wsvn/pkg-swig/branches/swig2.0/LICENSE-UNIVERSITIES Instead I would rather refer to common-licenses, but the texts of the license in there do not match word-by-word with BSD/MIT. Does anybody think it is wrong to summarize in debian/copyright that SWIG is GPLv3 with parts being under MIT or BSD license instead of putting in a full copy? It is my understanding that GPLv3 is the most restrictive license of the bunch. Dear Torsten, The GPL adds restrictions but does not cancel the terms of the MIT and BSD licenses, so their requrirement that ‘Redistributions in binary form must reproduce the above copyright notice…’ still fully applies: you have to quote them entirely. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100811231821.gc24...@merveille.plessy.net
Re: fmodapi license and non-free
Le Wed, Jan 12, 2011 at 09:47:09PM +, Johey Shmit a écrit : There is a Non-Commercial License which to me sounds like it's ok for 'non-free'. It can be found at http://www.fmod.org/index.php/sales and reads: […] Can anyone confirm if that's ok for 'non-free'? Dear Johey, this license does not allow explicitely redistribution, so I think that you would need a clarification from fmod. In addition the license does not allow modification as well, so even if it were technically possible to redistribute the software in the non-free area of our archive, the package would be very difficult to maintain. So it looks like a bad start… Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110112232147.ga20...@merveille.plessy.net
Re: data copyright or not -- what is Debian's take?
Le Mon, Jan 24, 2011 at 10:44:34AM -0500, Yaroslav Halchenko a écrit : Or should I advise to use the text of MIT license, verbally and explicitly describing possible uses and disclaiming any warranty? but once again without any copyright statement. Dear Yaroslav, licenses of the family of the MIT or the BSD require to to reproduce copyright statements on derivatives, and I think that it would cause headaches to many to attempt to seriously comply with them. We are blessed that a lot of data is truly in the U.S. public domain and therefore we can use it completely freely. In case deposition in the public domain is not permitted by the law, I would recommend to use very permissive terms. Some people keep it short, with the WTFPL or the politically correcter BOLA, and some people prefer longer terms to hammer the fact that by giving their data, they can not be responsible for disappointments, errors or misuses made by third parties. The Creative Commons Zero was invented for that case. http://sam.zoy.org/wtfpl/ http://blitiri.com.ar/p/bola/ http://creativecommons.org/choose/zero/ In any case, I recommend to not use the MIT or equivalent licenses that are picky on copyright reproduction, unless it is the will of the copyright holders to have their names accompanying each and every derivative. But can you imagine the mess if one had to track which contributor to acknowledge when reproducing an extract of the human genome ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125055904.ga...@merveille.plessy.net
Re: copyright on upstream patches
Le Fri, Feb 18, 2011 at 10:16:26AM +0100, Harald Jenny a écrit : I also thought about this but as the license text for the University of California differes slightly from the one of Petr Rehor I wasn't sure this is the correct way to do it - I also thought about: Oops, I missed this as the first and the last BSD texts were identical… Files: * Copyright: 2005, Petr Rehor r...@rx.cz License: BSD-1 Files: compat/fts_compat.h, compat/daemon.c, compat/mkdtemp.c, compat/fts_open.c Copyright: 1987, 1989, 1990, 1993, 1994, The Regents of the University of California License: BSD LICENSE TEXT FROM California Files: debian/* Copyright: 2009-2011, Harald Jenny har...@a-little-linux-box.at License: BSD-1 License: BSD-1 LICENSE TEXT FROM Petr Rehor As I'm not sure how detailed the exact wording of the license text must be preserved I wanted to be on the safe side but when it's ok to just use the amavisd-milter License stanza also for the University of California this is for sure better... what's the list's opinion on this? That is a good point. My personal impression (but not really an informed opinion: I am ready to change my mind if I hear good arguments), is that if the license text is not identical to the reference BSD license, then it is not the BSD license. Note that if you pick BSD-1 as a keyword, it looks like a versionned short name. How about BSD-like ? Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110218110358.ge...@merveille.plessy.net
Re: The Evil Cookie Producer case
In accordance with Section 7(b) of the GNU Affero General Public License, you must retain the producer line in every PDF that is created or manipulated using iText. Hello, in my understanding of section 7 of the AGPL, the supplemental terms are there to ensure compatibility with other free license, and the ‘legal notices or author attributions’ that are the object of the paragraph b) are typically found in the program's source code, not in code or the data generated by the program. The GPL has a similar section. Regardless of the purpose and the intentions behind requiring to ‘retain the producer line in every PDF that is created or manipulated using iText’, if this addition to the AGPL does not fall under Section 7(b), this makes iText potentially incompatible with other works released under the (A)GPL license. That alone may be a reason to reconsider this additional term. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307100240.gc22...@merveille.plessy.net
Re: The Evil Cookie Producer case
Le Mon, Mar 07, 2011 at 11:06:22AM +0100, Bruno Lowagie a écrit : Op 7/03/2011 11:02, Charles Plessy schreef: Regardless of the purpose and the intentions behind requiring to ‘retain the producer line in every PDF that is created or manipulated using iText’, if this addition to the AGPL does not fall under Section 7(b), this makes iText potentially incompatible with other works released under the (A)GPL license. That alone may be a reason to reconsider this additional term. Is there any jurisdiction about this I can forward to my attorney? I do not have experience in contacting them, but I think that if I were in your case, I would ask directly to Free Software Foundation, since they probably know the best what is the intention behind Section 7. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307101252.gd22...@merveille.plessy.net
Re: Font license
Le Mon, May 09, 2011 at 03:09:15PM +0200, أحمد المحمودي a écrit : 1.The Font Software cannot be Sold, Modified, Altered, Translated, Reverse Engineered, Decompiled, Disassembled, Reproduced or Attempted to discover the Source Code of this Font in no means. Dear Ahmed, this is very restrictive and somewhat ambiguous. For instance depending on what “Reproduced” is interpreted it may mean that we can not redistribute copies. Perhaps you can try the other way round: explaining the DFSG upstream, and asking them if they confirm that their license is compatible with our guidelines, after undelining the potential problems. This may be a good opportunity to ask them if they would kindly consider a free license, or at least a non-free license that is already in Debian. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509134452.ga32...@merveille.plessy.net
Re: Are ‘UniProt’ records complying with the DFSG ?
Le Tue, Jul 19, 2011 at 10:50:15PM -0400, Yaroslav Halchenko a écrit : unfortunately IMHO we (Debian) are not in position to provide such legal service to the community as to claim that something is not copyrightable (e.g., are you sure it is not in all jurisdictions?) in contradiction to the author's original copyright/license claim. We can only contact upstream and try clarifying/changing various license issues (in my case above the author is already R.I.P... heh), strip such questionable materials or complement them by shipping in non-free... I see no other way around. Le Wed, Jul 20, 2011 at 07:21:35AM +0200, Florian Weimer a écrit : There's a notice at the top which explains that the FAQ has been superseded. It doesn't appear to be a mere policy matter, the legal analysis seems rather incomplete. Thanks for your comments. I have contacted the UniProt consortium about the UniProt records in EMBOSS, to ask them if they consider them copyrightable, and if it is not the case, if they could provide a replacement such as test data distributed under a Free license. If this does not work, I will ask for the removal of EMBOSS and re-upload to non-free. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110724235600.gb6...@merveille.plessy.net
Re: License check for a new(ly modified) license..
Le Tue, Sep 27, 2011 at 07:02:53PM -0400, Felyza Wishbringer a écrit : Would this be better wording? 2. Nobody is liable for what .. you do with it Dear Felyza, I think that unfortunately, there is no possiblity to have a license that is short and fun / satyrical / provocative / …, and at the same time have a wording that accurately fits the laws of many countries about liabilities and intellectual property. Just see for instance at the Creative Commons Universal Public Domain Dedication license: http://creativecommons.org/publicdomain/zero/1.0/legalcode This said, there are some minimalistic license that have a very short disclaimer, like the GNU All-Permissive license: http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110927232906.ga6...@merveille.plessy.net
Re: Fwd: Re: RFS: wmaker
Le Tue, Nov 15, 2011 at 08:50:43AM +0100, Rodolfo kix Garcia a écrit : I am not sure if I can use the WTFPL-1 license in the License field. In the file http://dep.debian.net/deps/dep5/; are the possible licenses to use, and of course, WTFPL-1 license is not included. Dear Rodolfo, The list in http://dep.debian.net/deps/dep5/ is not limitative, you can use WTFPL-1 or any other keyword if you like. The public-domain short name is reserved for cases where the work is really in the public domain in the strict legal sense of it; this is a rare case (for instance, some works of U. S. government employees). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2015082442.ga27...@merveille.plessy.net
Re: Fwd: Re: RFS: wmaker
Le Tue, Nov 15, 2011 at 09:49:47AM -0500, Hendrik Weimer a écrit : Charles Plessy ple...@debian.org writes: The public-domain short name is reserved for cases where the work is really in the public domain in the strict legal sense of it; this is a rare case (for instance, some works of U. S. government employees). US government works are only in the public domain when distributed within the US. In all other countries that have signed the Berne Convention you still need a license, which should also apply to many Debian mirrors. http://www.quantenblog.net/free-software/us-copyright-international Hi, at least for the Debian point of view, what I can say is that it redistributes public domain US government works outside US without license, and that the FTP team does not seem to find it problematic, as in my experience it still accepts packages containing such works. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2015223049.gm25...@merveille.plessy.net
Re: conflict between name and text of a license
Le Tue, Dec 13, 2011 at 10:28:05PM +0100, Cédric Boutillier a écrit : I am packaging a software containing files with the COPYING file here attached. They have a double BSD and DR, but the text below BSD License is in fact that of the MIT/Expat license. Dear Cédric, since the Expat license is already a renamed MIT license, I think that you can go ahead and call the syck's files license MIT or Expat. If it is for a copyright file in the DEP 5 format, it is preferred to call it Expat. You can anyway add a comment reminding that the files' author wrongly called the license BSD, if you would like. If you think that we can not exclude that the author, when writing BSD, really meant that he wants his software to be licensed under the same terms as a BSD license, and not under the terms that he wrote, then maybe the safest would be to help the upstream author who uses these files in unit tests to replace them. That would also have the advantage of getting rid of the DR, which some (me for instance) may find bad taste. One of the problems of saying BSD is that it does not indicate the terms clearly, as for instance the first version of the BSD license had a GPL-incompatible advertisemnt clause… Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111213231832.gc19...@merveille.plessy.net
Re: Local community license issue
Le Sat, Jan 07, 2012 at 07:35:02PM +0200, Victor Nitu a écrit : Is the GNU GPL a decent enough license to be applied to our contributors' work? Or any CC variant? What shall I answer to their question, as a community website co-founder? Dear Victor, if you and the other contributors are not worried that your works will be used in proprietary derivatives, it may be most simple to take extremely liberal licenses, like the Unlicense, or to explore the way the Translation Project does, that is to promise to not exert copyrights. http://unlicense.org/ http://translationproject.org/html/whydisclaim.html Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120108091050.gd1...@merveille.plessy.net
Re: Debian official web site is still non-free
Le Sun, Jan 08, 2012 at 11:17:02PM +0100, Stefano Zacchiroli a écrit : I'm under the *impression* that an important amount of people objecting copyright assignments do so to avoid the risk that their contributions get re-licensed under terms that go against their moral beliefs about software freedom. That is why I won't sign a copyright assignment to a for-profit entity. Hi Stefano, in my understanding, there is still a big difference between copyright assignment and re-licensing, even if we trust the license to be free. - In the case of assignment, the author has to comply with the license chosen by SPI. - In the case of re-licensing, the author can still use his work under the license he prefers. Imagine for example that I write for the Debian Med project's pages a short explanation of what ‘biological sequence alignment’ means. In that case, I would like to keep the option to re-use my work freely. However, if the website were copylefted, and if I would transfer my copyright, this would restrict my possibilities to re-use my own work. For that reason, I think that copyright assignment and choice of license can not be separated. Which is another good reason to go for relicensing or copyright disclaiming instead. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120109013219.ga18...@merveille.plessy.net
Re: Bug#388141: Ask contributors a permission to relicense
Le Sun, Jan 15, 2012 at 02:45:20PM -0400, David Prévot a écrit : Since the “web team” is not a clearly defined entity, I propose, for legal purpose, that the license choice stays ours but we mandate the Debian project leader to publicly announce it once we have decided the accurate license(s) (thus there is another safeguard: the “web team” won't choose a silly license without a formal acknowledgement of the Debian project by the voice of its leader). ——— Subject: Permission to relicense my work on the Debian website I hereby give permission to relicense my work — which consist of edition or translation of portions of text from one human language to another human language, that I have provided to the Debian website or that I will provide in the future — to any DFSG compatible license as chosen by the web team, and announced by the Debian project leader. ——— Dear David, I would definitely agree with the above. This said, it may be even simpler to make the contributors relicence themselves. For instance: I hereby license my past and future contributions to the Debian website, which consist of edition or translation of portions of text from one human language to another human language, under the DFSG compatible license that will be announced by the Debian project leader on the debian-devel-announce diffusion list in his next message titled “New license for the Debian website”. This removes questions such as “do we have the right to give the right to relicence”, or “what if in 10 years the website is re-relicensed with terms that I will not like (because the DFSG will have been amended)”, etc. One last comment – I realise that I gave many more than average – is that the contributors sometimes contribute some programmatic work as makefiles or perhaps patches to some scripts. If applicable, the relicensing would be even more simplified by targetting all contributions to the webwml repository. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120116040509.ga10...@anx191.gsc.riken.jp
Re: Fwd: Re: Copyright and License status of transtab
Le Tue, Jan 31, 2012 at 12:04:26PM -0800, Clint Byrum a écrit : I contacted the author of the python module, and the attributed author of the directory in question. His reply is below. Dear Clint, In the reply, I read: Should I ever get around to making another transtab release (an old, unfinished project) Regardless of the license, this calls in question whether this piece of code is fit for the level of support expected for a Debian package. If there are possible replacements that are actively maintaine, it may pay off to switch to them. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120131233838.ga16...@merveille.plessy.net
Re: custom license (package: bwctl)
Le Fri, Feb 03, 2012 at 05:16:26PM +0100, Raoul Borenius a écrit : You are under no obligation whatsoever to provide any enhancements to Internet2, or its contributors. If you choose to provide your enhancements, or if you choose to otherwise publish or distribute your enhancement, in source code form without contemporaneously requiring end users to enter into a separate written license agreement for such enhancements, then you thereby grant Internet2, its contributors, and its members a non-exclusive, royalty-free, perpetual license to copy, display, install, use, modify, prepare derivative works, incorporate into the software or other computer software, distribute, and sublicense your enhancements or derivative works thereof, in binary and source code form. Dear Raoul, these terms have been discussed earlier on this list, and many commenters quiestionned its freeness. Nevertheless, our archive contains works distributed under very similar terms. http://packages.debian.org/changelogs/pool/main/a/apbs/apbs_1.2.1b-1/copyright http://lists.debian.org/debian-legal/2009/08/msg00028.html http://lists.debian.org/debian-legal/2009/09/msg1.html This license allows to make derivatives under any terms, very similarly to the BSD license. It makes it impossible to publish derivatives under no terms at all. This restriction is much weaker than copyleft licenses, which forbid this as they also forbid to redistribute derivatives under non-copyleft terms. Thefore, while the validity of this concept of default license may be questionable, I do not think that it is non-free. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120204002329.ga1...@merveille.plessy.net
Re: custom license (package: bwctl)
Le Sat, Feb 04, 2012 at 09:20:19AM -0500, Clark C. Evans a écrit : | without contemporaneously requiring end users to enter into | a separate written license agreement for such enhancements Ok. So, this language iss the one under debate I guess. Simply putting on a license text isn't sufficient, you need to *require* end users to *enter* into a *written* agreement. Hi, this is exactly the key point. In my understading, “to enter into a written license agreement” can be done by receiveing a license text, reading it and accepting it. If one can read it, it is written. But I am not a native speaker. If it is the meaning of the Internet2 license that both parties must sign a document in order to “enter into a written license agreement”, then it is not a free license. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120207082713.gd24...@merveille.plessy.net
Re: DEP-5 best practice
Le Sun, Feb 12, 2012 at 05:25:18PM +1100, Dmitry Smirnov a écrit : Dear Dmitry, 1) Question #1: what would be the best way to emphasise/distinguish difference between license of a software as a whole from the license of the most of its source files? It is possible to use a License field in the Header paragraph, to summarise the license of the package as a whole. There, you can explain the consequences of combining GPL-2+ and GPL-3+. 2) Would it be accurate to merge two paragraphs above if there is no overlapping copyrights (but the same license) or is it better to keep two separate paragraphs? It is less accurate, but permitted by the syntax. It is your choice. For large packages, it will save a lot of time to the maintainer to collate the copyright statements. For the packages I maintain, I like to give a separate paragraphs to works that, although distributed under the same license, are obviously independant, like contributed scripts, convenience copies of libraries, etc. 3) Would it be correct to assume that files with lack of license header are covered by the license of a software as a whole, and therefore their copyright can be added to the very first DEP-5 paragraph or if such files qualify for standalone paragraph? (If latter is true, what's would be the best to put in License field?) Note that this question is not specific to the machine-readable format. The same problem arises when writing free-form copyright files. There is no other solution than using common sense or contacting the authors. For example, in case of works in a contrib directory, it can be questionnable if they are distributed under the same license as the main files. For files in the main source tree, it may be that the authors just forgot to add a notice. In doubt, you need to contact the upstream authors. If it is clarified that files lacking license notices are under the same terms as the other files, they can be included in the same Files pattern. 4) Are the files with license header but no copyright, qualify for inclusion into second DEP-5 paragraph listing most of the contributors releasing files under matching license? (This is a license of roughly 95% of files in the package) 5) Are files with no license and no copyright qualify for standalone paragraph? (If not where would be the best to list them) 6) What would be the best way to describe such files according to DEP-5 if this difference is significant? Same as above. If you have doubts about the redistribution terms of a file in a source pacakge, then you must not upload to the Debian archive. If you write a machine-readable Debian copyright file where a Files paragraphs has a pattern that matches everything (Files: *), then you basically state that, in your opinion of maintainer, all files that are matched by that pattern, regardless of the notices they contain or not, are distributed under the license stated by that paragraph. For the copyright statements, the current practice is to reproduce them and optionally combine them. If they are missing, then there is nothing to reproduce. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120212073835.ga9...@falafel.plessy.net
Re: XUL template - proper license
Le Sun, Feb 12, 2012 at 08:50:45PM +0200, Θοδωρής Λύτρας a écrit : https://github.com/zotero/zotero/blob/master/chrome/content/zotero- platform/unix/standalone/menuOverlay.xul It is a XUL template, and includes the following copyright notice: The Original Code is Mozilla.org Code. The Initial Developer of the Original Code is Netscape Communications Corporation. Portions created by Netscape are Copyright (C) 1998-2000 Netscape Communications Corporation. All Rights Reserved. It's not clear to me which (if any) parts of the code is (C) Netscape. I think they just used it as a base to write their own menu in XUL. So I wonder: should I disregard this notice and consider this file to be part of Zotero, and thus AGPLv3? And if not, how should I write it in my DEP-5 compliant debian/copyright file?? Dear Theodore, looking at this file, and after reading https://developer.mozilla.org/en/XUL_Overlays, I think that there is nothing copyrightable remaining from whaterver template the Zotero authors used. Paul's suggest to ask them for confirmation is of course good to take. To document the current file in the machine-readable format, you can either add the Netscape copyright statement to the paragraph containing the Files: * pattern, as the AGPL-3+ is the main license of Zotero, or, at your option, make a specific Files paragraph for that file. In any case, machine-readable or not, you should not disregard copyright and license notices when writing the Debian copryight files. Have a nice day, and thank you very much for maintaining xul-ext-zotero ! -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120213003241.ga25...@falafel.plessy.net
Re: picviz license (generated images as derivative work ?)
Le Sat, Feb 25, 2012 at 03:45:40PM +0100, Pierre Chifflier a écrit : Note that the GPL places important restrictions on derived works, yet it does not provide a detailed definition of that term. To avoid misunderstandings, we consider an application to constitute a derivative work for the purpose of this license if it does any of the following: o Integrates source code from Picviz o Integrates images generated by Picviz o Executes Picviz and parses the results (as opposed to typical shell or execution-menu apps, which simply display raw Picviz output and so are not derivative works.) o Integrates/includes/aggregates Picviz into a proprietary executable installer, such as those produced by InstallShield. o Links to a library or executes a program that does any of the above Dear Pierre, it looks like the Picviz authors want to prevent some competitors to encapsulate Picviz in a proprietary system. In many aspects, this is already forbidden by the GPL. Perhaps you can recommend them to ask for clarifications to the FSF if necessary, and perhaps also to have a look at the AGPL if among their worries there is the case where a competitor would make a proprietary web service encapsulating Picviz. Similarly, it looks like the GPL considers the the build and install system as part of the source code, and the clarification that Picviz should not be installed via InstallShield looks therefore unnecessary. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120226114307.gb8...@falafel.plessy.net
Re: MIT +no-false-attribs
Le Fri, Mar 09, 2012 at 04:34:10PM +0100, Jérémy Lal a écrit : In the latest version, Author has been replaced by Original Author, and that term defined in the copyright line : https://raw.github.com/isaacs/npm/master/LICENSE Dear Jérémy, this clause is quite similar to the clause 6c of the The LaTeX Project Public License version 1.3c. 6. If you are not the Current Maintainer of the Work, you may distribute a Derived Work provided the following conditions are met (...) c. No information in the Derived Work implies that any persons, including (but not limited to) the authors of the original version of the Work, provide any support, including (but not limited to) the reporting and handling of errors, to recipients of the Derived Work unless those persons have stated explicitly that they do provide such support for the Derived Work. By analogy, it looks that the npm license is free. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120311015132.ga10...@falafel.plessy.net
Re: Using freetranslation.mobi to translate .po files (Was: google translating gpl2+ licenced documentation...)
Le Mon, Mar 12, 2012 at 02:09:00PM +0100, Petter Reinholdtsen a écrit : I wrote a small perl script to process through a .po file and pass all completely untranslated text fragments to this service and store the resulting translation (if it succeeded) as a fuzzy translation in the .po file. The translation then need to be reviewed by a human before it is used to generate the documentation in question. I checked in rough translations in debian-edu-doc after first running this new tool for en-nb and manually checking a few of the new translations. Hello everybody, this reminds me the behaviour of virtaal, which will propose to pre-fill tranlsations with the output of Microsoft Translator. If it is not possible to translate copylefted text with such services, maybe the functionality should be disabled by default ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312133343.ga29...@falafel.plessy.net
Re: Using freetranslation.mobi to translate
Le Sat, Mar 24, 2012 at 12:31:24AM +0100, Petter Reinholdtsen a écrit : So even if one accepted the terms of Google Translator, which I do not, and used it directly instead of URL: http://freetranslation.mobi/ , this part would then not be a licensing problem. But it seem irrelevant for this discussion, as I was using URL: http://freetranslation.mobi/ and not Google Translator. Dear Petter, are you sure if http://freetranslation.mobi/ actually respects Google's terms of use ? Being closed source, it is not possible for instance to see if it accesses the translations through Google's API or if it acts more like a rogue proxy. If you want to use freetranslation.mobi regularly, I would recommend to ask Google for a clarification. In any case, that you respect freetranslation.mobi's terms of use does not make you free from Google's terms. Imagine for instance if one would set up a website called gpl2bsd.org, which would substitute GPL notices by BSD notices: users obtaining the relicensed software would not be allowed to keep on following the BSD license after they are notified that they downloaded an unauthorized copy. According to http://www.google.com/intl/en/policies/terms/ : When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones. This license continues even if you stop using our Services (for example, for a business listing you have added to Google Maps). Some Services may offer you ways to access and remove content that has been provided to that Service. Also, in some of our Services, there are terms or settings that narrow the scope of our use of the content submitted in those Services. Make sure you have the necessary rights to grant us this license for any content that you submit to our Services. In the case Google would publish a derivative of a GPLed text uploaded for translation, even in the limited purpose of operating, promoting, and improving [their] Service, the GPL would be violated if the derivative would not mention its original license in the published material. I admit that this is a far-fetched scenario, but that may need to be considered before pasting GPLed text in Google Translate. For the resulting translations, however, I think that I agree that there is no copyright claimed on them, and that they can be freely added to the original project. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120324032603.gb16...@falafel.plessy.net
Re: Using freetranslation.mobi to translate .po files
Le Sat, Mar 24, 2012 at 09:23:39PM -0400, Clark C. Evans a écrit : I suggest that the developer may want to *contact* Google tell them what you wish. Hi all, I just sent the following message in the following form. http://support.google.com/translate/toolkit/bin/request.py?hl=encontact_type=contact_us Email address: ple...@debian.org Subject: Sharing and Publishing Brief summary: Terms of use when translating through an intermediate. Message: Dear Google, . freetranslation.mobi offers translation services that are Powered by Google, and I wonder if using freetranslation.mobi implies agreeing to Google's terms of service. . The question arises from a discussion where it is wondered if it is possible to submit copylefted material to Google Translate. You can see the (longish) thread the URL below. . http://lists.debian.org/debian-legal/2012/03/msg00031.html . By the way, can you confirm if the following terms of service are relevant to Google Translate ? . http://www.google.com/intl/en/policies/terms/#toc-content . Have a nice week-end, . -- Charles Plessy Tsurumi, Kanagawa, Japan Let's see if we have an answer. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120325021327.gb5...@falafel.plessy.net
Re: foremost package - Licence of debian/* files
Le Fri, Apr 13, 2012 at 09:33:06PM +0200, Francesco Poli a écrit : On Fri, 13 Apr 2012 15:36:22 -0300 Raúl Benencia wrote: I see [1] that the package is currently public domain, except for a couple of files, which are instead copyrighted and released under the terms of the GNU GPL v2 or later. [1] http://packages.debian.org/changelogs/pool/main/f/foremost/current/copyright Hence I wonder: why would you want to gratuitously restrict the whole package to GPL-3+ just because of debian/* ? I would suggest licensing debian/* files under GPL-2+ for consistency with the packaged work. Actually, the only evidence I see for api.c and ole.h being GPL-2+ is the statement on Chicago's project page on SourceForge. http://sourceforge.net/projects/chicago/develop I would rather suggest a license more in line with public domain works, such as Creative Commons zero license, the SQLite public domain dedication, or the GNU all-permissive license. http://creativecommons.org/publicdomain/zero/1.0/ http://www.sqlite.org/copyright.html http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120414032407.gc4...@falafel.plessy.net
Re: CC-BY-SA 2.5 can be re-released under 3.0?
Le Sat, Aug 18, 2012 at 11:49:23AM +0200, Fabio a écrit : See this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432095 and my reply with links to CC FAQ (sorry for the broken links due to crappy webmail). So would it be possible to just restrict the package license to 3.0 to be debian compatible? Dear Fabio, CC licenses version 3.0 are compatible with version 2.0, but on the other hand, CC licenses do not allow to redistribute a work under a later license: the section 4.b, that contains « You may distribute [...] a Derivative Work [...] under [...] a later version of this License » only applies to derivatives (called adatpations in version 3.0). Section 4.a, which applies to the original work, does not give this permission. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120819003234.ga20...@falafel.plessy.net
Re: About kstars-data-extra-tycho2 distributability
Le Mon, Aug 20, 2012 at 07:54:05PM +0100, Noel David Torres Taño a écrit : On the package kstars-data-extra-tycho2 it has arisen a doubt about its distributability: See bug #681654 Dear Noel, sorry to discard the arguments you already gave in #681654, but have you considered asking for a clarification to one of the current mainstream distributors ? http://cdsarc.u-strasbg.fr/viz-bin/Cat?target=httpcat=I/259 Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120821015543.ga11...@falafel.plessy.net
Re: Freeness of this license
Le Thu, Aug 30, 2012 at 10:48:35AM +1000, Ben Finney a écrit : LICENSEE shall indemnify, hold harmless and defend the Copyright Owners and their trustees, officers, employees, students and agents against any and all claims arising out of the exercise of any rights under this Agreement, including, without limiting the generality of the foregoing, against any damages, losses or liabilities whatsoever with respect to death or injury to person or damage to property arising from or out of the possession, use, or operation of Software or Licensed Program(s) by LICENSEE or its customers. This is an imposition of boundless and unknowable costs on the licensee, based on the action of other parties. It goes far beyond the (already included) warranty disclaimer, and reaches into the future life of the licensee to oblige legal defense of the copyright holder. It makes the work non-free, in my opinion. Hi Ben and others, I would like to advertise the packages-metadata repository: http://anonscm.debian.org/viewvc/collab-qa/packages-metadata/ svn://svn.debian.org/collab-qa/packages-metadata/ http://wiki.debian.org/UpstreamMetadata Today it already contains 3431 Debian copyright files. Most of them are up to date (but consistency checks have not been implemented yet). Using this tool, one can search for similar license terms in the Debian archive. Note that the pool includes the non-free section... Given the multiplicity of variants, it is hard to tell if there are similar restrictions on works already accepted in Debian. Maybe the DNG SDK from Adobe in digikam ? 5. INDEMNIFICATION If you choose to distribute the Software in a commercial product, you do so with the understanding that you agree to defend, indemnify and hold harmless Adobe against any losses, damages and costs arising from the claims, lawsuits or other legal actions arising out of such distribution. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120830045046.ga16...@falafel.plessy.net
Re: About packages-metadata [was: Re: Freeness of this license]
Le Thu, Aug 30, 2012 at 07:25:30PM +0200, Francesco Poli a écrit : Do you mean that one can search by cloning the subversion repository and then using grep (and other similar tools) recursively in the resulting local directory tree? Yes, exactly. Since the all the copright files are in a subdirectory, the grep command can also be run on '*/*.copyright' instead of recursively; this will remove some noise as Subversion keeps copies in subdirectories. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120830230352.ga3...@falafel.plessy.net
Re: About kstars-data-extra-tycho2 distributability
Le Mon, Aug 20, 2012 at 07:54:05PM +0100, Noel David Torres Taño a écrit : On the package kstars-data-extra-tycho2 it has arisen a doubt about its distributability: See bug #681654 On Martes, 21 de agosto de 2012 02:55:43 Charles Plessy wrote: sorry to discard the arguments you already gave in #681654, but have you considered asking for a clarification to one of the current mainstream distributors ? http://cdsarc.u-strasbg.fr/viz-bin/Cat?target=httpcat=I/259 Le Thu, Aug 30, 2012 at 07:33:38PM +0100, Noel David Torres Taño a écrit : I thought I sent this before, but it seems that not. from: HOTLINE-DU-CDS Non-Nominatif (UDS) cds-quest...@unistra.fr subject: Re: About Catalogues License message-id: 31d-5035ef80-1b-53516180@99327283 Dear Noel Torres, here is the CDS policy for the scientific data we distribute: Catalogues available at CDS contain scientific data distributed for free, for a scientific usage. Companies including such data in their commercial products cannot charge their clients for the data. Furthermore, users must be informed of the origin of the data: this means an explicit reference to the service provided by the CDS and also to the original author(s) of each catalogue. Hi Noel, sorry that I did not find it by myself. The following parts of their answer is ambiguous. data distributed for free, for a scientific usage Does it mean that other usages, for instance commercial, artistic or military, are disallowed if downloading the data for free ? Companies including such data in their commercial products cannot charge their clients for the data. Does it mean that for-profit use is disallowed, or does it mean that, while one can charge for the software packages that redistributes and displays the data, the presence of the data can not be used as a justification in the price ? For that question in particular, the SIL open font license is an interesting example. It is Free according to Debian, but note the following clauses: 1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. http://scripts.sil.org/cms/scripts/page.php?item_id=OFL_web It means that one can sell a software that contains the font, but one can not sell an isolated file that contains just the font. Perhaps this is what is meant for the data in the CDS above ? All in all, I think that you unfortunately need to ask for one more clarification. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120830235727.gb3...@falafel.plessy.net
Re: New package algol68toc: terms of the copyright.
Le Sun, Sep 16, 2012 at 01:25:21PM +0100, Steve McIntyre a écrit : Chris wrote: I think this clause in the license absolutely fails the dissident test Please point to the DFSG section that mentions the dissident test. Hi Steve, I think that the dissident test and others are indirectly mentionned to everyone who wants to join Debian: http://anonscm.debian.org/viewvc/nm/trunk/nm-templates/nm_pp1.txt?revision=1246view=markup 60 PH7. How do you check if a license is DFSG-compatible? 61 62 PH8. There are a few tests for this purpose, based on (not really) common 63 situations. Explain them to me and point out which common problems can 64 be discovered by them. I do not find these tests particularly useful, but as long as they are promoted this way, we are likely to see people using them on this lit. If you think they create more noise than signal, perhaps you or others can consider asking for a change to the NM templates via a bug reported to nm.debian.org. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917001842.ga6...@falafel.plessy.net
Re: Bug#687693: ca-certificates: Cacert License is missing
Le Sat, Sep 15, 2012 at 12:35:09PM -0500, Raphael Geissert a écrit : Hi everyone, mejiko: thanks for pointing it out, I'm forwarding your report to our debian-legal mailing list to seek their opinion. On Saturday 15 September 2012 03:15:10 mejiko wrote: [...] ca-certificates packeages included Cacert Root certificates. This certificates licensed under Cacert Root Distribution License (RDL). [...] http://www.cacert.org/policy/RootDistributionLicense.php https://lists.cacert.org/wws/arc/cacert-policy/2012-02/msg00031.html https://fedoraproject.org/wiki/Licensing/CACert_Root_Distribution_License TL;RD; RDL looks non-free, Philipp Dunkel from CAcert says Debian is fine (to distribute) because of the disclaimer re the certificates included in ca- certificates, Fedora says it is non-free. What do the others think about it? To me, it doesn't just seem to be a (re-)distribution issue. Rather, the need for an additional agreement with CAcert. Hello Raphael, could it be a very strangely phrased disclaimer of warranty ? That A lets B rely on A, is similar to A warrants to B. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120917002736.gc6...@falafel.plessy.net
Re: Why LGPLv3/CC-by-sa-v3.0 for the logo?
Le Sat, Sep 22, 2012 at 06:34:52PM +0200, Francesco Poli a écrit : In the meanwhile, what I was proposing was that the licensing of the Debian Open Use Logo should not create a deliberate incompatibility with either the GPLv2 or the GPLv3. Hi Francesco, The Debian Open Use Logo without « Debian » is still distributed under a persmissive license on www.debian.org/logos, so anybody who worries about license incompatibilities can make a backup now, and redistribute it under its permissive license later if it looks useful. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012094424.ga30...@falafel.plessy.net
Re: Bug#681654: #681654 kstars-data-extra-tycho2: undistributable
On Miércoles, 14 de noviembre de 2012 17:35:44 Timo Juhani Lindfors wrote: if http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681654#52 is correct and the issue is commercial use (and not nondistributability) how about just moving kstars-data-extra-tycho2 to non-free instead of having this bug delay wheezy release? You can always reintroduce it back to main if the issue is solved. Le Wed, Nov 14, 2012 at 05:44:42PM +, Noel David Torres Taño a écrit : I agree, iff debian-legal agrees so Hello everybody, Here is the statement in 681654#52 Catalogues available at CDS contain scientific data distributed for free, for a scientific usage. Companies including such data in their commercial products cannot charge their clients for the data. Furthermore, users must be informed of the origin of the data: this means an explicit reference to the service provided by the CDS and also to the original author(s) of each catalogue. For me, it looks reminescent of the SIL Open Font License, which states: The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. If one considers that in the statement in 681654#52, cannot charge for the data means the same as not sold by themselves in the OFL, then it would be consistent to keep kstars-data-extra-tycho2 in Debian, as SIL-OFL-licensed works are allowed. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121118000213.ga10...@plessy.org
Re: Bug#681654: #681654 kstars-data-extra-tycho2: undistributable
Le Sun, Nov 18, 2012 at 11:15:01AM +0100, Francesco Poli a écrit : On Sun, 18 Nov 2012 09:02:13 +0900 Charles Plessy wrote: [...] Catalogues available at CDS contain scientific data distributed for free, for a scientific usage. [...] Doesn't this fail DFSG#6 ? Hi, given that it comes from an email conversation and not a proper license, it is hard to decide if it has to be taken as a disclaimer or as a restriction. So if it is a serious concern, it means that a more formal clarification is needed. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121118110139.ga8...@falafel.plessy.net
Re: licensing question for nom.tam.fits
Le Fri, Nov 30, 2012 at 11:26:29PM +0100, Francesco Poli a écrit : P.P.S.: I am not sure what you should write in the Copyright field for the upstream files, but (c) 1996-2012 by Thomas A. McGlynn does not look right, as long as the upstream work is really in the public domain (which, as you probably know, means that the work is *not* subject to copyright!)... The machine-readable debian/copyright file format specification v1.0 (http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) is not too clear on this point, unfortunately... Maybe you should ask on the debian-policy mailing list and suggest that this topic should be clarified in the specification. Hi Francesco, the 1.0 specification mentions for the Copyright field: If a work has no copyright holder (i.e., it is in the public domain), that information should be recorded here. Inspecting Debian copyright files from svn://anonscm.debian.org/collab-qa/packages-metadata/ I see that many chose contents such as none, nobody, public-domain, not relevant, etc, which I think are good enough, given that the content of the Copyright field is free-form. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121201014747.ga31...@falafel.plessy.net
Re: licensing question for nom.tam.fits
Le Sat, Dec 01, 2012 at 12:17:15PM +0100, Francesco Poli a écrit : Since one of the standard short names for the License field is public-domain, I thought that specifying Copyright: public-domain License: public-domain [explanation of why the files are in the public domain...] was awkward and redundant. Hence, I wondered what should be put in the Copyright field when the License field says public-domain... Inspecting Debian copyright files from svn://anonscm.debian.org/collab-qa/packages-metadata/ I see that many chose contents such as none, nobody, public-domain, not relevant, etc, which I think are good enough, given that the content of the Copyright field is free-form. OK, so maybe Copyright: none License: public-domain [explanation of why the files are in the public domain...] is the way to go. I just wish that the 1.0 specification were more explicit on this point... If you would like, you can open a wishlist bug, and if the specification is updated in the future (there is no timeline for this and my opinion is that currently it would be premature), this bug will remind us to consider adding a recommendation (and asking you at that time if you would like to summarise the contents of the Copyright field in files where License indicates public-domain). Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121201113439.ga...@falafel.plessy.net
Re: Open data french license
On Thu, 20 Dec 2012 11:41:46 +0100 (CET) x.guim...@free.fr wrote: The complete text can be found here : * Original text : http://www.data.gouv.fr/Licence-Ouverte-Open-Licence * English translation : http://ddata.over-blog.com/xxxyyy/4/37/99/26/licence/Licence-Ouverte-Open-Licence-ENG.pdf You are free to re-use the « Information » : • To reproduce, copy, publish and transmit the « Information » ; • To disseminate and redistribute the « Information » ; • To adapt, modify, transform and extract from the « Information », for instance to build upon it in order to create « Derivative information » ; • To exploit the « Information » commercially, for example, by combining it with other « Information », or by including it in your own product or application. Bonjour Xavier and everybody, I do not see the permission to disseminate modified informations. If this restriction is confirmed, then the license is not free from Debian's point of view. Bon week-end, -- Charles -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121221104042.gd30...@falafel.plessy.net
FWD: on the variability of BSD and MIT licenses
Dear all, there is an interesting email on the SPDX mailing list, distributing an article about the BSD and MIT license families. Here is a link to the page with the attached file. http://lists.spdx.org/pipermail/spdx/2012-December/000785.html Have a nice day, -- Charles Plessy Illkirch-Graffenstaden, France -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121227225634.gb14...@falafel.plessy.net
Re: Bug#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
On Sat, Jan 12, 2013 at 11:43 PM, Francesco Poli (wintermute) I think that the effective licensing status of the binary packages (GPL-2+ or GPL-3+) should be explicitly and clearly documented in the comment at the beginning of the debian/copyright file and, probably, in the binary package long descriptions, as well. Le Sun, Jan 13, 2013 at 09:50:58AM +0100, Reinhard Tartler a écrit : I am not happy at all with cluttering the binary package description with license blabla. I would do so only as last resort Dear Reinhard, Francesco and everybody, I think that the Debian copyright file of libav 6:9.1-1 is clear enough with its comment in the header, and that it is best to keep the license information out of the description of the package. Note that the machine-readable format also allows License fields in the header paragraph to give the license information for the package as a whole. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130114015538.gc5...@falafel.plessy.net
FWD: SPDX Technical team invites your participation!
Hello everybody, for those interested in the subject: SPDX (Software Package Data Exchange, http://spdx.org) is calling for contributions for their 2.0 version. Cheers, -- Charles Plessy, Tsurumi, Kanagawa, Japan - Forwarded message - Date: Tue, 19 Mar 2013 13:57:39 + Subject: SPDX Technical team invites your participation! Hello SPDX'ers: Just a quick blast to the larger SPDX mailing list to update you on the goings-on of the Technical team and invite your participation. For a while now SPDX 1.1 has been out in the field, and over the past 6 months or more the Tech team has been studying the areas of improvement to target for an SPDX 2.0 specification. There have also been contributions to the set of tools around SPDX, which will be presented at the Linux Collaboration Summit next month. Regarding SPDX 2.0 we received tremendous industry and open source community input in the form of Use Cases and conceptual model proposals. A big thanks to all who contributed their time and ideas to that exercise! Those Use Cases have given us a valuable point of reference for the areas where the SPDX 1.1 model could be expanded to support greater adoption. More recently we are transitioning from conceptual modeling discussions / proposals into concrete proposals and we would welcome your involvement. An example of some proposals under consideration for 2.0: - exactly how a 'later' SPDX document references earlier SPDX documents to reuse/add/subtract/amend data - how to indicate Usage of individual files (as this may relate to obligations...) - how to indicate that a binary was derived from sources (and therefore license discoveries/assertions about the source may apply to the binary) - how to indicate that a snippet within a file is derived from another file and what licensing info applies to the snippet If you would like to help steer the technical proposals and decisions, please feel free to chime in on the spdx-t...@spdx.orgmailto:spdx-t...@spdx.org mailing list and join our weekly concalls Tuesdays 2pm Eastern time. See http://spdx.org/content/participation-guidelines-sign-0 for details Thanks! - Bill [cid:image001.gif@01CC836A.D8B42B40] Bill Schineller Senior Director, KnowledgeBase Black Duck Software, Inc. 8 New England Executive Park Burlington, MA 01803 E: bschinel...@blackducksoftware.commailto:kgold...@blackducksoftware.com T: 781/425-4405 ___ Spdx mailing list s...@lists.spdx.org https://lists.spdx.org/mailman/listinfo/spdx - End forwarded message - -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130320020435.ga30...@falafel.plessy.net
Re: data and software licence incompatabilities?
Le Tue, Aug 27, 2013 at 05:54:46PM -0400, Paul Tagliamonte a écrit : On Tue, Aug 27, 2013 at 10:55:33PM +0200, Francesco Poli wrote: CC licenses may be perfectly fine in *your* opinion. Apparently in many other people's opinion, too. But they are not in *my* opinion. Sorry, this was not *my* opinion, it was *Debian*'s opinion. This *is* debian-legal, isn't it? Hi Paul, Frankly speaking, Debian's opinion on the CC licenses does not exist. There is the empirical observation that this or that CC license is accepted or rejected from our archive, with both false positives and false negatives, and there is not any document that presents logically and clearly the facts behind the FTP team's choice of accepting version 3.0 and rejecting older versions. Given that the difference between the accepted and rejected license is so thin, I think that we can not blame people being unsatisfied in one direction or the other and telling it repeatedly their opinion on that matter. If you do not like this, please write a convincing and authoritative explanation of Debian's opinion, that will close the debate. Cheers, -- Charles Plessy Ceterum censeo Carthaginem delendam esse -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130831143031.ga8...@falafel.plessy.net
Re: data and software licence incompatabilities?
Le Sun, Sep 01, 2013 at 11:39:16AM -0400, Paul Tagliamonte a écrit : Perhaps you'd be interested in helping: http://lists.debian.org/debian-project/2013/01/msg00043.html I can not write your explanations for you, sorry. I have read the diff between the versions 2.0, 2.5 and 3.0 mutiple times, and I have not found anything convincing that would support the current situation of rejecting 2.0 and accepting 3.0. Note that I already asked. http://lists.debian.org/debian-project/2013/02/msg00080.html I think that your call for help here is upside-down: we can spend years documenting rare licenses where it is obvious that they do not fit the DFSG. This will not make a significant difference. What will be much more helpful would be to have a clear documentation the frequently problematic cases, with the pros and cons, and the final decision taken. Again, it is your decision, which I do not understand, so I can not write the explanation for it. But I would be grateful if you did. It does not need to be long: there is at least one sentence in CC 2.0 licenses, that has been changed in CC 3.0 licences to make them Free. The reason I ask with so much insistance is that I really feel like an idiot when I contact upstream to ask them to relicense works, and I am not able to explain why it matters. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130901164319.gc8...@falafel.plessy.net
Re: data and software licence incompatabilities?
Le Mon, Sep 02, 2013 at 10:06:01AM -0500, Gunnar Wolf a écrit : Excess repetition makes many of us regulars pay less attention to the topics. I'll mention this specific example, trying not to make it into an ad-hominem: Francesco has a *great* license comprehension and comparison skill, much greater than mine, and I appreciate reading his messages when I am starting, or have time, or am in a good mood. But I know there is a very high probability his mails will include a Well, but remember I don't think any CC licenses are as good as GPLv2! paragraph. So, Francesco: I will also tune in with Steve's request. I think your point would be better driven if not constantly repeated. And you would find this crowd much more likely to accept your ideas. Hello everybody, I think that this discussion is going completely out of proportions. Francesco always makes sure that his replies contain an informative answer. In the last part of his emails, he adds his point of view in a way that it is very clear that it is not Debian's. People who already read it can easily skip it, just like email signatures. If Debian bans Francesco from this list, I will fee very ashamed of us. Also, with such a low threshold for banning people who are polite, precise, who do not engage into flamewars, and never show aggressivity, we will set the stage for massive purge and witch-hunting, because of many people are within the treshold. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130903062927.gc19...@falafel.plessy.net
Re: redistributability of two software pieces in non-free
Le Sat, Sep 14, 2013 at 09:35:30AM +0200, Johannes Schauer a écrit : here the relevant parts of the copyright of a piece of software which is necessary for vmd, a molecular visualization program: --%--- […] * 3) Other interested research groups will be redirected * to the author. The user will not redistribute the code outside * his immediate research group. Dear Johannes, I think that this clause forbids the redistribution by Debian. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130915003833.ga5...@falafel.plessy.net
Re: ODbL / DbCL licenses: not DFSG compliant?
Le Sat, Sep 21, 2013 at 06:46:55PM -0400, Nick Oosterhof a écrit : are the Open Database License (ODbL) [1] and Database Contents License (DbCL) DSFG [2] compliant? It seems they are not, but I would like to make sure. Specifically I found an earlier thread [3] where it was argued that section 4.6 of the ODbL [1] makes it non-compliant (I presume with DSFG 1), as this section reads: Access to Derivative Databases. If You Publicly Use a Derivative Database or a Produced Work from a Derivative Database, You must also offer to recipients of the Derivative Database or Produced Work a copy in a machine readable form of: a. The entire Derivative Database; or b. A file containing all of the alterations made to the Database or the method of making the alterations to the Database (such as an algorithm), including any additional Contents, that make up all the differences between the Database and the Derivative Database. The Derivative Database (under a.) or alteration file (under b.) must be available at no more than a reasonable production cost for physical distributions and free of charge if distributed over the internet. which would restrict people from selling a Derivative Database or Produced Work for significant (higher than reasonable production) cost. Is that a reasonable interpretation? Dear Nick, in case of use for profit, the section 4.6 requires that the customer can access to what the DFSG call source code or patch files, with no unreasonable additional cost. It therefore does not restrict people from selling a Derivative Database or Produced Work for significant cost. This is similar to the requirements for conveying non-source forms in the GPL and the AGPL, which are accepted as Free by Debian. I have not studied the other clauses of the ODbL, but section 4.6 therefore does not seem to make it non-free. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130922094910.ga1...@falafel.plessy.net
Re: incompatible licenses in the debian directory
Le Wed, Sep 25, 2013 at 10:18:58AM -0400, Miles Lubin a écrit : Here's the issue: - Since the last upload, upstream has switched from the CPL (Common Public License) to the EPL (Eclipse Public License). - The debian directory had no explicit license mentioned in the copyright file. It was pointed out by Paul Tagliamonte that the previous maintainer(s) must agree to the change in license. - Soeren Sonnenburg, the previous maintainer, has insisted that his work be licensed under GPLv3 exclusively. - EPL and GPLv3 are incompatible (http://en.wikipedia.org/wiki/Eclipse_Public_License), but the extent to which they are incompatible is not clear to me. Hi Miles, Soeren and everybody, if Soeren did not indicate a license for his work in the Debian directory (to the extent that it is copyrightable), I think that the general assumption that it is under the same license as the Upstream work, in particular for the patches (which is why there is no License field in DEP 3, the Patch Tagging Guidelines). The CPL is also listed as incompatible with the GPL on FSF's website, so the patches definitely were not GPL-licensed. http://www.gnu.org/licenses/license-list.html#CommonPublicLicense10 For the manpage: it does not contain a copyright or a license statement, and the Debian copyright file mentions If not stated otherwise Copyright: (C) 2000-2003, 2005-2008 International Business Machines Corporation and others. License: Common Public License Version 1.0 In any case, it would be good to submit the manpage Upstream, and the most cooperative way would be to use the same license as Upstream. Integrating the manpage upstream reduces the packager's load, and shares the work beyond Debian. Soeren, are you sure you would like this manpage to be licensed under terms that may be not welcome Upstream ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130925225037.ga3...@falafel.plessy.net
Re: CC0 and authors' names in Copyright field
Gioele Barabucci gio...@svario.it writes: What should the Copyright field contain for packages dedicated to the public domain with CC0? Le Wed, Oct 02, 2013 at 08:25:48AM +1000, Ben Finney a écrit : DEP 5 URL:http://dep.debian.net/deps/dep5/ is Debian's standard for the ‘debian/copyright’ content. Hello Ben and Gioele, Just to clarify, the “machine readable debian/copyright file” specification, developped as “DEP 5”, is a stardard, but its use is not mandatory. The debian/copyright can also be written free-form, or following other formats (if any) that preserve a good human-readability. Currently, the canonical URL for the standard is http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/. As for CC0, as Ben explained, it is a license, and the simplest is to list the copyright holders as for other licenses. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131001234021.gb30...@falafel.plessy.net
Re: CC0 and authors' names in Copyright field
Le Wed, Oct 02, 2013 at 09:49:46AM +0200, Gioele Barabucci a écrit : Could the copyright-format page [1] be changed to state more explicitly that the Copyright field should list the names of the authors even in the case of public domain works (or works licensed via CC0)? I would like to file a bug report but I do not see which package I should use for that. [1] http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Hi, the machine-readable specification is contained in the debian-policy package, and there is already a bug opened on that matter. http://bugs.debian.org/694883 Le Thu, Oct 03, 2013 at 12:52:02AM +0200, Gioele Barabucci a écrit : Solution 2 (names in the Copyright field): Files: * Copyright: Dedicated to the public domain (CC) by John Doe License: CC0 License: CC0 Creative Commons Legal Code [... rest of the CC0 text ...] Or is there an even better third solution? Solution 2 is fine; Copyright: [year] John Doe would be enough as well. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131003000653.ga23...@falafel.plessy.net
Re: Creative Commons 4.0 licenses published
Le Thu, Nov 28, 2013 at 12:03:31PM +0100, Thorsten Glaser a écrit : On Thu, 28 Nov 2013, Paul Wise wrote: Mike Linksvayer suggests upgrading to CC0 instead: This is not a good idea: CC0 is up for a rework too, they just decided to get CC 4.0 out of the door first, and the current CC0 version is *explicitly* discouraged for use with software. Hi Thorsten, Can you share a link to such a recommendation with a reasonable explanation ? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131128122720.ga3...@falafel.plessy.net
Re: Need more (legal) information
Le Tue, Mar 25, 2014 at 12:06:53PM +0100, Thibaut Varène a écrit : The kanjidic documentation states (emphasis is mine): The following people have granted permission for material for which they hold copyright to be included in the files, _and distributed under the above conditions_, while retaining their copyright over that material: Jack HALPERN: The SKIP codes in the KANJIDIC file. As I understand this, kanjidic and the SKIP codes it embeds are freely redistributable under the licensing terms of kanjidic. That other licensing provisions for the SKIP codes may be made in other use cases (as detailed in Appendix F of the same document) seems quite irrelevant to me: you are questioning the DFSG-compliance of kanjidic (and by extension the package that includes it: tagainijisho) and as far as I can see, the whole content of the file `tagainijisho-[version number]/3rdparty/kanjidic2.xml', including the SKIP codes, are covered by the license stated at the top of the file: CC-BY-SA, which is DFSG-compliant. Hi Thibaut, looking at the link you sent, it seems that the “above conditions” are “KANJIDIC can be freely used provided satisfactory acknowledgement is made, and a number of other conditions are met”, which is quite vague. In addition, just below the part that you cited (“Jack HALPERN: The SKIP codes in the KANJIDIC file.”), there is “With regard to the SKIP codes, Mr Halpern draws your attention to the statement he has prepared on the matter, which is included at Appendix F.” To me, it appears that Appendix F, which has non-Free clauses, applies. Have you tried to contact the authors of KANJIDIC ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325131358.ga7...@falafel.plessy.net
Re: DEP-5 copyright names on a single line
Le Wed, Jun 04, 2014 at 02:10:08PM +0200, Daniel Pocock a écrit : In the DEP-5 doc http://dep.debian.net/deps/dep5/#copyright-field Any formatting is permitted years of publication for one copyright holder may be gathered together One thing is not mentioned explicitly: can multiple names be on the same line if the years are the same? E.g. https://github.com/arcticwaters/weupnp/commit/0d1f840b5cb646fb06f139462a5cf51a1fb4b97d contains this: Copyright: 2008-2014, Alessandro Bahgat Shehata, Daniele Castagna or is it mandatory to have one line per copyright holder? Hi Daniel, the machine-readable format does not forbid to collate everything on one line. Especially, for the package where you take the example, there are already upstream files where the two holders are on the same line of a copyright statement, so there is no problem at all. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140604121619.ga21...@falafel.plessy.net
Re: [PHP-QA] Debian and the PHP license
Le Tue, Jul 29, 2014 at 04:47:34PM +0200, Ferenc Kovacs a écrit : from the replies on the debian mailing lists it seems that this decision on dropping any project using the php license distributed outside of php-src is controversial to say the least. Hello Ferenc, from an outsider point of view (I do not maintain PHP packages in Debian), my impresssion is also that the removal of PHP packages is controversial. I guess you also saw the LWN article here: http://lwn.net/Articles/604630/ The good news is that things can resolve without formal decision: the immediate cause for removing some PHP packages from our Testing distribution (that represents our future release, not the Debian archive as a whole) is that bugs of severity serious were filed against them to represent the licensing question. If one closes these bugs or downgrade their severity, then the packages automatically (modulo a small delay) become part of Testing again. This already has been done for packages such as php-memcached, and could be done for others. Thank you for your patience ! -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140729223824.gc31...@falafel.plessy.net
Re: [PHP-QA] Debian and the PHP license
Le Wed, Jul 30, 2014 at 02:38:58PM +, Thorsten Glaser a écrit : That, too. But AIUI that licence also forbids us from shipping a modified version of PHP without rebranding (like Firefox(tm)). I think that we are ridiculing ourselves by ignoring the arguments that have been given to us by the PHP developers in the past. See, we are getting famous in Wikipedia: https://en.wikipedia.org/wiki/PHP_License#Debian_packaging_controversy Debian maintainers have had a long-standing discussion (since at least 2005) about the validity of the PHP license.[4] Expressed concerns include that the license contains statements about the software it covers that are specific to distributing PHP itself, which, for other software than PHP itself therefore would be false statements. I think that the situation is different: - It has been proposed by a developer to remove PHP modules licensed under the PHP license, in application of a policy that had been neglected for years. This proposition was eventually represented by release-critical bugs. - For some PHP modules, the bugs have been closed, and there was no further reaction. - In the meantime the usual vocal people sending the majority of emails on our mailing lists are giving the impression that removing PHP modules is a position of Debian as a whole, while it is definitely not. This drama can be ended by closing the remaining bugs and going back to work. This has been done for packages that some people care most, like php-memcached, and could be done for other packages. When things have cooled down, it can be proposed to correct the REJECT-FAQ according to current practice of accepting PHP-licensed code. Back to the question of rebranding, the PHP developers have already explained that because PHP is a three-letter word, they are not in a position to protect their name with a trademark. Therefore, they do it with a license. We can not take Mate and distribute it as “Gnome Plus”. We can not take a fork of PHP and call it “BetterPhp”. People can not take a Debian CD, add non-free software, and sell it as “Debian Enhanced”. We and other protect our names, and PHP does it too. I do not see a problem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140730230300.gb24...@falafel.plessy.net
Re: [PHP-QA] Debian and the PHP license
Le Fri, Aug 01, 2014 at 04:59:11PM +0100, Ian Jackson a écrit : Draft question for SFLC: Some members of the Debian project have some concerns about the PHP licence. These worries are dismissed by other members and by relevant upstreams. We would like some advice. Hello Ian and everybody, I think that it is important that a few of the ‘some members’ would identify themselves in support for that request, and explain what they would do if the worries expressed below turned out to be true. Among the Debian Developers, some have more stakes in the packages than others. Members of the FTP team may remove the packages or ask them to move to non-free; members of the release team can remove them from Stable and Testing; members from the security team can refuse to support the packages; the maintainers of the packages can orphan or abandon them. Lastly, any Debian Developer can start a General Resolution. If the only support for contacting lawyers comes from Developers who have the least stakes in the question (GR only), then we should really consider if the work that we are about to ask to the lawyers will be wasted in the trash bin instead of being seriously considered. Here are two other coments on the text itself. Q4. Does the fact that the PHP licence conditions about the use of the PHP name are contained in the actual copyright licence, rather than in a separate trademark licence, significantly increase the risks we would face if we had a disagreement with upstream about our modifications (or our failure to seek approval) ? Note that PHP does not hold a trademark on the PHP name and therefore can not grant a trademark license. Sadly we must consider in this context the fact that it does happen - thankfully rarely - that an upstream takes offence to something Debian does and attempts to revoke or renounce the licence or claim that the licence forbids. It is important to us that we can still, under such conditions, continue to distribute the software (perhaps under a different name), since we may have come to rely on it. It is important to note that clarifications on the PHP license have already been given by PHP developers. The question is then if they are free to revert their clarifications and use a new interpretation of their license to force Debian to stop distributing or modifying PHP and its modules. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140801231037.ga8...@falafel.plessy.net
Re: [PHP-QA] Debian and the PHP license
Le Sat, Aug 02, 2014 at 08:10:49AM +0900, Charles Plessy a écrit : I think that it is important that a few of the ‘some members’ would identify themselves in support for that request, and explain what they would do if the worries expressed below turned out to be true. Sorry for the extra mail; I just would like to clarify that by “Developers in support”, I mean: “Developers who think that the PHP license may be problematic”, not “Developers who think that calling lawyers will be an efficient mean to resolve the disagreements”. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140801235712.gb8...@falafel.plessy.net
Re: Upstream GPL-3+ vs debian/* GPL-2+
Le Tue, Aug 19, 2014 at 11:15:46AM -0300, Eriberto Mota a écrit : I have a doubt about a situation. The upstream source code is GPL3+. Packaging is a derivative work and I think that it must be GPL. So, GPL-3+, right? Or can the debian/* be GPL-2+? Dear Eriberto, if your packaging work contains copyrightable parts (note that some typical files in debian directories are definitely trivial and therefore non-copyrightable), then their license need to be compatible with the upstream sources if they are combined in the same work. The GPL-2+ is compatible with the GPL-3+, because the “+” means “or (at your option) any later version”. Without that clause, the GPLv3 and the GPLv2 are not compatible. Note that the importance is compatibility. You can definitely chose a more permissive license, like CC0, MIT, etc. if you wish so. Also, for works that are not combined with upstream sources (like a manual page written from scratch for instance), you can chose any Free license you like. But I think that it is best practice to pick the same license as the upstream work in such cases, so that you have better chances to contribute it upstream instead of keeping it as a Debian-only modification. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819214405.gb13...@falafel.plessy.net
Re: Upstream GPL-3+ vs debian/* GPL-2+
Le Thu, Aug 21, 2014 at 05:43:09PM +0100, Ian Jackson a écrit : Thanks a lot for your reply Charles. But I am a bit confuse... Is the debian/ a derivative work from upstream code? If yes, must be the license GPL-3+ or not? No, it is not a derivative work. (Except for debian/patches/ if you use that, but that's presumably not what you mean.) Yes, sorry for not being clear: by « if combined » I meant debian/patches. I agree with Ian that a permissive license is the most helpful in general. For the patches to upstream, while a permissive license will always be compatible, it may be better to use the same license as upstream, to simplify their work. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821220807.ga...@falafel.plessy.net
Re: Question about a custom license from dictconfig
Le Tue, Aug 26, 2014 at 03:44:02PM +0100, MJ Ray a écrit : Dariusz Dwornikowski wrote: I encountered this license while packaging (as in this file [1]). My questions is, what type of license is it, and is it DFSG compatible ? Please CC me, I am not on the list. [1] https://bitbucket.org/vinay.sajip/dictconfig/raw/53b3c32dea4694cd3fb2f14b3159d66d3da10bc0/src/dictconfig.py This looks close enough to MIT/Expat-style licensing that most of it seems to meet the DFSG. The only thing I'm not sure about is whether it's OK for other people also called Vinay Sajip to release changes under their own name. Anyone know? If not, then it fails DFSG. Hello everybody, non-advertisement clauses are very frequent and I have not seen that they cause a problem. Also, the license in question is already present in a large number of files in Debian. http://codesearch.debian.net/search?prev=q=the+name+of+Vinay+Sajip Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826211059.ga30...@falafel.plessy.net
Re: Public domain and DEP-5-compliant debian/copyright
Le Tue, Sep 16, 2014 at 11:18:11AM +0200, Florent Rougon a écrit : 1. I have files in a program with the following copyright statement: # Copyright (C) 2002-2010, 2013, 2014 ... # Copyright (C) 2000 ... # # This program is in the public domain. but, as I understand it, public domain is the absence of copyright... right? Would it be better to replace this with: # Contributors: 2002-2010, 2013, 2014 ... # 2000 ... # # This program is in the public domain. ? 2. With the following stanza in debian/copyright (DEP-5): Files: examples/* License: public-domain I get two lintian warnings, the first of which being missing-field-in-dep5-copyright for the Copyright field IIRC, and the second one being 'missing-license-paragraph-in-dep5-copyright public-domain'. Dear Florent, for the first point, please do not modify the upstream copyright statements unless you have the permission from the authors: it is more likely to create new confusions than to clarify the situation. For the entry in the machine-readable copyright file, since the information available suggests that the authors claim a copyright, I would just consider that “This program is in the public domain.” is the license of the file: Files: examples/* Copyright: (C) 2002-2010, 2013, 2014 author A (C) 2000 author B License: says-public-domain This program is in the public domain. Not elegant, but accurate. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916100412.gc2...@falafel.plessy.net
Re: Public domain and DEP-5-compliant debian/copyright
Le Fri, Oct 10, 2014 at 06:50:49PM +0200, Florent Rougon a écrit : [ Remainder: this thread is about a file whose copyright/licensing statement is of the form: # Copyright (C) 2002-2010, 2013, 2014 ... # Copyright (C) 2000 ... # # This program is in the public domain. It has been established by the mavens from this list that the copyright statements contradict the public domain assertion, and that simply stating This program is in the public domain is not enough to make it so in general. As a consequence, I am trying to have the file relicensed under a proper license such as BSD-2 or BSD-3. I have also taken note of the suggestions given here about the Apache Software Foundation License 2.0 (which I am still considering) and the CC-0, thank you. ] Sorry for the little delay. I have recently tried to contact the person who is most likely, appart from me, to legitimately own some copyright over the file in question in this thread, namely demo.py from pythondialog (python-dialog in Debian). This person has been friendly in the past, there is no problem on this side, however time is pressing because of the imminent freeze of jessie and I am therefore considering the other alternative. Hello Florent, you can decouple the two issues: - The package is totally redistributable in Debian as it is, you do not need to relicense the files to update to the new upstream release. - You can work on the resolving the apparent contradiction at the pace you want, you can even consider it a wishlist, “patch welcome” issue only. Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141011003846.ga14...@falafel.plessy.net
Re: License of binary packages
Le Thu, Nov 13, 2014 at 05:35:00PM +0100, Ole Streicher a écrit : I asked this question already some months ago in debian-mentors, but didn't get an answer: How is the license of a binary Debian package determined? The file debian/copyright only contains the license of the sources; however the binary license may differ -- f.e. when a BSD source is linked to a GPL library. Also there is usually more than one license used in the sources. Hi Ole, in some packages I maintain, I put such information in the debian/copyright file (in the License field of the header, as I am using the machine-readable format). However, it is not canonical, nor automated. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113223947.ga23...@falafel.plessy.net
Re: Python library under permissive GPL-compatible license optionally using GPL library
Hi Yaroslav, Le Fri, Dec 12, 2014 at 12:07:41PM -0500, Yaroslav Halchenko a écrit : If we have a library X in Python, released under some GPL-compatible license (e.g. BSD-3 or Expat) and then using (optionally) some GPL code (at run time) provided by another library Y -- what are the implications? Am I wrong on any of the following statements - the project X codebase doesn't have to be relicensed to GPL Right - the project X can use project Y (since under GPL compatible license) Right. Much of the GPL is about redistribution, not use. - It is only at 'run time' when actual linking to the library Y happens, so project must comply with GPL but whose responsibility it is then and what needs to be enforced? - original distributor of X must have provided all the sources with modifications? But it was user's decision to use GPL'ed library If the distributor of X distributes only X and asks the users to do all the extra work, then it does not have to redistribute the sources of Y. - or user must somehow make sure he has the sources... (sounds dubious) Indeed. - is mere ability to be used with GPL licensed library Y makes distributors of code of X required to comply with GPL? (e.g. provide modified sources) No, but the distributors of X would start to have obligations if they would distribute X and Y together, for instance as a binary form. In the case of Debian, since our archive contains the source packages, package-X can depend on package-Y or contain code derived from package-Y without needing extra work on the redistribution. (Of course, the maintainer of package-X has to ensure that liceses are compatible). [1] http://mail.scipy.org/pipermail/nipy-devel/2014-December/010707.html If a third party download X and Y from their original distributors, and redistribute the combination as binary code without the source, then they will violate the GPL. Thus, even if X is their main interst, if they download Y because X needs it, they need to read Y's license. If X provides some download scripts for Y, it would be kind to write somewhere in the documentation that Y is GPL-licensed. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141213001602.gc26...@falafel.plessy.net
Re: Makefile.in.in license
Le Sat, Jan 31, 2015 at 07:15:11AM +1100, Riley Baird a écrit : I have no idea how to interpret the below license: This file file be copied and used freely without restrictions. It can be used in projects which are not available under the GNU Public License but which still want to provide support for the GNU gettext functionality. Please note that the actual code is *not* freely available. I found this license while I was writing the d/copyright for the granule package[1], but it's also in the gtk+2.0 package[2]. Hi Riley, a quick search trough the other source packages in Debian shows that this file is present in many of them. http://codesearch.debian.net/results/file%20file%20be%20copied/ Therefore, empirically it is DFSG-free. My impression about this license is that it might be intended as a joke. So if the copyright holder declines to relicense, you can probably ignore the problem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150130232546.gc14...@falafel.plessy.net
Re: Consensus about the Academic Free License (AFL) v3.0
Le Wed, Jun 10, 2015 at 11:48:19PM +0200, Francesco Poli a écrit : Hello debian-legal regulars, I would need to ask your consensus opinion on the non-freeness of the Academic Free License (AFL) v3.0. Hi Francesco, I think that there is a broad consensus to accept the AFL as Free license, in Debian, the OSI, Fedora, the FSF, etc. Its wording is often poorly chosen, but I think that the consensus is to conclude in favor of the Free interpretation. Here are a few comments about the license. - point 3) is poorly worded, but assuming it is well-intented, it is Free. - regarding points 5) and 9), the FSF notes that the AFL has clause similar to one of the Open Software License that requires distributors to try to obtain explicit assent to the license (http://www.gnu.org/licenses/license-list.en.html#OSLRant). This is easy to infringe, but this is not forbidden by the DFSG (which is why we tolerate advertisement clauses, which are also easy to infringe). - The Attribution Notice sounds a bit like an invariant section, but it is also very similar to the NOTICE file from the Apache License, which is Free. Altogether, I think that #689919 should stay closed, although it would be great of course if the Subversion authors would manage to elimiate this license from their sources, because this license is not a good example to follow. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150610234107.gd15...@falafel.plessy.net
Re: GPL + question
Le Fri, May 29, 2015 at 09:32:12AM +0200, Ole Streicher a écrit : I just had a discussion with an ftp-master who rejected one of my packages. The package in question is missfits. It contains a directory, src/wcs/ with files that were originally released by Mark Calabretta under LGPL-2+, but changed by the upstream author (Emmanuel Bertin) and released in the package under GPL-3+. debian/copyright currently mentions only GPL-3+ for the whole package. The ftp-master now asked me to add GPL-2+ for these files to debian/copyright. But I think that this would be wrong, since the files under src/wcs are not distributable under GPL-2+ (because they contain GPL-3+ code from Emmanuel Bertin). Do I miss an important point here? Hi Ole, I am also surprised by this request (isn't there a typo with a L missing in front of GPL-2+ ?). The README in src/wcs contains: This directory contains a modified version of the WCSlib V2.2 library by Mark Calabretta mcala...@atnf.csiro.au, released under the GNU Lesser General Public License. The original version was downloaded from ftp://ftp.cv.nrao.edu/fits/src/wcs/. See http://www.atnf.csiro.au/people/mcalabre/WCS/wcslib for more details. Here, the author of missfits says that he modified the copy of the WCSlib that he redistributes with the sources of missfits. In addition, he added a GPLv3+ header on top of each file. Unfortunately, WCSlib version 2.2 is so old that I could not find a pristine copy on the Internet to confirm that each file was really modified. If it were me, I would give the benefit of the doubt to the upstream author of missfits, and trust him that if he added a GPLv3+ header, it is because he modified the files, as he says in the README. In that case, the license to be indicated in debian/copyright should be GPLv3+. Have a nice week-end, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150529231946.gd4...@falafel.plessy.net
Re: DFSG-ness of two
Le Sat, May 30, 2015 at 11:26:59AM +1000, Riley Baird a écrit : - 3. You may not have any income from distributing this source -(or altered version of it) to other developers. When You -use this product in a comercial package, the source may -not be charged seperatly. This clause is really annoying, but it seems to allow the file to be sold as part of a commercial package. Hence, it could perhaps be considered to meet DFSG#1. But a developer doesn't have the freedom to sell the software for profit to other developers. Hi Riley, as suggested in the original question, this clause is similar to clause 1 of the SIL Open Font License 1.1, which is DFSG-Free. Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150530014604.gf4...@falafel.plessy.net
Re: DFSG-ness of two
Le Sat, May 30, 2015 at 11:26:59AM +1000, Riley Baird a écrit : - 3. You may not have any income from distributing this source -(or altered version of it) to other developers. When You -use this product in a comercial package, the source may -not be charged seperatly. But a developer doesn't have the freedom to sell the software for profit to other developers. On Sat, 30 May 2015 10:46:04 +0900 Charles Plessy ple...@debian.org wrote: as suggested in the original question, this clause is similar to clause 1 of the SIL Open Font License 1.1, which is DFSG-Free. Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. Le Sat, May 30, 2015 at 11:58:06AM +1000, Riley Baird a écrit : The second sentence is similar to the Open Font License, but I was talking about the first sentence. Hi again, The two sentences can not be dissociated: the second sentence gives as much freedom as in the SIL OFL 1.1, regardless of the restrictions in the first sentence, so altogether, the clause 3 quoted above is DFSG-Free, if we agree that the SIL OFL 1.1 itself is DFSG-Free. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150531000831.ga26...@falafel.plessy.net
Re: DFSG-ness of two
Le Sun, May 31, 2015 at 11:04:32AM +1000, Riley Baird a écrit : - 3. You may not have any income from distributing this source -(or altered version of it) to other developers. When You -use this product in a comercial package, the source may -not be charged seperatly. The two sentences can not be dissociated: the second sentence gives as much freedom as in the SIL OFL 1.1, regardless of the restrictions in the first sentence, so altogether, the clause 3 quoted above is DFSG-Free, if we agree that the SIL OFL 1.1 itself is DFSG-Free. The second sentence is restricted by the first sentence. Within the meaning of the license, a commercial package does not include source sold to other developers. That is a different interpretation than mine, and it might be useful to confirm with the original author if this is what he intended. In any case, Debian already redistributes software licensed under these terms in fpc_2.6.4+dfsg-5/fpcsrc/packages/regexpr/src/regexpr.pas and lazarus_1.2.4+dfsg2-1/components/synedit/synregexpr.pas (thanks, codesearch.debian.net), so either this was overlooked, or the interpretation taken by the FTP team is that the second sentence solves the problem introduced by the first. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150531013253.ga11...@falafel.plessy.net
Re: Is mpage DFSG compatible?
Le Sun, Oct 18, 2015 at 06:23:50PM -0200, Eriberto Mota a écrit : > > When migrating the debian/copyright file to 1.0 format, I did a full > revision in source code and I found two doubtful situations for me. > > The first issue is the license used by mpage: > > * Permission is granted to anyone to make or distribute verbatim > * copies of this document as received, in any medium, provided > * that this copyright notice is preserved, and that the > * distributor grants the recipient permission for further > * redistribution as permitted by this notice. > > IMO, this license doesn't allow modify the source code. So, this > license is inadequate. > > The second issue is the license of the Contrib/mfix/test.ps file: > > % Copyright (c) 1986-89, ArborText, Inc. > % Permission to copy is granted so long as the PostScript code > % is not resold or used in a commercial product. Hi Eriberto, just a side comment since you already had a lot of good answers. When encountering strange license terms, I always look for them in codesearch.debian.net. It can either suggest that the license is not problematic (for instance if it is found in a large number of high-profile packages), or it gives the opportunity to correct the error archive-wide. In the case of mpage, the lines "distributor grants the recipient permission for further" and "Permission to copy is granted so long as the PostScript code" are not found in any other package; good ! Cheers, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Source files
Le Wed, Oct 14, 2015 at 11:47:02PM +0200, Francesco Poli a écrit : > > I am personally convinced that nowadays the definition of source should > *no longer* be regarded as an open question: I think that the most > commonly used and accepted definition of source code is the one found > in the GNU GPL license. Hi Francesco and everybody, sorry for drifting that thread further... I can not help adding that, the world being in perpetual change, the definition of source will one day become an open question again. My favorite guess is that at some point, it will be argued that the commit messages and the revisions of a file are part the source, since inspecting them is part of the "preferred" way to modify the file. But we are not there yet... Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Source files
Le Mon, Oct 12, 2015 at 11:49:03AM +0200, Ole Streicher a écrit : > > For one of my packages (python-astropy), I got a Lintian error that it > would contain a non-source file jquery.dataTables.js. This is mainly > discussed in a bug report > > https://bugs.debian.org/798900 > > however it seems that the problem is more general. The python-astropy > package indeed contains a file jquery.dataTables.js, which for me, > however, looks like a good source: It is well readable, it contains > comments, etc.: > > https://sources.debian.net/src/python-astropy/1.0.4-1/astropy/extern/js/jquery.dataTables.js/ > > However, it contains one line > > /*globals $, jQuery,define,_fnExternApiFunc,[...] > > which is ~1400 characters long and may be automatically inserted. This > line is now taken by lintian as indication that the file is not a source > file. Aside from the question whether this heuristics is too simple, I > am now curious on how a "source" is defined in the Debian context. Is it > f.e. required that every single character was inserted manually? Or that > at least some of the content was created manually? Hi Ole, looking at the upstream work on GitHub (https://github.com/DataTables/DataTablesSrc), I see that the long line is changed from time to time in commits that change other lines as well. Therefore, it does not look like jquery.dataTables.js is an autogenerated file. Maybe the long line was machine-generated at the beginning, but it does not matter anymore. By all means, the file is regularly edited like any as a source file. And by the way, while anybody is free to disbelieve that a file is a real source file, the only persons whose judgement really matter on that subject are the members of the FTP team. So you are free to disagree with random bug reporters, and they are free to escalate it if they are not convinced by your arguments, but in the meantime, Debian's point of view is that the file is source unless the contrary has been demonstrated, given that it has passed the screening of the FTP team when it entered our archive. You can also add Lintian overrides if the Lintian maintainers are uncooperative. Thanks for your hard work, and have a nice day, Charles Plessy -- Charles Plessy Tsurumi, Kanagawa, Japan
