Re: [License] Gsas-II
MARIE Alexandre writes: > I would like to know if the license of Gsas-II is free to use. Thank you for taking care to keep software free for all. Especially thank you for posting the license text here for discussion. > Here is the license : > __ > General Structure Analysis System - II (GSAS-II) > OPEN SOURCE LICENSE > > Copyright 2010, UChicago Argonne, LLC, Operator of Argonne National > Laboratory > All rights reserved. > > GSAS-II may be used by anyone on a royalty-free basis. Use and > redistribution, with or without modification, are permitted provided > that the following conditions are met: Explicitly grants license to resitribute in modified and unmodified form. Good. > * Redistributions of source code must retain the above copyright > notice, this list of conditions and the following disclaimer. This is a restriction that is conventionally considered acceptable. Good. > * Software changes, modifications, or derivative works should be noted > with comments and the author and organization's name. This might be too restrictive; it effectively forbids anonymous contribution and redistribution. > * Distribution of changed, modified or derivative works based on > GSAS-II grants the GSAS-II copyright holder unrestricted permission > to include any, or all, new and changed code in future GSAS-II > releases. This is, IIUC, met by granting every recipient (including GSAS-II) this same license. This seems to be a weaker copyleft (one specific party must receive the same license). I think this is okay, if imbalanced. > * Redistributions that include binary forms must include all relevant > source code and reproduce the above copyright notice, this list of > conditions and the following disclaimers in the documentation and/or > other materials provided with the distribution. This combines two requirements: * A typical requirement to preserve the copyright information and license (good). * A requirement that *every* distribution must come with source code. This may be too burdensome; for example, GPL allows the source to be omitted, requiring only that a recipient who *requests* source must receive it. > * Neither the names of UChicago Argonne, LLC or the Department of > Energy nor the names of its contributors may be used to endorse or > promote products derived from this software without specific prior > written permission. A typical requirement not to misrepresent the attribution of a modified work. Good. > * The software and the end-user documentation included with the > redistribution, if any, must include the following acknowledgment: > "This product includes software produced by UChicago Argonne, LLC > under Contract No. DE-AC02-06CH11357 with the Department of Energy." This is a burden on certain forms of work. This might make the work non-free. There are several problems with the license restrictions. They may make the work effectively non-free. I would recommend the copyright holders express their intent through a more well-known free-software license like GPLv3 or Expat. -- \ “When I wake up in the morning, I just can't get started until | `\ I've had that first, piping hot pot of coffee. Oh, I've tried | _o__)other enemas...” —Emo Philips | Ben Finney
Re: Public domain and DSFGness
David Given writes: > I'm doing some historical data preservation work […] I'm hoping to be > able to produce a Debian package containing this stuff eventually for > use in emulators. Thank you for promoting the preservation and spread of free software. > Back then people were really slack about licensing. Typically > So: from Debian's perspective, what's the degree of proof I need to > provide in order to demonstrate DSFG-ness of works such as this? This is difficult to discuss in the abstract, because it so often depends on peculiarities of the specific works and the documentation surrounding them. We try to keep these discussions to specific works that are actually proposed to enter Debian. Is there a specific work we can examine that you are working to package for Debian? -- \ “I can picture in my mind a world without war, a world without | `\ hate. And I can picture us attacking that world, because they'd | _o__) never expect it.” —Jack Handey | Ben Finney
Re: Custom license conditions and grant for Wordplay package
Moshe Piekarski writes: > On 4/10/19 7:50 PM, Ben Finney wrote: > > * If the formulation “please do foo” is an enforcible *condition* on the > > grant, then there are several such enforcible conditions that make > > this work non-free: > Given that the wordplay package may not meet the DFSG, do I have to > remove it? That may eventually be necessary, if the copyright holder(s) can't be convinced to make a DFSG-compatible grant of license in the work. Before that, it would be better to start a discussion with the copyright holder(s) to get a more robust grant under free software conditions. The existing Read Me document gives some hope here: * The spirit of the existing grant seems to be “I want this software to be useful to the world as free software”, which indicates that a future release under a GNU GPLv3-or-later grant could meet their wishes. * The copyright holder clearly wants to be contacted about this and about people building on the work. Let's hope the contact details still work! * So far there seems to be only one copyright holder in the work, which may make it easier to get a change of license grant. You could discuss with them to confirm whether this is still true for the work. -- \ “Following fashion and the status quo is easy. Thinking about | `\your users' lives and creating something practical is much | _o__)harder.” —Ryan Singer, 2008-07-09 | Ben Finney
Re: Custom license conditions and grant for Wordplay package
Ben Finney writes: > = > -- > > Wordplay Version 7.22 Evans A Criswell 03-20-96 > > -- > > This program was written for fun and is free. Distribute it as you please, > but please distribute the entire package, with the original words721.txt and > the readme file. If you modify the code, please mention my name in it as the > original author. Please send me a copy of improvements you make, because I > may include them in a future version. > > I may be contacted by email at crisw...@cs.uah.edu > > Evans A Criswell > Research Associate > Computer Science Department > University of Alabama in Huntsville > Huntsville, AL 35899 > > -- > = There is a significant ambiguity in this text, and I'm pretty sure we would find it problematic if this work were submitted today. The ambiguity is: What is the effect of “please do foo” in the context of a copyright license grant? * If the formulation “please do foo” is an unenforcible *request* to do foo, then there are no conditions in this grant. Under this interpretation, the legal effect is entirely in “Distribute [this program] as you please”. * If the formulation “please do foo” is an enforcible *condition* on the grant, then there are several such enforcible conditions that make this work non-free: * There is no permission granted to modify the work as the recipient pleases and to redistribute that modified work (instead, this is conditional on “distribute the entire package […]”). This fails DFSG§3. * There is an explicit clause preventing redistribution of parts of the work. This fails DFSG§1 and DFSG§3. * There is an explicit requirement that the person redistributing must send a copy to a specific party. This therefore fails DFSG§1 and DFSG§3. (See the thought experiments at https://people.debian.org/~bap/dfsg-faq.html> for why.) So it seems that the only way this work can be considered free is if we take all the “please do foo” as mere unenforcible requests that don't place any restriction on the recipient. I don't know whether a copyright case would be decided that way by a judge; it seems at least likely that a judge would take “[grant of permission], but please [do foo]” as an expression of the copyright holder's intent to restrict the license grant. -- \ “I bought some batteries, but they weren't included; so I had | `\to buy them again.” —Steven Wright | _o__) | Ben Finney
Custom license conditions and grant for Wordplay package (was: license compatibility)
debian.mailingli...@melachim.net writes: > What is the work we are discussing? Can we see the full source online > somewhere (to see its entire license grant)? (That was written by me in a previous message, but it's appearing in the material you wrote. I think something is failing in your message quoting set-up, which is likely to make discussion confusing. Would you like help fixing that? Contact me off-list if you need my help there.) > http://deb.debian.org/debian/pool/main/w/wordplay/wordplay_7.22.orig.tar.gz For reference in this thread, the license grant contained there appears to be, in its entirety, this text from the Read Me document: = -- Wordplay Version 7.22 Evans A Criswell 03-20-96 -- This program was written for fun and is free. Distribute it as you please, but please distribute the entire package, with the original words721.txt and the readme file. If you modify the code, please mention my name in it as the original author. Please send me a copy of improvements you make, because I may include them in a future version. I may be contacted by email at crisw...@cs.uah.edu Evans A Criswell Research Associate Computer Science Department University of Alabama in Huntsville Huntsville, AL 35899 -- = I'll comment on that text in a separate message. -- \ “It's easy to play any musical instrument: all you have to do | `\ is touch the right key at the right time and the instrument | _o__)will play itself.” —Johann Sebastian Bach | Ben Finney
Re: license compatibility
Moshe Piekarski writes: > Can I re-release code written under this license as gpl-2? What is the work we are discussing? Can we see the full source online somewhere (to see its entire license grant)? -- \ “Of all classes the rich are the most noticed and the least | `\ studied.” —John Kenneth Galbraith, _The Age of Uncertainty_, | _o__) 1977 | Ben Finney
Re: Please advise regarding DFSG compliance of WPL-2
Giacomo Tesio writes: > On Mon, 18 Feb 2019 at 16:20, Joerg Jaspert wrote: > > Best: Someone (read: License author) could publish a translation > > that is not saying "I'm rubbish". > > Are you sure that it's entirely possible? Yes. It's up to the party publishing the license whether they claim the translation represents what they want to communicate. > It's not always possible to perform a lossless translation between two > human languages, and I'm not sure if having two not perfectly > equivalent licenses is such a best practice. That's not what Joerg proposed. It doesn't need to be perfect, it needs meet only the lower bar that the party publsihing that text stands behind its meaning as accurately representing their communication. In the absence of that, it's not for anyone else to authoritatively claim that they have an accurate representation of the license author's meaning. So it's a problem that can only be addressed by the license author/publisher. Publishing a translation, while simultaneously saying “this translation can't be relied on”, is totally worthless for a legal text with precise meanings. -- \“We should be less concerned about adding years to life, and | `\ more about adding life to years.” —Arthur C. Clarke, 2001 | _o__) | Ben Finney
Re: Please advise regarding DFSG compliance of WPL-2
أحمد المحمودي writes: > This is the authoritative Arabic version of the license [Waqf Public > License 2.0], followed by the informal English translation of the > license. Thank you for providing both in this mailing list thread, for examination. The freedom or otherwise of software is in part dependent on the explicit text granting license for that software under the specific conditions. What software is distributed with a grant of Waqf General Public License 2.0? Where can we see the grant of license explicitly stating that? -- \ “The enjoyment of one's tools is an essential ingredient of | `\ successful work.” —Donald Knuth, _The Art of Computer | _o__) Programming_ | Ben Finney
Re: redistribution of the ARIN TAL
Marco d'Itri writes: > ARIN believes that they have a right to limit distribution of this RSA > public key (used for verification of routing security): > […] > And they are arguing that people cannot download this file from > a well-known location without first agreeing to some conditions. Where can we read those claims and the specific conditions they wish to apply? > (Please Cc: me on replies.) Done. -- \“Absurdity, n. A statement or belief manifestly inconsistent | `\with one's own opinion.” —Ambrose Bierce, _The Devil's | _o__)Dictionary_, 1906 | Ben Finney
Re: Bug#919356: Licensing of include/linux/hash.h
Jens Axboe writes: > On 2/11/19 11:27 PM, Ben Finney wrote: > > If, on the other hand, the file is to be free software, there would need > > to be a clear grant of some free software license to that work. > > FWIW, fio.c includes the following mention: > > * The license below covers all files distributed with fio unless otherwise > * noted in the file itself. > > followed by the GPL v2 license. Great! That does appear to be a positive assertion from the copyright holder, that we have a grant to use that work under GPLv2. That written grant of license can be used in the Debian package to demonstrate our license to the work. > I'll go through and add SPDX headers to everything to avoid wasting > anymore time on this nonsense. Not necessary from my point of view for this specific case, because we have the clear explicit grant of license. Don't let me stop you from doing the good work of documenting more clearly :-) -- \ “Come on Milhouse, there’s no such thing as a soul! It’s just | `\ something they made up to scare kids, like the Boogie Man or | _o__) Michael Jackson.” —Bart, _The Simpsons_ | Ben Finney
Re: Bug#919356: Licensing of include/linux/hash.h
Martin Steigerwald writes: > Well the file has in its header: > > /* Fast hashing routine for a long. >(C) 2002 William Lee Irwin III, IBM */ > > /* > * Knuth recommends primes in approximately golden ratio to the maximum > * integer representable by a machine word for multiplicative hashing. > * Chuck Lever verified the effectiveness of this technique: > * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf > * > * These primes are chosen to be bit-sparse, that is operations on > * them can use shifts and additions instead of multiplications for > * machines where multiplications are slow. > */ > > It has been quite a while ago. I bet back then I did not regard this > as license information since it does not specify a license. Thus I > assumed it to be GPL-2 as the other files which have no license boiler > plate. I.e.: Check file is it has different license, if not, then > assume it has license as specified in COPYING. > > Not specifying a license can however also mean in this context that it > has no license as the file contains copyright information from another > author. If a work (even one file) “has no license”, that means no special permissions are granted and normal copyright applies: All rights reserved, i.e. not redistributable. So, no license is grounds to consider a work non-free and non-redistributable. If, on the other hand, the file is to be free software, there would need to be a clear grant of some free software license to that work. Given the confusion over this file, I would consider it a significant risk to just assume we have GPLv2 permissions without being told that explicitly by the copyright holder. Rather, the reason we are seeking a clearly-granted free license for this one file, is because we are trying to replace a probably non-free file with the same code in it. It seems we need to keep looking, and in the meantime assume we have no free license in this file. -- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
Re: Bug#919356: Licensing of include/linux/hash.h
Martin Steigerwald writes: > Well the file has in its header: > > /* Fast hashing routine for a long. >(C) 2002 William Lee Irwin III, IBM */ > > /* > * Knuth recommends primes in approximately golden ratio to the maximum > * integer representable by a machine word for multiplicative hashing. > * Chuck Lever verified the effectiveness of this technique: > * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf > * > * These primes are chosen to be bit-sparse, that is operations on > * them can use shifts and additions instead of multiplications for > * machines where multiplications are slow. > */ > > It has been quite a while ago. I bet back then I did not regard this > as license information since it does not specify a license. Thus I > assumed it to be GPL-2 as the other files which have no license boiler > plate. I.e.: Check file is it has different license, if not, then > assume it has license as specified in COPYING. > > Not specifying a license can however also mean in this context that it > has no license as the file contains copyright information from another > author. If a work (even one file) “has no license”, that means no special permissions are granted and normal copyright applies: All rights reserved, i.e. not redistributable. So, no license is grounds to consider a work non-free and non-redistributable. If, on the other hand, the file is to be free software, there would need to be a clear grant of some free software license to that work. Given the confusion over this file, I would consider it a significant risk to just assume we have GPLv2 permissions without being told that explicitly by the copyright holder. Rather, the reason we are seeking a clearly-granted free license for this one file, is because we are trying to replace a probably non-free file with the same code in it. It seems we need to keep looking, and in the meantime assume we have no free license in this file. -- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
Re: Bug#919356: Licensing of include/linux/hash.h
Martin Steigerwald writes: > Well the file has in its header: > > /* Fast hashing routine for a long. >(C) 2002 William Lee Irwin III, IBM */ > > /* > * Knuth recommends primes in approximately golden ratio to the maximum > * integer representable by a machine word for multiplicative hashing. > * Chuck Lever verified the effectiveness of this technique: > * http://www.citi.umich.edu/techreports/reports/citi-tr-00-1.pdf > * > * These primes are chosen to be bit-sparse, that is operations on > * them can use shifts and additions instead of multiplications for > * machines where multiplications are slow. > */ > > It has been quite a while ago. I bet back then I did not regard this > as license information since it does not specify a license. Thus I > assumed it to be GPL-2 as the other files which have no license boiler > plate. I.e.: Check file is it has different license, if not, then > assume it has license as specified in COPYING. > > Not specifying a license can however also mean in this context that it > has no license as the file contains copyright information from another > author. If a work (even one file) “has no license”, that means no special permissions are granted and normal copyright applies: All rights reserved, i.e. not redistributable. So, no license is grounds to consider a work non-free and non-redistributable. If, on the other hand, the file is to be free software, there would need to be a clear grant of some free software license to that work. Given the confusion over this file, I would consider it a significant risk to just assume we have GPLv2 permissions without being told that explicitly by the copyright holder. Rather, the reason we are seeking a clearly-granted free license for this one file, is because we are trying to replace a probably non-free file with the same code in it. It seems we need to keep looking, and in the meantime assume we have no free license in this file. -- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
Re: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear
Domenico Andreoli writes: > the situation of dwarves-dfsg improved a lot over the weekend That's good to hear. What is the event you're referring to? Can you give a URL to something that describes this change? > the only knot left is now the license of hash.h > > This file is also present in the kernel [0] with an updated copyright > but still without license. The file you show (in the Linux code base) seems likely to have an equivalent implementation under a different license, from some other code base. > I received a private email from somebody in the kernel community who > already tried to contact Nadia in the past but did not get any reply. Thank you also for contacting the Linux developers forum to ask https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1900588.html>. > I think that pushing it to non-free is formally the right thing but I > actually feel it's not the right thing. To know that work (that file) is free software, we need a clear grant of some specific license, for that work. If the work is not free, it would be incorrect to have the work in Debian. Alternatives, for complying with the Debian Free Software Guidelines with this package, include: * Find a credible grant of license under some GPL-compatible free license to that exact file. Document that explicit grant in the Debian package. This demonstrates the work is DFSG-free. * Convince ‘dwarves-dfsg’ upstream to replace that file with a different implementation (I don't know whether such an implementation exists) under a license compatible with the same version of GNU GPL. Document that explicit grant in the Debian package. This demonstrates the modified work is DFSG-free. * Replace that file in Debian only, with a different implementation as above. Document that explicit grant in the Debian package. This demonstrates the modified Debian package is DFSG-free. * Move the work to the ‘non-free’ area. * Remove the work altogether. Those are in descending order of (my recommended) preference. -- \ “Speech is human, silence is divine, yet also brutish and dead: | `\ therefore we must learn both arts.” —Thomas Carlyle, 1830 | _o__) | Ben Finney
Re: Hacking License
Giacomo Tesio writes: > On Tue, 18 Dec 2018 at 17:22, Ian Jackson > wrote: > > Perhaps you don't care about encouraging, into contributing to your > > project, people who are short of time and who are picky about what > > they spend time evaluating. > > Well, actually this is true. > I'm not looking for contributors, I'm trying to contribute. Then it seems you have no more need for us to evaluate your custom license text. If you have no interest in contributors to your work, you have no interest in the conditions for that contribution. If, on the other hand, you actually want to welcome contributors to collaborate on the work you release, you have received good advice in this discussion on how better to do that. -- \ “True greatness is measured by how much freedom you give to | `\ others, not by how much you can coerce others to do what you | _o__) want.” —Larry Wall | Ben Finney
Re: Compatibility of GPLv2 and Apache v2 (OpenSSL again)
Sebastian Andrzej Siewior writes: > Yes and my understanding is that every GPLv2 software, that links > against openssl, needs such an addon. The alternative being that the resulting work is not legally redistributable (because the terms of both GPLv2 and the OpenSSL license cannot be simultaneously satisfied). So yes, the only way such a work can be distributed conforming to both those sets of conditions if the grant of license gives *more* permissions (such as one you state), at which it's not merely GPL any more. > The wording (of the addon) was drafted on debian-legal a few years > back. Can you give citations to what you're referring to? there have been many such discussions so it would help if we're both talking about the same thing. > So this is true for series 1.1.1 and earlier. The master branch will be > released as 3.0 and some point. So we have some time to clarify this > :) Ah, so this is not a change that has happened yet. Good, thank you for bringing it to our attention so we can discuss it :-) > Please see > https://www.openssl.org/blog/blog/2018/11/28/version/ The part of that article salient for this discussion seems to be: OpenSSL version 3.0.0 will be the first version that we release under the Apache License 2.0. We will not be applying the Apache License to earlier releases of OpenSSL. That doesn't specify the grant of license so it's unclear what the total set of conditions will be. > https://github.com/openssl/openssl/blob/master/LICENSE That is a nearly-verbatim copy of the Apache License 2.0 with no legally substantive changes (only the URL in the header changed to an HTTPS). Merely dropping a copy of the license document doesn't tell use exactly what is the grant of license, as many works (including OpenSSL itself, and as you point out a lot of works that link to OpenSSL) have a complex grant of license that incorporates some combination of conditions. It is not enough to assume that a license document implies the entire grant of license. So we will need to see what exact text is the grant of license (the text saying something like "This is OpenSSL, Copyright © 2018 Foo Bar. You are hereby granted freedom to do X, Y, Z under these explicit specific conditions"). Is the grant of license somewhere in the Git repository to be examined? -- \ “… correct code is great, code that crashes could use | `\ improvement, but incorrect code that doesn’t crash is a | _o__)horrible nightmare.” —Chris Smith, 2008-08-22 | Ben Finney
Re: Hacking License
Giacomo Tesio writes: > thanks to the public and private advices that I received on the last > version, I further improved the Hacking License. Giacomo, I again ask you: please don't impose on the free software community the burden of yet another roll-your-own license text. We already have a minefield of difficult-to-predict interacting clauses just with the *existing* license conditions that are well known. Adding yet another set of conditions massively multiplies the potential set of combinations, making it that much harder to determine whether a given work is free software. Please realise that this is *not* a benefit to the community. > Does this license match the DFSG? In my opinion: * It is impossible to say with any confidence whether this set of conditions makes a work free or non-free, because so many of the clauses are too vague. * It is needlessly burdeonsome to parse the text, because many terms are used in a highly idiosynratic way, and mislead the reader into thinking a term is being used with its traditional meaning when something quite different is meant instead. Please do not keep iterating slight changes to this text and asking for volunteers to spend effort combing through it. You know by now that you can make your work free software by instead choosing an existing well-known free software license, and save everyone a lot of pain. We can spend volunteer, non-expert effort to try to find possible corrections to be made for an existing software work. But that is on a best-effort basis, hoping to reduce the barriers to software freedom. You do yourself no favours in the free software community by trying to get us to evaluate numerous iterations of a license that you have, against all advice, written in the absence of trained legal professionals, to add to the existing body of competing license texts. > Would a package for my library so licensed be included in Debian? > If not, why? This forum can never tell you authoritatively the answer to whether a work would be included in Debian, because this forum does not make those decisions. As for “why”: If a work under this license text were submitted for inclusion in Debian, I think it would be quite reasonable for the FTP masters to reject it solely because the license text makes it too difficult to determine whether the work is free or non-free. You are asking to have specific clauses scrutinised and improved, and I appreciate the desire for that. I think any such effort is misguided, despite your evident good intentions. It will not improve software freedom, for the reasons I have stated above. With thanks for your desire to contribute free software to the world: I ask you to choose a license text – such as the Expat license or Apache License 2.0 or GNU GPLv3 – that is well-known to make a work free software, and instead use that license for works you release. -- \ “To have the choice between proprietary software packages, is | `\ being able to choose your master. Freedom means not having a | _o__)master.” —Richard M. Stallman, 2007-05-16 | Ben Finney
Re: Compatibility of GPLv2 and Apache v2 (OpenSSL again)
Sebastian Andrzej Siewior writes: > GPL software has an exception clause in order to link against OpenSSL > which has the advertising clause. This appears to be a statement that any work licensed under GNU GPL has such an exception. That is not true, to my knowledge. > Clamav for instance has this piece: Right. That piece is not part of any version of the GPL; it is an additional clause in the grant for recipients of that specific work (ClamAV). So each work needs to be examined for its specific grant, to see what the full combination of effective license conditions are to the recipient of that specific work. > OpenSSL upstream now switched the license from BSD style to Apache > License 2.0. What can you cite for that change? The official OpenSSL site contradicts that claim. According to https://www.openssl.org/source/license.html>, OpenSSL is subject to the conditions of the terms of both OpenSSL License and, simultaneously, Original SSLEay License. Neither of these is Apache License 2.0. -- \ “I have always wished for my computer to be as easy to use as | `\ my telephone; my wish has come true because I can no longer | _o__) figure out how to use my telephone.” —Bjarne Stroustrup | Ben Finney
Re: Hacking License
Giacomo Tesio writes: > Hi, I've just published a new version of the Hacking License that > receipts some of the objections proposed on debian-legal and on > copyleft-next. > […] > I would really appreciate further feedbacks. Please be aware that this is *not* a forum particularly suited for forming a new copyright license text. We are volunteers specifically focussed on discussing *works for submission to Debian*. I acknowledge that you started discussions in the context of a specific software work, and that is appreciated. However, you are strongly seeking feedback not on the work of software, but on your new license text. That's not a good use of this forum, and this forum is not especially likely to be fruitful for that goal. You have already been told gently that *for the purpose of Debian* we strongly discourage works have new license texts. Trying to come up with a new set of license conditions from scratch, without using legal experts paid to work on the many drafts you'll need to make such a text robust, is a huge waste of many people's time now and in the future. For the sake of anyone who would receive that software, I implore you to not do it, and also to not be under any illusion that this discussion forum is a suitable way to meet that goal. It is not. If you want to release a work of software compatible with Debian, please do everyone – yourself included – a huge favour and choose an existing, well-understood, known-by-copyright-experts-to-be-effective free license already used for many existing software works. -- \ “All my life I've had one dream: to achieve my many goals.” | `\—Homer, _The Simpsons_ | _o__) | Ben Finney
Re: Does Debian itself have a license?
Ole Streicher writes: > This however covers only the *source* of the package, not the binary > packages. There is no way to find out the license of the binary > packages without checking very carefully the sources and the way the > package is created. So, the end user does not know what he is allowed > to do with a certain (binary) Debian software package. You're right, that is a practical shortcoming which impacts Hong Xu's concern about the feasibility of that effort. That is a matter which should IMO be discussed more broadly than ‘debian-legal’. This is because it's much more about tools and installation locations and how users get information. It's actually AFAICT not much to do with the copyright information of packages, only about how to get that information once the packages are installed. -- \ “Pinky, are you pondering what I'm pondering?” “Well, I think | `\ so, Brain, but ‘apply North Pole’ to what?” —_Pinky and The | _o__) Brain_ | Ben Finney
Re: Does Debian itself have a license?
Hong Xu writes: > The metadata of packages include information package descriptions, > dependencies, etc. that were created by Debian developers. Thanks for clarifying. Okay, that seems to describe the Debian packaging files, a work that sometimes is part of the upstream work but often is a separate work combined with the upstream work. > It seems to me that the copyright file of package does not describe > the license of this information since the copyright holder seems to be > always the upstream copyright holders. You're right to question this. The files that constitute Debian packaging often have copyright held by parties different from the upstream work. In those (many) cases, the distinct copyright information for the Debian packaging should be described explicitly in the source package's ‘debian/copyright’ (and therefore be installed as part of the binary packages created from that source). > For example, /usr/share/doc/bash/copyright reads "Copyright (C) > 1987-2014 Free Software Foundation, Inc." Although the author of the > packaging "Matthias Klose " is mentioned, there is no > license claimed for his packaging work. I consider that to be a bug worthy of reporting. (The absence of explicit grant of license for the packaging work is a violation of Debian Policy §4.5.) It will be a bug that many packages in Debian have, so you might want to co-ordinate a response. After discussion you might find the response is “this isn't urgent because it has been this way for decades”. Or you might find a different consensus. Be aware of the Debian Developer's Reference guidance on reporting a bug to many packages at once (in brief: don't until you discuss it with the package maintainers and achieve consensus) https://www.debian.org/doc/manuals/developers-reference/ch07.en.html#submit-many-bugs>. > As far as I know, there are a lot of cases where default configuration > files in Debian are handcrafted, either from scratch or modified from > those in the upstream package. The copyright document for a package must (Debian Policy §4.5) contain comprehensive copyright information for all the package, whether originating from upstream or from Debian maintainers or anywhere else. So I think that every part of Debian is required to have its copyright information declared explicitly in the ‘copyright’ document of one or more installed packages on the system. If you know of an exception, let's discuss that; otherwise I think the response is to talk about specific packages that fail to meet that requirement. -- \ “From the moment I picked your book up until I laid it down I | `\was convulsed with laughter. Someday I intend reading it.” | _o__) —Groucho Marx | Ben Finney
Re: Does Debian itself have a license?
Hong Xu writes: > I understand that each piece of software has its own license in Debian > and they can be easily looked up. However, I have trouble finding the > license of the Debian itself, e.g., metadata of packages, default > configuration files created by the Debian project, etc. Can you > provide any information on that? Thanks! My understanding is that the entire operating system is delivered as packages, and each package declares its copyright information in its ‘/usr/share/doc/$PACKAGENAME/copyright’ document. The “metadata of packages” I am not sure what you mean? To my knowledge all the metadata is part of the source form of the package, and so is subject to the license conditions described for that package. Is there something else you refer to as “metadata of packages”? Maybe you mean data that is auto-generated by running some tool on the source package. If so, and again in my own understanding, the resulting work is (a) not affected by new copyright restrictions because, being auto-generated, no creative transformation has occurred, and (b) therefore all the same license conditions apply as for the source works from which it was generated. The same would be true for any default configuration files. They will be auto-generated (maybe even, simply copied) from some files installed from a specific package, and so are subject to whatever general license conditions apply for each package. > Example: Fedora provides a license for the compilation of the project: > <https://fedoraproject.org/wiki/Legal:Licenses/LicenseAgreement>; and > so does CentOS (License agreement upon first boot). I am not aware of any such explicit declaration for the entirety of Debian as a whole work. -- \ “The Initial Mystery that attends any journey is: how did the | `\ traveller reach his starting point in the first place?” —Louise | _o__) Bogan, _Journey Around My Room_ | Ben Finney
Re: DFSG-compatibility of a overly short license [tensorflow dependency]
Lumin writes: > The license for the last libtensorflow.so dependency is very confusing > because it looks quite incomplete, or exetremely overly simplified. Thank you for naming the specific software package, and showing the complete license text. > > https://github.com/tensorflow/tensorflow/blob/master/third_party/fft2d/LICENSE > > > > Copyright(C) 1997,2001 Takuya OOURA (email: oo...@kurims.kyoto-u.ac.jp). > > You may use, copy, modify this code for any purpose and > > without fee. You may distribute this ORIGINAL package. There are no restrictions specified (so we have only the restrictions from copyright law). That explains, I think, the extreme brevity of the text: it grants freedoms without specifying any conditions. The license to redistribute in source or binary form is unconditionally granted (required for DFSG §2). The license to modify is unconditionally granted (required for DFSG §3). However, the license to redistribute derived works is not granted (this violates DFSG §3). By the deliberately emphasised “ORIGINAL package”, this is apparently a deliberate exclusion on the part of the authors of this text. > Is this a free software license? Is it DFSG-compatible? By this analysis, the work is not DFSG-compatible and is not free software. -- \ Moriarty: “Forty thousand million billion dollars? That money | `\must be worth a fortune!” —The Goon Show, _The Sale of | _o__) Manhattan_ | Ben Finney
Re: DFSG-compatibility of X13-ARIMA-SEATS (U.S. federal govt. software)
Sébastien Villemot writes: > I would like to package X13-ARIMA-SEATS¹, which is software developed > at the U.S. Department of Commerce. As such, it is not copyrighted in > the U.S., and rights to use, redistribute and modify are explicitly > granted outside the U.S. Thank you for seeking to package and maintain this in Debian. And thanks for posting the full text of the license under discussion. > However, the last clause of the licence says that the “user agrees to > make a good faith effort to use the Software in a way that does not > cause damage, harm, or embarrassment to the United States/Commerce.” > This may be seen as a restriction on use (and therefore contrary to > DFSG§6) The term “use” is too vague, IMO, for help in discussing whether some action is restricted by copyright. You are right to point to DFSG§6, which distinguishes restrictions on “field of endeavour”. I think this case does in part depend on whether “[…] not cause damage, harm, or embarrassment to the United States/Commerce” excludes some field of endeavour. If it does, the restriction fails DFSG§6. > though it is unclear to me whether this is a significant-enough > restriction to make it non-free, and whether it is really enforceable. It is prudent, IMO, to assume that no restriction is beyond being enforced by those who wish to control how recipients use published works. Certainly, restrictions we would have thought trivial in past decades are now taken seriously by international copyright law. So, even if we think the restriction may today not be enforced, the standard should not be enforcibility but whether it conforms to DFSG. > Do you think that this license is DFSG-compatible? I'd like to see discussion of fields of endeavour for a work like this, which may violate the restriction, and whether excluding those would count as a restriction on freedom of endeavour. -- \“[T]he great menace to progress is not ignorance but the | `\ illusion of knowledge.” —Daniel J. Boorstin, historian, | _o__) 1914–2004 | Ben Finney
Re: New license review
Bastien ROUCARIES <roucaries.bast...@gmail.com> writes: > May I ask a review about this license (http://lillicense.org/v1.html, > verbatim below) Which work is being proposed for Debian, that is received with that license? The purpose of this forum isn't to review license texts in isolation, in part because we are not generally qualified to give legal advice. Rather, the purpose is to discuss the legal issues of distributing works in Debian. -- \ “If you always want the latest and greatest, then you have to | `\ buy a new iPod at least once a year.” —Steve Jobs, MSNBC | _o__) interview 2006-05-25 | Ben Finney
Re: W3C FSA (Final Specification Agreement)
Thorsten Glaser <t...@mirbsd.de> writes: > Hi Ben, > > >Debian doesn't consist of licenses; it consists of software works > >under specific grants of license. > > Last time I looked, there was no difference in practice except > for the GFDL. So, DWIM ;-) That's not the case. Without knowing the grant of license, one doesn't know whether the copyright holder permits, for example, redistribution under the GPL version 2 only, or version 3 only, or the GPL version 3 or any later version, or the recipient's choice of GPL version 3 or CC-By-SA 4.0, etc. So it's essential to know what is the specific *grant of license* from the copyright holder to recipients of the work. > >Are you proposing a Debian package of the MusicXML standard? Or some > >other work? > > I was wondering what to do if there was a piece of software > containing the MusicXML specification or DTDs as part of itself. Do you know of such a work, proposed for inclusion in Debian? If not, I think we shouldn't spend much time on speculation :-) -- \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | _o__) later?” —http://www.achewood.com/ | Ben Finney
Re: W3C FSA (Final Specification Agreement)
licensee for infringement of claims essential to implement the Specification or any W3C Recommendation; 10.7.7. may not impose any further conditions or restrictions on the use of any technology, intellectual property rights, or other restrictions on behavior of the licensee, but may include reasonable, customary terms relating to operation or maintenance of the license relationship such as the following: choice of law and dispute resolution; 10.7.8. shall not be considered accepted by an implementer who manifests an intent not to accept the terms of the W3C Community RF Licensing Requirements license as offered by the licensor. 10.7.9. The RF license conforming to the requirements in this policy shall be made available by the licensor as long as the Specification is in effect. The term of such license shall be for the life of the patents in question. I am encouraged to provide a contact from which licensing information can be obtained and other relevant licensing information. Any such information will be made publicly available. 10.8. You or Your. “You,” “you,” or “your” means any person or entity who exercises copyright or patent rights granted under this Agreement, and any person that person or entity controls. = > Is this acceptable for Debian? Debian doesn't consist of licenses; it consists of software works under specific grants of license. So it matters what specific grant the Debian Project is being asked to accept. Are you proposing a Debian package of the MusicXML standard? Or some other work? Where is the text granting specific license in that work? -- \ “Our urge to trust our senses overpowers what our measuring | `\ devices tell us about the actual nature of reality.” —Ann | _o__) Druyan, _Cosmos_, 2014 | Ben Finney <bign...@debian.org>
Re: JPL Planetary Ephemeris DE405
Ole Streicher <oleb...@debian.org> writes: > The exception used here is that facts are not copyrightable. Positions > and movement parameters of celestial bodies, presented in their natural > form (to keep the use of JPL-DE data as example) are bare facts. And > most of research data is just this: facts. You keep stating this as though it is universally true. It has been pointed out, in this thread and many times before, that “it's a collection of facts” does *not* constitute a universal get-out-of-copyright incantation. I wish what you assert were true; but it simply is not. For example, so-called “sui generis” database restrictions recognise copyright in even collections of brute facts, in many Berne signatory jurisdictions <URL:https://en.wikipedia.org/wiki/Sui_generis_database_right>. In jurisdictions like those, where such restrictions are recognised under law, merely being a collection of facts does not constitute an exception to general copyright restriction. Therefore the work is by default restricted by copyright law. Therefore the work cannot be in Debian without license conditions that satisfy the DFSG. > To bring some citations: Those are, as far as I can tell, statements that *some jurisdictions* exempt works like these. That doesn't counter my point, above. There are significantly many jurisdictions where the work *is* restricted by copyright, that we cannot assume universal – nor even widespread – exemption from copyright restriction in this work. > Is this enough material to claim an exception? It may be enough to claim an exemption in the USA. Unfortunately for your case, Debian recipients in other jurisdictions also need to know the works in Debian are DFSG-free. You are IMO correct to argue that such works *should not be* restricted by copyright. But the fight to make it actually true, needs to be taken outside this forum and fought in those law-making jurisdictions that continue to restrict collections of fact under copyright. -- \ “Airports are ugly. Some are very ugly. Some attain a degree of | `\ugliness that can only be the result of a special effort.” | _o__) —Douglas Adams, _The Long Dark Tea-Time of the Soul_, 1988 | Ben Finney
Re: JPL Planetary Ephemeris DE405
Ole Streicher <oleb...@debian.org> writes: > It would help in the discussion if you could point to these > constraints (which are applicable to research data), and not just > claim that they may apply in this case. That's shifting the burden. Like it or not (for the record: I don't like this), most Berne signatory jurisdictions assume by default that a fixed expression is subject to copyright. There are exceptions, but those exceptions must be positively shown: the burden is on those who would claim copyright does not apply. -- \ “Whenever you read a good book, it's like the author is right | `\ there, in the room talking to you, which is why I don't like to | _o__) read good books.” —Jack Handey | Ben Finney
Re: JPL Planetary Ephemeris DE405
Ole Streicher <oleb...@debian.org> writes: > Research data however are *not* a product of a creative scientific > work. You may continue to assert that. It doesn't change the facts of how copyright law works. The Debian Project is bound to work within the constraints of the current copyright regime. I support your goal of minimising the reach of copyright, and I hope that bears fruit. What is fruitless is simply asserting, in this forum, that you don't think copyright applies. If you want copyright not to apply around the world to a certain class of information, your endeavour is not here in this forum; it is with the lawmakers in those jurisdictions. -- \ “Some forms of reality are so horrible we refuse to face them, | `\ unless we are trapped into it by comedy. To label any subject | _o__)unsuitable for comedy is to admit defeat.” —Peter Sellers | Ben Finney
Re: JPL Planetary Ephemeris DE405
jonathon <jonathon.bl...@gmail.com> writes: > The source code for the ephemeris is physical observations of the stars, > planets, and other bodies in it. The physical observations are not a work of expression; likewise, my physical observation of a mountain is not a work of expression. They may be the “source of the data” in some sense, but that sense is not relevant for figuring out the license on a work of expression. In the mountain example, the mountain is not a work of expression; a digitally-recorded photograph of that moment at a place and time *is* a work of expression. It may even be the source form of the work. The “physical observations of [natural phenomena]” does not describe a form of the work, so it cannot be the source form of the work. Rather, the source form of the work is whichever form of the work – in this case, some specific form of the ephemeris data – which would be preferred for the purpose of making modifications to the work. -- \ “Think for yourselves and let others enjoy the privilege to do | `\ so too.” —Voltaire, _Essay On Tolerance_ | _o__) | Ben Finney
Re: JPL Planetary Ephemeris DE405
Ole Streicher <oleb...@debian.org> writes: > Again, as shown here: this license covers *software*, not *data*. That's not a distinction that matters for the question at hand. Any work, regardless of how you might categorise it, if it is to be in Debian must conform to the DFSG. > Data is fundamentally different from software Whatever those differences may be, they don't change the required freedoms to the recipient, for the work to be in Debian. > for example, there is no "source code" for DE405. There is just no > "preferred way to edit" for such a database -- these database are > created from observation and not thought to be edited by hand. The freedoms that the recipients are to be granted, to satisfy the DFSG, are not limited by what the original distributors imagine. It does not matter what categories you say the work is in or not in. It does not matter whether the original distributor can or cannot imagine why they might want to do that. If a recipient of Debian gets it into their head, for any reason or no reason, to modify and re-distribute the work, the Debian Social Contract promises that they are permitted to do that; so the work's copyright license must permit that. > So, it is just wrong to apply software licenses to databases like DE405. That's contrary to the position of the FTP masters, and contrary to the Debian Social Contract §1. -- \ “I never forget a face, but in your case I'll be glad to make | `\ an exception.” —Groucho Marx | _o__) | Ben Finney
Re: JPL Planetary Ephemeris DE405
Dave Hibberd <d...@vehibberd.com> writes: > […] > See especially sections on Kernels Distribution and Kernels > Redistribution. The intent is to allow anyone to use or redistribute > as long as the files/kernels are not modified." That intent explicitly does not permit distribution of modified works. That permission is needed if the work is to be free software. > Under my reading of their terms, it feels like a free license we can > distribute the files under - they permit use, redistribution and > modification as the user sees fit, and are only looking to limit their > liability for support of any modified code. I think it is non-free, for the reason above. If the license conditions also do not permit redistribution of modified works, the work is not DFSG-free. It cannot be in Debian. If the license conditions, instead, do permit redistribution of modified works, the license conditions are contrary to the stated intention, above. We should consider carefully whether to honour the intent or the license. That conflict needs to be resolved, IMO. Do they intend to grant all the DFSG freedoms to the work's recipient, or not? > Can anyone confirm or suggest why I may be wrong in this > interpretation? Thank you for continuing to seek an unambiguous grant of free license in this work. -- \ “Nothing worth saying is inoffensive to everyone. Nothing worth | `\saying will fail to make you enemies. And nothing worth saying | _o__)will not produce a confrontation.” —Johann Hari, 2011 | Ben Finney
Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?
Ben Finney <bign...@debian.org> writes: > To the extent that text is derived from the GNU LGPL, it is a copyright > violation: I didn't explain well enough why I was including some of the text. This is from the GNU LGPL v2.1: > Copyright (C) 1991, 1999 Free Software Foundation, Inc. […] > Everyone is permitted to copy and distribute verbatim copies > of this license document, but changing it is not allowed. > > <URL:https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html> This is from the GNU LGPL v3: > Copyright © 2007 Free Software Foundation, Inc. […] > Everyone is permitted to copy and distribute verbatim copies of this > license document, but changing it is not allowed. <URL:https://www.gnu.org/licenses/lgpl.html> I showed both of those to show that the requirement has not changed between versions (so it is sufficient to determine that the text is derived from either version of the GNU LGPL). -- \ “It is the integrity of each individual human that is in final | `\examination. On personal integrity hangs humanity's fate.” | _o__) —Richard Buckminster Fuller, _Critical Path_, 1981 | Ben Finney
Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?
Dmitry Alexandrov <321...@gmail.com> writes: > I did not wdiff(1) it, but it definitely sounds like a word-for-word > copy of second GNU Lesser GPL to me. :-) To the extent that text is derived from the GNU LGPL, it is a copyright violation: Copyright (C) 1991, 1999 Free Software Foundation, Inc. […] Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. <URL:https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html> Copyright © 2007 Free Software Foundation, Inc. […] Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. So, as a separate matter, it appears the distributors of IUPAC/InChi-Trust License are in violation of copyright law. This would AFAICT include any redistributor, which would preclude having the work in Debian. -- \ “I wish I had a dollar for every time I spent a dollar, because | `\ then, yahoo!, I'd have all my money back.” —Jack Handey | _o__) | Ben Finney
Re: GPLv3 source code with license check for some build configuration, DFSG ok?
This seems to be a good use of the ‘debian-legal’ discussion forum. Can you reply to this thread – note the Cc to ‘debian-legal’, please subscribe there to follow if you like – with a copy of the exact text granting license (“you may such-and-such under conditions so-and-so”). More questions follow. Thomas Preud'homme <thomas.preudho...@celest.fr> writes: > ultracopier's source code has a license check when built in ultimate > mode. However the source code is readily available, licensed under > GPLv3 and I plan to ship a non ultimate build into Debian. Is that ok > according to DFSG and thus ok to distribute in Debian? You'll need to explain more of what “ultimate mode” means. Especially we need to know what change in program behaviour would be had by some recipient choosing to disable that check and redistribute it to others. > I would say yes because the build Debian would distribute wouldn't be > restricted in use and its source code would be readily available and > free to be modified. Note that the freedoms of the DFSG must be available to every Debian recipient, whether direct or indirect. If not, the work is not DFSG-free. > I'm less sure about the ultimate edition (note that this would not > affect Debian). GPLv3 says: > > "You may not impose any further restrictions on the exercise of the […] That is a significant concern, yes. If the recipient can simply ignore the additional restriction, and there is no effective change to the program behaviour, then that is not really an effective restriction and we may as well just patch out the non-free check. If the recipient cannot simply ignore the additional restriction, then to some extent the restriction makes the work non-free. Some other resolution would be needed; plausibly, this would exclude the work from Debian. When you can describe more we can judge the conditions better. -- \“No matter how cynical you become, it's never enough to keep | `\up.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney
Re: GPL-2+ with additional trademark spice
Mihai Moldovan <io...@ionic.de> writes: > So for the time being, can I just tag this as GPL-2+ as usual without > mentioning the trademark restriction part in debian/copyright? To clarify: As said in this thread, it is not a restriction (because it imposes no restriction that isn't already there in the absence of the clause). I agree that it appears to be phrased as a restriction. > Given that it doesn't affect the license itself, I think that I can > omit this detail in the packaging. You would do best, IMO, to put the full license grant including that clause, into ‘debian/copyright’. Our analysis here of the clause's effects notwithstanding, Debian Policy requires the full copyright information in that file, and IMO this clause is part of that information. -- \ “It is a part of probability that many improbable things will | `\ happen.” —Aristotle, _Poetics XXV_, 335 BCE | _o__) | Ben Finney
Re: GPL-2+ with additional trademark spice
Mihai Moldovan <io...@ionic.de> writes: > While working on a package (not yet part of Debian), I noticed the following > copyright and license notice: Thank you for posting the full text of the grant of license. > # This copyrighted material is made available to anyone wishing to use, > # modify, copy, or redistribute it subject to the terms and conditions of > # the GNU General Public License v.2, or (at your option) any later version. > […] Any Red Hat trademarks that are incorporated in the > # source code or documentation are not subject to the GNU General Public > # License and may only be used or replicated with the express permission of > # Red Hat, Inc. This is confusing, because the GNU GPL v2 has no mention of trademark. I would advise the copyright holder to phrase this in terms of what the GPL actually permits or forbids. > The first part obviously is just stating that the file in question is > being made available under the GPL-2 (or any later version) license. > However, how does the trademark notice play with that? In my opinion, the addendum is completely null. The grant of license, above, *already* grants no trademark permission (because it doesn't mention trademark otherwise, and the GNU GPL v2 doesn't mention trademark at all). So it is *apparently* just an assertion of what is already the case – no special permission to use trademarks – in the absence of that statement. > One might argue that this a combination of the third BSD-3-clause > license clause with GPL-2+ and since BSD-3-clause is compatible (to a > degree) with GPL-2+ through LGPL-2.1(+), this usage should be fine. > Pure speculation on my side only, though. Yes, I think it would be helpful to ask the copyright holder to re-write that license grant, to express their intention more clearly so we don't need this speculation. Ideally, if the clause is not any additional restriction or permission, they should remove it from the license grant text entirely, and just use the standard license grant text. -- \“[T]he great menace to progress is not ignorance but the | `\ illusion of knowledge.” —Daniel J. Boorstin, historian, | _o__) 1914–2004 | Ben Finney
Re: Bug#874295: Not a bug
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Ben Finney writes ("Re: Bug#874295: Not a bug"):
> > (Yes, I think a web browser should not download and execute
> > arbitrary JavaScript either. That one problem remains unaddressed is
> > not a justification for the same problem elsewhere.)
>
> This is obviously out of scope for the discussion of this bug.
Certainly. I was responding parenthetically to a point that, I agree
with you, was out of scope.
--
\ “I would rather be exposed to the inconveniences attending too |
`\ much liberty than those attending too small a degree of it.” |
_o__) —Thomas Jefferson, 1791-12-23 |
Ben Finney <bign...@debian.org>
Re: Bug#874295: Not a bug
Thomas Pierson <cont...@thomaspierson.fr> writes: > Clementine does not require or depend on a external software to run > properly. So for me the policy 2.2.1 is respected. I agree that, as described, Clementine's normal function as a general-purpose music player is available without any non-free music services. So this does not infringe Policy §2.2.1. > It's only if a user want to connect to a particular external service > that a plugin file is downloaded and used. That is still a problem, IMO. It would be best if the program did not do that, and instead prompted the user to install the non-free package providing that plug-in. > But it's the same case for many software like web browser which > download and run proprietary javascripts without any warning. (Yes, I think a web browser should not download and execute arbitrary JavaScript either. That one problem remains unaddressed is not a justification for the same problem elsewhere.) > So unless someone point me a clear justification I will close this bug > as invalid for now. I agree that, despite the problems remarked on of downloading and executing unpackaged code to execute on the user's computer, this is not a dependency for the program performing its normal function. So this does not appear to be a Policy §2.2.1 violation. -- \ “If we could change ourselves, the tendencies in the world | `\ would also change.” —Mohandas K. Gandhi, _Collected Works_, 1913 | _o__) | Ben Finney <bign...@debian.org>
Re: French gov open license
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Ben Finney writes ("Re: French gov open license"):
> > More precisely, “pass DFSG” is not something we can ask of licenses.
> > Rather, the DFSG are for evaluating a *work* proposed for entry to
> > Debian.
> > […]
>
> I think this is rather disingenuous. […]
You've presented an example supporting my position:
> I have read the licence PDF and it is a reasonable licence for open
> data. But if used together with some program, it would need to be
> analysed for compatibility with that program's licence.
Yes. So, examining the license is not sufficient to say that a work is
DFSG-free; the work itself, along with license grant and the full
license text, are needed. Without those, “is it DFSG-free?” can't be
answered.
> But that doesn't mean that rejection for wrongnesses in the licence
> itself don't occur. There are plenty of examples. It can make sense
> to look at the licence and say "if the whole work was under this
> licence, and there were no other problems, it would be OK".
That's a pretty big “if”, as attested by many discussions over the
years in this forum :-)
I think we agree; I'm not sure why you think it's disingenuous, but I'm
attempting to avoid the common situation where we are asked to judge a
license text divorced from the work and without seeing the grant of
license. Those are crucially important — as is, of course, the license
text itself.
--
\ “Skepticism is the highest duty and blind faith the one |
`\ unpardonable sin.” —Thomas Henry Huxley, _Essays on |
_o__) Controversial Questions_, 1889 |
Ben Finney
Re: French gov open license
Jérémy Lal <kapo...@melix.org> writes: > I don't think there is such a thing named "recognized by DFSG". I agree. > A license can pass DFSG or not, and this one, after reading it, > seems to be okay. More precisely, “pass DFSG” is not something we can ask of licenses. Rather, the DFSG are for evaluating a *work* proposed for entry to Debian. Until we have a work to examine, with a grant of license from the copyright holders (and holders of other monopolies) in that work, the question of DFSG doesn't even come up. So, the question will need to be asked about a work proposed for entry into Debian. -- \ “For myself, I am an optimist — it does not seem to be much use | `\ being anything else.” —Winston Churchill, 1954-11-09 | _o__) | Ben Finney
Re: Freeness of vague Synopsys license
Andreas Bombe <a...@debian.org> writes: > I'm now unsure whether I should keep the Synopsys libraries which > found some wider use before its features were finally offered by the > VHDL language standard. > > Here is the copyright statement and license from one of the files in > its entirety: Thank you for naming the specific work, and for presenting the text of the license grant and conditions. I agree with you that the question of “does this grant of license permit modification and redistribution”. > | Copyright (c) 1990, 1991, 1992 by Synopsys, Inc. All rights reserved. > | > | This source file may be used and distributed without restriction > | provided that this copyright statement is not removed from the file > | and that any derivative work contains this copyright notice. > > It offers use and distribution without restriction, but technically > not explicitly modification. However, if permission of modification > weren't intended, the requirement of keeping the copyright statement > would be pointless. We have a stronger argument in favour of this license granting permission to modify and redistribute. The license states specifically what the recipient must do with “any derivative work”. I think a fair interpretation of “provided […] that any derivative work contains this copyright notice” in the conditions, is that the license grants permission to redistribute a modified version of the work — what copyright law typically calls a “derived work”. It is not as clear as it should be, though. The mere ability of some people to find an interpretation that coincides with our wishes, is a poor guide to whether the license will actually be found to grant those permissions when tested. We should not eagerly take our interpretation as the right one. You might contact the copyright holders, and ask them to release a version of the work with the wording changed to that of the Expat license <URL:https://directory.fsf.org/wiki/License:Expat>. This is a well-understood license text, widely acknowledged to result in a free work. This would remove the doubts raised by the current unclear wording. -- \ “Faith is the determination to remain ignorant in the face of | `\ all evidence that you are ignorant.” —Shaun Mason | _o__) | Ben Finney
Re: [cups-devel] CUPS License Change Coming
Didier 'OdyX' Raboud <o...@debian.org> writes: > Is Apple going with "pristine" Apache License 2.0 [1] without further > exceptions? That's an important question. I don't think anyone on this forum can answer it better than an official answer from Apple Corp. Who has asked it of them? -- \ “First things first, but not necessarily in that order.” —The | `\ Doctor, _Doctor Who_ | _o__) | Ben Finney
Re: I am the RD of ASUS, want to confirm the Debian license
刘欢 <appleeatwo...@gmail.com> writes: > Sorry to use a private email,The company's mailbox can not send mail > to @ list.debian.org Sorry to learn of that misconfiguration in your IT system. I hope your company's IT department can correct that fault. > We are developing a laptop test software, hoping to use Debian as the > operating environment, and pre-installed in the user's computer. > According to Debian lisence You probably know, but to be clear: There is no one “Debian license”. The many packages comprising the Debian system have myriad copyright holders, and those holders each grant license only in the specific work in that package. > we do not have to pay for it, just open the Debian source code we use. It is true that all of the different licenses, granted in the many different packages, have an explicit freedom in common: The freedom to redistribute the work you received, with or without modification, under the same license conditions as you received it. There are other conditions and grants in various packages, but that common grant of freedom is the one I think you are referring to. > But whether we need open source our test software.I did not find the > relevant instructions on the official website. The instructions are not special to Debian. If you want to redistribute a work derived from another work, that action is goverend by copyright law and you must obtain permission somehow. For free-software works, like all the ones that comprise the Debian system, the freedom is explicitly granted to redistribute the derived work with the same license conditions that you received the work. > We do not want to open source our software, because it will involve the > interests of some third-party vendors. That is a shame, because it is against the interests of software freedom and the interests of software users. Please grant recipients of the Debian system – with or without your modifications – the same grant of license that you received. -- \“It is seldom that liberty of any kind is lost all at once.” | `\ —David Hume | _o__) | Ben Finney
Re: Anki logo copyright question
Julian Gilbey <j...@debian.org> writes: > Anki is licensed under the AGPL3 (GNU Affero General Public License > 3), but the logo is licensed with the following conditions. Thanky ou for providing the specific conditions here, so we can discuss them in context. > IANAL, and cannot work out whether these make the use more restrictive > or less I share your confusion. The conditions applied certainly are more restrictive than the AGPLv3 conditions. Yet the author of the preamble clearly intends that this grants “more liberal” license. > = > > Anki's logo is copyright Alex Fraser, and is licensed under the AGPL3 > like the rest of Anki's code, but with extra provisions to allow more > liberal use of the logo under limited conditions. You can start a dialogue with Alex Fraser to ask what “more liberal” means here? What does Alex think is forbidden by the AGPLv3, that needs this extra grant? > Under the following conditions, Anki's logo may be included in blogs, > newspaper articles, books, videos and other such material about Anki. These actions would seem to already be licensed by the AGPLv3, without these additonal conditions. What is Alex's position on that? -- \ “Often, the surest way to convey misinformation is to tell the | `\ strict truth.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney
Re: Wily may be non-free
Jacob Adams <tookm...@gmail.com> writes: > I've now filed a bug (#872866) but, given the current state of the > wily package, I decided to set the severity to serious. That sounds fine, thank you for submitting that report. -- \ “I have always wished for my computer to be as easy to use as | `\ my telephone; my wish has come true because I can no longer | _o__) figure out how to use my telephone.” —Bjarne Stroustrup | Ben Finney
Re: Wily may be non-free
Jacob Adams <tookm...@gmail.com> writes: > It is currently in debian main, but appears to be non-free. Thank you for drawing attention to this. > However, it includes two libraries that are compiled into the final > executable, libframe and libXg. Both these libraries contain the > following copyright notice at the top of each file [2]: > > /* Copyright (c) 1992 AT - All rights reserved. */ One thing is certain: The ‘debian/copyright’ file needs to be updated with an explanation of the copyright status of those files. > That seems pretty clearly non-free to be, but as it's currently in > Debian, I figured I would ask here before filing an RM bug against > wily. I think you can make a bug report to discuss the matter. Start it at “important” severity because the ‘debian/copyright’ file is not accurate. If the discussion does not reveal a good explanation for the source files that makes the work clearly DFSG-free, then the severity should be increased. -- \ “It has yet to be proven that intelligence has any survival | `\ value.” —Arthur C. Clarke, 2000 | _o__) | Ben Finney
Re: .ttf in source packages
Jeff Epler <jep...@unpythonic.net> writes: > Are ".ttf" files "source files" under the DFSG? That's not a question that can be answered for all works. It needs to be asked of each work. > (Surely they are not the source files used within Bitstream during the > development of the font!) Probably not. The question to ask is: What is the preferred form of the work *today* for someone making modifications to the work? If there is no better form that even exists, then the preferred form of the work today is the only form of the work today. On the other hand, if there is some better form of the work, that would be preferred when making modifications, that form is the source form. And yes, this does raise the question of the honesty of those who make claims about what forms of the work exist today. -- \ “Instead of a trap door, what about a trap window? The guy | `\ looks out it, and if he leans too far, he falls out. Wait. I | _o__)guess that's like a regular window.” —Jack Handey | Ben Finney
Re: OpenSSL license for new packages.
Paulo Ricardo Paz Vital <pvi...@gmail.com> writes: > Since this is an engine for OpenSSL, we have choose the license as > OpenSSL License, which is based on BSD license. Two problems with that: * There are multiple licenses that meet the description “BSD license”. They are published by the BSD project(s) for their works. They all have different effects and need to be distinguished. So, when discussing a license text actually published by BSD, please state exactly which one is being talked about. * A license text “based on” another is best distinguished because it will, again, most likely have different effects. Look at the text as it is, without muddling the issue by saying what it's based on. So, when discussing a license text, name it unambiguously (without “based on foo”) so that it is examined as a separate document. > The point is, two of the OpenSSL License [2] statements say the > follow: Can you bring the full conditions – all of the conditions that apply to the work, no matter if they're in multiple license texts – and post it here in this thread for reference? -- \“Telling pious lies to trusting children is a form of abuse, | `\plain and simple.” —Daniel Dennett, 2010-01-12 | _o__) | Ben Finney
Re: tss2: Is it DFSG compatible
Breno Leitao <lei...@debian.org> writes: > There is a package at mentors[1] and a RFS[2] requesting this package > to be included in Debian. Looking at it I found that, although this > package uses license BSD-3 license, it contains the following excerpt Thank you for raising the issue here. For reference in this discussion, can you please include the full text of the conditions in a message here? > Licenses and Notices > Copyright Licenses: > > * Trusted Computing Group (TCG) grants to the user of the source > code in this specification (the "Source Code") a worldwide, > irrevocable, nonexclusive, royalty free, copyright license to > reproduce, create derivative works, distribute, display and perform > the Source Code and derivative works thereof, and to grant others > the rights granted herein. Whatever qualifies as “the source code in this specification” is explicitly free software for the recipient of this license; they are free to do all those actions, which IMO is the full set of freedoms needed for a work in Debian. Good so far. > * The TCG grants to the user of the other parts of the specification > (other than the Source Code) the rights to reproduce, distribute, > display, and perform the specification solely for the purpose of > developing products based on such documents. This attempts to limit the purpose which users of “parts of the specification (other than the Source Code)” can have. That is IMO a non-free restriction, and a work under those restrictions cannot be in Debian because it violates DFSG §6. > Is this last paragraph a possible violation of DSFG, or, should it not > be taken in consideration since it seems to exempt the source code? All parts of a work – indeed, the work as a whole – must satisfy the DFSG for it to be allowed in Debian. Whether or not it is “source code” is immaterial to that requirement. Parts which are not free to Debian recipients must be excluded from anything in the Debian system. So if a source package were needed to build a work, it must not use (or derive from) those non-free parts in any source or binary package. -- \ “For mad scientists who keep brains in jars, here's a tip: why | `\ not add a slice of lemon to each jar, for freshness?” —Jack | _o__) Handey | Ben Finney
Re: Identification of two licenses
Lev Lamberov <dogs...@debian.org> writes: > while working on migration of swi-prolog package to machine-readable > copyright file I've stuck with two licenses, so asking for an advise on > how to specify these licenses (I mean what to choose as their short > names). I was not able to identify them or find in SPDX Open License > List. Thank you for showing the full license text for discussion. I think it's best to choose unique names for these unique license texts, because they are not clearly identical to any other. They may be effectively the same as some other well-known license text, but that is not immediately obvious and I think you should choose a name that does not claim identity with any other license text. As another action, you might contact the copyright holders and ask them to choose instead a well-known free-software license text with thoroughly stidued effects, such as the Expat license; they would then need to make a new release specifying that exact license text. -- \ “Some mornings, it's just not worth chewing through the leather | `\ straps.” —Emo Philips | _o__) | Ben Finney
Re: BSD license type?
Ole Streicher <oleb...@debian.org> writes: > Wouldn't it be better to show somehow the relationship in the name? What purpose would that serve? I think this is a custom license text, not published by BSD, so should clearly avoid any implication of being published by BSD. > IMO it is already clear that it is not identical to a BSD license if I > use a (slightly) different name, like "Simplified-BSD-3-Clause" or > "BSD-3-Clause-alike". My objection is that those imply too strong a connection with the licenses published by BSD, and further imply that they are as well-known and as well-studied in their effects. That implication is false. The name should therefore not give that implication, by avoiding entirely the “BSD” label. > If the text is identical, one would use the predefined short names; > reversely that means that if it is not a predefined short name, that > it is not the identical text. I'm advising to make that much clearer by using a name that (correctly) implies a custom license that is not widely known in its effects. -- \“I went to the hardware store and bought some used paint. It | `\ was in the shape of a house.” —Steven Wright | _o__) | Ben Finney
Re: BSD license type?
Ole Streicher <oleb...@debian.org> writes: > Change from the original BSD-3-Clause is that the originally second > condition is merged/simplified with the first, and the third is > renamed. > > What short name should I assign to it? I would advise that the name should not invite confusion with the existing license texts that actually are published prominently for the Berkeley Standard Distribution. In other words, if this is not identical with an existing widely-known BSD license text, don't use BSD in the name. You could instead choose a short name that is specific to that work. e.g. “License: CISCO-CSA”. -- \“[It's] best to confuse only one issue at a time.” —Brian W. | `\ Kernighan, Dennis M. Ritchie, _The C programming language_, 1988 | _o__) | Ben Finney
Re: Unsure about a License with mandatory attribution clause
Andreas Moog <andreas.m...@warperbbs.de> writes: > while packaging libml I noticed the following part in a license text: > (https://github.com/volkszaehler/libsml/blob/master/test/unity/license.txt) > > The end-user documentation included with the redistribution, if any, > must include the following acknowledgment: "This product includes > software developed for the Unity Project, by Mike Karlesky, Mark > VanderVoord, and Greg Williams and other contributors", in the same > place and form as other third-party acknowledgments. Alternately, > this acknowledgment may appear in the software itself, in the same > form and location as other such third-party acknowledgments. This is more specific, but IMO not more onerous, than attribution clauses in the BSD licenses. So the questions to answer, I think, are: Does this restrict the recipient's freedoms under DFSG? * Attribution requirement is, in general, considered DFSG-free. * The clause only takes effect if there is already “end-user documentation”. All Debian packages must be distributed with end-user documentation; the ‘debian/copyright’ file is part of that, as you point out. * The attribution states a fact that will, I believe, remain true so long as the software continues. (Some licenses, e.g. the FDL, require preserving statements of fact that are not always true. So it's good to consider this question.) * The clause also allows for the notice to appear “in the same form and location as other such third-party acknowledgements”. So, that definitely describes the ‘debian/copyright’ file. My conclusion is that this is a DFSG-free license, with an unconventionally specific requirement of attribution. I would prefer that the copyright holders should choose a conventional well-understood license, but I don't see that this one causes any specific problem for Debian recipients. -- \“Simplicity is prerequisite for reliability.” —Edsger W. | `\ Dijkstra | _o__) | Ben Finney
Re: unknown license for package/debian/* in d/copyright in adopted package
Nicholas D Steeves <nstee...@gmail.com> writes: > I pushed updates here: > > https://anonscm.debian.org/git/pkg-emacsen/pkg/muse-el.git/tree/debian/COPYING.emails That's a good record. Better than most Debian packages, I'd say :-) Can you put the Message-ID field for each message in the header for the message? That will make it easier to refer to specific messages later. As it is, I can say I think you need only these ones: * Date: Thu, 1 Jun 2017 10:15:58 +1000 From: Trent Buck <trentb...@gmail.com> * Date: Wed, 31 May 2017 20:24:01 -0700 From: Michael Olson <mwol...@gnu.org> * Date: Thu, 01 Jun 2017 09:57:49 +0200 From: Julien Danjou <a...@debian.org> > How important is this updated copyright? It's important to include explicit grant of specific license in writing from all copyright holders. > Do I need to worry about getting it into Stretch? I think it can wait until after the release, though I don't speak for the release team or FTP masters. -- \ Eccles: “I just saw the Earth through the clouds!” Lew: “Did | `\ it look round?” Eccles: “Yes, but I don't think it saw me.” | _o__)—The Goon Show, _Wings Over Dagenham_ | Ben Finney
Re: unknown license for package/debian/* in d/copyright in adopted package
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Ben Finney writes ("Re: unknown license for package/debian/* in d/copyright
> in adopted package"):
> > Are there messages in that file that could be removed? I typically
> > try to get a single message from the copyright holder, that contains
> > an explicit and unambiguous grant of a specific license.
>
> I think it is better not to bother upstream with pointless
> administrivia.
Given an appropriate definition of “pointless administrivia”, of course
I agree with that.
I'm responding (belatedly) to your request for feedback on the
*existing* record of correspondence :-)
--
\“… no testimony can be admitted which is contrary to reason; |
`\ reason is founded on the evidence of our senses.” —Percy Bysshe |
_o__) Shelley, _The Necessity of Atheism_, 1811 |
Ben Finney
Re: unknown license for package/debian/* in d/copyright in adopted package
Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > Do you agree that my mail exchange as found in the sympathy package is > a good example of how to ask these questions, and how to record the > answers ? Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > I meant this, which I provided a link to earlier: > https://browse.dgit.debian.org/sympathy.git/tree/COPYING.emails Yes, that's a good record of the conversation. It'd be better IMO if it included each message's Message-ID field, or some other URI for each message so that the parties in the conversation can later verify that it matches their own record of the discussion. Are there messages in that file that could be removed? I typically try to get a single message from the copyright holder, that contains an explicit and unambiguous grant of a specific license. Often that isn't forthcoming as clearly as we might like, because of how the correspondence unfolds. I appreciate that you pressed for that in the discussion for ‘sympathy’. Maybe that's just an example of a case where no one message will clearly show the grant of license, and the whole set needs to be examined. -- \“If it ain't bust don't fix it is a very sound principle and | `\ remains so despite the fact that I have slavishly ignored it | _o__) all my life.” —Douglas Adams | Ben Finney
Re: zstd: PATENTS application to copyright
Jeff Epler <jep...@unpythonic.net> writes:
> Apparently,
> https://github.com/facebook/zstd
> https://github.com/facebook/zstd/blob/dev/LICENSE
> https://github.com/facebook/zstd/blob/dev/PATENTS
Thank you for this, and for the complete text of the conditions. It
allows discussion to be more easily read in the archives of this forum.
> Contents of .../LICENSE of this date:
> BSD License
>
> For Zstandard software
> […]
That is a standard 3-clauses BSD license. It grants all the
DFSG-required freedoms to every recipient.
> Copyright (c) 2016-present, Facebook, Inc. All rights reserved.
The “All rights reserved” is legal twaddle AFAICT, because it is then
immediately contradicted by *granting* some rights to the recipient.
The “Copyright (c) 2016-present” is an overreach. Copyright inheres when
a work is published – fixed in a medium of expression – not forever into
the future, whenever the “present” that the document is being read.
Neither of those is a DFSG problem, I believe. They do exhibit a
troubling disregard for the proper limits to copyright.
> Contents of .../PATENTS of this date:
> Additional Grant of Patent Rights Version 2
>
> "Software" means the Zstandard software distributed by Facebook, Inc.
>
> Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
> ("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
> (subject to the termination provision below) license under any Necessary
> Claims, to make, have made, use, sell, offer to sell, import, and otherwise
> transfer the Software.
I'm less familiar with the effects of wording in patent law. This has
the appearance of granting limited license to exercise patents held by
Facebook.
> The license granted hereunder will terminate, automatically and
> without notice, if you […]
What is “hereunder” intended to mean? No license is granted following
that text; the only license granted in this document is *above* (prior
to) this text.
Does it mean “the license granted below”? If so, it appears to be null,
because there is no such license.
Does it mean “the license granted in this document”? If so, this clause
is attempting to punish patent attacks with revocation of the patent
license granted above.
This clause is activated when the recipient asserts a proprietary idea
patent over some other party's use of that idea.
I am quite sure the act of asserting software idea patents is not a
freedom anyone is guaranteed in free software; indeed, it is violently
contrary to software freedom.
So, because it does not appear to limit any DFSG freedom, this clause
appears to me to be no problem for the DFSG.
--
\ “No great artist ever sees things as they really are. If he |
`\did, he would cease to be an artist.” —Oscar Wilde, _The Decay |
_o__) of Lying_, 1889 |
Ben Finney
Re: zstd: PATENTS application to copyright
Mathieu Malaterre <ma...@debian.org> writes: > I cannot find any older thread discussing zstd being in the main > section of Debian, so I am raising the subject just for later > reference. Can you post the URL to the code base being discussed? Also, the full text of the license conditions recipients receive. -- \ “My mind is incapable of conceiving such a thing as a soul. I | `\ may be in error, and man may have a soul; but I simply do not | _o__) believe it.” —Thomas Edison | Ben Finney
Re: Github TOS effecting change to copylefts?
"kmarsc...@ellemsoftware.com kmarsc...@ellemsoftware.com" <kmarsc...@ellemsoftware.com> writes: > I see it as overhyped and exaggerated. What is “it”? Whose position are you characterising as overhype and exaggeration? > I'm sure the FSF is simply trying to bully github into promoting > copyleft in their TOS (rather than not talking about it at all). Nothing in the articles referenced so far gives any support to that claim. Can you show us what you're reading that makes credible “the FSF is simply trying to bully GitHub”? -- \“We cannot solve our problems with the same thinking we used | `\ when we created them.” —Albert Einstein | _o__) | Ben Finney
Re: GPL compliance for commercial hardware product running Debian
kevin anthoney <kevin.antho...@weldspares.co.uk> writes: > We're looking at developing a commercial product, which will > essentially be a PC running Debian with a browser on it configured to > connect to our web app. Thank you for choosing Debian to run on this product. Note that this forum (‘debian-legal’) is a discussion forum for the legal issues of distributing works in Debian; this is not a contact point for official legal advice about any aspect of Debian. In that light, then, I'll just answer your questions as an interested community member. > Would we need to provide source code for all the GPL software running > on the PC? You should, IMO, provide corresponding source to any recipient who asks. Some license conditions require this (e.g. the GNU GPL), and IMO it is simpler to just provide it for all the works you distribute. This is what the Debian project does, and so it is normally what redistributors of Debian should do. > Assuming the answer is "yes", is there a sensible method of collating > all the necessary source code? Every package in Debian has full corresponding source available <URL:https://www.debian.org/distrib/packages>. For any works you modify, the corresponding source is of course in your possession, and you should make that corresponding source available to any recipient who asks for it. -- \“I fly Air Bizarre. You buy a combination one-way round-trip | `\ticket. Leave any Monday, and they bring you back the previous | _o__) Friday. That way you still have the weekend.” —Steven Wright | Ben Finney <bign...@debian.org>
Re: License for code comments in postgis package
"kmarsc...@ellemsoftware.com kmarsc...@ellemsoftware.com" <kmarsc...@ellemsoftware.com> writes: > Partial extracts (in the code), to which those extracts **reference** > back to the original document, fall under FAIR use. Fair use is not a concept common to Berne convention copyright jurisdictions, so is no help for works in Debian. Any argument for exclusion from copyright should not be made on grounds that are not common to Berne convention jurisdictions. -- \ “There is more to life than increasing its speed.” —Mohandas K. | `\Gandhi | _o__) | Ben Finney
Re: License for code comments in postgis package
Joe Healy <joehe...@gmail.com> writes: > This may be a question for upstream rather than debian, but I thought > I would start here to see if anyone was aware of this issue or had > dealt with it previously. Thank you for raising the issue. Yes, this should also be discussed (separately, and diplomatically) with the upstream maintainers. > At a number of places in the source code for postgis, reference is > made to the comp.graphics.algorithm FAQ [1]. To be clear, I don't think reference (in the sense of referring via a mention, or a URL) invokes any issues for the redistribution of ‘postgis’ or any other work. You mean, I think, that the ‘postgis’ source code directly includes parts of the FAQ document. > As an example, see the comments at [2]. This appears to be a fairly > direct lifting of text from the FAQ, a document which a Joseph O'Rouke > is (claims to be?) the author of. The Debian Project tends to take the position that, if a work is claimed to have copyright held by a party, we should take that claim on face value until demonstrated otherwise. This is partly from the pragmatic position that we usually have no better information. The example you point to may be argued as a representation not of creative work, but of brute fact; and therefore not restricted by copyright. That would be open to argument and only a court case could really decide it. > It appears that redistribution of that document in its entirety is > permitted, however nothing is said about partial extracts. > > This article is Copyright 2003 by Joseph O'Rourke. It may be freely > redistributed in its entirety provided that this copyright notice is > not removed. These conditions do not grant license to redistribute derived (modified) works. So a work under these conditions would thereby be incompatible with the GPL. It would also thereby fail to meet the DFSG. > 1) Should Joseph O'Rouke be listed in the debian/copyright file? For this specific case, I don't know. As above, I wonder whether this extract is restricted by copyright. > 2) Do we (and upstream) have permission to distribute the resulting > source code (as GPL or otherwise)? >From the copyright holders of the FAQ document, we clearly do not have such permission. Whether the FAQ document's copyright extends to this work, is an open question. -- \ “If you can do no good, at least do no harm.” —_Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney
Re: unknown license for package/debian/* in d/copyright in adopted package
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Ben Finney writes ("Re: unknown license for package/debian/* in d/copyright
> in adopted package"):
> > The principle is to consider what a hypothetical future package
> > maintainer, or FTP master or recipient, will need to have to verify
> > the copyright holder does in fact grant the stated license.
> >
> > […]
> >
> > The important thing is that the grant be explicit, specific as to
> > which work and which license terms, and that it all be clearly in
> > writing.
>
> Do you agree that my mail exchange as found in the sympathy package is
> a good example of how to ask these questions, and how to record the
> answers ?
As to how to record the information, I would expect to find it in the
‘debian/copyright’ file, and I don't see what you're referring to at
<URL:https://sources.debian.net/src/sympathy/1.2.1%2Bwoking%2Bcvs%2Bgit20161222/debian/copyright/>.
So, if you can point to what you mean, I may be able to better respond :-)
--
\ “Faith is the determination to remain ignorant in the face of |
`\ all evidence that you are ignorant.” —Shaun Mason |
_o__) |
Ben Finney
Re: unknown license for package/debian/* in d/copyright in adopted package
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Nicholas D Steeves writes ("unknown license for package/debian/* in
> d/copyright in adopted package"):
> > I'm adopting src:muse-el, and the old d/copyright file does not
> > state which license the old debian/* uses.
>
> This kind of thing is quite annoying.
Agreed. The Debian packaging should have an explicit grant of license,
recorded in ‘debian/copyright’ specifically for the ‘debian/*’ pattern
so that if upstream's licensing changes the Debian packaging license
continues to be clear.
> I would encourage everyone who does packaging to explictly licence
> your debian/* with some very permissive licence (eg, MIT).
I default to grating “GPLv3 or later” for mine; often I'll change that
to match the upstream work's license grant.
I don't see any special reason to prefer lax license grants for Debian
packaging, so I default to copyleft.
> > I was recently able to contact Michael Olson. Would a signed email
> > from Michael Olson certifying that his contributions to debian/*
> > were of either GPL-2, GPL-2+, or MIT be sufficient to allow an
> > update to src:muse-el/debian/copyright? If so, to whom should I ask
> > him to send that email?
>
> The mail does not have to be signed.
The principle is to consider what a hypothetical future package
maintainer, or FTP master or recipient, will need to have to verify the
copyright holder does in fact grant the stated license.
I agree that having the message be cryptographically signed is not
necessary, but it is good to have if feasible.
The important thing is that the grant be explicit, specific as to which
work and which license terms, and that it all be clearly in writing.
--
\ “I may disagree with what you say, but I will defend to the |
`\death your right to mis-attribute this quote to Voltaire.” |
_o__) —Avram Grumer, rec.arts.sf.written, 2000-05-30 |
Ben Finney
Re: is igmpproxy dfsg compliant?
Pali Rohár <pali.ro...@gmail.com> writes: > Because igmpproxy is based on mrouted originally licensed under > Stanford That characterises a chain of derivative works: a work (mrouted) was received by a party, who had license under the non-free <URL:https://fedoraproject.org/wiki/Licensing/mrouted> “send a copy to Stanford when you redistribute” conditions. When that third party redistributed it (modified or not), everyone who received it from them has license under those same terms. So ‘igmpproxy’ also has components under those non-free terms. What parts of the work are under those non-free conditions by copyright holders *other than* Stanford? > and later relicensed under BSD Stanford's new grant of license can AIUI only have effect on their copyright claim in the work. It does not change the existing grants of license from other copyright holders, and Stanford certainly cannot grant license on behalf of those copyright holders. The question I don't see answered is: what modifications are there in ‘igmpproxy’ from copyright holders other than Stanford, which are not affected by Stanford's later license grant? > PS: I'm not subscribed to list, so CC me. This discussion is long-running enough that I would recommend participants should subscribe to the forum where it's happening. -- \ “Jury: A group of 12 people, who, having lied to the judge | `\ about their health, hearing, and business engagements, have | _o__) failed to fool him.” —Henry L. Mencken | Ben Finney
Re: Is the RAR archiver freely distributable?
Francesco Poli <invernom...@paranoici.org> writes: > On Fri, 11 Nov 2016 10:07:09 +1100 Ben Finney wrote: > > [...] > > I believe there are actively-enforced patents on DVD-CSS that > > prohibit distribution of, for example, free software that opens > > files encrypted with that scheme. > [...] > > Is this the actual reason? I don't claim it's *the* reason for anything :-) It is certainly one factor in decisions about what packages should be in Debian. Relevant for this discussion, it appears to be a factor distinguishing ‘libdvdcss2’ from RAR compression tools. > I was under the impression that the issue was due to DMCA (in the USA), > EUCD (in the EU) and similar insane laws in other jurisdictions... That's another factor, yes. -- \ “Every man would like to be God, if it were possible; some few | `\ find it difficult to admit the impossibility.” —Bertrand | _o__)Russell, _Power: A New Social Analysis_, 1938 | Ben Finney
Re: Is the RAR archiver freely distributable?
Dmitry Alexandrov <321...@gmail.com> writes: > May I ask again, what law (what jurisdiction) are you talking about. I am being deliberately non-specific about jurisdiction, and limiting the above assertions to those that describe law regardless of jurisdiction. > I am not familiar with North American laws, but there *is* a law > prohibiting distribution of DRM-circumvention tools, for instance, in > the Ukraine […] Yes, exactly: it is a *specific action* (distribution) that is restricted, not the object. Thank you for providing a specific example of law that does not make *objects* illegal, but *actions* by persons. Which is why I'm pointing out that it can only make sense to talk about what *actions* the law restricts. The tool is not legal or illegal, it is what a person may do that is restricted. So, the questions to ask for a proposed work in Debian are all about those restrictions on actions. What actions by Debian recipients are restricted by the specific conditions on the work, and do those restrictions constitute violation of DFSG? What actions by the Debian Project are restricted by specific laws? Do those restrictions exclude redistribution of the work by the Debian Project at all? Do those restrictions allow redistribution, but exclude the work from Debian? -- \ “[On the Internet,] power and control will shift to those who | `\ are actually contributing something useful rather than just | _o__)having lunch.” —Douglas Adams | Ben Finney
Re: Is the RAR archiver freely distributable?
Gunnar Wolf <gw...@gwolf.org> writes: > Dmitry Alexandrov dijo [Wed, Nov 09, 2016 at 12:19:19AM +0300]: > > Are ‘key recovery tools’ illegal somewhere? Tools for circumventing > > digital restristions measures definitely are. > > If you use them on files you legally own, they are legal. They will be > illegal for cracking content for which you should not have access. Another way of saying that is: The tool isn't legal or illegal. It is specific *actions* by persons that is restricted by law. > The tool cannot differentiate, it can only do its job. Likewise, AFAIK the law doesn't make a tool illegal, only specific actions. This is why it's of primary interest how the freedoms *of the recipient* are affected, by the restrictions on a work proposed for Debian. Also of interest are whether the Debian Project is legally permitted to redistribute the work at all. The question of “what is the recipient restricted from doing, and does that restriction violate the DFSG?” involves whether executing the tool is legal. The answer for the case under discussion is probably “if you break the law, that action was illegal; if you use it otherwise, probably not”. That's what Gunnar's answer above is getting to. There isn't a question about whether the tool “is legal”, only what actions are restricted. A Debian recipient can get a tool that was distributed quite legally by the Debian Project, and then choose to use it in a way that violates a law. By itself, that doesn't mean the Debian Project has violated any law; and it doesn't mean the restriction violates the DFSG. There is a quite separate question of “what is the Debian Project legally restricted from distributing?” I believe there are actively-enforced patents on DVD-CSS that prohibit distribution of, for example, free software that opens files encrypted with that scheme. If the Debian Project distributes such a tool, it *is* violating an actively-enforced law. That is, clearly, a very different restriction that doesn't even involve DFSG, and makes the tool not redistributable at all by the Debian Project. -- \ “Be careless in your dress if you must, but keep a tidy soul.” | `\ —Mark Twain, _Following the Equator_ | _o__) | Ben Finney
Re: LOSLA (LEGO Open Source License Agreement 1.0)
ES OR LOSSES, EVEN IF SUCH PARTY SHALL HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES. THIS LIMITATION OF LIABILITY SHALL NOT APPLY TO LIABILITY FOR DEATH OR PERSONAL INJURY RESULTING FROM SUCH PARTY'S NEGLIGENCE TO THE EXTENT APPLICABLE LAW PROHIBITS SUCH LIMITATION. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS EXCLUSION AND LIMITATION MAY NOT APPLY TO YOU. Section 10. U.S. Government End Users. The Covered Code is a ''commercial item,'' as that term is defined in 48 C.F.R. 2.101 (Oct. 1995), consisting of ''commercial computer software'' and ''commercial computer software documentation,'' as such terms are used in 48 C.F.R. 12.212 (Sept. 1995). Consistent with 48 C.F.R. 12.212 and 48 C.F.R. 227.7202-1 through 227.7202-4 (June 1995), all U.S. Government End Users acquire Covered Code with only those rights set forth herein. Section 11. Responsibility for Claims. As between LEGO and the Contributors, each party is responsible for claims and damages arising, directly or indirectly, out of its utilization of rights under this License and You agree to work with LEGO and Contributors to distribute such responsibility on an equitable basis. Nothing herein is intended or shall be deemed to constitute any admission of liability. Section 12. Trademarks. This License does not grant, nor shall any provision of this License be construed as granting, any rights or permission to use the trade names, trademarks, service marks, or product names of LEGO. Section 13. Governing Law To the extent possible under applicable law, this License shall be governed by Danish law and shall be subject to the non-exclusive jurisdiction of the Commercial and Maritime Court of Copenhagen. This License will not be governed by the United Nations Convention of Contracts for the International Sale of Goods, the application of which is hereby expressly excluded. You acknowledge that the export of any Covered Code is governed by the export control laws of the United States of America and other countries. If you are downloading any Covered Code, You represent and warrant that You are not located in or under the control of any country which the export laws and regulations of such country or of the United States prohibit the exportation of the Covered Code. Section 14. Miscellaneous. This License represents the complete agreement concerning subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not apply to this License. EXHIBIT A - LEGO® Open Source License Agreement The contents of this file are subject to the LEGO® Open Source License Agreement Version 1.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.__.com Software distributed under the License is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License. The Original Code is __. LEGO is the owner of the Original Code. Portions created by _ are Copyright (C) _. All Rights Reserved. Contributor(s): __. = -- \ “There's no excuse to be bored. Sad, yes. Angry, yes. | `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, | _o__) ever.” —Viggo Mortensen | Ben Finney
Re: Freeware Public License (FPL)
Charles Plessy <ple...@debian.org> writes: > Le Sun, Oct 30, 2016 at 11:21:37AM +1100, Ben Finney a écrit : > > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > > > > I'm afraid you'll have to go back to the authors/copyrightholders > > > and get them to fix the licence for this particular program. My main point is: When the copyright holders have granted license conditions that have software-freedom issues because it's a custom license tht hasn't stood the test of legal expertise and widespread discussion before deployment: fix that, by (as copyright holders) choosing a better *existing* license. > > Preferably, convince the copyright holders that the reliable option > > is an existing, well-understood, known free-software license such as > > [examples]. > > I think that [different examples are] much more in the spirit of [the > copyright holder's existing choice]. Sure. My main point stands: To get this fixed, please convince the copyright holders that they want an existing license that has been widely vetted by legal experts and known to explicitly grant full software freedom to all recipients. -- \ “Never do anything against conscience even if the state demands | `\ it.” —Albert Einstein | _o__) | Ben Finney
Re: Freeware Public License (FPL)
Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > I'm afraid you'll have to go back to the authors/copyrightholders and > get them to fix the licence for this particular program. Preferably, convince the copyright holders that the reliable option is an existing, well-understood, known free-software license such as Apache License 2.0 or GNU GPL v3. > That includes a statement by the licence author that they didn't mean > to forbid modification. Unfortunately that's not good enough when > other people have adopted the bad licence text. Yes. This is a very common problem with license texts written without legal expertise and thorough widespread vetting before deployment. Much better for the copyright holders to choose license conditions that have already survived those tests. -- \ “Theology is the effort to explain the unknowable in terms of | `\ the not worth knowing.” —Henry L. Mencken | _o__) | Ben Finney
Re: Freeware Public License (FPL)
Jörg Frings-Fürst <deb...@jff-webhosting.net> writes: > a short question: is this license DFSG compatible? The DFSG does not apply to licen texts in isolation. It applies to works for distribution in Debian. A particular license is only one aspect of the work to consider. > Freeware Public License (FPL) Which work are we considering? Where can we see the work's complete source code? > This software is licensed as "freeware." Note that “freeware” has an almost entirely unrelated meaning from software freedom. It normally means “distributed for no fee”, which is not an issue of software freedom. > Permission to distribute this software in source and binary forms, > including incorporation into other products, is hereby granted > without a fee. This freedom (permission to redistribute) is necessary for software freedom but is not sufficient; DFSG requires more than this (see the DFSG for details). Because no other DFSG freedoms are granted, those remain reserved to the copyright holders. So a work under this license would be non-free. -- \ “For a sentimentalist is simply one who desires to have the | `\luxury of an emotion without paying for it.” —Oscar Wilde, _De | _o__) Profundis_, 1897 | Ben Finney
Re: Is ISC License considered DFSG free?
Jari Aalto <jari.aa...@cante.net> writes: > Excellent summary Ben. Thank you for saying so. > Do you think, if it would be good if I added note about ISC license to > the Debian License information page[1] and point it to this thread for > future reference? No, I think my assessment is one person's opinion. It is based on no legal expertise. What you propose would give it too much authority. Better to seek a package using these license terms that the FTP Masters have expressed a position on; if that doesn't exist, mine is not a substitute :-) -- \“Good judgement comes from experience. Experience comes from | `\ bad judgement.” —Frederick P. Brooks | _o__) | Ben Finney
Re: Is ISC License considered DFSG free?
Jari Aalto <jari.aa...@cante.net> writes: > The agrep software is currently in non-free. Latest code > appears to have moved under ISC License[1] Thank you for including the full text of the grant of license, and the license conditions. > [1] http://webglimpse.net/sublicensing/licensing.html > > (...) Webglimpse and Glimpse are available under the ISC > open source license (...) > > Anyone distributing the Glimpse code should include the > following license: > > Copyright 1996, Arizona Board of Regents on behalf of The > University of Arizona. > > Permission to use, copy, modify, and/or distribute this > software for any purpose with or without fee is hereby > granted, provided that the above copyright notice and this > permission notice appear in all copies. > > [WARRANTY DISCLAIMER IN SHOUTY CAPITALS] All required DFSG freedoms are granted by this text. The conditions do not impose any non-free restrictions. By my reading, the grant and conditions are exactly equivalent to the well-understood Expat license grant and conditions. This work, provided its complete license grant and conditions was only the above text, would IMO be uncontroversially DFSG-free. Thank you for pursuing effective software freedom for Debian recipients of this work. -- \ “Faith is the determination to remain ignorant in the face of | `\ all evidence that you are ignorant.” —Shaun Mason | _o__) | Ben Finney
Re: Updating CIDER's Research Software Agreement License For Use in Ngspice
Eric Kuzmenko <eric.gra...@gmail.com> writes: > I am not a lawyer so my advice on this matter may be erroneous. Please note that the ‘debian-legal’ forum is also not a good one to seek legal advice. > Therefore, I am choosing to include the Free Software Foundation, > Debian's legal group, and the Software Freedom Conservancy to weigh > in; please advise us on what should be done. Nor is the ‘debian-legal’ forum a good place for general advice about software licensing. Our scope is limited to discussing the legal effects on Debian recipients, of software packages that are or are proposed to be in Debian. We don't claim to give advice beyond that. > Here is something I believe you may be able to do (feel free to > correct me): A backward-sorted quote chain is not likely to be a reliable guide to what is needed now. Could you summarise the issue, and the question being asked of us here? -- \ “I have said to you to speak the truth is a painful thing. To | `\ be forced to tell lies is much worse.” —Oscar Wilde, _De | _o__) Profundis_, 1897 | Ben Finney <b...@boojum.com.au>
Re: Include pieces of internal kernel header in GPL-3 project
Jan Luca Naumann <j.naum...@fu-berlin.de> writes: > I want to package a project Which work are you proposing to package? Many times, the specific work will have peculiarities that need to be considered. So just knowing the license in abstract is not enough. Where can we see the complete source of the work online? -- \ “We spend the first twelve months of our children's lives | `\ teaching them to walk and talk and the next twelve years | _o__) telling them to sit down and shut up.” —Phyllis Diller | Ben Finney
Re: would this custom license considered DFSG-free/GPL-compatible
Yaroslav Halchenko <deb...@onerussian.com> writes: > Would you consider this short custom license DFSG-free The Debian project doesn't consider licenses in isolation. The relevant question is “Do recipients of *this specific work* have full exercise of their software freedoms?” You're tacitly acknowledging this when you ask whether the terms are GPL compatible. That implies (correctly) that what matters is the freedom of a specific work, considering all constraints. So, which specific work are we discussing here? Can we see the source online? -- \ “Actually I made up the term “object-oriented”, and I can tell | `\you I did not have C++ in mind.” —Alan Kay, creator of | _o__)Smalltalk, at OOPSLA 1997 | Ben Finney
Re: Bug#838414: gpick: colors.txt is non-free
Elías Alejandro <eal...@gmail.com> writes: > Could you review this issue? What kind of review are you asking for? What new information has appeared that prompts a review? For what it's worth, I agree with the earlier assessment that the restriction on usage violates DFSG §6. Further, the term “use” is hopelessly vague and AFAIK null in copyright. There are various common interpretations of what actions “use” could mean in a copyright license text, that are incompatible with each other. Better to change the conditions to be specific about what actions are permitted. -- \ “[W]hoever is able to make you absurd is able to make you | `\unjust.” —Voltaire | _o__) | Ben Finney
Re: Can "rockyou" wordlist be packaged in Debian?
Eriberto Mota <eribe...@debian.org> writes: > However, I will wait more opinions before submit a package to Debian. Don't (only) wait for them here. I would advise you to ask the people distributing the work what they think the copyright status of the work is. Do they consider the work is subject to copyright? Do they consider themselves the sole copyright holders? If not, what other specific parties hold copyright in the work? Do the distributors consider they can unilaterally decide to set redistribution terms? What terms do they set? And, importantly: What compelling reasons are presented for *everyone else* to consider those answers sufficient? -- \“The difference between religions and cults is determined by | `\ how much real estate is owned.” —Frank Zappa | _o__) | Ben Finney
Re: Can "rockyou" wordlist be packaged in Debian?
Thanks for raising this question. Eriberto Mota <eribe...@debian.org> writes: > Well, the quoted event resulted in a file with 14 million passwords, > distributed by Kali Linux. Do you have any reference to the discussions those people had over their license to distribute that information? I would expect such a discussion to get into the issue of whether a single password is subject to copyright restrictions, and further whether a compiled collection of such works is itself subject to copyright restriction. I would want to see such a discussion with clear, solid support for the freedom to redistribute that work under a free license, before proposing its distribution in Debian. -- \ “Airports are ugly. Some are very ugly. Some attain a degree of | `\ugliness that can only be the result of a special effort.” | _o__) —Douglas Adams, _The Long Dark Tea-Time of the Soul_, 1988 | Ben Finney
Re: Bug#837666: Fwd: Bug#837666: udunits: license change
Thank you for raising this issue. Alastair McKinstry <mckins...@debian.org> writes: > As indicated below, the license on a package I maintain has changed, > adding a new clause to the 3-clause BSD license. (Hence making this license *not* a BSD license as commonly understood.) > Can debian-legal please review and comment on the clause: > >4) This license shall terminate automatically and you may no longer > exercise any of the rights granted to you by this license as of > the date you commence an action, including a cross-claim or > counterclaim, against the copyright holder or any contributor > alleging that this software infringes a patent. This termination > provision shall not apply for an action alleging patent > infringement by combinations of this software with other > software or hardware. Such a clause is IMO a restriction on the free redistribution of the work: it retroactively revokes the grant of copyright license to the recipient, based not on any violation of copyright. For comparison, the GPLv3 and Artistic v2 license conditions deal with patents by granting *more* freedom, not less. They each explicitly grant to the recipient freedom from restrictions by patents in the work held by its copyright holders. By contrast, this custom license is a poor idea and may be non-free, because it's difficult to make “license can be revoked retroactively” free. You could recommend to the copyright holder that if they want to protect recipients against patent action, they should instead grant license under the Apache or GNU GPL license terms which are already well-known to result in free works. -- \ “… correct code is great, code that crashes could use | `\ improvement, but incorrect code that doesn’t crash is a | _o__)horrible nightmare.” —Chris Smith, 2008-08-22 | Ben Finney
Re: [Individual|Corporate] Contributor License Agreement
Frederic Bonnard <fre...@linux.vnet.ibm.com> writes: > Though, as Ian mentionned, and as I intuitively felt, I still think > there are unpleasant conditions in this agreement, in respect to the > social contract will of giving back to the community, amongst others. > It's a real stymie. Yes, CLAs are a steadily growing plague on free software. > My best option is, indeed, to ask to remove those agreements from the > source. It can often be effective to offer an alternative. You may want to offer the idea that, instead of asking for an additional CLA, they could simply ask for the contributor to certify the origin of the contribution <URL:http://developercertificate.org/>. -- \ “We demand rigidly defined areas of doubt and uncertainty!” | `\—Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas | _o__) Adams | Ben Finney
Re: [Individual|Corporate] Contributor License Agreement
Frederic Bonnard <fre...@linux.vnet.ibm.com> writes: > I'm wondering if an agreement meets the DFSG during the packaging > process of a library called libvecpf. Thanks for raising this while doing the packaging work, it is important to get this right. > It's under GPLv2.1+ but there are 2 additional files which are > agreements. > Depending if you are an individual contributor or a corporate one : > - https://github.com/Libvecpf/libvecpf/blob/master/ICLA.txt > - https://github.com/Libvecpf/libvecpf/blob/master/CCLA.txt There is no “GPLv2.1”. Do you mean “GNU GPLv2”, or something else? In your assessment, are those additional “agreement” files binding on any recipient of the work, to modify and/or redistribute the work or exercise any other DFSG freedom? > I see amongst some problems with : > - contributor must fill, sign and send the agreement > - reveal his identity > - notify the Libvecpf Maintainer of any facts or circumstances of which You > become aware that would make these representations inaccurate in any > respect. If I understand correctly, failure to meet any of those requirements does not affect the recipient's freedom to exercise DFSG freedoms. (They are requirements that the maintainer imposes on *accepting* changes into the official repository, if I read correctly.) But I could be wrong. What do you think causes a DFSG problem? -- \“This sentence contradicts itself — no actually it doesn't.” | `\ —Douglas Hofstadter | _o__) | Ben Finney
Re: declaring a license
Herbert Fortes <terb...@gmail.com> writes: > I am doing a QA for python-irc[0] and the tarball does not have a > COPYING/License file. The statement is done in setpu.py file and > PyPi[1] only. You have already done the action I'd recommend: convince upstream to put an explicit grant of license prominently in the code base. Thank you. > Now I have an email that explicit declares one License to all project > I can put the file in debian/. In the tarball you only see that in > setup.py file. > > Is that enough ? To resolve the issue not just Debian recipients but for every recipient, upstream needs to put that license grant text in a prominent place (e.g. a top-level ‘COPYING’ file) in the released code base. Have they indicated they will do that? Until that happens, yes it's traditionally accepted for Debian packages to contain the grant of license text in the ‘debian/copytright’ file. My recommendation is to put that text in the non-standard “License-Grant” field of the appropriate “Files” stanza. -- \ “Broken promises don't upset me. I just think, why did they | `\ believe me?” —Jack Handey | _o__) | Ben Finney
Re: Inclusion of PDF with CC Attr 3.0 license
Rafael Laboissière <raf...@debian.org> writes: > I will strip the PDF file from the tarball, add a link to it in > README.Debian, and also contact the upstream authors for making the > source files available. Thank you, that's a good course. -- \“We have to go forth and crush every world view that doesn't | `\believe in tolerance and free speech.” —David Brin | _o__) | Ben Finney <b...@benfinney.id.au>
Re: Inclusion of PDF with CC Attr 3.0 license
Walter Landry <wlan...@caltech.edu> writes: > Ian Jackson <ijack...@chiark.greenend.org.uk> wrote: > > My personal view is that there would be no problem shipping the PDF, > > even though Debian's users would have no practical ability to modify > > this PDF. Making a modified version of a scientific paper like this > > one is neither useful, nor, unless especial care is taken, ethical. > > As someone who reads and writes papers, this is not true. Reusing > figures for talks and other papers is immensely useful. Copying the > LaTeX for an equation can also be quite helpful. This paper has both > of these elements. It is not like it is hard to add the attribution > required by the license. In addition to those important use cases of partial re-use, there are more. For example, re-rendering the source document (without significant modification) to a different format is highly valuable, and is thwarted when the source document is not made available to recipients. All of these are useful, and ethically sound, uses that require equal access to the source document. -- \ “I cannot conceive that anybody will require multiplications at | `\ the rate of 40,000 or even 4,000 per hour …” —F. H. Wales, 1936 | _o__) | Ben Finney
Re: transformed external sources with untouched copyright in upstream source ball
Howdy Jerome, Thank you for discussing this issue of software freedom. Jerome BENOIT <calcu...@rezozer.net> writes: > One of the package that I Intend To Package, libgap-sage not to > mention it [1], contains source files that are basically > transformation of source files from an other software, gap as you have > likely guessed it: grossly, a prefix (libGAP_) is prepended to each > variable/function name. Judging by that description, there is clearly a source form of the work (the ‘gap’ software) using a build process. To be free software, IMO the build process needs to also be available in full to every recipient. So, if a transformation is done, that transformation needs to be automated (maybe a script, or an existing build tool *and* configuration for that build tool), and these specific scripts and configuration constitute part of the source form of ‘libgap-sage’. > I am uncomfortable here because the files are transformed, but no > mention of it is done in their headers. For the purposes of the Debian project, it should be enough to clearly document the provenance of the work and to collect all the files that constitute source (including build scripts and configuration). > My first submission to ftpmaster was rejected because the copyright of > these files as it appears in theirs untouched header was not mention. Which source package in Debian will constitute the source form of this work? That package is the proper place to document copyright information for that source, IMO. So it depends on what is really the source form of this work, and what source package(s) are involved. -- \ “Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.” —Anthony Taylor | Ben Finney
Discussing legal issues of a code base, before official procedure (was: "Use as you wish" license)
Roberto <robe...@zenvoid.org> writes: > Some advisory is valuable for me just before I choose to include such > files in my project. Thank you, that is indeed one of the main benefits of discussing the issue in this forum. > I have not found any previous discussion about those licenses so > asking here seem to be the right thing to do, if that is not the case, > can you please point me the correct steps, should I ask ftpmasters > directly or there is another mailing list you think more appropiate? The FTP Masters are, as you point out, only human; and they have a severe shortage of time. They are not able to commit to answering direct enquiries about proposed packages. That's why this forum is useful: We are volunteers who can discuss a proposed code base *before* the FTP Masters need to spend any time on it, and then the discussion is archived for them to refer to if the package eventually is submitted for inclusion in Debian. So consider this a kind of “peer review before publication”, where there are no authorities and no official decrees, but only a robust discussion by interested parties. It's one way to find problems before they go too far. -- \ “I cannot be angry at God, in whom I do not believe.” —Simone | `\ De Beauvoir | _o__) | Ben Finney
Re: "Use as you wish" license
Roberto <robe...@zenvoid.org> writes: > Is "Use as you wish" an acceptable license? There are widely divergent interpretations of “use” in copyright licenses. Some will interpret it to mean practically any action at all; some will restrict it to mean only private use within a code base, but not redistribution or modification. So I think it is too risky to accept such a license if there is no explicit permission to all the freedoms needed for DFSG works. I would advise anyone writing such a grant of license to avoid the word “use” entirely, and state precisely what freedoms are granted. -- \ “I know that we can never get rid of religion …. But that | `\ doesn’t mean I shouldn’t hate the lie of faith consistently and | _o__) without apology.” —Paul Z. Myers, 2011-12-28 | Ben Finney
Re: sct public domain
Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Jacob Adams writes ("Re: sct public domain"):
> > Ok that makes sense. Wasn't sure if public domain was more
> > complicated but clearly not.
>
> "Public domain" is very complicated. It means different things in
> different places :-(. But happily here the authors hve not only said
> public domain, but also given a clear separate permission. So this is
> fine.
The licensor even managed to avoid the often problematic “use” (which
has a long history of confusion about which actions are “use” and which
are not).
The license to “do as you wish” is, AFAIK, relatively free from
problematic or restrictive interpretation :-)
> > It doesn't seem like a conversion like that is copyrightable though.
> > Do I still credit him or is this definitely not copyrightable?
>
> We should credit people who have contributed, even if copyright law
> doesn't ncecessarily require it. So: I would state the facts, as you
> do here.
Agreed. Since we can do as we wish, I would encourage that we record
attribution information when it's available, because it is surprisingly
common to need that information years later.
--
\ “I'm having amnesia and déjà vu at the same time. I feel like |
`\ I've forgotten this before sometime.” —Steven Wright |
_o__) |
Ben Finney
Re: png files
Herbert Fortes (hpfn) <h...@ig.com.br> writes: > But some .png files are like a chess board with a grey color. There is > nothing in it. > > Since a file to be free must have source that can be editable, is that > a problem ? A consensus definition of “source” in Debian is “the preferred form of the work for making modifications to it”. Is that file in that form? If a recipient wants to make modifications to the work (the image in the file), is that form suitable for making the modifications? If so, that form of the work is a source form of the work. Yes, this requires human judgement, and yes it can be abused. With that said, I think that PNG files containing simple geometric shapes would pretty clearly be their own source form. -- \ “Too many pieces of music finish too long after the end.” —Igor | `\ Stravinskey | _o__) | Ben Finney
Re: Legal issues with haskell-unix-time
Eloi <entfe...@gmail.com> writes: > Just a side question: Are these funcions even copyrightable? Copyright is not a thing done to works; it exists automatically, from the moment a work exists in fixed form. (From this unfortunate fact, comes many of the thorny issues of making works free.) I assume you're asking something like “does copyright law restrict recipients of a work consisting entirely of these functions?” > The is_leap function is quite trivial, and the typical exercise for a > programming student; the timegm is a conversion from a tm struct to an > unix time which could even be reimplemented with no great effort. The question of “does copyright apply?” varies significantly by jurisdiction, and across years, and across case law. One common rule of thumb to tell whether copyright might obtain in a work is: was there creative decision-making involved in generating the work? If the work could feasibly be expressed in various ways, then any given expression may be considered – by whichever copyright jurisdiction decides the hypothetical case in the future – to be a creative work. -- \ “Oh, I realize it's a penny here and a penny there, but look at | `\ me: I've worked myself up from nothing to a state of extreme | _o__) poverty.” —Groucho Marx | Ben Finney
Re: R packages licensed MIT but not shipping a copy of the MIT license itself, Re: R packages licensed MIT but not shipping a copy of the MIT license itself
Mattia Rizzolo <mat...@debian.org> writes: > On Wed, Mar 23, 2016 at 06:10:57AM +1100, Ben Finney wrote: > > This issue should be resolved by the upstream distributor, as I > > agree with you that they are not compliant with the conditions of > > the license. You may want to have that discussion with them. > > I wonder how to contact R people, I've never approached R world > before. Nor I. You could start by summarising the issue to the Debian R folks <URL:https://wiki.debian.org/R#contact>, and perhaps direct them to our conclusions. -- \ “I tell you the truth: this generation will certainly not pass | `\ away until all these things [the end of the world] have | _o__) happened.” —Jesus, c. 30 CE, as quoted in Matthew 24:34 | Ben Finney
Re: R packages licensed MIT but not shipping a copy of the MIT license itself, Re: R packages licensed MIT but not shipping a copy of the MIT license itself
Mattia Rizzolo <mat...@debian.org> writes: > On Tue, Mar 22, 2016 at 07:52:18AM +1100, Ben Finney wrote: > > Mattia Rizzolo <mat...@debian.org> writes: > > > > > What I'm saying is that IMHO the only license requirement (the > > > second paragraph of it that you reported above, about including > > > the copyright notice *and* the permission notice in any copy of > > > the software) is not fulfilled by R packages. > > > > Thanks for clarifying. > > > > Can you point us to a representative source package that you think has > > this problem? > > src:r-cran-praise (as of current version 1.0.0-1) is a good example. I see. The upstream source does not include the “above copyright notice and this permission notice” as required by the license conditions. That is a violation of the license conditions, I agree. > As also pabs said [1] we should be good enough, but I'd prefer we > could drop the enough here. > > [1] https://lists.debian.org/debian-legal/2016/03/msg00067.html This issue should be resolved by the upstream distributor, as I agree with you that they are not compliant with the conditions of the license. You may want to have that discussion with them. I also agree with Paul Wise, that the Debian source package conforms to the license conditions (by always including the required text). So any redistributor of Debian, or this component from Debian, will by default not violate those conditions. -- \ “bash awk grep perl sed, df du, du-du du-du, vi troff su fsck | `\ rm * halt LART LART LART!” —The Swedish BOFH, | _o__)alt.sysadmin.recovery | Ben Finney
Re: detail about license in duc package
Herbert Fortes (hpfn) <h...@ig.com.br> writes: > On version 1.4.0 of the duc package a new file became part of the > software. At a first read I thought it was free. But now I have > doubts. Thank you for taking care to verify Debian users have free software. > First paragraph: > > "Permission is hereby granted, free of charge, to any person obtaining a > copy of this software and/or associated documentation files (the > "Materials"), to deal in the Materials without restriction, including > without limitation the rights to use, copy, modify, merge, publish, > distribute, sublicense, and/or sell copies of the Materials, and to > permit persons to whom the Materials are furnished to do so, subject to > the following conditions:" > > It is define "Materials" as the documentation files only ? That appears to be a custom text by someone who is uncomfortable with using “software” to refer to non-programs. It is otherwise the same as the corresponding paragraph from the Expat license text. My reading of that passage is that “the Materials” refers to “this software and/or associated documentation files”. I think they should just use “software” as in the original, because that term rightly refers to any digitally-encoded information. Either way, the grant is clearly free-software and DFSG-conformant. -- \ “I disapprove of what you say, but I will defend to the death | `\ your right to say it.” —Evelyn Beatrice Hall, _The Friends of | _o__) Voltaire_, 1906 | Ben Finney
Re: R packages licensed MIT but not shipping a copy of the MIT license itself, Re: R packages licensed MIT but not shipping a copy of the MIT license itself
Mattia Rizzolo <mat...@debian.org> writes: > Yes, I see how the MIT license is DFSG-free. What I'm saying is that > IMHO the only license requirement (the second paragraph of it that you > reported above, about including the copyright notice *and* the > permission notice in any copy of the software) is not fulfilled by R > packages. Thanks for clarifying. Can you point us to a representative source package that you think has this problem? -- \ “God was invented to explain mystery. God is always invented to | `\ explain those things that you do not understand.” —Richard P. | _o__) Feynman, 1988 | Ben Finney
Re: R packages licensed MIT but not shipping a copy of the MIT license itself, Re: R packages licensed MIT but not shipping a copy of the MIT license itself
Mattia Rizzolo <mat...@debian.org> writes: > So, today I discovered [0] that R-project has some polices regarding > licenses [1]. In particular they have one regarding the MIT license > [2]. This needs to go together with their extensions manuals [3]. > > Read together they say that if you have an R module you want to license > under MIT (which is really Expat) you have to: I think the wording is ambiguous. At the <URL:https://www.r-project.org/Licenses/> there are no requirements, and no license grants at all, for the dozen license names listed. It simply states that those licenses are “in use” for the code base. Then some statements that R and some specific parts are “licensed under”, or “distributed under”, specific named license conditions. Those could be taken as grant of license as specified in those texts (the GPL v2, the GPL v3, the LGPL v2.1), since they all give explicit freedom to do all the actions needed for DFSG freedom. So the issue you raise would turn on what restrictions are implied by the earlier listed license pages. For the “MIT License” page, we have: > Based on http://opensource.org/licenses/MIT > > This is a template. Complete and ship as file LICENSE the following 2 > lines (only) > > YEAR: > COPYRIGHT HOLDER: > > and specify as > > License: MIT + file LICENSE > > Copyright (c) , I don't think any of the above text implies a *requirement* on the recipient of the license. Indeed, the license grant begins at the standard “MIT” (which is Expat-equivalent) permission grant: > > a copy of this software and associated documentation files (the > "Software"), to deal in the Software without restriction, including > without limitation the rights to use, copy, modify, merge, publish, > distribute, sublicense, and/or sell copies of the Software, and to > permit persons to whom the Software is furnished to do so, subject to > the following conditions: > > The above copyright notice and this permission notice shall be > included in all copies or substantial portions of the Software. That alone grants all the DFSG-conformant freedoms. I don't think anything else in the text is rightly interpreted to restrict those freedoms in any way. It would be better if the guidelines were more clearly phrased to be guidance for *how* to apply the license; as it is, they are terse and too easily misread. But I think a careful reading would not imply any extra restriction on the license recipient. So in my opinion, this is just a clumsy way to present a page that nevertheless is an explicit grant of the standard Expat license conditions in a work. In short: this does not IMO disqualify the work from conforming to the DFSG. Thank you for taking software freedom seriously for Debian recipients. -- \“If it ain't bust don't fix it is a very sound principle and | `\ remains so despite the fact that I have slavishly ignored it | _o__) all my life.” —Douglas Adams | Ben Finney <b...@benfinney.id.au>
Re: R packages licensed MIT but not shipping a copy of the MIT license itself
Mattia Rizzolo <mat...@debian.org> writes: > [ please CC me as I'm not in d-legal@ ] Done. > So, today I discovered [0] that R-project has some polices regarding > licenses [1]. In particular they have one regarding the MIT license > [2]. This needs to go together with their extensions manuals [3]. Thanks for raising our attention to those. For reference, so that we can see the text in the context of this discussion, here is the text in question. At <URL:https://www.r-project.org/Licenses/> is the following text: = R Licenses The following licenses are in use for R or associated software such as packages. The “GNU Affero General Public License” version 3 The “Artistic License” version 2.0 The “BSD 2-clause License” The “BSD 3-clause License” The “GNU General Public License” version 2 The “GNU General Public License” version 3 The “GNU Library General Public License” version 2 The “GNU Lesser General Public License” version 2.1 The “GNU Lesser General Public License” version 3 The “MIT License” The “Creative Commons Attribution-ShareAlike International License” version 4.0 R as a package is licensed under GPL-2 | GPL-3. File doc/COPYING is the same as GPL-2. Some files are licensed under ‘GPL (version 2 or later)’, which includes GPL-3. See the comments in the files to see if this applies. Some header files are distributed under LGPL-2.1: see file COPYRIGHTS (on the SVN server). = Each of the named licenses is a link to another page. At “MIT License” is a link to <URL:https://www.r-project.org/Licenses/MIT> which reads: = Based on http://opensource.org/licenses/MIT This is a template. Complete and ship as file LICENSE the following 2 lines (only) YEAR: COPYRIGHT HOLDER: and specify as License: MIT + file LICENSE Copyright (c) , Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. = -- \ “What I have to do is see, at any rate, that I do not lend | `\ myself to the wrong which I condemn.” —Henry Thoreau, _Civil | _o__) Disobedience_ | Ben Finney <b...@benfinney.id.au>
