Re: hard linking libboost copyright files
On Sun, Feb 04, 2024 at 10:50:43AM +, Muhammad Yaaseen wrote: > The question is once we install the libboost .deb packages into a system, > the copyright file for each libboost package is stored separately in > /usr/shared/doc/packages folder. I'm think of hardlinking these copyright > files so that we same some memory. Is this legally allowed. Sorry, but this is also not a mailing list for providing legal advice to end users. If you are concerned about the legality of what you are doing downstream of Debian, you should consult your own lawyer. > -Original Message- > From: Steve Langasek > Sent: Sunday, February 4, 2024 3:07 PM > To: Muhammad Yaaseen > Cc: debian-legal@lists.debian.org > Subject: Re: hard linking libboost copyright files > > On Sun, Feb 04, 2024 at 05:38:57AM +, Muhammad Yaaseen wrote: > > > we see that the copyright for libboost debian packages are 2MB each > > and are all the same. as per > > https://www.debian.org/doc/debian-policy/ch-docs.html section > > 12.5<https://www.debian.org/doc/debian-policy/ch-docs.html%20section%2 > > 012.5> we are not allowed to create symbolic links. the doubt I have > > is whether I can hardlink these files and reduce the memory > > utilization. > > This isn't really a legal question; as a practical matter, it is not possible > to ship cross-package hardlinks in .deb packages. > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: hard linking libboost copyright files
On Sun, Feb 04, 2024 at 05:38:57AM +, Muhammad Yaaseen wrote: > we see that the copyright for libboost debian packages are 2MB each and > are all the same. as per > https://www.debian.org/doc/debian-policy/ch-docs.html section > 12.5<https://www.debian.org/doc/debian-policy/ch-docs.html%20section%2012.5> > we are not allowed to create symbolic links. the doubt I have is whether > I can hardlink these files and reduce the memory utilization. This isn't really a legal question; as a practical matter, it is not possible to ship cross-package hardlinks in .deb packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: UEFI Revocation List being distributed by Debian
Hi Mario, On Thu, May 07, 2020 at 02:25:41AM +, mario.limoncie...@dell.com wrote: > Hello, > Recently there has been a discussion within upstream fwupd to start > including the UEFI dbx revocation list directly with the fwupd package. > During the code review for this as part of reviewing the terms included > with it there are concerns if this would fit within the DFSG. Would it be > possible to request a review of these terms to determine if this is > appropriate to distribute in Debian? > https://uefi.org/revocationlistfile > Furthermore, if it is not acceptable to distribute this raw data in > Debian, one of the options being considered is to programmatically > re-generate a list of invalid hashes but without the signatures in the > original file. Would that be acceptable to distribute in Debian instead? First, the license is not an end-user license and if someone chooses to agree to the license as part of downloading, this appears to only be binding on the downloader; it is not a license that must be included in the redistribution to users (as debian/copyright). Second, the following URL is accessible without affirmatively agreeing to the license. http://www.uefi.org/sites/default/files/resources/dbxupdate.zip Third, the contents of this file are a non-copyrightable list of statements of mathematical facts. Distribution of this file is not subject to copyright law. I don't think there is any issue with Debian distributing this file. FWIW Ubuntu already distributes this file in the secureboot-db package. I do not think that Ubuntu would want to enable updates of the revocation list via the fwupd package since revocations could in principle impact the bootability of the system (if the dbx update included a hash of Ubuntu's shim, or Ubuntu's signing key). dbx updates should be carefully managed in conjunction with updates to the bootloader itself, which the tighter coupling of a directly-managed native package gives us. I think similar reasoning would apply for Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: FRR package in Debian violates the GPL licence
Hi Paul, On Wed, Mar 20, 2019 at 10:54:12AM +, Paul Jakma wrote: > On Wed, 20 Mar 2019, Ole Streicher wrote: > > Those files do not use GPL code; they just refer to it. No line of that > > code was originated in GPL licensed code. > Ah, you're in the "copyright only protects literal copying" camp, and you > don't acknowledge the concept of derived works. > There's little point discussing further with you, if so. What is the point of this discussion, in general? debian-legal is a public mailing list where individual Debian Developers (and non-Debian Developers) opine on questions of licenses, with no legal authority. Even if you manage to persuade some number of people here that your position is correct, that doesn't translate to a change in Debian's position on shipping the package in question. You can file a severity: serious bug against the package and ask the Debian FTP team to intervene; if they agree with you the package would be removed. If you believe there is a license violation that needs to be addressed even if the Debian ftp team don't agree with your and your lawyer's interpretation of copyright law, then you should probably be having your lawyer get in touch with Debian, and Debian's lawyers will review and respond, and the matter will be adjudicated via the legal system - not via an opt-in mailing list. But as for the substance of your claim, what you are doing here is asserting copyright on an interface. While there has been recent notable case law in certain jurisdictions which wrongly supports the notion that interfaces contain sufficient creativity to be copyrightable, that is an incredibly toxic precedent to set in the Free Software world. > Copyright gives authors of works not just the right not to just control > literal copying, but also a controlling right in any adaptations of their > work (amongst other things). Whether you agree with this or not, various > variants of this concept are law in many countries around the world. Coding to an interface is not "adaptation" of a copyrighted work. Your interpretation of copyright law is inconsistent with how Debian has operated for over 20 years, and I do not expect Debian to cede this position without lawyers getting involved, or for Debian to be willing to distribute any of your code, as part of frr or otherwise, at the end of the process. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]
On Fri, Apr 27, 2018 at 07:34:37PM -0400, Sergio Durigan Junior wrote: > [ Adding debian-legal to the Cc list. ] > On Friday, April 27 2018, Fabian Wolff wrote: > > Dear mentors, > > I am looking for a sponsor for a QA upload of the link-grammar > > package. > [...] > > The package is available on Mentors: > > https://mentors.debian.net/package/link-grammar > So, here's the other thing I noticed. d/copyright doesn't seem to be > up-to-date. Also, I don't see any mention about the "debian/" directory > on d/copyright, which might be a problem. I understand the package is > already at this state, but I think it may be a good idea to fix it. > First, I'd recommend re-checking d/copyright and making sure new > copyrights are properly listed. I've found a few notices mentioning > 2017/2018, so it's a good idea to list them. I understand this is a > very boring task, but it's something we take seriously at Debian. > As for the "debian/" directory, I *think* it should be enough to list > everybody who has ever touched the debian/ directory. I used the > following one-liner to get a formatted list: > $ git log --date="format:%Y" --format="Copyright %ad %an <%ae>" debian/ | > sort -u > Copyright 2009 Ken Bloom <kbl...@gmail.com> > Copyright 2010 Ken Bloom <kbl...@gmail.com> > Copyright 2011 Ken Bloom <kbl...@gmail.com> > Copyright 2015 Wookey <woo...@wookware.org> > Copyright 2016 Gianfranco Costamagna <costamagnagianfra...@yahoo.it> > Copyright 2016 Gianfranco Costamagna <locutusofb...@debian.org> > Copyright 2016 Jeremy Bicha <jbi...@linux.com> > Copyright 2016 Jeremy Bicha <jbi...@ubuntu.com> > Copyright 2017 Adrian Bunk <b...@debian.org> > Copyright 2017 Jeremy Bicha <jbi...@ubuntu.com> > Copyright 2017 Steve Langasek <steve.langa...@ubuntu.com> > Copyright 2018 Fabian Wolff <fabi.wo...@arcor.de> > > After massaging a bit: > Copyright 2009-2011 Ken Bloom <kbl...@gmail.com> > Copyright 2015 Wookey <woo...@wookware.org> > Copyright 2016 Gianfranco Costamagna <locutusofb...@debian.org> > Copyright 2016-2017 Jeremy Bicha <jbi...@ubuntu.com> > Copyright 2017 Adrian Bunk <b...@debian.org> > Copyright 2017 Steve Langasek <steve.langa...@ubuntu.com> > Copyright 2018 Fabian Wolff <fabi.wo...@arcor.de> > So I think it should be enough to put these lines there. As for the > licence... Well, I'd choose the same licence as the package, although > if we are to be pedantic here, the right thing would be to get in touch > with everyone above and getting their confirmation. I don't know... > Anyway, I am copying debian-legal here, hoping that someone more > knowledgeable can shed some light. I happened to notice my name in this list, which exposes a flaw in this methodology. My sole mention in the changelog of this package is: * Apply patch from Steve Langasek adding the missing test dependency on default-jdk. (Closes: #865902) First, the full diff is 'https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=865902;filename=link-grammar_5.3.16-1ubuntu1.debdiff;msg=5'. This is "obviously" not copyrighted by me under US copyright law; it is a single line change, which was copy-pasted from debian/control and is purely functional with no creativity (the only possible "creativity" is the ordering of the test dependencies and this is uninteresting). Second, in the case that a change *is* copyrightable, it is not reasonable to assume that the person submitting a given patch is the copyright holder. In the general case, patches that I submit to the Debian BTS from my @canonical.com address would be copyright my employer, not me personally. I don't think you should be taking it upon yourself to add copyright statements regarding debian/ contents where authors have not asserted their copyright up front. There is precious little in debian/, outside of debian/patches/, which should generally be considered copyrightable in a well-done package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: your mail
Hi Jennifer, On Tue, Sep 20, 2016 at 09:45:17AM -0400, Jennifer Nielsen wrote: > I believe my personal, private data( photos, videoing, watching, recording > audio, etc.) Has been tampered with, and placed on the Debian FTP site, > without my permission or knowledge. Your copyright permission notice states > that without permission from me it becomes a copyright, patent issue. I > believe that money has been involved in distribution of it. If you have > advice for me or a way to help, I greatly appreciate it! Thank u I think you must have misunderstood something. The Debian FTP site is this: http://ftp.debian.org/debian/ This site is used to distribute the Debian operating system, which is Free Software. No private data is distributed from this site. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: TPP 14.17
On Sat, Nov 07, 2015 at 11:53:23AM +1100, Glenn McGrath wrote: > hmm, i would equate copying with distribtion, but i guess im old and rusty; > > Where am i going wrong with this line of thinking > > 1. The GPL requires the ability to distribute source code to those you > distribute binaries to. > 2. This clause says; No Party (Country) can require the transfer of ... > source code of software owned by a person of another Party (Country) as a > condition for the ... distribution ... of such software in its territory. > Assume i copy a Debian install CD and give it to my neighbour, i am > obligated to make the Source code available to them for the GPL'ed parts. > The source code will be "software owned be a person of another Party" > So no party can require me to uphold my obligation make source code > available in its territory. > Meaning, nobody can force me to give the source code to my neighbour. No. The TPP is a horrible treaty and no country should ratify it; however, the above text doesn't prohibit free software. It says that a *party to the treaty* (country) cannot oblige another party to provide their source code as a condition of distributing in its territory. In the case of free software, the country is not imposing a requirement to make source available; it is only enforcing the *software license's* requirement to make source available. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Upstream pointing to COPYING file in headers
On Sat, May 02, 2015 at 11:52:13AM +1000, Ben Finney wrote: Eriberto Mota eribe...@debian.org writes: --- (C) 2007-2009 Lluís Batlle i Rossell Please find the license in the provided COPYING file. --- That is an assertion of copyright without a grant of license. Nonsense. There is no ambiguity here at all, it tells you exactly where to find the license. However, you are right that it is *not* a correct license grant for GPLv2+, only for GPL2. This is inconsistent with the license statement on the website. I advise you make efforts to convince the copyright holder to follow the guidance in the COPYING document on “How to Apply These Terms to Your New Programs”. What they have is needlessly ambiguous. Agreed. Since the website expresses intent to license under GPLv2+, they should include this in the source files as well. Absent a clarification from upstream, I would take the conservative approach of treating this as a GPL2 (not GPL2+) work for debian/copyright. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: trademark vs. renamed derivates
On Mon, Jul 21, 2014 at 05:24:28PM +0200, Thorsten Glaser wrote: Hi everyone, is there any example language for something like the following around already, which I could reuse? “This software Y is based on the software X, which was written by the company Z; both X and Z are trademarks, but Y is not, nor do we intend to use these trademarks (which is why we renamed it in the first place), but we mention this because this is a derivate and we want/must name the initial developers, but don't want to infringe on their trademarks either, so what do we do?” Stating the origin of the code is not a trademark infringement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Sources licensed under PHP License and not being PHP are not distributable
On Thu, Jun 26, 2014 at 01:54:37PM +0200, Frederic Peters wrote: Hello Ondřej, hi -legal, One more note: PHP is *not* compatible with GPL[1]. If you have sources that combine PHP-licensed source with GPL-licenced source the result is not distributable. That includes linking GPL library to PHP licenced source (e.g. libreadline as most notable example of GPL library). Do I read this correctly as there is a problem with any PHP binding to a GPL library? If there's a problem, would it be enough to add an exception to the library, just like it happens with OpenSSL? If you are the copyright holder of the GPL library, you can add an exception permitting the library to be linked into a plugin for PHP. However, unlike the OpenSSL exception, which is an exception about allowing GPL apps to be distributed together with libraries they've been written to use, the exception you describe gives people permission to use the GPL software from GPL-incompatible language runtimes. I don't think anyone who licensed a library under the GPL (mainly the FSF) would have any reason to grant such an exception. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: packaging reverse engineered code when an EULA forbids this
Hi Julian, On Tue, Jun 03, 2014 at 11:21:08PM +0200, Julian Taylor wrote: hi, I was asked by ftp-masters to clarify the status of some files in the scipy package [0] The files are are simple serialized numeric arrays created by the proprietary program IDL. They are used as testcases for a reverse engineered implementation the de/serialization in the python scipy package. The data in the files are just a couple random numbers in a certain format and should not fall under any copyright. The issue seems to be that reverse engineering is not allowed by IDL's EULA as the files contain following header: IDL Save/Restore files embody unpublished proprietary information about the IDL program. Reverse engineering of this file is therefore forbidden under the terms of the IDL End User License Agreement (IDL EULA). All IDL users are required to read and agree to the terms of the IDL EULA at the time that they install IDL. Software that reads or writes files in the IDL Save/Restore format must have a license from ITT Visual Information Solutions explicitly granting the right to do so. In this case, the license will be included with the software for your inspection. Please report software that does not have such a license to ITT Visual Information Solutions (i...@ittvis.com). The io code itself is DFSG free. Is there any issue in packaging and distributing this code and these simple testcase? A user may not be able to use the code legally, but on the other hand he/she probably also never accepted IDL's EULA as IDL is not being used. To me this notice hardly has any legal relevance at all and should not be an issue for packaging. I have inquired upstream about this and according to a comment in the source it was apparently written with permission of ITT Visual Information Solutions, but the exact correspondence has not turned up yet. A couple points here: - In many jurisdictions (definitely in the US, and IIRC in the EU), prohibitions on reverse engineering are null and void. - In the event that such a prohibition on reverse engineering does have legal force, the author would be in violation of the EULA; but this does not imply that, once created, there is any liability on the part of the distributor or the user. We should not a priori block software from inclusion in Debian just because it has been reverse-engineered in apparent contravention of an EULA. It's for the courts to determine if such a work infringes copyright of the original. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: CAcert Licensing and Inclusion in Debian main
Michael, On Tue, Apr 01, 2014 at 09:58:33PM -0500, Michael Shuler wrote: I have reopened #687693, as I believe that I was in error by ignoring the CAcert Root Distribution License. I closed that bug in order to maintain status quo, but have continued to feel that I was wrong in doing so, based on several points in the Social Contract. I am seeking a legal determination on whether the CAcert RDL follows the DFSG or is non-free. Additional questions about CAcert's inclusion in ca-certificates were raised in #718434. As a result of those questions and history, Ubuntu removed CAcert's root certificates from ca-certificates and nss in LP: #1258286. Prompted by Ubuntu's removal, my understanding that that redistribution did not follow DFSG, and the other issues presented, I removed the CAcert root certificates from ca-certificates. #741561 is seeking a possible re-introduction of CAcert's roots in Debian and would require proper judgement on licensing, prior to proceeding. I am familiar with the premise that SSL certificates may be seen as un-copyrightable, however, CAcert has (I assume with legal advice) intentionally burdened their root certificates with a license which claims copyright, as well as, by several opinions, verbiage that makes it non-free. I strongly believe that ignoring the CAcert RDL, in order to maintain status quo, is not the ethical thing to do for Debian, and I would enjoy some legal guidance. Thanks for your time. https://bugs.debian.org/687693 http://www.cacert.org/policy/RootDistributionLicense.php https://bugs.debian.org/718434 https://bugs.debian.org/741561 Facts are not copyrightable. Period. Stupid, unenforceable, scaremongering license texts attached to factual data (of which an SSL certificate is a veritable mathematical definition) should be ignored. If there's a reason to include the certificate in question in Debian, you should feel free to do so, ignoring any license claims. If it is not copyrightable, then you are not bound by any purported license - and therefore it cannot fail the DFSG. This is entirely separate from the question of whether they should be included in the ca-certificates package, or enabled by default. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: FYI: debian-legal is discussing the inclusion in the Debian archive of erotic interactive fiction depicting the sexual abuse of children
On Fri, Mar 14, 2014 at 03:30:38AM -0700, Vincent Cheng wrote: Due to the above, I'm going to be watching the progress of Unteralterbach's packaging very closely in the coming months, as well as opposing this every step of the way. If this actually makes it into the NEW queue, I have no hesitation on raising this issue again on -devel and -project, and/or all other steps available to me as a DD to oppose this (e.g. on the remote chance that this actually passes through the NEW queue, I'll forward this issue to the tech-ctte, and sponsor a GR to get Unteralterbach removed from the archive if need be). To save you time there, I'll point out now that I don't believe the TC has any authority to rule on this question. There is no technical question here, only political and legal ones. The correct avenues of appeal are to the ftp masters, the DPL, and the project through a GR. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: FYI: debian-legal is discussing the inclusion in the Debian archive of erotic interactive fiction depicting the sexual abuse of children
On Thu, Mar 13, 2014 at 11:17:00AM +0100, Johannes Schauer wrote: This discussion might not be the last one about inclusion of content (pornography, violence, theory of evolution, bdsm, lgbt or whatever else one might find offensive) in Debian which is in some way illegal in one or more jurisdictions. I didnt hear a word from ftp-masters on this yet but if content can't be included in main because then Debian's redistribution would be forbidden in a great number of jurisdictions, then why not create a new archive area for such content? Because it is not Debian's mission to distribute all the bits. We were all very glad when we were able to get rid of the non-US archive, a decade ago - and that was an archive for *very important* software that was essential to security on the Internet (including, among other things, ssh and gpg). There's no way that Debian should bring back per-country archives for something less important than this - and certainly not for game content that will by some people (and not necessarily just by those seeking to suppress it) be seen as an endorsement of behaviors that violate people's human rights. Even if we had volunteers to work on this, the Debian project should refuse their efforts and steer clear of this issue. See also https://lists.debian.org/debian-project/2014/03/msg00145.html. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [License-review] Chroma license / United States Government Contract
On Tue, Dec 17, 2013 at 07:59:14AM +1100, Ben Finney wrote: Andreas Cadhalpun andreas.cadhal...@googlemail.com writes: Correct me if I am wrong, but I think that if one uses the source of a GPL licensed program to build another program, this has to be distributed under the GPL as well. (Section 2. b) of the GPL) That's roughly correct; the act which requires licensing the whole work under GPL is to distribute a “derivative work” of the prior GPL-licensed work; see URL:https://en.wikipedia.org/wiki/Derivative_work. The corollary is that if the derived work is not distributed under terms compatible with the GPL, the recipient has *no* effective license in the work – and, indeed, the party redistributing has no license to do so, and is themselves violating the GPL of the prior work. If that is true, is it allowed to simply use the chroma source, as if the COPYING contained the GPL v2, or is it necessary to contact the author of chroma and request a change of the COPYING file? If their work is derived from a work they received under GPL, then “chroma” may be redistributed only under GPL-compatible terms (e.g., the GPL itself), otherwise they are violating copyright on the GPL-licensed work and “chroma” recipients have no effective license. There is no credible legal theory that would hold that the source of chroma is a derivative work of the bundled GPL sources. There is only an issue with distributing the bundled work if you distribute it as a binary. So this makes the package undistributable for Debian, but not necessarily for upstream. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: what but please really requires?
On Mon, Dec 16, 2013 at 09:55:22PM +0100, Samuel Thibault wrote: We would like to include a file in the jing-trang package, the licensing terms can be read on http://www.ascc.net/xml/schematron/ : “The Schematron software and this page are available for any public use, under the conditions of the zlib/libpng license (the least restrictive), but please mention our names in any documentation or About screens for any products that uses it.” What but please actually requires? I would tend to understand that it's just a wish from the author, not a licensing term, but IANAL. That's pretty unambiguously a polite request, not part of the license requirements. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: kamailio tls module and GPL openssl linking exception
Hi Victor, On Tue, Nov 12, 2013 at 11:22:08AM +0100, Victor Seva wrote: I'm the maintainer of the Kamailio package and I would like to push the inclusion of the openssl linking exception to upstream but I'm not sure about what parts of the upstream program should be changed in order to satisfy the GPL. Kamailio is a project with more that 10 years of existence and it's almost impossible to contact every single author of every single part of the program, but AFAIK it's quite possible to be able to add the exception to the core of the program. Kamailio runs with a core process that loads the user's configured plugins. The tls module is the only module that needs openssl to run. This module provides the ability to use a TLS transport and the core process is the one that creates and maintains the different transports. For sure that any plugin can use the provided transports, but all of them are using the core functions/structures to connect. They never connect directly to the tls module by themselves. Modules are being packaged by groups and the tls module will have it's own package. The kamailio program can be used without the tls module. Upstream is willing to add the openssl exception to core files but we want to be sure that this is enough to satisfy the GPL. The only bits of the code that you need an OpenSSL exception on are the bits that are linked to OpenSSL out of the box. However, the meaning of linked isn't the most obvious one. If you're only providing the tls module as an optional, never-installed-by-default plugin, then it's just a plugin and only the plugin code needs to have an OpenSSL exception attached to it. If, however, you are enabling the tls plugin *by default* - for instance, by providing a metapackage that pulls the two separate packages in together, or by having a Recommends: that automatically pulls the tls module in and automatically activates it - then effectively, you as the maintainers are creating the combined work which links against OpenSSL. You can then no longer rely on it being a plugin to keep it at arm's length, and you would need an OpenSSL exception on /all/ of the code. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: kamailio tls module and GPL openssl linking exception
On Tue, Nov 12, 2013 at 10:10:58PM +0100, Victor Seva wrote: Hi Steve, Thanks for your quick reply. 2013/11/12 Steve Langasek vor...@debian.org: If, however, you are enabling the tls plugin *by default* - for instance, by providing a metapackage that pulls the two separate packages in together, or by having a Recommends: that automatically pulls the tls module in and automatically activates it Ok. But in this case installing the module *by default* via Recommends will *not* get the module active nor loaded. The user has to change the default configuration file and explicitly activate the tls module in order to get the tls loaded. Is is then ok to have the tls module in Recommneds? In that case, yes: because combining the plugin into a single program is an action taken by the user (by modifying the config), not by the maintainer. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: debian patent policy?
Hi Paul, Forwarding your message on to debian-project, which is where project policies are discussed. On Fri, Sep 27, 2013 at 04:33:44PM -0500, Paul Elliott wrote: Policy Statement 1)Debian will not knowingly distribute software encumbered by patents; Debian contributors should not package or distribute software they know to infringe a patent. 2)Debian will not accept a patent license that is inconsistent with the Debian Social Contract or Debian Free Software Guidelines. 3)Unless communications related to patents are subject to attorney-client privilege, community members may be forced to produce them in a lawsuit. Also, patent concerns expressed publicly may turn out to be unfounded but create a good deal of fear, uncertainty, and doubt in the meantime. Therefore, please refrain from posting patent concerns publicly or discussing patents outside of communication with legal counsel, where they are subject to attorney-client privilege. This is very confusing. I have some ideas in my head that I am thinking about patenting, but I only want to torture the proprietary software people with it. I would certainly license all free software and free software users. But according to 1) that would not do any good, because 1) read literally means that if software is patented at all and software infringes on a claim, debian will have nothing to do with it. The key word here is infringe. Reading on a patent is not the same thing as infringement; if a piece of software implements a patent, but we have a valid license for that patent, that's not infringement. But 2) read conversely, implies that there could be a patent license that debian will accept. Yes, it must be a patent license that conveys to all downstreams the same rights that Debian is granted, and that transfers when the user exercises their freedom to create a (free) derivative work. After all, if debian accepted absolutely no patent licenses, the clause about inconsistant with the DSC or DFSG would be unnecessary, and 2) would read: Debian will accept no patent licenses. So what would a patent license consistant with DSC and DFSG look like? And what good would it do? 1) read literally means that if software infringes on the claims of a patent debian would have nothing to do with it, consistant license be damned. It is all very confusing. And 3 means I can't even ask anyone about this confusion. Can anybody clarify? 3) says not. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: OpenJDK 7.0 license question
On Wed, Sep 04, 2013 at 07:13:50PM +0200, Mathieu Malaterre wrote: [CC me please] Hi there, Could someone please clarify why OpenJDK 7.0 went to main with the following license: http://openjdk.java.net/legal/ - http://openjdk.java.net/legal/OpenJDK-TCK_SE7_27Dec2011.pdf As Walter notes, this appears to be the license for the TCK, which is not part of the OpenJDK that we ship. The TCK is not freely redistributable at all. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: data and software licence incompatabilities?
On Tue, Sep 03, 2013 at 08:04:20AM -0500, Gunnar Wolf wrote: Steve Langasek dijo [Mon, Sep 02, 2013 at 08:13:30PM -0700]: So, my request is for you _not_ to ban him, but for Francesco to tone down. Yes, this might re-escalate later on, and things might be re-evaluated. But talking about banning him _now_ is IMO too soon, too harsh. There is nothing soon about this. I have been telling Francesco for *years* to stop pushing his personal agenda on this mailing list, and it was a mistake on my part to not follow up with the listmasters sooner. The fact that he is a prolific poster who is otherwise knowledgeable makes the effect of his misuse *worse*, not better. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: data and software licence incompatabilities?
On Tue, Sep 03, 2013 at 03:29:27PM +0900, Charles Plessy wrote: 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. You are missing the point. The problem is not that such content annoys regulars. The problem is that people who are *not* regulars, including both Debian maintainers who are only casually involved in licensing questions and upstreams who are seeking advice about how to get their software into Debian. This list is the face of Debian to the outside world on licensing questions. Francesco has shown he is not willing to leave his personal opinions aside on this list; we should therefore not allow him to act as part of Debian's face. If Debian bans Francesco from this list, I will fee very ashamed of us. If Debian fails to ban Francesco from this list, the list should be disbanded. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: data and software licence incompatabilities?
On Tue, Sep 03, 2013 at 11:08:17AM -0700, Steve Langasek wrote: On Tue, Sep 03, 2013 at 03:29:27PM +0900, Charles Plessy wrote: 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. You are missing the point. The problem is not that such content annoys regulars. The problem is that people who are *not* regulars, including both Debian maintainers who are only casually involved in licensing questions and upstreams who are seeking advice about how to get their software into Debian. ... are bombarded with such statements. This list is the face of Debian to the outside world on licensing questions. Francesco has shown he is not willing to leave his personal opinions aside on this list; we should therefore not allow him to act as part of Debian's face. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: data and software licence incompatabilities?
Dear Listmasters, Francesco Poli has been a longtime subscriber to the debian-legal mailing list. He has quite extensive knowledge about licensing, and is often the first person to answer inquiries about new licenses sent to the list. However, he also consistently, repeatedly uses the list to tell people about his personal positions on licenses where these disagree with the position taken on behalf of the project by the Debian ftp team. He has done this for years, and for years people (including myself) have been asking him to stop. Francesco Poli is not a Debian Developer. His refusal to stop using debian-legal as a soapbox for telling everyone who asks a question about licenses about how he thinks the ftpmasters are wrong is an abuse of this list which makes the list significantly less useful for its *intended* purpose of examining new licenses, promulgating license information to new packagers and upstreams, and discussing questions of the overall legality of software in Debian. By making his disagreement with the ftpmasters the subject of any thread in which the pertinent licenses are discussed, he sows confusion about the status of these licenses, whose status in Debian is otherwise not at all ambiguous. Since Francesco has made it clear that he has no intention to stop his abusive use of debian-legal (see below) or even recognize why his behavior is problematic, I am asking the listmasters to ban him from this mailing list. Francesco, if you want to get Debian to *change its position* on licenses where you think an error has been made, please start a discussion in an appropriate forum such as debian-project and Cc: the ftp team. debian-legal is not and never has been the place to get changes made to the policy for the ftp archive, and your continued use of the list for espousing your *personal opinion* on questions that have been settled *for years* from the project's perspective is actively harmful and must stop. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org On Sat, Aug 31, 2013 at 03:46:32PM +0200, Francesco Poli wrote: On Tue, 27 Aug 2013 14:37:24 -0700 Steve Langasek wrote: [...] You have a right to your own opinion. You do *not* have a right to express it *on this list*. The purpose of this list is to provide guidance to maintainers and upstreams regarding *Debian's* definition of free software, as well as guidance regarding the *legality* of particular combinations of works. You using the list as a soapbox for your opinions about licenses that you think Debian *shouldn't* accept is an abuse of the list. Sorry, but I think I am *not* abusing this list by just expressing my own opinions on the acceptability of licenses. The description of this list says [1]: Discussions about legality issues such as copyrights, patents etc. [1] https://lists.debian.org/debian-legal/ There cannot be *any* discussions, if, for each given topic, only *one* opinion is allowed to be expressed, and any other dissenting opinion is banned. signature.asc Description: Digital signature
Re: data and software licence incompatabilities?
On Tue, Aug 27, 2013 at 10:55:33PM +0200, Francesco Poli wrote: On Mon, 26 Aug 2013 17:15:58 -0400 Paul Tagliamonte wrote: On Mon, Aug 26, 2013 at 11:00:38PM +0200, Francesco Poli wrote: I respectfully disagree: I am convinced that the GNU GPL is far better than any CC license, for both programmatic and non-programmatic works. But that's not the point, anyway. What I was trying to say was just that having those files under GPL-compatible terms would erase any possible doubt (and also enable other potential uses that are currently forbidden). Please don't spread FUD against the CC license set when it'll be perfectly fine. (quite literally F.U.D. in this case). The CC licenses are perfectly fine, no matter how much you disagree. CC licenses may be perfectly fine in *your* opinion. Apparently in many other people's opinion, too. But they are not in *my* opinion. I think I have a right to have my own opinion and to express it publicly, as long as I clearly describe it as my *own personal* opinion. You have a right to your own opinion. You do *not* have a right to express it *on this list*. The purpose of this list is to provide guidance to maintainers and upstreams regarding *Debian's* definition of free software, as well as guidance regarding the *legality* of particular combinations of works. You using the list as a soapbox for your opinions about licenses that you think Debian *shouldn't* accept is an abuse of the list. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 12:53:01PM -0700, Howard Chu wrote: Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2] [1]: The Dissident test [2]: The Desert Island test Sure, but #2 is stupid. We didn't say must send changes back immediately. Nor would we wish any such thing; if you're in the middle of making a long series of changes we obviously want to wait until the changes are completed and have settled down. Otherwise someone could make a case that the changes should be sent back the instant they are written, one keystroke at a time, which is ludicrous. Send changes back in a timely manner. You obtained the software somehow; therefore at some point in time a distribution channel was available to you. The next time such channel is available, send your changes back. If you're stuck on a desert island and die before such channel reopens, no one's going to sue you. I'd say #1 is borderline stupid. It is worded such that it only applies to hiding existence of a system from the government. Fair enough; I'm not the government. That's not the point. The purpose of the Dissident Test is to demonstrate that distribution channels for software are not necessarily symmetric; it may be very easy for you to distribute the software, but very hard/expensive/dangerous for a recipient to distribute their modifications back to you. In the specific case of the Dissident Test, the unreasonable cost of returning the changes upstream - as opposed to distributing them to whoever you happen to be distributing binaries to (possibly no one) - is that sending those communications back may give hostile authorities information you don't want them to have, such as your location, details about the software you're modifying, or even simply the fact that you're doing something that you care about encrypting to keep them from prying. Even if you aren't otherwise doing anything the government disapproves of, the mere act of sending these changes upstream might get you labelled a spy. This is one example of why Debian says it's ok for a license to require modifications to be distributed to your downstreams, but not ok to require those changes be sent to a particular party. Users should not have to choose between complying with the license and being safe from their government; they should be *free* to exercise their rights on the code in Debian, even when they aren't free in other aspects of their lives that we don't have control over. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 04:27:14PM -0700, Howard Chu wrote: That's not the point. The purpose of the Dissident Test is to demonstrate that distribution channels for software are not necessarily symmetric; it may be very easy for you to distribute the software, but very hard/expensive/dangerous for a recipient to distribute their modifications back to you. In the specific case of the Dissident Test, the unreasonable cost of returning the changes upstream - as opposed to distributing them to whoever you happen to be distributing binaries to (possibly no one) - is that sending those communications back may give hostile authorities information you don't want them to have, such as your location, details about the software you're modifying, or even simply the fact that you're doing something that you care about encrypting to keep them from prying. Even if you aren't otherwise doing anything the government disapproves of, the mere act of sending these changes upstream might get you labelled a spy. This is still an unreasonable test. Again, it ignores the element of time. Send your changes at your earliest convenience. If the NSA is breathing down your neck, convenience might be a long time away, but that's understandable. It ignores the element of time because the licenses this test was constructed in response to don't *allow* the user to do so. There is no common sense at your convenience rule baked into the law; if the licensor means that this should be done at the modifier's convenience, they should be spelling that out in the license - with the understanding that the licensor and licensee may not agree on what is convenient, and that it may *never* be convenient from the licensee's POV. Let's not forget that Al Capone was convicted not for murder, racketeering, or bootlegging, but for tax evasion; and that the US tax code specifies where on your tax form you are required to report income from the sale of illegal drugs. It would be ironic for a dissident to evade capture and prosecution for years, only to finally be brought up on charges of criminal copyright infringement (with or without the consent of the copyright holder!) for failing to submit their changes upstream while operating clandestinely. This is one example of why Debian says it's ok for a license to require modifications to be distributed to your downstreams, but not ok to require those changes be sent to a particular party. Users should not have to choose between complying with the license and being safe from their government; they should be *free* to exercise their rights on the code in Debian, even when they aren't free in other aspects of their lives that we don't have control over. Freedom always has a price. The price of benefiting from free software should be that you help others benefit from it too. That's your position. That's not the Debian position. We *encourage* those who benefit from free software to give back; but we decided early on as a project that *requiring* people to give back was a higher price than we were willing to accept. Even here http://people.debian.org/~bap/dfsg-faq.html As that URL suggests, this is not an official statement of the Debian project, it's a document maintained by one individual Debian developer. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Inquire of ECCN/LE of Debian 6.05
On Tue, Jun 11, 2013 at 01:50:19PM +0900, Rieko Nagao wrote: Dear Paul Wise, Thank you. Does this mean you (Debian) doesn't have the ECCN certified by BIS? Correct, Debian has not requested an ECCN certification from the BIS. Debian does export its software under the TSU exception as described in CFR 740.13(e), including the provisions for notification to the BIS of publication URLs until recently (when the BIS informed Debian they had sufficient information and asked us to stop proactively notifying of new software versions). Do we need to confirm the specification of your product by ourselves? If you are intending to export products from the US that include the Debian OS, then it would appear you would need to confirm this yourselves, yes. Since you appear to be based in Japan, I don't understand why you would need an ECCN certification from the BIS. Does Japan not have its own process for ECCN determinations under the Wassenaar Arrangement? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: license advice
Hi Andrew, On Mon, Apr 08, 2013 at 03:46:01PM +0200, Andrew Shadura wrote: There's a project which isn't free software nor is it open-source (as they haven't found a monetisation model which would allow them to open the sources), but they'd like be able to have it in non-free section. They've asked me to give them ideas on what to change in their current EULA to make that possible. So I'd like to ask someone to review the license (I've attached the file they gave me) and give me advices on what it'd be good to change. Please comments on everything — not sure every change will be accepted by them, but more problematic things we'll have here discussed, more possibilities to change them. I haven't reviewed the attached license, for a simple reason - an EULA is *not* a distribution license. In order to be included in non-free, we must have a license that permits us (and our mirrors) to freely redistribute the software over the Internet, without any requirement to agree to a license *at all* as a precondition (because we can't agree on our mirrors' behalf, and the mirror operators will never see this license). So you can have any use restrictions you want in the license on a package in non-free (provided you can find a DD willing to upload it), but you *must* have a license for distribution that's separate from any EULA. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: mapswithme Source: http://mapswith.me Files: * Copyright: 2010-2013 MapsWithMe License: END-USER LICENSE AGREEMENT FOR MAPSWITHME IMPORTANT: PLEASE READ THE TERMS AND CONDITIONS OF THIS LICENSE AGREEMENT CAREFULLY BEFORE CONTINUING WITH THIS PROGRAM INSTALL: MapsWithMe End-User License Agreement (EULA) is a legal agreement between you (either an individual or a single entity) and MapsWithMe for the MapsWithMe software product(s) identified above which may include associated software components, media, printed materials, and online or electronic documentation (SOFTWARE PRODUCT). By installing, copying, or otherwise using the SOFTWARE PRODUCT, you agree to be bound by the terms of this EULA. This license agreement represents the entire agreement concerning the program between you and MapsWithMe, (referred to as licenser), and it supersedes any prior proposal, representation, or understanding between the parties. If you do not agree to the terms of this EULA, do not install or use the SOFTWARE PRODUCT. The SOFTWARE PRODUCT is protected by copyright laws and international copyright treaties, as well as other intellectual property laws and treaties. The SOFTWARE PRODUCT is licensed, not sold. 1. GRANT OF LICENSE. The SOFTWARE PRODUCT is licensed as follows: (a) Installation and Use. MapsWithMe grants you the right to install and use copies of the SOFTWARE PRODUCT on your mobile device or computer running a validly licensed copy of the operating system for which the SOFTWARE PRODUCT was designed. (b) Backup Copies. You may also make copies of the SOFTWARE PRODUCT as may be necessary for backup and archival purposes. 2. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS. (a) Maintenance of Copyright Notices. You must not remove or alter any copyright notices on any and all copies of the SOFTWARE PRODUCT. (b) Distribution. You may not distribute registered copies of the SOFTWARE PRODUCT to third parties. (c) Prohibition on Reverse Engineering, Decompilation, and Disassembly. You may not reverse engineer, decompile, or disassemble the SOFTWARE PRODUCT, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation. (d) Rental. You may not rent, lease, or lend the SOFTWARE PRODUCT. (e) Support Services. MapsWithMe may provide you with support services related to the SOFTWARE PRODUCT (Support Services). Any supplemental software code provided to you as part of the Support Services shall be considered part of the SOFTWARE PRODUCT and subject to the terms and conditions of this EULA. (f) Compliance with Applicable Laws. You must comply with all applicable laws regarding use of the SOFTWARE PRODUCT. 3. TERMINATION Without prejudice to any other rights, MapsWithMe may terminate this EULA if you fail to comply with the terms and conditions of this EULA. In such event, you must destroy all copies of the SOFTWARE PRODUCT in your possession. 4. COPYRIGHT All title, including but not limited to copyrights, in and to the SOFTWARE PRODUCT and any copies thereof are owned by MapsWithMe or its suppliers. All title
Re: Advice regarding deleted images on Commons (tarot deck)
On Sat, Apr 06, 2013 at 12:04:58PM -0400, Matteo Cypriani wrote: Thomas Preud'homme (CC'ed) and myself are currently packaging Salut à Toi, an XMPP-based communication system (see ITP #703659), and part of it is media files, including a French tarot deck. This deck is of a classical design that corresponds to the Piatnik deck originally published by Piatnik Söhne [PS]. The upstream author of Salut à Toi, Jérôme Poisson (CC'ed), picked the files on Wikimedia Commons, but they have since been deleted for copyright reasons [DEL]. Since the arguments were not very clear and Jérôme was convinced the design was old enough to fall into the public domain, he asked for an undeletion request [UNDEL] with some new arguments, but it was refused. Subsequently, the remaining cards of the same design, such as [TN], have been marked for deletion on Commons. My questions are: 1. Can we introduce these file in Debian despite the decision made on Commons? Wikimedia and Debian can make their own independent decisions about whether they think a work is copyrighted. Neither decision has any legally binding force. 2. Do you have any advice for us to be sure that these images are in the public domain, or that they're not? 1) upload, 2) wait for a copyright holder to step forward and claim infringement and provide proof, 3) don't worry about it until then. Since it's exceedingly unlikely that there is any copyright holder to step forward, it seems reasonable to me to assume that these works are in the public domain without presenting a pedigree that proves that they are. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Seeking advice on Pan license issue with optional TLS component
Hi Dominique, On Tue, Feb 12, 2013 at 02:26:18PM +0100, Dominique Dumont wrote: Here's a summary of the issue for debian-legal folks. Pan package on Debian got bug #699892 because Pan GPLv2 only is linked with gnutls LGPLv3, which is not permitted by FSF. Pan folks are willing to re-license Pan to GPLv2 and later. But getting copyright owner authorisation for all software components copied into Pan is a big problem: there's no obvious contact for some of these components. Reading http://www.gnu.org/licenses/gpl-faq.html#MereAggregation, I think we may not need to re-license all components of pan code. Pan is made of several part. Some parts like uulib or e-*-dialog.c are integrated in Pan by source code copy. Other parts like gnutls are integrated with dynamic linking (optionaly). To respect the license terms, I think we need to check the compatibility between parts when the parts are actually working together (i.e. some data is exchanged directly between these 2 components). I.e. we need to check that: - Pan license is compatible with gnutls license - Pan license is compatible with e-*-dialog.c (and others) but we don't need to ensure that e-*dialog.c license is compatible with gnutls license because these 2 parts work independently (well, I think so, you Pan guys should be able to confirm easily). As I understand it, these e-*-dialog.c components are all linked into a single binary, /usr/bin/pan. If so, I don't think there's any grounds for claiming that this is mere aggregation. Linking object files together into an executable binary is absolutely in scope for the kinds of things that the GPL is designed to guard against. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Public Domain again
On Fri, Feb 01, 2013 at 02:04:26AM +0100, Jérémy Lal wrote: On 01/02/2013 01:25, Don Armstrong wrote: On Fri, 01 Feb 2013, Jérémy Lal wrote: My issue is that i don't understand how public domain is DFSG, If a work can actually be placed into the public domain Does this mean there are cases where the work cannot actually be placed into the public domain ? In *most* jurisdictions, it appears to not be possible for a copyright holder to release their work into the public domain. That's why CC0 exists as a workaround, to make a pseudo-public domain dedication of a work. Works that are genuinely in the public domain (because they are old enough, or because they were produced under circumstances which do not result in copyright attaching to the work in the first place) are definitely DFSG-free. They also have *no* license, because there is no one you need to ask permission from! To be practical, are these files all right to be listed as 'public-domain' in debian/copyright : * without copyright notice Yes; * with a short notice 'There is no licence for this, I don't care what you do with it' no (this is not a statement that it's in the public domain, and there is no license implies no permission is actually granted); * without copyright notice, and an explicit 'this code is under public domain' yes, provided this is true; * the same as above, but with a copyright name year next to it, (i made that last example, to be sure i get it) no, because these are contradictory statements. Public domain means *the absence of copyright*. If someone is claiming the work to both be in public domain and covered by copyright, they have failed to understand and we must assume the work is under copyright with no license grant. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Sita Sings the Blues goes public domain
On Sat, Jan 19, 2013 at 06:34:35AM +0800, Paul Wise wrote: Sita Sings the Blues goes public domain (CC0): http://blog.ninapaley.com/2013/01/18/ahimsa-sita-sings-the-blues-now-cc-0-public-domain/ ... but not DFSG-free. In what way is CC-0 not dfsg-free? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
On Tue, Jan 15, 2013 at 02:41:07PM +0100, Jonas Smedegaard wrote: the current defined purpose of the copyright file apparently is only to cover copyrights and licensing or _source_. That's not true. The purpose of the copyright file has *always* been to ensure that the license for a given binary package is correctly documented in that package. It's just that the safest way to ensure this is by documenting the entire license for the source package in debian/copyright and copying that file to each of the binary packages. Unfortunately we took a wrong turn somewhere and started considering debian/copyright itself the requirement, and that's a *bug*. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20130115195935.gd24...@virgil.dodds.net
Re: Ethics/morals issue
Hi Gary, On Sun, Nov 25, 2012 at 02:33:40PM -0500, Gary Wilson wrote: Good day - We have a son taking Computer Science at Ryerson University in Toronto Canada. He is very religious and is concerned that using your software without reading, in detail all of your license agreements including the entire list for both free and non-free suppliers. This is jeopardizing his study. Can you help by clarifying your requirements/understanding of who needs to read what. I realize this is probably a very unusual query but it is causing our family significant turmoil. Any help will be sincerely appreciated. Thanks All software included in Debian (that is, in the Debian main repository) is freely usable without restriction. There should be no need for your son to read any licenses before using Debian. In addition, all software in Debian is modifiable and redistributable under a license that meets the requirements laid out at http://www.debian.org/social_contract. It's advisable to read the specific license terms of the individual software components before modifying them. Software in non-free, which is not enabled by default in Debian, may have restrictions on use. It is recommended to read the specific license terms of non-free software you install prior to use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Request review of cdrtools-3.0 for inclusion in Debian
Hi Eric, On Tue, Nov 13, 2012 at 03:20:22PM -0800, Eric Shattow wrote: I seek clarification on how closely cdrtools-3.0 meets the Debian Free Software Guidelines. Web: http://cdrecord.berlios.de/private/cdrecord.html Tarball: ftp://ftp.berlios.de/pub/cdrecord/cdrtools-3.00.tar.gz Would an official debian legal representative please consider the cdrtools-3.0 release for review? 1. Does cdrtools-3.0 release pass the DFSG? Why or why not, and please could this be supported by legal or official decision by the Debian project? It doesn't matter if the stated license of cdrtools passes the DFSG. The author and copyright holder of cdrtools has an adversarial relationship with the Debian project, and cdrtools was removed from Debian as a direct result of this conflict and the author's clear intent to disallow modifications that must be permitted under the DFSG. Jörg Schilling's software is not welcome in Debian. We have no need for litigious upstreams, and cdrtools has been obsoleted by cdrkit which, contrary to Mr. Schilling's representations, is more featureful and less buggy on Linux than cdrtools. See http://bugs.debian.org/377109 for the full history here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: debian/copyright completeness/finickyness
On Mon, Nov 05, 2012 at 11:43:29PM +0100, Alexander Toresson wrote: For an application I'm currently helping with packaging, there are many (source and non-source) files without license statements, of which many don't even have a stated author. How do we handle these? Do we need to investigate the license and/or author of each file, or is it possible to assume that the files are under the main license of the application, and are made by the main authors of the application? Unless you have a specific reason to believe this is not the case, yes, it's a reasonable assumption that the files have the same copyright and license as the main body of the work. There is no requirement of per-file copyright notices. Also, when using a machine-readable copyright file, do you need to separate paragraghs for different authors? http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field suggests that you would not need to do that, but I've gotten different information from the main maintainer of the package. Provided that the license is the same, such that it's possible to express this as a single paragraph without being inaccurate, you don't need separate paragraphs. (E.g., if the source package contains source for two different programs, and the sources are freely but incompatibly licensed, don't just say Files: * License: License-1 and License-2 since that doesn't tell users anything about what their rights are.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#687693: ca-certificates: Cacert License is missing
On Sun, Nov 04, 2012 at 02:56:27PM -0600, Michael Shuler wrote: Among other suggestions, Francesco Poli recommended including a verbatim copy of this license. You should not. If the license has no legal force, you should not propagate it and give people the impression that it does. The CAcert license is therefore something we should entirely ignore, because it has no legal force. Is this really the case? Should Debian ignore CAcert's license on their root certificates? Here is my reasoning, distilled as best I can: CAcert has explicitly licensed their root certificates. This is an inaccurate statement. What CAcert have done is unilaterally assert that you *need* a license for their root certificates. If you don't need a license, then what they have done is not licensing: it's an attempt to assert control not granted to them under law. Even if SSL certificates are not copyrightable, the RDL contains the language: In the event that any provision of this license is held to be invalid or unenforceable, the remaining provisions of this license remain in full force and effect. Which is irrelevant, because *we don't need a license in the first place*. I hereby grant you a non-exclusive, worldwide, royalty-free license to eat cheese with salami, subject to the following conditions: - You do not use the name of debian-legal while talking with food in your mouth. - You do not eat cheese with wine. - Neither the name of the University of California nor the name of the Tillamook County Creamery Association may be used to endorse or promote products derived from your consumption of cheese and salami without specific prior written permission. In the event that any provision of this license is held to be invalid or unenforceable, the remaining provisions of this license remain in full force and effect. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#687693: ca-certificates: Cacert License is missing
On Sat, Nov 03, 2012 at 03:28:08PM -0500, Michael Shuler wrote: Control: severity -1 serious Control: tags -1 pending (Setting to serious, due to policy violation) After reading the -legal thread, comments above, the CAcert mailing list thread, the Fedora explanation, and carefully reading the licensing myself, the cautious side of me says the right thing to do is remove the CAcert certificates from the package. This change will be committed to the collab-maint git repo shortly. I appreciate the bug report, mejiko, and for others taking the time to consider this issue. I will consider a ca-certificates-cacert ITP for inclusion in non-free. Which debian-legal thread were you reading? Because the two comments I see cc:ed to this bug report from debian-legal, from Francesco Poli and Florian Weimer, both point out that *certificates are not copyrightable*. An SSL certificate is a unique representation of a mathematical fact; since it contains no creative element, copyright law does not provide for any monopoly rights prohibiting distribution. The CAcert license is therefore something we should entirely ignore, because it has no legal force. Your proposal to remove it from the package without specific legal guidance to the contrary is a gross overreaction. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20121104011525.gb6...@virgil.dodds.net
Re: National Land Survey open data licence - version 1.0 - 1 May 2012
On Thu, Oct 25, 2012 at 11:36:30AM +0300, Timo Juhani Lindfors wrote: [ Replying to an old thread. For your convenience here's a link to the original thread: http://lists.debian.org/debian-legal/2012/05/msg00014.html ] Francesco Poli invernom...@paranoici.org writes: * remove the name of the Licensor from the product or service, if required to do so by the Licensor. I am personally convinced that such a requirement is non-free. I think it's very similar to one of the clauses found in CC-v3.0 licenses. See for instance my analysis of CC-by-v3.0: https://lists.debian.org/debian-legal/2007/07/msg00124.html However, Debian FTP-masters disagree with me on the freeness of works released under the terms of CC-v3.0 licenses: https://lists.debian.org/debian-legal/2010/01/msg00084.html Hence, it's *possible* (but not granted) that FTP-masters would consider the above-discussed section 2.2 as acceptable, unfortunately. It seems that since CC has such a clause it is getting copied to other licenses. I heard of one such license this week: Helsinki Region Infoshare – data pool licence 1. The licensor (holder of copyright or associated rights in the licensed material) hereby grants the licensee (user of the licensed material under the terms of this licence) a global, free of charge, non-exclusive, permanent licence to copy, disseminate, edit, combine and otherwise use the licensed material according to the terms and conditions set out in items 2 and 3 below. The licensed material may be used for non-commercial and commercial purposes. 2. The original copyright information in the licensed material must be acknowledged in the manner indicated by the licensor. This attribution must be deleted if so requested by the licensor. 3. The copyright details of the licensed material must not be attributed in any way that suggests that the publisher of the licensed material endorses the user or the use of the data material. -- http://www.hri.fi/lisenssit/hri-nimea/ Note that while CC has to the extent practicable to shoften the requirement this softening is not present anymore in National Land Survey open data licence or this Helsinki Region Infoshare – data pool licence. Could this to the extend practicable be the key difference why CC would be considered free but these two new licenses would not? Does Finnish law recognize the concept of author's rights (moral rights)? It appears that the intent of this clause is to reassert a right that is already granted by law in some jurisdictions: the right for their name not to be associated with a mutilated form of their work. If this were a license used by a copyright holder in France or Germany, where I know such moral rights exist, then I believe this clause would be a no-op and should therefore be ignored when evaluating the freeness of the license. When used by a Finnish copyright holder, I'm not sure; this may be an example of a tentacles of evil effect from the license. There's also the fact that, as worded, it does *not* refer to the author, it refers to the Licensor who may be a different party. So it's possible that there are some bugs in the wording, of both the CC license and the licenses you cite. I do think, however, that they're compatible in *intent* with the DFSG, which has explicit provisions regarding the integrity of authors' works. Requiring a rename or requiring changes be carried as patches is not conceptually different from requiring removal of attribution. None of these requirements are something we recommend to authors, but they are free. The National Land Survey license does have a pretty major bug that the other two do not, due to differences in wording (another example of why people shouldn't write their own licenses): * remove the name of the Licensor from the product or service, if required to do so by the Licensor. This does *not* say that you must remove the name from the *attribution*. It says you must remove the name, which implies you must remove it from anywhere it appears, including in functional elements. In practice, if someone wanted to package data distributed under this license, they could sanitize that data by proactively removing any occurrences of the Licensor's name first *except* for the credits; once done, this degenerates to the previous case. But it's obviously a hassle to do that. All in all, with respect to these clauses I side with the ftp masters (who have already accepted CC-BY-SA 3.0) and believe they're DFSG-compatible, though I would definitely not recommend any of these clauses. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc
Re: dissident test has been proven wrong and should not be used any more
On Mon, Sep 24, 2012 at 11:42:35PM +0900, Osamu Aoki wrote: But this dissident test has been streched to the extreme and shot down many licenses as DFSG violation. snip * requiring to comply with law of the country is quite reasonable (GPL2.0 does. Many licenses also require export control compliance.) No, it is not reasonable, and it is not DFSG-compliant. If there are licenses being allowed into Debian that are enshrining requirements to comply with unrelated laws, that's something that needs to be corrected ASAP. Do you have a specific example of software in main whose license requires the user/developer to comply with particular laws? (Note that the GPL2.0 does NOT require compliance with the law; it only states that you may not use other legal obligations as a justification for failure to comply with the terms of the GPL.) The DFSG does not allow licenses to discriminate against fields of endeavour, and that absolutely includes illegal ones. The law is sometimes wrong; it's important that users of Debian not be exposed to double jeopardy as a result, including in cases of civil disobedience. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Java3D license incompatible with DFSG?
On Sun, Sep 16, 2012 at 05:56:18PM -0700, Ken Arromdee wrote: On Sat, 15 Sep 2012, Steve Langasek wrote: * You acknowledge that this software is not designed, licensed or * intended for use in the design, construction, operation or * maintenance of any nuclear facility. This is a standard No warranty clause wrt nuclear facilities in the US. It is not a restriction placed on the use of the software in nuclear facilities by the copyright holder, it is a CYA statement that the software has not been approved *by the government regulatory agencies* for use in nuclear facilities in the US. Stuff like this has puzzled me. I would think that in order to use this software, you must do something which would have the effect of disadvantaging yourself in a lawsuit wouldn't be considered free. A statement you must acknowledge X means that any user who wants to claim not-X in court is forced to drop that claim in order to use the software. Well first, there are clauses allowed as DFSG-compliant that have much more of a disadvantaging effect in the event of a lawsuit. Far more users are likely to be affected by a choice of venue clause than a clause limiting the author's liability if you try to use the software in a nuclear plant. Even a vanilla no warranty clause has much more effect. Second, there is absolutely nothing in the DFSG that would require authors expose themselves to lawsuits of any kind. The objections to the use of choice of venue clauses (which ultimately have found their way into main despite these objections) centered around the impact such a clause has on the *copyright holder's* ability to sue the *licensees* en masse, not on the ability of the licensee to sue the copyright holder. Taking away your right to sue the copyright holder *entirely* for anything related to the software, as a condition of the license grant, would still allow you to exercise the rights that the DFSG is concerned with (use, modification, and distribution). In this specific case, you're suggesting that we should for some reason care that a user can't make a counterfactual claim in court that this software has been licensed by the DOE for use in nuclear facilities. That's so far removed from the goals of the DFSG that it's not even funny. The reward for releasing software freely to the world should not be exposure to frivolous lawsuits from users. If this is a statement that the software hasn't been approved, shouldn't it say you acknowledge that we *claim* X (thus not depriving the user of the opportunity to challenge X in court), and not you acknowledge X? No, because the intent of the clause is to save the copyright holder from being sued by $random_idiot. Notwithstanding the extreme improbability that $random_idiot in this case is a real person rather than a hypothetical construction, that's not at all contrary to the principles of free software. GPL3, for instance, includes two distinct restrictions on the recipient's right to sue: Disclaimer of Warranty + Limitation of Liability (sections 15-17), and prohibition of patent claims (section 10). Perhaps you believe that these clauses make the GPL non-free as well; but Debian, and the Free Software community generally, does not. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Java3D license incompatible with DFSG?
On Sat, Sep 15, 2012 at 12:39:23PM -0600, Eric Smith wrote: I quoted from the Sun license on Java3D: * You acknowledge that this software is not designed, licensed or * intended for use in the design, construction, operation or * maintenance of any nuclear facility. Steve Langasek wrote: This is a standard No warranty clause wrt nuclear facilities in the US. It is not a restriction placed on the use of the software in nuclear facilities by the copyright holder, it is a CYA statement that the software has not been approved *by the government regulatory agencies* for use in nuclear facilities in the US. Warranty disclaimers are fine under the DFSG. While that may[*] have been the intent, it specifically states that the software is not [...] licensed. It is explicitly stating that Sun was not granting the BSD license, or any other license, to those in that field of endeavor. No, you are misinterpreting what is meant here by licensed. I also dispute the idea that there is a standard 'No warranty' clause wrt nuclear facilities in the US. The (admittedly limited) research I have done suggests that this clause is simply something that Sun's lawyers invented, and was subsequently copied by quite a few otherwise open-source projects, mostly those using Java. It's possible that Sun was the originator of the clause in question. There's enough free software licensed by Sun or using license texts derived from theirs that it's by this point a de facto standard. And it has been recognized as free by Debian, because the intended meaning is the one I mentioned above. Since the 1960s it has been common for manufacturers of electronic components and equipment to disclaim liability for use of their products in life-critical or safety-critical systems, but as far as I can tell there wasn't any widespread use of an anti-nuclear clause. Not until you started to see the intersection between corporate lawyers familiar with these liability issues with safety-critical systems, and free software. [*] I don't think this has anything to do with whether the US government has approved the software; that is up to the government and not Sun. Rather I think the purpose was to disclaim liability for any nuclear attack or meltdown. Either way, though, it is just speculation. The purpose is to disclaim liability by making users aware that it does not have a license from the US government. This is why licensed is juxtaposed with designed and intended instead of being a direct statement that you are not *allowed* to use it in a nuclear facility. On Sun, Sep 16, 2012 at 12:22:00AM -0600, Eric Smith wrote: If the clause really had something to do with the US government, it would be identified as such, and if it had to do with the US government controlling what is used in US nuclear facilities, it would have specifically stated that, rather than being completely open-ended about where the nuclear facilities are located. (The US generally wouldn't have jurisdiction over what software was used in nuclear facilities in other countries, e.g., France.) If the US government somehow was involved in licensing software for use in nuclear facilities, we would see this clause in all sorts of software, rather than only in software licensed by Sun, and by other parties that have copied the Sun license. In any case, regardless of the intent, it is clear that it does state that the software is not licensed for use in nuclear facilities. It fails to meet the DFSG and OSD regardless of whether the clause was written for Sun's benefit or at the behest of the US government. No. At this point you are willfully misinterpreting the text despite having it explained to you what this clause means, apparently from some belief that the text of a license would never be written in a way that's unclear to a layman. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Java3D license incompatible with DFSG?
On Sat, Sep 15, 2012 at 01:52:54AM -0600, Eric Smith wrote: In the course of trying to package Java3D for Fedora, Tom Calloway brought to my attention that the Java3D license includes the following statement: * You acknowledge that this software is not designed, licensed or * intended for use in the design, construction, operation or * maintenance of any nuclear facility. This is a standard No warranty clause wrt nuclear facilities in the US. It is not a restriction placed on the use of the software in nuclear facilities by the copyright holder, it is a CYA statement that the software has not been approved *by the government regulatory agencies* for use in nuclear facilities in the US. Warranty disclaimers are fine under the DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Non-free postscript code in EPS image
Hi Michael, On Tue, Jul 31, 2012 at 09:03:52PM +0200, Michael Wild wrote: I'm maintaining a package that contains an EPS image created with Adobe Illustrator and hence contains postscript library code that is copyrighted by Adobe, e.g.: * Copyright(C)2000-2006 Adobe Systems, Inc. All Rights Reserved * Copyright(C)1997-2007 Adobe Systems, Inc. All Rights Reserved. * Copyright 1997-2006 Adobe Systems Incorporated. All Rights Reserved. * Copyright 1987-2006 Adobe Systems Incorporated. and so on. Does this make the file non-redistributable and non-DFSG free? If not, would I need to list all these copyright statements into debian/copyright? Strange thing is, most of it is simply boilerplate that is not even used. Running it through eps2eps (a ghostscript wrapper) brings the file down from 220K to 4K! A copyright statement does not, by itself, say anything about the license of the work. Since Illustrator is frequently used for producing output files that are expected to be distributed, it would be reasonable to assume that the output is liberally licensed and that whatever license is listed in the package is in fact the correct one, with no other license attaching to this output. If you find an authoritative license statement to the contrary, *then* we should worry about whether this is non-redistributable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Non-free postscript code in EPS image
On Tue, Jul 31, 2012 at 07:51:55PM +, Bart Martens wrote: A copyright statement does not, by itself, say anything about the license of the work. Since Illustrator is frequently used for producing output files that are expected to be distributed, it would be reasonable to assume that the output is liberally licensed and that whatever license is listed in the package is in fact the correct one, with no other license attaching to this output. If you find an authoritative license statement to the contrary, *then* we should worry about whether this is non-redistributable. The user of Adobe Illustrator may have had the intention to create files that can be freely redistributed. If parts of the files are copyrighted by Adobe (Michael wrote contains postscript library code that is copyrighted by Adobe) without license from Adobe, then the files cannot be freely redistributed. Correct but irrelevant. No one here has provided any evidence one way or the other about whether Adobe has given a license. The sensible *default* assumption is that when an upstream asserts that the license on their work is $foo, they know what they're talking about even when portions are copyright other people/entities. There's no reason to deviate from this sensible default just because it's known that one of the entities listed releases other software under proprietary licenses. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Non-free postscript code in EPS image
On Wed, Aug 01, 2012 at 12:45:27AM +0200, Bernhard R. Link wrote: even when portions are copyright other people/entities. If there is a hint to distrust what people claim about their work, I see no way how a judge could believe a But I was told it is if one did not at least check what hints one got. If someone claims he has a license from Adobe, then well, believe him unless you run into some statement from Adobe that they do not give away any licenses like that. If someone just claims it is under a free license but does not even refer to those parts having a different copyright, then it gets unlikely enough in my eyes that one has to assume the default of the law: no permission at all. This notion of documenting the copyright of every single line of every single file is a new development in Debian - and not a healthy one. Not documenting the copyright of bits that were incorporated by way of a binary generation is *normal*, and unless those bits are under the GPL, it's not generally a problem - except for passing Debian NEW, which seems to have taken copyright auditing ad absurdum in recent years. So no, I don't think failing to include these copyright statements in the documentation is any sort of evidence of a lack of due diligence on the part of the upstream. And regarding Since Illustrator is frequently used for producing output files that are expected to be distributed, it would be reasonable to assume that the output is liberally licensed and that whatever license is listed in the package is in fact the correct one, with no other license attaching to this output. have you ever looked at some EULAs? A quick look at http://www.adobe.com/products/eulas/ makes me think this is quite unlikely. (If I read this correctly, some things you are allowed to embed, but only verbatimly and for specific purposes, but the limits are quite absurd and I'm not sure it even gives permission to distribute for all the stuff you find in some postscript files). I've read EULAs before, sure. But the only EULA that has any bearing on this is the EULA for the version of Illustrator upstream used to generate the PDF, and that one I have not read. If this issue is important enough to you that you want to track down the EULA and verify that the embedded code isn't freely distributable/modifiable, that's your prerogative; but I stand by my statement that *Debian* should not block on such an investigation. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: public domain no modification
On Sat, Apr 07, 2012 at 05:05:27PM +0200, Mathieu Malaterre wrote: I am working on the package for Java Components for Mathematics (#667923). Some files are distributed with a clear public domain type license: This source code file, and compiled classes derived from it, can be used and distributed without restriction, including for commercial use. (Attribution is not required but is appreciated.) However some other files are distributed with a much nastier license: ... 1) This source code file, in unmodified form, and compiled classes derived from it can be used and distributed without restriction, including for commercial use. (Attribution is not required but is appreciated.) 2) Modified versions of this file can be made and distributed provided: the modified versions are put into a Java package different from the original package, edu.hws; modified versions are distributed under the same terms as the original; and the modifications are documented in comments. (Modification here does not include simply making subclasses that belong to a package other than edu.hws, which can be done without any restriction.) Clearly §2 is meant to distinguish derived work from original work. However in our case, this means this package will have to have its name change whenever we need to patch the source code (eg. fix a compilation error). This appears to be entirely consistent with the requirements of DFSG #4. It doesn't mean that you have to change it *whenever* you patch the source code, only that you have to change it the *first* time you patch the source code. Best to change the name up front, so that future patching doesn't immediately break interface compatibility with reverse-dependencies. Does it make sense to upload the 1.0 version under the name 'jcm', or should I prefer 'debian-jcm' package just to allow future work on it ? Nothing in the license quoted above requires you to change the *Debian* package name. It only requires that you change the *java* package name. You should use whatever name for the Debian package makes the most sense, but change the name of the Java package to something other than edu.hws. HTH, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: public domain no modification
On Tue, Apr 10, 2012 at 12:01:45AM +0200, Francesco Poli wrote: On Sat, Apr 07, 2012 at 05:05:27PM +0200, Mathieu Malaterre wrote: Clearly §2 is meant to distinguish derived work from original work. However in our case, this means this package will have to have its name change whenever we need to patch the source code (eg. fix a compilation error). This appears to be entirely consistent with the requirements of DFSG #4. That's not my understanding of the issue under consideration: more details are included in my own analysis [1]. Yes, because as usual your analysis is way out in left field. My impression is that clause 2 introduces odd restrictions on how modified versions are packaged package is synonymous with name in this case. DFSG#4 says free works may require a name change when modified. and insists that modifications be documented in comments (which, depending on how it is interpreted, may be a very strong restriction). You mean like this restriction? a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. You know, the one in the GPLv2? Your claims that this may be non-free are absurd. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Using freetranslation.mobi to translate .po files
On Mon, Mar 26, 2012 at 09:38:30AM -0400, Clark C. Evans wrote: On Sun, Mar 25, 2012, at 01:36 PM, Ben Finney wrote: I think this is a false assumption, the service itself required creativity to implement, and the specific choice of word associations in specific contexts is not algorithmic nor factual, but individual calls by translation submitters who have granted the translation service license to use their work. By the same argument, the GCC copyright holders can claim to hold copyright in every program compiled using GCC, and the copyright holders in PHP can claim copyright in every web page that program renders. I think that's exactly as unsound as the argument you present. I don't think your comparison is sound. A compiler is going from one synthetic anguage with well defined semantics to another. A human language translation isn't simmilar at all. If you insist on assuming that the output is indeed the result of a mechanical compilation and if you presume the final result is GPLv2+, then the process must comply with Clause #6 of the GPLv3. This requires the corresponding *source code* needed to _generate_ the work from its source code be compatibly licensed Hence, if you want to compare this process to the GCC case... the translator itself must be released under the GPLv3. Not in the least. Releasing something under GPLv2+ means the recipient gets to *choose* which version of the GPL they're complying with, including when they create derivative works. In the GPLv3 only case, I think there's also still room to maneuver; even though the translation is initially a mechanical translation, once done, doesn't this translation then become a new part of the *source*, subject to hand editing and revision? If so, I don't think it falls under section 6. I think presuming the translation output isn't copyrighted is wishful thinking, valuing *your* copyrights over the copyrights of others. Copyright is defined as attaching to creative expressions. If there's nothing creative in the way the translation is *expressed*, it's not copyrightable; nor is there recognition under copyright law that the output of a machine is covered by any copyright other than that of the input. (BTW, if you're claiming that there's creativity in the machine translation itself and that copyright attaches, that's pretty much mutually exclusive with claiming that it's object code under GPLv3 section 6.) For example, if the chunks arn't copyrightable, and assembling chunks is just an automated process... why is the source document copyrightable, it's just a series of uncopyrighted facts (e.g. words). If the sequence matters, then you're not just sending chunks to the service, you're sending the entire document. US copyright law recognizes that there may be creative expression in the selection and organization of factual information. This is why a phonebook (or a timezone database!), which has a trivial structure of organization and is intended to be exhaustive, is not recognized as having a copyright, but an anthology of selected short stories has an editor's copyright in addition to the copyrights of the individual authors. So when you choose what bits to feed into the machine and how to assemble the output, the new copyright that attaches is yours, assuming that the choosing and assembling is non-trivially creative; the machine doesn't hold any copyright. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Using freetranslation.mobi to translate .po files
On Mon, Mar 26, 2012 at 02:00:24PM -0400, Clark C. Evans wrote: On Mon, Mar 26, 2012, at 09:53 AM, Steve Langasek wrote: In the GPLv3 only case, I think there's also still room to maneuver; even though the translation is initially a mechanical translation, once done, doesn't this translation then become a new part of the *source*, subject to hand editing and revision? If so, I don't think it falls under section 6. I think there's two ways to look at it. If you look at it through a non-technical lense, the translation is copyrighted and hence you can't simply slap a GPLv2+ license on it. If you want to view it technically, I think the current explanations don't account for copyright on the sequence of non copyrightable chunks; or, if you might randomize your submissions, that the cached results don't amount to copying chunks of the translation dictionary used by the service. I think you might want to familiarize yourself with copyright law in more depth. The rules on this stuff are well established, within the technical domain that is law. Copyright attaches to creative expressions by human beings. US copyright law recognizes that there may be creative expression in the selection and organization of factual information. This is why a phonebook (or a timezone database!), which has a trivial structure of organization and is intended to be exhaustive, is not recognized as having a copyright So, you claim that a translation dictionary isn't copyrightable? I'm not saying that at all. A dictionary may be much more than a collection of facts; there may be selection of terms, creativity in how alternative translations are ordered or decided between, and so forth. However, the act of *using* the translation dictionary to translate something strips away the creative, copyrightable aspects, leaving only the copying of bare information and not any creative expression. So copyright in many cases protects against someone taking your translation dictionary verbatim and publishing copies of it, but someone can still use that dictionary as part of a machine (or human) translation without the dictionary author's copyright attaching to the translation. I'm not sure this assumption is true -- which words to map to which words isn't factual, it is a judgement call and creative interpretation based on context. I don't think that it being a judgement call is sufficient to satisfy the requirement for creativity under copyright law, and certainly not if it's a *machine* doing the judging. The mappings certainly are a matter of fact; otherwise there would be no such thing as a wrong translation. So I really think the creativity here is negligible. Certainly when I'm translating something, my effort is spent on finding the *right* words, not the *creative* ones. Different translators may come up with different word choices. Also, if you're in Europe, you may also have to comply with database laws, which, as I understand it, protect against copying of sweat-of-the-brow collections. AIUI that's accurate as far as it goes; but again, what's being done here is not copying a dictionary but using it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GPG key issue
Hi Francesco, On Mon, Jan 09, 2012 at 07:39:36AM -, Francesco Namuri wrote: I hope this is the right place to ask for a advice. I have become DD in last days, in all my NM process, and in all my debian work I used only my first and last name, my doubt is related to my second name. I use it only on official/buroccratic documents. Now I've created a new 4096 GPG key, I've specified also my second name (I tought that is more correct), my doubt regards this. Maybe it's a problem asking for a replacement of my old key? It's better if I recreate a key without my second name? thanks very much for any advice. debian-legal is not really the right list for this question; debian-legal is for discussions of licensing of packages in the archive. I would suggest debian-devel as a more appropriate venue for this. If your intent is to get people who have signed your old key to sign your new key based on a GPG transition statement, I would recommend that you include at least one UID on your new key that has the same name as on your old key. But you can add multiple UIDs to the key with different full names, so you can easily have one UID that matches your old key and one with your full name. From the standpoint of the Debian keyring, I believe that as long as the keyring maintainers can clearly map the UIDs on the old key to the new one, there should be no problem with the update. For getting signatures on your new key, that's going to be up to the individual signers to confirm that the name on the UID matches the name they know for you. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Educational Community License 1.0
Hi Gervase, On Thu, Sep 01, 2011 at 01:03:02PM +0100, Gervase Markham wrote: On 29/08/11 15:18, Ben Finney wrote: then effectively Debian policy is that no trademarks may appear anywhere in Debian. The purpose of trademarks in law is as a determinant of origin. What in DFSG §8 (or in my explanation of it) makes this infeasible, in your view? If you understand DFSG §8 to apply to trademarks, then the right to use a trademark to identify the software must be offered to those outside Debian. But we do not regard DFSG 8 as applying to trademarks. There is an explicit exemption in the DFSG that software may require a name change when modified. Debian also requires that software not be subject to restrictions on its modification (DFSG §3). These two principles combine to say that the the software, arbitrarily modified, must still be permitted to bear the trademark. As any software can be incrementally transformed into any other software, this effectively means the mark can be used on any software at all. I suspect you don't agree with that, so where is my logic wrong? You could argue that trademark holders can grant the right to use the trademark to Debian for the exact Debian version, and to everyone else for the exact Debian version, and so everyone actually has equal rights. But in practice, either this means that the trademark holder needs to approve all changes Debian makes (which is generally unacceptable to Debian, I understand) or the trademark holder says OK, Debian, I trust you, make modifications - at which point, the licence becomes specific to Debian again and you are back behind §8. For the specific case of firefox, which is the only instance I'm aware of in which an upstream has ever insisted on such a strict interpretation of their rights wrt trademarks of free software, the maintainer of that package made a conscious decision to change the package name because *from the start* there would be a change that the trademark holder did not approve of: removing the logos that were included with a non-free copyright license. I don't think I can draw any conclusions about whether Debian would *generally* find it unacceptable to use a trademark where all changes to the package must be signed off by the mark holder. The one real-world example we have to date clearly involved terms that were not acceptable. But I believe a trademark license that left Debian free to apply security fixes and fixes for bugs with the integration with the OS without requiring prior sign-off by the mark holder would almost certainly be acceptable to Debian. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Mail Notification: OpenSSL+GPL on Debian
On Wed, Jun 29, 2011 at 03:32:18PM +1200, Dan Wallis wrote: 2011/6/24 Steve Langasek vor...@debian.org: However, in reading the bug log my understanding is the upstream author's position is that the GPL does not require dynamically-linked libraries to be distributed under the same license terms. I don't believe this is an accurate interpretation of the GPL as written, but if Jean-Yves is the sole copyright holder of the work, then this is a clarification of the intended license, which I believe is sufficient for Debian's purposes. If there are other copyright holders, we would need to get similar clarification of intent, or an OpenSSL linking exception, from each of them. That's great news. Thanks. :) Pascal, as the package maintainer, Pascal is no longer the maintainer, actually; the maintainer is now LIU Qi. But the @bugs.debian.org address reaches him, so I guess he's following along. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20110629065239.ge29...@virgil.dodds.net
Re: Mail Notification: OpenSSL+GPL on Debian
Thanks for raising this issue. On Fri, Jun 24, 2011 at 04:47:56PM +1200, Dan Wallis wrote: First off, apologies if I'm out of place in sending you this, or if it's already been discussed here before. I did search the archives [0], but didn't see any mention of this particular suggestion. As I understand things, there's currently a stalemate between the Debian policy, and the package author. I can see in the Ubuntu bug report [1] that there is what appears to be a well-written solution, with which the package author agrees, in comment #86 [2]. I am not a lawyer however, so would like to get the go-ahead from debian-legal. Does this logic seem sound from a legal point-of-view? Following on with that idea, would something as simple as the attached patch be sufficient to resolve this stalemate? If not, could you perhaps suggest suitable wording? No, it would not. Indicating in user-facing documentation that it is recommended to use OpenSSL is not equivalent to granting distributors permission to distribute binaries linked with OpenSSL as part of an OS. However, in reading the bug log my understanding is the upstream author's position is that the GPL does not require dynamically-linked libraries to be distributed under the same license terms. I don't believe this is an accurate interpretation of the GPL as written, but if Jean-Yves is the sole copyright holder of the work, then this is a clarification of the intended license, which I believe is sufficient for Debian's purposes. If there are other copyright holders, we would need to get similar clarification of intent, or an OpenSSL linking exception, from each of them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: CodeIgniter license
On Sun, May 01, 2011 at 05:53:33PM +0200, Florian Weimer wrote: There is no requirement in Debian to track the copyright status of the work beyond what's required by statute or by the licenses themselves. If we do not track the copyright status, how can we make sure that the licensing conditions actually match the requirements of the DFSG? You cannot make sure of this with or without maintainers adding verbose copyright detail to debian/copyright. The only way you'll be sure is when someone tells you some of this information is wrong! So this would be a lot of effort for no real benefit AFAICS. Verbosity is no guarantee of correctness, and the more manual work we demand from maintainers in documenting copyright, the lower the average quality of that documentation will be. The risk of a hostile entity deliberately injecting code into our archive so that they can sue us later for copyright infringement is remote - and the sort of hypothetical that we shouldn't be basing our policies around. There is, however, considerable risk that we pick up code from some upstream where upstream was negligent or has deliberately violated copyright requirements. This risk will exist anyway. There is never an upper limit to the amount of time, energy, and money you can spend trying to reduce risk. There is, however, a limit to how much good it does you to engage in such risk mitigation. I think trying to manually document the copyright holder of each file in each source package in our archive is definitely past the point of diminishing returns. I submit as evidence of this the fact that Debian has never yet been sued for such unintended copyright infringement. OTOH, I think good tools that help us *automatically* record copyright information in a meaningful way and assist us in auditing the copyright and license status of our packages are a worthy investment. This risk is unfortunately not remote. People do label pictures taken by others with the wrong CC license, and those who rely on the incorrect labeling commit copyright infringement if they make use of the CC-granted permissions. But including the name of the copyright holder (if upstream even gives us the real name instead of claiming it's their creation) doesn't significantly help us in preventing the labelling with the wrong license. We don't have the resources to conduct an audit over the entire archive by contacting all the copyright holders to verify the licenses; and it would be very easy for some of these copyright holders to become annoyed by such inquiries (and many of them will not bother replying, I'm sure). So what's the point of spending more effort than we already do gathering names of copyright holders if this won't significantly improve our confidence in the correctness of the license statements? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Auto-acceptance of license by download a problem for 'main'?
On Wed, Apr 27, 2011 at 03:42:32PM -0400, Michael Hanke wrote: Dear -legal, I'm currently looking into packaging a software with a license that has the following clause: | Your contribution of software and/or data to (including prior | to the date of the first publication of this Agreement, each a | Contribution) and/or downloading, copying, modifying, displaying, | distributing or use of any software and/or data from | (collectively, the Software) constitutes acceptance of all of the | terms and conditions of this Agreement. If you do not agree to such | terms and conditions, you have no right to contribute your | Contribution, or to download, copy, modify, display, distribute or use | the Software. I had some concerns about the fact the users of such package would automatically agree to all conditions in that license even before they get to see it on there system. However, apparently this is not a problem for inclusion of such package into main -- this conclusion is based on the fact that the slicer package also uses exactly this style of license: http://packages.debian.org/changelogs/pool/main/s/slicer/slicer_3.6.3~svn16075-2/slicer.copyright I assume that this is OK, because the rest of the license only imposes DFSG-compliant constraints. Is that correct? If this were an *actual* EULA, where the user had to read and accept the license in order to gain access to the work, it would be a DFSG problem. In the case of slicer, nothing in the upstream license requires the distributor to impose such an EULA on the user, so no one has to accept the license as a condition of using the software in Debian and the default rights under copyright apply. As long as the license of your software is similar, where the EULA claims are trivially circumventable by the maintainer, this should also be fine. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20110430083335.ga1...@virgil.dodds.net
Re: node.js has a trademark now
On Fri, Apr 29, 2011 at 08:23:36AM +0200, Jérémy Lal wrote: Hi, nodejs is packaged in debian [0], along with libnode-* modules [1] Today the company owning nodejs announced a new trademark policy [2]. I understand that : * the logo is not a problem, i just have to remove it from the source package (it is not in the binary package) Why do you think it needs to be removed from the source? * the TM symbol must be added in places where Node.js, nodejs, node are written. Can they really trademark the node name ?!? They certainly can trademark the name node, but why do you think this trademark requires you to add any ™ symbols anywhere? * all node modules must have the following sentence in their copyright : Node.js is an official trademark of Joyent. This module is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. Why? Is that right ? are there more changes to do to stay DFSG ? No, in fact there should be no changes you need to make to the package as a result of a trademark license because nothing we do in Debian packaging infringes trademark. You should ignore the license terms unless you're doing something with the name *aside from* packaging that could infringe the trademark. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20110429073034.ga9...@virgil.dodds.net
Re: Lawyer request stop from downloading Debian
On Sun, Apr 24, 2011 at 09:57:22PM +0530, Sriram Narayanan wrote: Joerg Schilling You must be joking. We're looking for legal expertise, not reality distortion fields. or LaForge too may be good sources of information. Who? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20110425003247.ga17...@virgil.dodds.net
Re: Is the old trademark suggestion still reasonable?
On Sun, Apr 17, 2011 at 02:05:44PM +0100, Arand Nash wrote: I'm shallowly involved with a game project which I hope someday might make it into Debian. Currently they use a rather non-free trademark/logo license. I read an interesting suggestion in the archives here[1] which I figured might be worth proposing as an alternative to the main developers. My adapted version would read something like:[2] Is this still a suggestion for a trademark license which you would still consider reasonably OK and fit for DFSG? [1] http://lists.debian.org/debian-legal/2007/04/msg00122.html http://lists.debian.org/debian-legal/2007/04/msg00082.html seems to be the better reference for this. In general, Debian does not consider *any* trademark license to be non-free, including the default state under the law of not granting any trademark license at all. The only problem arises when trademark-like restrictions are entangled with the copyright license of the work. As for this particular license, note that debian-legal does not give legal advice; the proposed license looks ok to me, but I'm not a lawyer and that license has never been tested in court TTBOMK so I have nothing to point to saying that it's good. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Inappropriate use of Debian logo.
On Sun, Nov 28, 2010 at 10:36:44AM +0100, Alessandro Rubini wrote: FYI - A computer shop has taken the Debian logo and used it for his business. http://imgur.com/gFKfs.jpg Thank you for making this jpeg, it's very clear. [...] The comapny Logo was created by photoshop and Logo software, we desgined it from the stretch. if you have somethins to say, give us a call. Unfortunately, they may be right and in good faith. This message confirms the swirl is just one of the defaults: http://lists.debian.org/debian-legal/2005/06/msg00340.html This is an unsubstantiated claim that has been repeated ad absurdum on the lists for years. Sure, it uses a default brush. But who has demonstrated that the exact swirl pattern can be reproduced trivially by accident? No one. When companies show up with a logo that reproduces your exact *application* of the brush, angle for angle down to the pixel, it stretches credulity to claim that this occurred to them independently. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: trademark infringement FreeFOAM
On Tue, Nov 23, 2010 at 07:27:38PM +0100, Gerber van der Graaf wrote: OpenCFD (R) has issued new guidelines for their tradmark OpenFOAM: http://www.openfoam.com/legal/trademark-guidelines.php My question is if these are legal: not allowing hydrostaticFoam as your self-written new solver for example. So, actually they are claiming the FOAM word to be used in a name. Is Pepsi Cola is a trademark infringement of Coca Cola? It's certainly legal for them to set any guidelines they want to for the use of their trademark. The question is, are you doing anything that infringes their trademark in the first place? If you're not doing anything to begin with that requires a trademark license from them, then you should ignore any such trademark policies. They mean nothing *unless you need a trademark license*. And the answer to whether you need a trademark license lies in statute and precedent. You should consult an attorney if you have doubts about whether you're doing something that infringes a trademark. But common sense goes a long way here... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Use of Debian Logo
Hi Vikram, On Mon, Oct 04, 2010 at 04:52:28PM +0530, vikramshankarn...@cdacnoida.in wrote: I work with the BOSS Team at CDAC Noida, we are working on a Live Installer(its licensed as GPLv2) for BOSS GNU/Linux(and its variants). BOSS GNU/Linux is currently based on Debian Lenny, therefore the live installer works with Debian Lenny too. It can be used to install a Debian Lenny Live image to Hard Disk. Currently all instructions, logos and the animation used are of BOSS/EduBOSS. I have read http://debian.org/logos/ and would like to know if I could use the Debian Open Use Logo for the Debian Lenny specific version of the installer. I would then change the instructions so that they refer to Debian instead of EduBOSS and also change the animation that plays while the LiveCD is being installed. debian-legal is a mailing list that provides guidance to developers about whether a given piece of software is distributable under DFSG terms. It does not give advice to third parties regarding the legality of particular uses of software, nor does it have the authority to grant licenses to Debian logos. If you have questions about whether your intended use of the logo is permitted under the existing Debian license, please consult your legal counsel. If you wish to request a license exception to use the logo in a way not permitted by the standing license, please direct such requests to the Debian Project Leader (lea...@debian.org). Regards, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: US government notification of new crypto package?
On Sat, Sep 25, 2010 at 03:19:14PM +0800, Paul Wise wrote: On Sat, Sep 25, 2010 at 3:00 PM, Steve Langasek vor...@debian.org wrote: So long as the upload queue continues to reside in the US, this is true. However, the current ftp team have made several proposals that seem to disregard this aspect of the crypto-in-main solution; I would recommend that any US-based developers who are concerned about compliance with US export regs be watchful for future developments. Could you expand on that, which proposals are you referring to? On Sat, Sep 25, 2010 at 01:18:21PM +0200, Joerg Jaspert wrote: which seems to indicate I need to update the US Bureau of Export Administration before uploading this package for the first time. Is this still a requirement? IIRC the archive software (dak) does this automatically for every new package (or every upload, not sure) whether it contains arms^Wcrypto stuff or not so that Debian can basically ignore this problem until the requirements change. So long as the upload queue continues to reside in the US, this is true. However, the current ftp team have made several proposals that seem to disregard this aspect of the crypto-in-main solution; I would recommend that any US-based developers who are concerned about compliance with US export regs be watchful for future developments. What the hell are you talking about? So what I had in mind was actually not so much a proposal as the fact that the ssh.upload.debian.org upload queue is now located in Canada. That means any US-based developer who uses this upload queue is engaged in software export which is not covered by the Debian project's blanket notifications. At the time ssh.upload.debian.org was instituted, there does not appear to have been any acknowledgement of this fact. I also recall discussion around one of the ftp-master maintenance events of moving ftp.upload.debian.org to UBC; but I don't find any references to this, so this may just be my fallible memory speaking. And for the rest on this list: You don't need to care, the archive cares for you. Well, if ssh.upload.debian.org is intended to be an example of the archive caring for us, then my recommendation stands. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moodle trademark
Hi Tomasz, On Sun, Sep 05, 2010 at 04:07:56PM +0100, Tomasz Muras wrote: New version of Moodle (Moodle 2) contains new file in a source code: TRADEMARK.txt. You can see the whole file in their repository: http://git.moodle.org/gw?p=moodle.git;a=blob;f=TRADEMARK.txt;h=d73a0765b19b37729360780dd2af7f530fc5317c;hb=HEAD The restrictions in that file made me wonder if I have a legal right to package Moodle as Moodle. I have asked their helpdesk as instructed and I've got OK from Moodle Trust - I can use Moodle trademarked name. The thing I don't fully understand is: is that enough to put package moodle in free? DFSG promises Free Redistribution and if somebody uses Debian moodle package to advertise Moodle service surely they will breach the trademark agreement. Advertising a Moodle service is not covered by DFSG's requirements of free redistribution. There are even existing *copyright* licenses which place restrictions on advertising (i.e., the original BSD license) that we consider free. Simply put, a trademark license, even a restrictive one, has no impact on DFSG compliance because it's unrelated to whether or not you use the software in question. You can infringe the moodle trademark by calling your service moodle /without ever using moodle at all/; that it's still possible to infringe this trademark when using the moodle software is therefore not an issue for the freeness of the package. Also, please don't ask trademark holders for permission to package software under the trademarked name; this only leads to the confused belief that we *need* such permission to use trademarks as package names, and we don't. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Moodle trademark
On Sun, Sep 12, 2010 at 08:53:44PM -0600, Morgan Gangwere wrote: On 9/12/2010 8:42 PM, Steve Langasek wrote: Simply put, a trademark license, even a restrictive one, has no impact on DFSG compliance because it's unrelated to whether or not you use the software in question. PMI, but isn't that exactly opposite the reasoning behind the Firefox/Iceweasel rebrand? The iceweasel rebranding was done in response to a restrictive *copyright* license on the firefox logo. This combined with the hard-line stance taken by upstream regarding the use of their name led the maintainer to decide that the best course of action was to rename the package; but the rename was done at the maintainer's discretion, only the firefox logo was actually a DFSG problem. Also, please don't ask trademark holders for permission to package software under the trademarked name; this only leads to the confused belief that we *need* such permission to use trademarks as package names, and we don't. Isn't it a good idea to CYA when you're not sure? Or has Debian taken an Ask for forgiveness later rather than permission now policy? If you want to CYA wrt legalities, you should be asking Debian *legal counsel* for advice regarding how to handle it - not running off and asking for permission for things we already have a right to do. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Distribution of media content together with GPLv2 code in one package?
On Sun, Apr 04, 2010 at 08:11:26PM -0700, Walter Landry wrote: Steve Langasek vor...@debian.org wrote: On Mon, Apr 05, 2010 at 12:22:53AM +0200, Francesco Poli wrote: However, it is my opinion that works with unavailable source do not comply with DFSG#2, regardless of the license. Your opinion is not relevant. The text of the DFSG is what's relevant, and the text says that *programs* must include source code, not arbitrary non-program works distributed in Debian. That was voted on 2004 and Debian decided that you are incorrect. It is time to move on. No, it did not. Debian decided that all works must comply with the DFSG. DFSG #2 does not apply to non-program works. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100405065245.ga23...@dario.dodds.net
Re: Distribution of media content together with GPLv2 code in one package?
On Mon, Apr 05, 2010 at 12:22:53AM +0200, Francesco Poli wrote: However, it is my opinion that works with unavailable source do not comply with DFSG#2, regardless of the license. Your opinion is not relevant. The text of the DFSG is what's relevant, and the text says that *programs* must include source code, not arbitrary non-program works distributed in Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20100404230042.ga21...@dario.dodds.net
Re: is CC BY 3.0 DFSG-free, again
Hi Sean, On Sun, Jan 24, 2010 at 01:58:23PM -0700, Sean Robinson wrote: I have looked around and not found a definitive answer to whether CC BY 3.0 is DFSG-free. http://wiki.debian.org/DFSGLicenses mentions CC BY-SA 3.0, but not CC BY 3.0. And previous discussions on this list have been unclear on a distinction and unresolved about their status wrt DFSG. I don't know which previous discussions you refer to, but reviewing the licenses, the *only* difference I see between CC BY 3.0 and CC BY-SA 3.0 is that CC BY-SA includes an *additional* restriction relative the CC BY (the copyleft requirement). Therefore, if CC BY-SA 3.0 is ok, CC BY 3.0 is also ok. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: BOINC: lib/cal.h license issue agree with the DFSG?
On Mon, Jan 04, 2010 at 03:07:23PM -0300, Nicolas Alvarez wrote: This choice-of-venue discussion looks like it won't get consensus soon, and it is getting us away from the original thread topic. How about we try this? Let's assume for a moment that choice-of-venue is both acceptable and allowed by the DFSG. Then look at the *rest* of the cal.h license terms instead of continuing the argument about this one. This has already been done. The license doesn't permit modification, so it fails the DFSG. However, it's been pointed out that the header file may not be copyrightable *at all* because it only contains interface definitions. After all, if one clause is DFSG-incompatible, the file is DFSG- incompatible. That's enough to take action (remove the file, contact upstream to remove the file, contact AMD to change header license, move package to non-free, etc); it's irrelevant whether the other clauses are compatible or not. Well, if one of the possible courses of action is to ask AMD to change the license, I recommend having an exhaustive list of DFSG problems with the license ready to hand, lest you find that they try to solve this by editing their license to address *only* the issue you've mentioned. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: BOINC: lib/cal.h license issue agree with the DFSG?
On Sun, Jan 03, 2010 at 12:01:15AM +0100, Andrew Dalke wrote: By that reasoning, if your cause is indeed just, and worthy, then I don't see why the same view doesn't apply to possible copyright suits. Because I'm arguing from the position that modern copyright regime is, as a whole, just, and that it's warranted for software authors to have limited monopoly rights over their works. If the copyright system is just, then authors have a right to ask you not to use their works in violation of the law, *even when that law is itself unjust*. An ethical citizen engaged in an act of civil disobedience should not have to worry about whether he's violating the wishes of a copyright holder by using Debian in the process. But this all follows directly from DFSG #6, anyway. Licenses must not discriminate against fields of endeavour to be considered free - even fields of endeavour that are illegal. Who's to say that the copyright owner doesn't agree with you? The copyright owner might agree with me, but that's DFSG #8 - if the copyright owner gives me a personal license to use his software in acts of civil disobedience that she agrees with, that's still not sufficient for including the work in main. Or put it this way, if the software said you may use this for illegal purposes then that could be seen as promoting breaking the law. That would be an absurd thing to put in a license, because *by default* your compliance with the law is a matter between you and the state, not between you and the copyright holder. So the license can remain mute on the question, as all DFSG-free licenses I've seen are. Otherwise I'm going to say that my not following the GPL is justifiable civil disobedience Er, go ahead and say that, but then you're entirely missing the point. If the copyright owners of embedded software for vehicles, and of GPS systems, had the same clause, do you think they would be suing people for copyright infringement every time you went over the speed limit? What I think is that the possibility that they *could* sue means such a license fails the DFSG. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: BOINC: lib/cal.h license issue agree with the DFSG?
On Sat, Jan 02, 2010 at 12:45:19PM -0800, Sean Kellogg wrote: While looking up the specific clauses for disclaimer and liability, I noticed section 12 of GPLv3. Curious as to how that clause is not essentially the same as the non-export clause? As a resident of the United States, I am bound by its laws. As I read (s)12, if those laws prohibited me from complying with a clause of the GPL, I lose the license granted by the GPL. Sure sounds like a don't do anything illegal clause to me. On the contrary, the GPL only says that you can't use the /law/ as an excuse for not complying with the /license/. The language leaves open the possibility that you might choose to continue distributing a work in compliance with the GPL but in violation of the law. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: BOINC: lib/cal.h license issue agree with the DFSG?
On Fri, Jan 01, 2010 at 03:13:58PM -0800, Sean Kellogg wrote: On Friday 01 January 2010 2:57:18 pm Francesco Poli wrote: /* Copyright (c) 2007 Advanced Micro Devices, Inc. All rights reserved. Redistribution and use of this material is permitted under the following conditions: I cannot find any permission to modify or distribute modified versions of the file. This seems to fail DFSG#3. What?! The grant is /right/ there... Redistribution and use of this material is permitted provided the following criteria are met, and then it lists the criteria. I suppose it could be its own little bullet point, but that sure seems explicit to me. That you failed to see that as a grant really calls into question the neutrality of the rest of your license evaluation. The grant covers redistribution and use. It's my understanding that neither redistribution nor use encompasses modifications under copyright law, and Debian has consistently required an explicit grant of permission to modify and to distribute the resulting modified works in order to be considered DFSG-compliant. THIS MATERIAL MAY NOT BE USED, RELEASED, TRANSFERRED, IMPORTED, EXPORTED AND/OR RE-EXPORTED IN ANY MANNER PROHIBITED UNDER ANY APPLICABLE LAWS, INCLUDING U.S. EXPORT CONTROL LAWS REGARDING SPECIFICALLY DESIGNATED PERSONS, COUNTRIES AND NATIONALS OF COUNTRIES SUBJECT TO NATIONAL SECURITY CONTROLS. Enforcing export control laws (or other laws), through a copyright license is not a good thing to do, IMHO. I think that, if I violate some export control law, I should be prosecuted for breaching that law, without *also* having to face copyright violation suits. Not saying I disagree, but your position on how export laws should be enforced really isn't at issue here. The problem AMD is addressing here is third party liability if someone where to violate US export laws. Is this clause really any different than you aren't allowed to do anything illegal with this software? No, it's not different at all - and a license that says you aren't allowed to do anything illegal with this software is *not* DFSG-compliant. Civil disobedience should not result in violations of the copyright licenses of software in Debian. And, if so, does the DFSG really prohibit a developer from proscribing the use in that manner and thus exposing the developer to a whole RANGE of contributory liability? Yes, it really does (assuming there's any contributory liability to be found here, anyway). This is a choice of venue clause. Choice of venue clauses are controversial and have been discussed to death in the past on debian-legal: my personal opinion is that they fail to meet the DFSG. A fight that has been lost many times... choice of venue is fine. Yes. I don't like choice of venue clauses, but the project has decided they are acceptable, and it's not appropriate to inject one's personal dissenting opinions into a license analysis on this list. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GCC 4.4 run-time license and non-GPLv3 compilers
Hi Florian, On Sat, Nov 21, 2009 at 01:20:15PM +0100, Florian Weimer wrote: It's been suggested to me that it might help Debian move forward on this issue if I provide some background on why Canonical has chosen to not regard this issue as critical for Ubuntu. My personal impression is that Debian does not view this issue as critical, either. Switching the GCC default hasn't happened for other reasons. Well, in conversations with Matthias, I understand that this is currently the main blocker. The FSF has not contacted Canonical requesting a resolution, The FSF generally licenses their code under GPL, version x or later, so they are not affected by this at all. My understanding is that there is a violation of the gcc 4.4 license because the exception is insufficient. So whether or not the FSF holds the copyright on the application /being/ compiled, they're in a position to comment on whether this is the intended result - and in a position to resolve the conflict by amending the exception. Developers who license their code under the GPL, version 2, and no later version, have a reason to complain. The OpenSSL and KDE issues are a precedents showing that we cannot rely on the system library exception for linking to the run-time library here. So the project's position will be slightly inconsistent, but I think we can live with that. In the OpenSSL case, we had definite information that the license conflict would not be resolved. If it came to light that this recent license conflict was deliberate on the part of the FSF, I would certainly support handling it in a consistent manner. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Is distribution of cracked Texas Instruments signing keys illegal according to DMCA?
On Thu, Oct 15, 2009 at 11:23:41AM +0200, Krzysztof Burghardt wrote: Is distribution of cracked Texas Instruments signing keys illegal according to DMCA? This list is not a source for legal advice. If you have questions about the legality of distributing a particular piece of software, you should contact the DPL who can refer the question to SPI's legal counsel. If not, is it legal to remove TI's keys and include rabbitsign in Debian (it will still be usable with community-created 0005 key which anyone can use to sign their own third-party OS). If the only component being disputed are the signing keys, why do you think this would not be legal? Finally, is it possible that signing application is illegal at all, no matter if distributed with or without keys, because it circumvents DRM? There are numerous applications in Debian that can be (and are) used for codesigning. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: issues with the AGPL
On Sat, Aug 22, 2009 at 02:31:38PM +0200, Florian Weimer wrote: All that is for USA, right? Do you know whether it works that way in other countries than USA, and probably UK, Canada and Australia too? There is no such thing as a unilateral contract in Germany. There's no such thing as a unilateral contract anywhere else either. A license is not a contract. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: legal questions regarding machine learning models
On Wed, May 27, 2009 at 11:42:46PM +0200, Francesco Poli wrote: On Wed, 27 May 2009 11:37:56 +0200 Steve Langasek wrote: On Wed, May 27, 2009 at 10:33:52AM +0200, Josselin Mouette wrote: Disclaimers, of course: IANADD, TINASOTODP (and IANAL, TINLA). If you really feel the urge to add meaningless acronyms to all your emails, please do so in your signature. Better yet: he should recognize that the reason he needs to add all these acronyms is because his posts are an inappropriate use of this mailing list and not productive, and stop posting. You're not new to such impolite replies, and I don't think your reputation benefits from them. I think it has no negative impact on my reputation with anyone whose opinion I value. Which most explicitly does not include you. You use this mailing list as your own personal soap box for advancing positions that have been *rejected* by Debian. That is not acceptable. The purpose of this list is to help Debian developers and upstreams understand Debian's policy for the main archive, and as a forum for Debian as a whole to work on refining that policy. You don't appear to contribute anything to Debian except the crap you spew on this mailing list. You are therefore *not* part of Debian. IANADD disclaimers do *not* excuse you abusing this list in order to shove your opinions down others' throats, when you know damn well that the project does not agree with you. So shut up already. Anyway, if disagreeing with FTP masters and expressing one's own opinion (while *explicitly* clarifying that what is expressed is just one's own opinion, and not necessarily the official Debian position) is an inappropriate use of this mailing list, then I suggest that the list is shut down as soon as possible and that debian-le...@l.d.o is turned into a forwarder to ftpmas...@d.o ... I would be much happier with having debian-legal shut down than with continuing a status quo that permits opinionated hangers-on like you to repeatedly twist the discussion to suit your personal agenda. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: mono and moonlight distribution method make me worried.
On Fri, May 29, 2009 at 11:05:56PM +1000, Peter Dolding wrote: This is going to cause upset I know pushing all the .net applications out of mainline.My problem here is legal status. Debian has to protect all its uses commercial and non commercial a like. Mono is going to have to be treated like patent restricted formats. Mono just happens to be one. Mono is treated like patent-restricted formats: we don't consider the existence of a software patent claim to be a sufficient reason to remove software from main. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: legal questions regarding machine learning models
On Wed, May 27, 2009 at 10:33:52AM +0200, Josselin Mouette wrote: Disclaimers, of course: IANADD, TINASOTODP (and IANAL, TINLA). If you really feel the urge to add meaningless acronyms to all your emails, please do so in your signature. Better yet: he should recognize that the reason he needs to add all these acronyms is because his posts are an inappropriate use of this mailing list and not productive, and stop posting. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian trademark
On Mon, May 04, 2009 at 12:35:34PM +0100, MJ Ray wrote: behrad eslami behrad...@yahoo.com wrote: if i register debian domain linke debian.ir or debian-ir.com for run the debian forume or user group, did it confilict with debian trademark? did i need any permission to use debian name for run website about debian. If it's a site for users of debian and not a business, it probably didn't need any permission, but I'd let the Debian Project Leader know you exist and get clear agreement if I were you. Read http://www.debian.org/trademark and email lea...@debian.org Not that I think we want people not formally affiliated with the Debian project registering domains using the name debian in any case, but I'm pretty sure we don't have a registered trademark in Iran and suspect we would find it hard to hold one. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sapphire.cpp -- Gpl compatible? DFSG-free?
On Fri, Apr 24, 2009 at 10:52:44AM +1000, Ben Finney wrote: Andrew Donnellan ajdli...@gmail.com writes: Well, it's public domain, so there's no restrictions on it and it should be fine. (Although there is some debate going on about whether it's in fact possible to disclaim copyright in some jurisdictions, but I highly doubt the author will try to enforce anything.) This is no guarantee against the author later realising they still hold copyright, changing their mind on their generosity, and enforcing their copyright on those who have violated that copyright. More significantly, it is no guarantee against *some other party* later realising they have (by whatever means) obtained the original author's copyrights, and deciding to enforce them. In other words, this assumption fails the “Tentacles of Evil” test. Wow. Please stop pretending that you have any clue at all what you're talking about. Andrew, public domain dedications have always been fine for Debian and taken at face value, provided that: - the author's intent is unambiguous (i.e., there isn't a statement this work is in the Public Domain followed immediately by a license that attempts to restrict use of the work), and - the author lives in a jurisdiction where the principles of the public domain, and public domain dedications, are recognized, even if it's not clear under present law how a public domain dedication can be made. This basically means that public domain dedications are ok if the author is in the US, questionable in most other jurisdictions where we would need clarification from someone familiar with the legal systems, and known to be insufficient in Germany. Even in cases where public domain is considered ok for Debian, it's preferable (and IMHO, better meets the goals of anyone wishing to place their work in the PD) that the author also include an explicit, liberal license with an explanation that this is done in case the PD dedication is not recognized as valid. The Creative Commons CC0 license is an effective way to do this: http://creativecommons.org/publicdomain/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Zimbra and Yahoo Public License
On Thu, Apr 16, 2009 at 10:53:08AM -0600, Ean Schuessler wrote: I continue to hold the view that establishing the legal venue gives clarity to the contractual structure of the agreement in a positive way. Its better to have the contract explicitly define which legal operating system it is designed to execute in. Otherwise, the language of the contract may be interpreted in a way radically different than the intent with which it was framed. This is a misstatement of choice of venue. You are describing choice of law, which is entirely different and has never been a matter of serious contention in Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Sun, Mar 29, 2009 at 10:33:38AM +0200, Bernhard R. Link wrote: * Steve Langasek vor...@debian.org [090328 23:46]: And this has all been discussed before. Obviously not often enough for you. Oh, I'd much rather be doing something other than discussing this, but as long as people are going to misrepresent the DFSG to this mailing list and repeat arguments that have already been refuted as if they're canon, it's fairly necessary. Also, a PDF is a program for a certain type of interpreter. A PDF as a program is its own source. You're talking about the preferred format for modification of *documentation*, not a program. There's no reason to expect that two different versions of mumble2pdf are going to output two *programs* that resemble one another in the slightest This is no different to a compiled binary. The argument used to justify the claim that the DFSG requires source for PDF and PS files is that PDF and PS are programming languages. Yet *no one* claims that when you write a text document that you will later postprocess into a PDF, you're writing a program! If what you've written is not a program, then the source document is not the source for a program in any meaningful sense. The difference between a compiler and a mumble2pdf converter is that a compiler's output will algorithmically resemble the original source to the program, no matter how much it optimizes, but two versions of mumble2pdf could output *completely different* programs which are related *only* in the (presumedly) human-readable output they display. - only that they output the same documentation. I concur the problem is less severe with documentation than with programs, as translating to text and reformating is often not that big a loss for documentation. But I think in most cases only a .pdf is still to hard to change to call it free. It's reasonable for you to hold the position that this is not free. But that's not what the DFSG says; and before someone tries to change the DFSG to say this, I would recommend someone try to come up with a brighter line to separate documentation than, e.g., fonts, graphics, sounds, and videos than just more people edit documents. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Sat, Mar 28, 2009 at 08:55:27AM +, MJ Ray wrote: Steve Langasek vor...@debian.org wrote: On Sat, Mar 28, 2009 at 09:51:46AM +1100, Ben Finney wrote: The PDF needs to come with sources to build the corresponding PDF *using only free software in Debian*, or it's not acceptable for Debian. The same needs to be true of any binary in Debian, AIUI. The DFSG does not say this. Source is only mandatory for programs under the DFSG as written. That's taking the example from the explanation to be the complete requirement. It's reading the text of the actual guideline instead of making inferences based on the title. Also, a PDF is a program for a certain type of interpreter. A PDF as a program is its own source. You're talking about the preferred format for modification of *documentation*, not a program. There's no reason to expect that two different versions of mumble2pdf are going to output two *programs* that resemble one another in the slightest - only that they output the same documentation. And this has all been discussed before. The Source missing entry in the REJECT-FAQ is Your packages contains files that need source but do not have it. These include PDF and PS files in the documentation. http://ftp-master.debian.org/REJECT-FAQ.html A recent (Dec 2008) addition with no grounding in the DFSG. If I see PDFs being rejected with this rationale when it's not a question of license compliance (PDFs distributed under the GPL certainly have to have source with them, but that's not a DFSG matter), I certainly intend to dispute it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Sat, Mar 28, 2009 at 09:51:46AM +1100, Ben Finney wrote: Chow Loong Jin hyper...@gmail.com writes: On Fri, 2009-03-27 at 13:57 +, MJ Ray wrote: [...] I'm not sure that it matters what you call the mobile component, if that data file is really some sort of program that has sources which aren't usable. How is that jar different from a PDF in this way? Unless I'm mistaken, a PDF without sources is an issue, but if the PDF comes with sources, this is not an issue. The PDF needs to come with sources to build the corresponding PDF *using only free software in Debian*, or it's not acceptable for Debian. The same needs to be true of any binary in Debian, AIUI. The DFSG does not say this. Source is only mandatory for programs under the DFSG as written. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: feedback on #516997 missing
On Sat, Mar 21, 2009 at 06:16:43PM +0100, Matthias Klose wrote: The bug submitter of #516997 apparently did ask for help on debian-legal before submitting this report, but didn't give any feedback on the upstream response. Please could the people involved with this followup on this report? Looking back at the thread, I see that I was insufficiently verbose in my reply. http://lists.debian.org/debian-legal/2009/02/msg00069.html When I said no as in no, I don't see the ambiguity, I failed to clarify that I meant there is no ambiguity because the wording is unambiguously free to anyone familiar with ordinary legal language - not that it's unambiguously non-free, as Ben Finney seems to maintain. Greg Harris has it right, and Ben Finney as usual is coming up with absurd constructivist non-free readings of licenses. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The copyright of a keyboard mapping and its implementation
On Mon, Mar 16, 2009 at 05:47:55PM +0100, Josselin Mouette wrote: there are two available layouts for French Dvorak keyboards. One of them, which is the cause of my concern, was written by Francis Leboutte, and was originally distributed as a (non-free) Windows driver. I started then to make another implementation of the same mapping, for X11. It soon turned out that the mapping forces to use dead keys, which sucks, so I used a variant that removes this need. Several people asked me of a French Dvorak layout, so I started to distribute it under the X11 license, and it finally ended up in the official X.org tarballs. Later, Francis Leboutte started to license the *layout* (not only the Windows driver) under a clearly non-free license (CC-NC-ND), and asked X.org to remove the driver, arguing that the X11-licensed version is illegal, being a derivative work of his layout. The X.org guys finally agreed to distribute the original variant instead, with the following licensing header: // Licence : X11 (the layout itself is released under CC-NC-ND licence) What in a keyboard layout is claimed to be original expression? Unless there are copyrightable comments, which can be stripped out, I don't think there's anything here that we should recognize as covered by copyright at all. Keep the keyboard mapping we currently have in X if it's useful (correcting the claim that there are restrictions on modification), or replace it with one that works better for the users. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: python-imaging
On Wed, Feb 25, 2009 at 04:31:10PM -0500, Jonathan Bastien-Filiatrault wrote: Ben Finney wrote: Greg Harris glhar...@panix.com writes: But that wording is *not* what has been used for ‘python-imaging’. Instead, the wording is: Permission to [foo] for any purpose and without fee is hereby granted, I find that wording rather ambiguous, in my mind it could mean any of the following: * You may [foo] for any purpose, without paying a fee * You may [foo] for any purpose, as long as you do so without fee Does anyone else see this ambiguity ? No. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#509287: Please give opinion about Bug#509287: afio: license is non-free
/381df257b583954e Counterargument: Although Mark was responsible for drafting the license and, we presume, had approval from the copyright holder (his employer) for this, we cannot infer that the copyright holder had any expectation that the work would be modified once released on USENET. Mark may have had this expectation as a developer familiar with the conventions of this USENET community, whereas the copyright holder may not have - and Mark may not have had a fiduciary responsibility to police modifications made to the work after release to the newsgroup. Consequently, demonstrating that Mark knew modifications would happen once posted to the community may not be sufficient for an estoppel defense. (If Mark can attest that his employer did know of the consequences of his posting the work to the newsgroup, I think that would negate this counterargument.) F. The license holder knew that it was common practice to modify code posted to comp.sources.unix. To illustrate that Lachman Associates would have been well aware of the practice of extending software tools in the context of the comp.sources newsgroups: in 1989, two Lachman employees greatly extended a terminal emulator program written by someone else in 1986, and posted their extended version to comp.sources.atari.st, see: http://groups.google.com/group/comp.sources.atari.st/msg/95d006760c056af1 Combined with the previous point, this is strong, but not conclusive, evidence that the copyright holder approved of modifications to their work. It is very common for trained lawyers to apply this worst-case-rule, to go by the worst possible interpretation of an ambiguous legal text. In fact, in a multidisciplinary business team, one of the key skills that a lawyer is expected to bring to the table is the skill to find the legal ambiguities and worst-cases. debian-legal trains non-lawyers to do the same thing. :) But that doesn't imply that the Debian project as a whole will feel itself bound by such worst-case scenarios. However, I would argue that applying this worst-case-rule to afio, a historical product of the FOSS community for which the license text cannot be changed anymore, is like throwing out the baby with the bathwater. There is no need to treat afio as if it might be a carefully constructed Trojan horse. Indeed, it's clearly not a Trojan horse, and if the holder of the original copyright did flip out and decide to sue, Debian and anyone receiving the code from Debian would be pretty far down on the list of defendants. We should nevertheless recognize that this is a possibility, and make an informed decision about whether to accept that risk. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Which license am I looking for?
On Wed, Jan 21, 2009 at 11:25:51PM +, Anthony W. Youngman wrote: At the end of the day, what I do, I do it IN ENGLAND, No, you don't. When you post to this mailing list, you are deliberately engaged in an act that crosses national boundaries (both your interlocutors in this discussion, and the lists.debian.org mailserver, are located outside of England), and any choice of law questions will be adjudicated according to the relevant international treaties. You can't lob bombs across the English Channel and expect the recipients not to press charges in French court, and you can't give Americans legal advice over the Internet and expect not to be held to American standards for the same. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please give opinion about Bug#509287: afio: license is non-free
severity 509287 important thanks Hi Erik, On Sun, Dec 21, 2008 at 01:00:16AM +0100, Erik Schanze wrote: Dear debian-legal folks, I got a Bug against package afio because of licence problems. Please see http://bugs.debian.org/509287. There was already a similar Bug 9 years ago that was closed, after one person from this list gave his OK. (http://lists.debian.org/debian-legal/1999/05/msg00162.html) But I think it's not that easy. It seems the clause is problematic. There is an ongoing discussion on a Redhat list https://bugzilla.redhat.com/show_bug.cgi?id=449037 and they excluded the package already. There is an other blog on http://www.kernelplanet.org/fedora/ that gave a summary of the current situation. What should I do? Have I move afio to non-free? Well, http://spot.livejournal.com/303000.html misses the point by a long shot. The original license is not non-free because of prohibitions on sale; there are other licenses we've accepted as free that prohibit direct sale of the software, so long as they allow commercial distribution of the software in a bundle with other software. It's not a *good* license, but it's not a non-free license for failing DFSG#1. If you read the full text of DFSG#1, it's clear that the wording was informed by just such licenses as this. Rather, the original license is non-free because it lacks any permission to *modify*. Since this is not a right that we have by default under copyright, if we don't have a license from the copyright holder to modify this software, then it fails DFSG#3. The question is, do we have permission to modify it? Tom Calloway claims that the later licensing notice is invalid because: [S]omeone (oh mysterious unknown person of the internets) decided that afio was pretty darned useful and uploaded it to sunsite (which used to be a pretty good place to dump useful UNIXy things that you found on the internets). At some point, someone at SunSite (again, this person's name is lost to the internets) decided to redefine the licensing terms. [...] Thus, whoever wrote it, took a big leap in IANAL licensing and decreed that the software package as a whole may be distributed under any method that meets the Artistic or LGPL license. So in point of fact, he admits he does *not* know who attached this license to the afio code. The claim that the work is covered by this license may be an unfounded assertion, but so is any claim that this is an invalid license. If specific evidence comes to light that permission was *not* granted by the copyright holder to place the work under the Artistic License, then we should treat this as an RC bug. But unless that happens, there's nothing here that makes the package ineligible for inclusion in main, AFAICS. So downgrading the bug severity is the correct course of action here for that reason. There's also enough cause for doubt here that it's warranted to continue investigating so we can be sure about the real license status; hence the bug should not be closed outright, IMHO. (The lenny-ignore tag is also left in place, reflecting the release team's intent to not treat this as a blocker for lenny if there were a reason to re-raise the severity.) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Non free license?
Hi Pietro, On Sat, Dec 20, 2008 at 08:32:32AM +0100, Pietro Battiston wrote: I'm interested in packaging Shapely, a python library [0]. The library was already packaged once, uploaded and then rejected by ftp-masters: I tried to get the reason but didn't get a response from (eventual) maintainer, neither from ftp-masters. In the end, I'm repackaging it from scratch, but also trying to guess what could be the reason of the rejection, and I noticed a not really standard license... but in fact, it's a normal 3-clauses BSD license, with the third clause slightly modified [1]. Could you confirm this license is OK with debian? [0]: http://trac.gispython.org/lab/wiki/Shapely [1]: http://svn.gispython.org/svn/gispy/Shapely/trunk/LICENSE.txt It is recommended that you include license texts verbatim in your mail to debian-legal, so it's clear that everyone is commenting on the same text. Copyright (c) 2007, Sean C. Gillies All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * 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. * Neither the name of Sean C. Gillies nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Yes, this is a normal 3-clause BSD license, with the standard author name substitution, and is perfectly acceptable for Debian main. There should have been a reject email sent by the ftpmasters in response to this upload, if it was rejected out of the NEW queue. Perhaps it was sent to your sponsor? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: gnome-mastermind trademark question
On Tue, Dec 02, 2008 at 09:49:34AM +0100, Miriam Ruiz wrote: It would be better to have a name upstream likes, but if the name is not legally safe for Fedora, it won't be for Debian either and ignoring the problem won't fix it. From the limited context you've provided, there's nothing to indicate that legal safety even enters into this. It's been stated that [Fedora] always rename[s] games which are clones. That's not legal advice regarding the question of whether trademarks are infringed by not changing the game name, it's a description of Fedora's policy - which is, of course, informed by particular cases in which a trademark holder /has/ pressured makers of clone games into changing their names. (But, TTBOMK, there is no actual case law on the question of free software clones infringing trademarks of commercial games, because these tend to get settled out of court - if for no other reason than that it's not usually worth the trouble to contest such overreaching trademark claims in the context of Free Software.) For comparison, Debian's trademark policy, to the extent that we can be said to have a policy, can probably be summarized as: ignore trademarks until a trademark holder presses the issue, then decide whether their claim is frivolous enough that we should consider pushing back; but in any event, give preference to keeping names consistent with upstream. It's also the operating consensus within Debian that package names aren't within the scope of trademark law, since they're functional elements that aren't being traded on in any way - so upstream renames are straightforward to handle with transitional packages. (internal note: We should file a bug to Debian's package about this) Why? IANAL and TINLA, though I have had the pleasure of responding to a trademark CD on behalf of the upstream of a free software game clone. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian logo on quilt; license issues?
Hi KS, On Sun, Nov 09, 2008 at 06:26:34PM -0500, KS wrote: A couple of years ago she wanted to make a quilt for me. As the discussion also involved open source at that time, I asked her why not just make me a small wall hanging of the Debian logo. She has worked on it for the last two years and has come up with a life size (about 6ft high) Debian logo (Open use logo) along with the Debian at the bottom. It is currently being displayed at an exhibition in Phoenix. At the time when I asked her to make it, I thought it would not be a problem as it was open use logo. But while browsing again on the Debian Logos page, I noticed the debian trademark licensing policy http://www.debian.org/trademark . Can the experts give their advice on this regarding any licensing issues involving the quilt artwork. The trademark page linked above covers licensing of the trademark on the name Debian. The trademark status of the Debian swirl is unfortunately fuzzy at the moment. However, assuming we do have a valid, enforceable trademark on the logo, it's my belief that you still wouldn't need a trademark license to use the logo for unrelated activities like making quilts. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AGPL and Debian
On Fri, Nov 28, 2008 at 12:42:09PM +0100, Joerg Jaspert wrote: recently we, your mostly friendly Ftpmaster and -team, have been asked about an opinion about the AGPL in Debian. The short summary is: We think that works licensed under the AGPL can go into main. (Provided they don't have any other problems). This is ambiguous because there has been more than one version of the AGPL over time. Can you please clarify which version of the AGPL this statement is meant to apply to, or if it's meant to apply to all versions? (I believe earlier versions of the AGPL had been rejected by ftpmasters previously, due to practical problems with the implementation of those licenses.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open logo license changed
On Sat, Nov 15, 2008 at 01:32:21PM +, MJ Ray wrote: Others have asked both DPL and Debian Press Team to announce it - without answer as far as I know. I'm not surprised that it hasn't been announced, because my last call to debian developers about trademarks was answered by fewer than 20 developers. Presumably you're referring here to the irrelevant straw poll you ran a while back, which wasn't worth responding to for reasons unrelated to my opinions on trademarks. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Alternatives to Creative Commons
On Thu, Sep 18, 2008 at 10:34:03AM -0400, Arc Riley wrote: On Thu, Sep 18, 2008 at 9:38 AM, Jamie Jones [EMAIL PROTECTED]wrote: Multiple tar.gz files could probably fix that - or requiring users to checkout from the revision control system. GPLv3 section 5c (note bold text): c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, *regardless of how they are packaged*. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. Clearly you cannot escape the terms of the GPL by splitting the work into different packages, otherwise everyone would do this. This is a circular argument. You have not established that the data and code comprise a single work under copyright law. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AGPLv3 DFSG-free?
On Mon, Sep 01, 2008 at 01:49:38PM -0500, Jordi Gutiérrez Hermoso wrote: 2008/9/1 Christofer C. Bell [EMAIL PROTECTED]: The AGPLv3 requires you to re-export that code in the event that you modify server software using it -- even if exporting crypto is illegal for you. This is not an issue. A license can't force you to do something that contradicts a higher law. Uh, no. If the license contradicts the law, then *you don't have a valid license*. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and OpenSSL in libs3
On Sat, Aug 16, 2008 at 03:31:29PM +0200, Simon Josefsson wrote: 1) If the library is conditionally compilable against either curl+openssl or curl+gnutls, only dynamically links against either (neither the library nor user executables would directly reference openssl or its symbols), and doesn't make direct use of the library (the aforementioned crypto primitives can be replaced with public domain reference implementations), wouldn't this be sufficient to make the library's users not derivative works of openssl, and thus allow ordinary GPL code to link? That needs to depend on the system library clause in the GPL for libssl, and libssl isn't considered a system library in Debian as far as I understand. libssl is a system library; the system library clause in GPLv2 can only unambiguously be used by software which is /not/ distributed as part of the system itself. In GPLv3 the wording is different but the conclusion is the same; the FSF doesn't mean for OpenSSL to get an exception by default. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Misuse of Debian logo for City Tourism
On Sat, Aug 02, 2008 at 10:04:07PM -0700, Claire Connelly wrote: There are 9624 registered U.S. trademark designs incorporating spirals.* Many of these are somewhat similar to one another; there are typically other elements (e.g., colors, wordmarks, number, arrangement) that differentiate them from one another. Taking a step back, though, I don't see evidence that Debian's logos are trademarked at all, at least in the U.S. Searching the USPTO database shows a single hit for Debian, for the word-only mark ``Debian'' as applied to ``Computer Utility and Operating System Software'' [0]. That trademark is held by SPI. The detailed file [1] includes two sets of ``specimens'', one of which is a screenshot of the Debian.org website showing the spiral logo, but the other includes images of a CD and the docs for Debian 1.3, which have a cute stack of letter blocks arranged to spell Debian.** So if the spiral logo isn't trademarked, then any infringement claims related to the logo have to fall back on copyright, which covers the specific expression and not the general theme. Under US law, trademarks exist when one trades on them, not just when one registers them. We *should* register the Debian logo as a trademark with the USPTO (and I think this is still under way... I hope?), but the continued delays in registration don't mean it's not a trademark, it just makes it harder to enforce it. But under trademark law, there's no reason to think that this city's video is infringing, since it's nowhere near the same field... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
