Re: Updating the PHP license
On Fri, 24 May 2024 00:11:39 -0500 Ben Ramsey wrote: > > On May 23, 2024, at 13:40, Francesco Poli wrote: > > > > On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote: > > > > [...] > >> I’ve updated the RFC according to your suggestions. > > > > Good! :-) > > Thanks for taking the time to do so. > > > >> You may find a diff of the changes here: > >> > >> https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716433712%5B1%5D=1716437291=sidebyside > >> > >> > >> Please let me know if you have any feedback on these changes. > > > > After a short review, they look OK to me. > > > > The only thing that I would emphasize more is: the PHP License, version > > 4.0 should not just have the text identical to the 3-clause BSD > > license, it should *be* the 3-clause BSD license. In other words, the > > PHP Group would not merely publish a new license with a text identical > > to the text of another license: the PHP Group would *designate*[^NOTE] > > the 3-clause BSD license as the new version of the PHP License (i.e.: > > version 4.0). > > > > [^NOTE]: or *elect*, or *adopt*, the most suitable word should be > >chosen by an English native speaker (which I am not) with legal > >training (which I do not have)... > > > > I think that, this way, clause 5 of the PHP License, version 3.01, > > would be triggered, but there would be no need to explicitly mention > > "PHP License, version 4.0" in the source code of a project that decides > > to upgrade its license (from PHP License, version 3.01 to its > > successor, the 3-clause BSD license). > > The reason would that "PHP License, version 4.0" would become an alias > > of "3-clause BSD license"... > > > > Similarly for the Zend License, of course. > > > > This is how I see it, but, clearly, it has to be checked with someone > > more knowledgeable than me about the legal aspects. > > > Again, great suggestions, Francesco. Many thanks! You are welcome! :-) > > I’ve made a few small changes that make it clear that the PHP License, > version 4, and Zend Engine License, version 3, both adopt the 3-clause BSD > License. > > Changes here: > https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716438337%5B1%5D=1716527050=sidebyside Yeah, I think this is an improvement. Some minor nitpicks (once again, by a non-native speaker, so they could be wrong...): it's not the PHP License, version 4.0, which adopts the 3-clause BSD license; it's the PHP Group which adopts the 3-clause BSD license as the new version (4.0) of the PHP License. If you agree with this reasoning, then I would change the following sentences: - This proposal addresses a longstanding issue within the open source - community by publishing new versions of the PHP License and the Zend - Engine License. The PHP License, version 4, and Zend Engine License, - version 3, will adopt the BSD 3-Clause License. into: + This proposal addresses a longstanding issue within the open source + community by publishing new versions of the PHP License and the Zend + Engine License. The BSD 3-Clause License is adopted as The PHP + License, version 4, and as The Zend Engine License, version 3. and: - Publish the PHP License, version 4, and Zend Engine License, version - 3, both adopting the BSD 3-Clause License, and deprecate the PHP - License and Zend Engine License, as proposed in the Proposal section? into: + Publish the PHP License, version 4, and Zend Engine License, version + 3, by adopting the BSD 3-Clause License as the new version of both, + and deprecate the PHP License and Zend Engine License, as proposed in + the Proposal section? I hope this helps. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpUWfjS4_WeA.pgp Description: PGP signature
Re: Updating the PHP license
On Wed, 22 May 2024 23:13:13 -0500 Ben Ramsey wrote: [...] > I’ve updated the RFC according to your suggestions. Good! :-) Thanks for taking the time to do so. > You may find a diff of the changes here: > > https://wiki.php.net/rfc/php_license_update?do=diff%5B0%5D=1716433712%5B1%5D=1716437291=sidebyside > > > Please let me know if you have any feedback on these changes. After a short review, they look OK to me. The only thing that I would emphasize more is: the PHP License, version 4.0 should not just have the text identical to the 3-clause BSD license, it should *be* the 3-clause BSD license. In other words, the PHP Group would not merely publish a new license with a text identical to the text of another license: the PHP Group would *designate*[^NOTE] the 3-clause BSD license as the new version of the PHP License (i.e.: version 4.0). [^NOTE]: or *elect*, or *adopt*, the most suitable word should be chosen by an English native speaker (which I am not) with legal training (which I do not have)... I think that, this way, clause 5 of the PHP License, version 3.01, would be triggered, but there would be no need to explicitly mention "PHP License, version 4.0" in the source code of a project that decides to upgrade its license (from PHP License, version 3.01 to its successor, the 3-clause BSD license). The reason would that "PHP License, version 4.0" would become an alias of "3-clause BSD license"... Similarly for the Zend License, of course. This is how I see it, but, clearly, it has to be checked with someone more knowledgeable than me about the legal aspects. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp2YhtpMKSg8.pgp Description: PGP signature
Re: Updating the PHP license
On Sun, 19 May 2024 14:53:48 -0500 Ben Ramsey wrote: > On May 19, 2024, at 11:42, Francesco Poli wrote: [...] > > If the PHP Group decides to elect the 3-clause BSD license as the next > > version (4.0) of the PHP License, then clause 5 of the PHP License version > > 3.01 will kick in and any piece of software currently licensed under > > the terms of the PHP License version 3.01 will *instantly* be also > > available under the terms of the 3-clause BSD license, at the > > recipient's choice. > > > > A similar reasoning should hold for the Zend Engine License, as well… > > I want to be clear that this RFC does not exert any control over other > projects that use the PHP License. I would not call it "control". Nobody will be forced to stop copying/modifying/redistributing other projects under the terms of the PHP License version 3.01 . It's just a license-upgrade clause that can be triggered by the license steward, which decides to publish a new version of the license. People who released their own projects under the terms of the PHP License version 3.01 were (or should have been...) aware of the existence of that license-upgrade clause: they decided to trust the PHP Group as license steward. They should not be surprised, if, at some point in time, that license-upgrade clause is actually triggered. [...] > One of my goals with the RFC is to get rid of the idea of a “PHP License,” I agree with this goal. > so it deprecates the PHP License and *replaces* it with the > BSD 3-Clause License. I don’t want there to be a “PHP License, > version 4.0.” I think that will continue to cause confusion > in the community. If the PHP Group decides to adopt the 3-clause BSD license as the new PHP License, version 4.0, there will be no obligation, I think, to mention the term "PHP License, version 4.0" in each PHP source code file. It will be possible to mention the 3-clause BSD license in each source file and to state that PHP will be released under the terms of the 3-clause BSD license. At the same time, somewhere on the php.net website, there will be a page that explicitly says that the PHP Group has adopted the 3-clause BSD license as the PHP License, version 4.0. > > Is there a reading of clause 5 (specifically “You may also choose > to use such covered code under the terms of any subsequent version > of the license published by the PHP Group.”) that would allow > projects using the PHP License to switch to the BSD 3-Clause License, > even if a subsequent version 4.0 of the PHP License is not published? First off, and I should have stated this more explicitly from the beginning, IANAL, TINLA. That being said, I personally don't see how the license-upgrade clause could be triggered, without actually publishing a new version of the license. AFAICT, the strategy to "adopt" the 3-clause BSD license as the new version 4.0 of the PHP License would trigger the license-upgrade clause, while at the same time deprecating the use of the PHP License. The web page on the php.net website could even explicitly say that the PHP License is now deprecated and that the PHP Group has designated the 3-clause BSD license as its successor (PHP License, version 4.0). In addition, triggering the license-upgrade mechanism would make it much clearer that there's no need to ask for permission to all the external contributors and that the license change can be performed just with a vote within the PHP Group. To a layman like me, the reasoning that no contributors, other than representatives of the PHP Group, are able to grant or assert clauses 4, 5, and 6, looks convincing. But I don't know whether it would actually hold water in a court. So, maybe, it's better, if the license-upgrade mechanism is also triggered. Or at least, this is how I personally see it. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpdDB3FKTMxI.pgp Description: PGP signature
Re: Updating the PHP license
On Sat, 18 May 2024 15:18:36 -0500 Ben Ramsey wrote: > Hi, all! Hello Ben! > > Over the years, the open source community, including Debian, has had > a few lengthy discussions and disagreements regarding the PHP > license.[^1][^2][^3] The TL;DR sentiment of all these discussions > amounts to: change the license to something well-understood and less > problematic. Indeed, I have personally voiced my disappointment with the PHP License for a long time. See, for instance, my [analysis] of the PHP License, version 3.01, and an additional [comment] about another issue. [analysis]: <https://lists.debian.org/debian-legal/2005/11/msg00272.html> [comment]: <https://lists.debian.org/debian-legal/2006/02/msg00371.html> And I have also attempted to persuade the PHP Group to switch to a well known and widely adopted general purpose (DFSG-compliant) license. I got in touch with the PHP Group back in 2016 and tried to convince them to switch to the 3-clause BSD license, but my attempt was unfortunately unsuccessful... > > So, that’s what I’m proposing to do in a new RFC I’ve drafted for the > PHP project: https://wiki.php.net/rfc/php_license_update Given what I said above, you may guess I am really happy about your RFC! Thanks a lot for drafting it and for stewarding this proposal. > > I’ve not opened this up for discussion within the PHP project yet, > since I’m still collecting feedback, and that’s why I’m sharing it > here. I’ve put a lot of work into presenting what I think is a sound > and well-reasoned argument for this change, and I’m asking for > feedback from this group regarding the method and theory I’m using to > go about it. Here's some feedback about version 0.3 of your RFC. | The proposed changes for the PHP software repository will not affect | the PHP Manual. The PHP Manual will remain licensed under the Creative | Commons Attribution 3.0 License or later. How unfortunate! Creative Commons licenses are also controversial (although this one, CC-by-v3.0, is accepted by the Debian Project, I personally disagree). Anyway, the general recommendation is to license the documentation under the same legal terms as the documented program or library. Hence, I would suggest to also switch the PHP Manual to the 3-clause BSD license... this would be absolutely great (although it would probably require to seek approval among its copyright holders). | External extensions currently licensed under the PHP License may | continue to use the PHP License. There is no need to change extension | licenses. I don't think so. If the PHP Group decides to elect the 3-clause BSD license as the next version (4.0) of the PHP License, then clause 5 of the PHP License version 3.01 will kick in and any piece of software currently licensed under the terms of the PHP License version 3.01 will *instantly* be also available under the terms of the 3-clause BSD license, at the recipient's choice. A similar reasoning should hold for the Zend Engine License, as well... > > Thanks in advance! You're welcome. Thanks to you for sharing this draft document! > > Cheers, > Ben Bye! :-) > > > [^1]: > https://duckduckgo.com/?q=site%3Ahttps%3A%2F%2Flists.debian.org%2Fdebian-legal%2F+php > [^2]: https://lwn.net/Articles/604630/ > [^3]: https://ftp-master.debian.org/php-license.html > -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpiFo3xMP9_N.pgp Description: PGP signature
Re: Expat license and "free for academic users"
On Tue, 20 Jun 2023 10:14:41 +0300 Andrius Merkys wrote: > Hello, Hi! > > [Please keep me in CC, I am not subscribed] Done. > > I encountered a package EvoEF2 [1] which is licensed under Expat and has > the following in its README.md: > > "EvoEF2 is free to academic users." > > To me such limitation seems to contradict the Expat license, but I > wonder what is the legal opinion about such combination. I know that I > can always ask the upstream for clarification which I did earlier when > the restriction was: > > "... unauthorized copying of the source code files via any medium is > strictly prohibited." > > However, I am interested in the legal meaning of the current situation. > > [1] https://github.com/tommyhuangthu/EvoEF2 > [2] https://github.com/tommyhuangthu/EvoEF2/issues/1 Well, take into account that I am not a lawyer. Anyway, to me, the sentence "EvoEF2 is free to academic users." looks a little misleading. One could nitpick that the sentence is not false: it's true that EvoEF2 is free to academic users, since it's released under the Expat license, and therefore it's free to everyone, including academic users. However, the sentence may make the reader think that EvoEF2 is free _only_ to academic users, although it does not say so. I would suggest to once again get in touch with upstream and persuade them to drop that sentence, or perhaps to replace it with something like "EvoEF2 is free to all users." I hope this helps. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp4iS7ux53zG.pgp Description: PGP signature
Re: The 'Source' field in DEP 5
On Sat, 12 Nov 2022 22:13:11 +0500 Akbarkhon Variskhanov wrote: > Hi. Hello! > > I know that this format is optional but I was wondering what exactly > this field is expected to include. In my interpretation, it's a URL to > a directory containing upstream tarballs, say > https://www.example.com/src/download. However, I've also seen people > put links to upstream Git repositories. Which one is closer to the > definition and is preferred over the other? The official [documentation] says: [...] | 6.4. Source | | Formatted text, no synopsis: an explanation of where the upstream | source came from. Typically this would be a URL, but it might be a | free-form explanation. The Debian Policy section 12.5 requires this | information unless there are no upstream sources, which is mainly the | case for native Debian packages. If the upstream source has been | modified to remove non-free parts, that should be explained in this | field. [...] [documentation]: <https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#source-field> I interpret it to mean that you should use this field to explain where you took the upstream source from. Basically, whatever you started from, in order to create the Debian package. > Technically, *the* source > is the Git repository but if we're talking about packaged releases, > tarball is the source to which the current debian/copyright file > applies. It seems to me that both interpretations may be deemed valid. > Was that intentional? Could you perhaps clarify it a little bit? I think it's flexible enough to accommodate for any specific case. Anyway, I am _not_ one of the people who were involved in the drafting of the machine readable debian/copyright format specification. Maybe one of those people can clarify better than me... I hope this helps. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpwW4n9wY8Qb.pgp Description: PGP signature
Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?
On Thu, 08 Sep 2022 23:32:34 -0600 Sam Hartman wrote: [...] > That's certainly what the FSF would prefer you do, yes. > However, there are a few things to consider: > > 1) It's not clear that the FSF's copyright on the GPL allows you to > borrow text from it for your license. I believe it does not. > > 2) It will be harder to figure out how a license constructed as you > propose differs from the GPL and may be harder to analyze such a > license. > > Keep in mind that the FSF, authors of the FAQ you point to want to make > it hard to "fork" the GPL both because they would rather you simply pick > the GPL and because they want to discourage license proliferation. > There's nothing wrong with those goals; as an example Debian almost > certainly wants to discourage license proliferation too. > But those goals do create a certain bias in what the FSF recommends. I agree with what you say here. > > In either case, I think we're well beyond the scope of this list. Yes. :-) -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpu7VoMGl5dp.pgp Description: PGP signature
Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?
On Thu, 08 Sep 2022 01:35:59 -0600 Sam Hartman wrote: > >>>>> "Francesco" == Francesco Poli writes: > > Francesco> So licensing under the terms of the GNU GPL v2 and then > Francesco> adding further restrictions creates a self-contradiction. > Francesco> That does not seem a correct way to apply the GPL... > > No, it does not. That term--the term that forbids you from adding > restrictions--clearly conflicts with the "main body of the license," so > the main body of the license rather than the GPL controls. Clearly such > a license is not GPL compatible, although it may be free. Other > discussion in this thread suggests it is in fact non-free, but I want to > push back on the idea that the license is self-contradictory (and thus > non-distributable). OK, maybe it does not create a self-contradiction. However, I think that it is at least a bit misleading that this license claims to be the GNU GPL v2 with exceptions/clarifications/additions, when these exceptions effectively disable one of the main points of the GNU GPL v2 (that is to say: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein"). I am under the impression that a more correct way to achieve the same results (free or non-free) would be to create a different license, possibly reusing some parts of the GNU GPL v2, but without referring to the GNU GPL v2 (except for the acknowledgment that the new license includes some modified pieces taken from the GNU GPL v2). In other words, following the [FAQ]. [FAQ]: <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#ModifyGPL> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpmuPQ7LkHRH.pgp Description: PGP signature
Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?
On Sun, 04 Sep 2022 20:29:24 -0700 Walter Landry wrote: [...] > Covered Software is licensed to you under the terms of the GPL > (Exhibit A), with all the exceptions, clarifications, and additions > noted in this Main License Body. Where the terms in this Main License > Body conflict in any way with the GPL, the Main License Body terms > shall take precedence. [...] But the GNU GPL v2 clearly states: [...] > 6. Each time you redistribute the Program (or any work based on the > Program), the recipient automatically receives a license from the > original licensor to copy, distribute or modify the Program subject to > these terms and conditions. You may not impose any further > restrictions on the recipients' exercise of the rights granted > herein. [...] So licensing under the terms of the GNU GPL v2 and then adding further restrictions creates a self-contradiction. That does not seem a correct way to apply the GPL... See also some [old discussions] about this kind of issue. [old discussions]: <https://lists.debian.org/debian-legal/2006/05/msg00303.html> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpcwps2k9X45.pgp Description: PGP signature
Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?
On Mon, 05 Sep 2022 23:48:38 +0200 Hilko Bengen wrote: [...] > It has been suggested that upstream switch the > license to AGPL3 instead, but nothing of the sort has happened and I > don't expect such a change to happen anytime soon. [...] Speaking for myself: please, no. Although the GNU AfferoGPL v3 is currently [accepted] by Debian FTP Masters, it's a [controversial] license that a [number of people] (including [myself]) consider non-free. [accepted]: <https://bugs.debian.org/495721#17> [controversial]: <https://bugs.debian.org/495721#28> [number of people]: <https://raw-output.org/20071120/agpl> [myself]: <https://lists.debian.org/debian-legal/2007/11/msg00233.html> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Re: Microsoft Public License DFSG compatibility
On Sat, 20 Aug 2022 00:42:39 -0400 Ben Westover wrote: > Hello, Hi! > > I was going to package some software that has portions licensed under > the Microsoft Public License. Is it copatible with the DFSG? A quick > search yielded no results. There seems to be an [old thread] about possible interactions with MS-PL licensed libraries and LGPL licensed libraries. However, it does not go into much detail about the MS-PL... [old thread]: <https://lists.debian.org/debian-legal/2010/12/msg00056.html> > Below is the full text of the license. > > Thanks, You are welcome. What follows is my quick analysis of the license text. Please note that I am a DM, but I only speak for myself: this is not an official statement from the Debian Project, just my own personal opinion. > -- [...] > > This license governs use of the accompanying software. If you use the > software, you accept this license. If you do not accept the license, do > not use the software. This may be a minor flaw of this license: it wants to govern use, while Free Software license should not restrict use (usually, only copy, modification, redistribution, and stuff like that, are possibly restricted). However, it seems that use is not much restricted by the license text (see below), so this flaw could perhaps be considered negligible... > > 1. Definitions [...] Nothing special or surprising here, it seems. > 2. Grant of Rights > > (A) Copyright Grant- Subject to the terms of this license, including the > license conditions and limitations in section 3, each contributor grants > you a non-exclusive, worldwide, royalty-free copyright license to > reproduce its contribution, prepare derivative works of its > contribution, and distribute its contribution or any derivative works > that you create. This seems to allow anyone to copy, modify, and/or redistribute the work. It looks OK. > > (B) Patent Grant- Subject to the terms of this license, including the > license conditions and limitations in section 3, each contributor grants > you a non-exclusive, worldwide, royalty-free license under its licensed > patents to make, have made, use, sell, offer for sale, import, and/or > otherwise dispose of its contribution in the software or derivative > works of the contribution in the software. This grants a patent license as well. It seems to be a good thing to have. > > 3. Conditions and Limitations > > (A) No Trademark License- This license does not grant you rights to use > any contributors' name, logo, or trademarks. This is implicitly true for many Free Software licenses. Hence, nothing to worry about, I would say. ...unless the work under consideration is associated with trademarks governed by some overly aggressive trademark policies. > > (B) If you bring a patent claim against any contributor over patents > that you claim are infringed by the software, your patent license from > such contributor to the software ends automatically. This clause restricts your possibility to sue for patent infringement: if you do so for patents related to the work, you lose the patent grant from the sued contributor over the work itself. This kind of clauses were discussed a long ago on debian-legal: if I recall correctly, this, rather limited, variant was considered to be acceptable by many (if not all) debian-legal regulars at the time. > > (C) If you distribute any portion of the software, you must retain all > copyright, patent, trademark, and attribution notices that are present > in the software. Nothing unusual. > > (D) If you distribute any portion of the software in source code form, > you may do so only under this license by including a complete copy of > this license with your distribution. If you distribute any portion of > the software in compiled or object code form, you may only do so under a > license that complies with this license. Rather permissive, I would say. > > (E) The software is licensed "as-is." You bear the risk of using it. The > contributors give no express warranties, guarantees or conditions. You > may have additional consumer rights under your local laws which this > license cannot change. To the extent permitted under your local laws, > the contributors exclude the implied warranties of merchantability, > fitness for a particular purpose and non-infringement. Typical warranty disclaimer (even though worded in rather unusual way). I think it's fine. All in all, it seems to me that the license text should be considered acceptable. I think that software solely licensed under these terms (barring other issues) could be considered to comply with the DFSG. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp9gRpaNMUxZ.pgp Description: PGP signature
Re: Is the APSL 2.0 DFSG-compliant?
hich would circumvent the requirement to make source code publicly or > semi-publicly available, is good and true in its core, but not a practical one > for software distributors that provide binary packages as the primary means of > installation, since the binary packages are almost never accompanied by source > code. Practically, Debian will always need to make source code available > externally, unless we require bundling source code with APSL-2.0-licensed > binary works. [...] Debian *is* offering source for download from the same archive/mirror infrastructure. This is enough for the GNU GPL v2, without any other future obligations. Contrast this with the APSL v2.0, which imposes obligations for at least 12 months from the initial "External Deployment", even in the cases where the source has been bundled with all binary distributions. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpnmZxte2mq7.pgp Description: PGP signature
Re: Advice about a package fork (displaycal)
On Tue, 05 Jul 2022 08:32:09 +0200 Christian Marillat wrote: > Hi, Hello Christian, > > [Please Cc me I'm not subscribed to this list] Done. > > I was the displaycal (python2 version) maintainer but asked his removal > as the curren maintain doesn't reply to e-mails > > A fork has been done, but as discussed in > https://github.com/eoyilmaz/displaycal-py3/issues/96 > people do not agree to the license and project.binary name. > > Can you give me your opinion ? Well, first of all, I should say that the GNU GPL does not require a name change for modified/derived/forked versions of a work. And copyright law does not cover names, as far as I can tell. Depending on the details of diplayCAL, and on the jurisdiction under consideration (which may vary across different hypothetical lawsuits, due to rules for the selection of venue...), trademark laws of a specific country could impose a name change for a fork. And anyway, in order to avoid confusion with the original project, I personally think it would be nice that a fork adopted a distinct name. Especially if the fork is significantly diverging from the original project and created without talking to the original developers (because they do not reply, in the present case, but that doesn't change the fact that they were not got in touch with...). I agree with Paul Wise (pabs3) that "diplayCAL-ng" (or "displayCAL-py3") is probably too similar to the original name to avoid confusion. You should come up with something more creative (maybe "FreeScreenCalibrator"? or "calibscreen"?). By the way, avoiding confusion is the main point of (sane) trademark laws. I hope this helps, at least a bit. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpeaMtbl4_0A.pgp Description: PGP signature
Re: a quick review of the timescaledb license
On Tue, 07 Jun 2022 12:11:11 -0400 Antoine Beaupré wrote: [...] > Okay, so what's in that `tsl/` folder? there you have *another* LICENSE > file which is a custom license written specifically (presumably by > lawyers) for timescaleDB: > > https://github.com/timescale/timescaledb/blob/3c56d3ecebbf476293ff43ded142bc9e5087f6de/tsl/LICENSE-TIMESCALE > > I haven't read the entirety of it, Nor have I, but some parts of it look clearly non-free, as you yourself point out. > but it's pretty clear to me that this > cannot be packaged in Debian at all, ever, under that license. Just > clause 2.2 (prohibiting use in "software-as-a-service") breaks clause 6 > of the Debian free software guidelines. [...] Part of clause 2.2 states: [...] | 2.2 Prohibitions. Notwithstanding any other provision in this TSL | Agreement, You are prohibited from (i) using any TSL Licensed Software to | provide time-sharing services or database-as-a-service services, or to | provide any form of software-as-a-service or service offering in which the | TSL Licensed Software is offered or made available to third parties to | provide time-series database functions or operations, other than as part of | Your Value Added Products or Services, or (ii) copying or distributing any | TSL Licensed Software for use in any of the foregoing ways. [...] This really seems to fail DFSG#6 . There are other parts of this license which appear to be blatantly non-free, but I haven't studied them in detail... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpp5K6SsIdtg.pgp Description: PGP signature
Re: Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))
On Wed, 26 Jan 2022 07:38:10 +0100 Andreas Tille wrote: > Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery: [...] > > The question, which keeps being raised in part > > because I don't think it's gotten a good answer, is what the basis is for > > treating copyright and licensing bugs differently than any other bug in > > Debian? I thought the basis was the fact that copyright and licensing bugs may have bad legal consequences (lawsuits against the Project for distributing legally undistributable packages, things like that), while technical bugs do not cause issues with lawyers and are, in this sense, "easier" to fix. The consequences of introducing a "legally botched" package into the archive are thus harder to undo, with respect to introducing a technically flawed package... > > > > The need for pre-screening was obvious when we had export control issues, > > but my understanding is that those have gone away. Are we working from > > legal advice telling us that this pre-screening is required for some legal > > purpose? If so, is it effective for the legal purpose at which it is > > aimed? Is this system left over from old advice? Have we checked our > > assumptions recently? I am under the impression that the pre-screening in the NEW queue is an attempt to catch legal issues *before* the package is introduced into the archive. As far as I remember, the FTP masters are the people responsible for what the Debian Project distributes through its archive... Is this wrong (or no longer valid)? [...] > > NEW processing is a lot of friction for the project as a whole and a lot > > of work for the ftp team. If we were able to do less work at the cost of > > a minimal increase in bugs, or at the cost of handling bugs a bit > > differently, maybe that would be a good thing? > > > > In other words, it's unclear what requirements we're attempting to meet > > and what the basis of those requirements is, which makes it hard to have a > > conversation about whether the current design is the best design for the > > problem we're trying to solve. > > I'm CCing debian-legal for this branch of the discussion (but I do not > read this list and think keeping debian-devel in the row is a good idea). Personally, I think the legal pre-screening by the FTP masters in the NEW queue is useful and should be kept. In fact, I wish the pre-screening were stricter. I've seen cases, where a bug is reported against a legally undistributable package and the issue is left unaddressed for ages with nobody apparently caring enough. Maybe it's better, if such issues are addressed *before* the package is accepted into the archive... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpR2ghAqCFHr.pgp Description: PGP signature
Re: Advice on licenses with "funny" amendments
On Thu, 7 Oct 2021 23:56:57 +0200 Dominik George wrote: > Hi, Hello! > > some times, we (the AlekSIS team) stumble upon upstream maintainers > who consider it funny to add amendments to licenses, or make up fun > licenses on their own. Personally, I think licenses and jokes are best left distinct. Inserting the latter into the former is often a bad idea... [...] > "BUT if you become a millionaire using this code, please bought >me a new brand luxury sailboat." [...] > "Please do whatever your mom would approve of. No tattoos, >No touching food with unwashed hands, No exchanging for drugs" [...] However, these two examples look more like kind requests, rather than legally binding requirements. The first one says "please bought me" [I think it should be "please buy me"]: you are not forced to do so. The second starts with "Please do". I think the continuation "No ... No ... No ..." is just an enumeration of what your mom would disapprove of. What do other debian-legal participants think? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpDRL0eQ517i.pgp Description: PGP signature
Re: Acceptability of a documentation license for Debian
ame terms | as the software they refer to, or any of the traditional free | software licenses like the GPL or the BSD license. [winning option]: <https://www.debian.org/vote/2006/vote_001#amendmenttexta> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpqmpRg7on8Z.pgp Description: PGP signature
Re: Acceptability of a documentation license for Debian
On Sun, 29 Aug 2021 20:16:57 -0400 Jeffrey H. Johnson wrote: > Greetings, > > I'm contacting the list to inquire regarding the acceptability > of the following proposed documentation license, as I'd like to > ensure that it will become be an impediment to having > documentation licensed under it added to Debian in the future. Hello, you seem to be drafting (possibly along with other people) a new license that you propose for documentation. Even before commenting the details of the license text, I would like to express my own personal opinion on the operation itself. My personal recommendation is: please, don't. License proliferation is harmful, and adding another newly drafted license to the already excessively long list of existing licenses should be avoided, unless absolutely necessary. Writing a good license text, avoiding all the subtle pitfalls that may cause unexpected results, is a very hard task: even legal experts may spend a very long time and yet come up with a flawed text. The use of existing, well-known and well-vetted licenses is highly recommended. Moreover, you are proposing a license specifically designed to be applied to documentation only. This is a poor choice, because the boundaries of what is exactly "documentation" are not so well-defined as one might think. In my own personal opinion, a good license should applicable to any kind of software (in the broad sense of the word, see my [essay] on the topic, for more details). [essay]: <https://www.inventati.org/frx/essays/softfrdm/whatissoftware.html> You are searching for a good simple and permissive license that can be applied to documentation. My recommendation is: if you are writing documentation for a specific program or library, use the same license as the program or library itself. This allows anyone to transfer material back and forth between the program or library and the documentation without having to ask for additional permissions (for instance: material from the documentation may be used to enhance the online help of a program or the comments in the source code of a library, and vice-versa). In the case of DPS8M, I seem to understand that the majority of the code is under the [ICU license], which looks perfectly OK for documentation as well (and meets the DFSG). [ICU license]: <https://gitlab.com/dps8m/dps8m/-/blob/505ed98481766ac936cf0b5ff8de04abd7547f08/LICENSE.md#dps8m-simulator Otherwise, if you are writing general documentation about many different programs/libraries or about other topics (science, art, ...), a simple permissive license that I would recommend is the [Expat] license or the [zlib] license. [Expat]: <http://www.jclark.com/xml/copying.txt> [zlib]: <https://www.zlib.net/zlib_license.html> [...] > Thank you, Thanks to you for asking for advice! I hope my reply may be helpful. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpEbZL3669IF.pgp Description: PGP signature
Re: Concern about a Sun license
On Tue, 10 Aug 2021 15:28:47 +0200 Pierre Gruet wrote:
> Hello,
Hi!
>
> When working on igv (which is currently in non-free), I stumbled upon
> the license [...] including the following:
[...]
> I feel that the "disparaging to Sun" part is a blocker for including the
> software in the main section. Do you agree?
> And what about the last sentence?
My own personal opinion is that there are a number of showstoppers
here, before the package can even be considered for inclusion in Debian
(main).
As far as DFSG-compliance is concerned, I took a look at its
debian/copyright [file], assuming it is accurate.
[file]: <https://tracker.debian.org/media/packages/i/igv/copyright-2.6.3dfsg-3>
The license for src/main/resources-jlfgr-1_0/* states, in part:
[...]
| Sun grants you ("Licensee") a non-exclusive,
| royalty free, license to use, and redistribute
| this software graphics artwork,
This grants permission to use and redistribute, but not to modify, thus
failing DFSG#3.
[...]
| ii) you do not
| utilize the software graphics artwork in a manner
| which is disparaging to Sun.
This specifically forbids some kind of use of the work, thus failing
DFSG#6.
I acknowledge that there may be other, copyright-unrelated, laws that
already forbid slander and/or libel. But this clause adds a possibly
overreaching license restriction that bans any use which may be
considered disparaging to Sun.
| Unless enforcement
| is prohibited by applicable law, you may not
| modify the graphics, and must use them true to
| color and unmodified in every way.
[...]
This restates (more explicitly) that no modification whatsoever is
allowed, thus making clearer that DFSG#3 is not met.
If anyone is going to attempt to persuade the copyright holders of
src/main/resources-jlfgr-1_0/* to re-license those files in a DFSG-free
manner, please take into account that Sun Microsystems, Inc. has been
acquired by Oracle Corporation in 2010 (as many people probably know),
but these assets are not necessarily in the hands of Oracle right now
(they could have been previously sold or donated to someone else).
Anyway, if you manage to track down the current copyright holders,
please try and persuade them to re-license under the Expat license, if
possible.
Another possibility could be to drop all those images from the package
and replace them with DFSG-free equivalent images.
In the meanwhile, I would recommended to also seek re-licensing
(from Apache-1.1 to Apache-2.0) of src/main/java/org/apache/*
The Apache-1.1 license is obsolete and has a clause (number 5) which I
personally consider overreaching and non-free (although Debian FTP
Masters seem to be OK with it).
Since those files are copyrighted by The Apache Software Foundation,
which switched to the Apache-2.0 license long ago, it's likely that
they are willing to re-license...
All the above concerns the DFSG-compliance.
Other requisites may still have to be fulfilled, before the package can
be considered for the [main] archive area...
[main]:
<https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area>
>
> I am a bit concerned because a check in sources.debian.org shows some
> software currently in main embed files with the "disparaging to Sun" part.
My own personal opinion is that a package in main with such a clause
has a bug that should be reported...
[...]
> P.S. : please CC-me, as I am not subscribed.
Done.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpS6EhkUzVux.pgp
Description: PGP signature
Re: Dúvida sobre licenciamento CRM Public License Version 1.0
On Mon, 26 Jul 2021 22:47:07 +0200 Francesco Poli wrote: [...] > For future reference, here's the complete text of the license > under discussion [...] My own personal comments follow. > Welcome to the Vtiger Public License > > Copyright (c) 2004 - 2017 www.vtiger.com All rights reserved. PLEASE > READ THE FOLLOWING LICENSE AGREEMENT CAREFULLY. ANY USE OF SOFTWARE > DOWNLOADED OR ORDERED FROM VTIGER IS PERMITTED ONLY UNDER LICENSE WITH > VTIGER. BY DOWNLOADING THIS SOFTWARE YOU AGREE TO BE BOUND BY THE TERMS > OF THIS LICENSE AGREEMENT. > > 1. Definitions. > > 1.0. "Commercial Use" means distribution or otherwise making the > Covered Code available to a third party. This is a weird definition of "Commercial Use": if, for instance, I gratuitously give it away to a friend, I am making "Commercial Use" of it... Let's try and remember this definition in the following. [...] > 2. Source Code License. [...] > (d) Notwithstanding Section 2.1(b) above, no patent license is granted: > 1) for code that You delete from the Original Code; 2) separate from > the Original Code; I agree with Walter's doubts on this. This really seems to mean that, if I separate the patented code (by progressively dropping the remainder), the patent license granted to me eventually disappears... [...] > 3.2. Availability of Source Code. Any Modification which You create or > to which You contribute must be made available in Source Code form > under the terms of this License either on the same media as an > Executable version or via an accepted Electronic Distribution Mechanism > to anyone to whom you made an Executable version available; and if made > available via Electronic Distribution Mechanism, must remain available > for at least twelve (12) months after the date it initially became > available, or at least six (6) months after a subsequent version of > that particular Modification has been made available to such > recipients. You are responsible for ensuring that the Source Code > version remains available even if the Electronic Distribution Mechanism > is maintained by a third party. I agree with Walter's comments on the practical issues raised by this clause. Debian does not guarantee that a version is kept online for at least 6 months after a subsequent version has been made available. I think this is a serious flaw of the license. [...] > 3.4. Intellectual Property Matters (a) Third Party Claims. [...] > If Contributor obtains such > knowledge after the Modification is made available as described in > Section 3.2, Contributor shall promptly modify the LEGAL file in all > copies Contributor makes available thereafter and shall take other > steps (such as notifying appropriate mailing lists or newsgroups) > reasonably calculated to inform those who received the Covered Code > that new knowledge has been obtained. This creates legal obligations to perform actions even after you have stopped distributing the Covered Code. I think this clause does not meet the DFSG, possibly because these obligations can be seen as a sort of fee for the right to distribute (DFSG#1). [...] > 11. MISCELLANEOUS. [...] > This License shall be governed by > Indian laws (except to the extent applicable law, if any, provides > otherwise), excluding its conflict-of-law provisions. This is a choice-of-law clause, which may be acceptable. > With respect to > disputes in which at least one party is a citizen of, or an entity > chartered or registered to do business in India, any litigation > relating to this License shall be subject to the jurisdiction of the > Courts in Chennai, with venue lying in Tamil Nadu State, India, with > the losing party responsible for costs, including without limitation, > court costs and reasonable attorneys' fees and expenses. [...] This is a choice-of-venue clause, a category of clauses which has been discussed to death on debian-legal in the past. My own personal opinion is that choice-of-venue clauses do not meet the DFSG, since they may impose arbitrary costs to licensees (living far away from the venue, India in the present case) being sued by the licensor. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpNgHjw4Tubc.pgp Description: PGP signature
Re: Dúvida sobre licenciamento CRM Public License Version 1.0
rm 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. 11. 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. This License shall be governed by Indian laws (except to the extent applicable law, if any, provides otherwise), excluding its conflict-of-law provisions. With respect to disputes in which at least one party is a citizen of, or an entity chartered or registered to do business in India, any litigation relating to this License shall be subject to the jurisdiction of the Courts in Chennai, with venue lying in Tamil Nadu State, India, with the losing party responsible for costs, including without limitation, court costs and reasonable attorneys' fees and expenses. The application of the United Nations Convention on Contracts for the International Sale of Goods is expressly excluded. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not apply to this License. 12. RESPONSIBILITY FOR CLAIMS. As between Initial Developer 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 Initial Developer and Contributors to distribute such responsibility on an equitable basis. Nothing herein is intended or shall be deemed to constitute any admission of liability. 13. MULTIPLE-LICENSED CODE. Initial Developer may designate portions of the Covered Code as “Multiple-Licensed”. “Multiple-Licensed” means that the Initial Developer permits you to utilize portions of the Covered Code under Your choice of the MPL or the alternative licenses, if any, specified by the Initial Developer in the file described in Exhibit A. EXHIBIT A - Vtiger Public License. "The contents of this file are subject to the Vtiger Public License (the "License"); you may not use this file except in compliance with the License." 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 Vtiger. The Initial Developer of the Original Code is Vtiger. Portions created by Vtiger are Copyright (C) www.vtiger.com. All Rights Reserved. Contributor(s): __. [NOTE: The text of this Exhibit A may differ slightly from the text of the notices in the Source Code files of the Original Code. You should use the text of this Exhibit A rather than the text found in the Original Code Source Code for Your Modifications.] EXHIBIT B - Vtiger CRM and Logo This License does not grant any rights to use the trademarks "Vtiger" and "Vtiger CRM" and "Vtiger" logos even if such marks are included in the Original Code or Modifications. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpnQ1KFcAt28.pgp Description: PGP signature
Re: MIT Licensed code in LD_PRELOAD?
On Mon, 21 Jun 2021 10:10:57 +0200 Marc Haber wrote: [...] > Is the MIT License sufficiently compatible to the (L)GPL to allow this > use? I assume that, by MIT, you mean the [Expat] license. [Expat]: <http://www.jclark.com/xml/copying.txt> As far as I can tell, the [Expat] license is basically compatible with (almost) anything... Hence, unless I am really mistaken, I would say that there should not be any showstopper. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpbjgkwxgOV0.pgp Description: PGP signature
Re: License and Copyright info for debconf translation of aide package
On Wed, 20 Jan 2021 10:16:19 +0100 Marc Haber wrote: > Hi, Hello! > > while reviewing the aide package for writing a machine-readable > debian/copyright file, I have stumbled up on the translations. I think that paying attention to translation licenses is a good thing to do. Thanks for caring about it! > > https://salsa.debian.org/debian/aide/-/tree/master/debian/po > > Oh, what a mess. > > Most of the translatiosn don't have a license statement at all, some > have correctly stated that the same license as for the aide package > applies, and one translator has made an obvious cut error, putting > the aide translation under the same license as the postfix package. Ouch! :-( > Since the postfix package uses a rather exotic dual-license scheme that > doesn't include a GPL variant, this is rather bad for an otherweise > GPLled package. Indeed, postfix is dual-licensed under the EPL v2.0 and the IBM CPL v1.0 (I am [not even convinced] that this license meets the DFSG). Definitely GPL-incompatible, anyway. I personally think that this translation should be re-licensed by the translators or removed. [not even convinced]: <https://lists.debian.org/debian-legal/2006/06/msg00234.html> > > Most of the files have not been touched for a decade, and I doubt that > the original translators are still around. > > Can I safely assume that a translation without an explicit license was > meant to be licensed with the package, which would be GPL-2+ in this > case? Well, a translation (.po file) is a derivative work of the original message collection (.pot file), which is extracted from the original program. If the original program is under the GNU GPL v2 license or later, one can argue that the translation is only distributable under the same licensing scheme (or later), and hence implicitly under the GPL. However, my personal opinion is that it would be much much better, if the licensing status of the translation file were explicitly stated. Hence, I would suggest you to seek clarification from translators, whenever possible. > Or is this unlicensed work and need to be relicensed, and in the > case the original translator is no longer available, must be removed? Maybe not removed, but a license clarification should be sought. What do others think? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpANhTc9Pk7S.pgp Description: PGP signature
Re: Bug#979101: Legally problematic GPL-3+ readline dependency
On Thu, 7 Jan 2021 18:45:14 -0300 Carlos Henrique Lima Melara wrote: > Hi, folks. Hello Carlos. > > I'm the new maintainer of devtodo and would appreciate an assistance of the > debian-legal on the license matter. As noted, devtodo is licensed under > GPL-2 only, although there is no boilerplate copyright on the source files. Please note that asking upstream to switch from GPL-2 to GPL-2+ is not the only way out from this license incompatibility issue. See my [message] to debian-legal for more information. [message]: <https://lists.debian.org/debian-legal/2021/01/msg00010.html> Some of these alternative strategies have already been mentioned in the original bug report... > > Taking this into consideration, would a public mail from the upstream to > this bug be enough to change the license to GPL-2+? Or it would be necessary > to add the boilerplate to all source files indicating GPL-2+ licensing? If you are going for option b (ask the copyright holders to re-license the program from GPL-2 to GPL-2+), then the best possible outcome would be to have them add the appropriate boilerplate to all the files. Failing that, a centralized LICENSE or README file placed by the copyright holders could suffice (or even a documented e-mail exchange with all the copyright holders, as a last resort). I hope this helps. Thanks for taking care of this! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpWkINTHYiiz.pgp Description: PGP signature
Re: GPL-2-only packages using GPL-3+ readline
On Sat, 02 Jan 2021 11:16:03 -0500 John Scott wrote: > In general, this license clash doesn't seem to be a strictly downstream issue. Well, in my own personal opinion, it is also (if not mainly) an issue for anyone who distributes prebuilt binaries linked with the incompatible library... Hence, I think it is indeed a downstream issue (too)... > Perhaps you should file bugs with the upstream projects to either revise > their > licensing if they can or explicitly depend on libeditreadline-dev, especially > for the projects that fail to build with it. ...although I agree that each of these issues is best resolved upstream, if possible. I think that the possible suggestions for the upstream developers (or, if all else fails, for the Debian package maintainers) should be one of the following alternatives (in descending order of preference): a) port the program to a GPLv2-compatible readline replacement (such as libedit or similar, possibly by using a shim library such as libeditreadline) b) re-license the program from GPLv2-only to GPLv2-or-later c) disable any link with readline and make do without command editing/history (which is not great, but it could be necessary in some cases) d) build the program by linking with an old GPLv2-compatible version of readline Please note that the drawbacks of option c could be mitigated by using wrappers such as rlwrap or rlfe... [...] > In any case I appreciate the digging you've done. +1 -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpb7Ua4FDOmC.pgp Description: PGP signature
Re: Bug#964815: it looks like dprof2calltree cannot be distributed with a GPL-2 work
On Fri, 10 Jul 2020 18:33:32 -0400 Nicholas D Steeves wrote: [...] > Adrian Bunk writes: > > > On Fri, Jul 10, 2020 at 03:38:57PM -0400, Nicholas D Steeves wrote: > >>... > >> * Neither name of the company nor the names of its contributors may be > >> used to endorse or promote products derived from this software without > >> specific prior written permission. > >> > >> I'm not 100% certain that bundling dprof2calltree with kcachegrind > >> constitutes a "product[s] derived from this software", because I'm also of > >> the opinion that bundling != derivation, but it seems like a lawyer might > >> argue the it does. Personally I would agree that bundling is different from creating a "derived product". But, of course, there's some room for interpretation (especially in a court...). > >> So kcachegrind and any distributions' package would also need written > >> persmission from OmniTI Computer Consulting. Only if they want to use the "OmniTI Computer Consulting" company name (or the name of possible contributors) in order to endorse or promote their products. And only as long as these products are deemed to be derived from dprof2calltree, as said above. > >>... > > > > You are arguing the 3-Clause BSD License would be non-free? > > > > No, because dprof2calltree is modified 4-Clause BSD. Well, as far as I can say, the 4-clause BSD license is considered acceptable for Debian main. It is also [considered] a free software license by the FSF, although it is considered GPL-incompatible, ugly and strongly recommended against (for people who are choosing a license to release new software under). [considered]: <https://www.gnu.org/licenses/license-list.html#OriginalBSD> > > > On Fri, Jul 10, 2020 at 03:53:48PM -0400, Nicholas D Steeves wrote: > >>... > >> At the very least, it appears that the advertising clauses make > >> dprof2calltree not DFSG-free, > > > > It does not: > > https://www.debian.org/legal/licenses/ > > > >> because they fail the "desert island test". > >>... > > > > It does not. > > > > If you choose to advertise the use of this software on your desert > > island, you have to include the acknowledgement in your advertisement. > > > > It fails the "desert island test" because > > 1. Any mention of the features or use of this software requires > user-facing display of the text "This product includes software > developed by OmniTI Computer Consulting". This needs to be done, in order to comply with the license. And it is the OAC (Obnoxious Advertising Clause), the actual reason why the 4-clause BSD license is GPL-incompatible. [OAC]: <https://www.gnu.org/licenses/bsd.html> > > 2. OmniTI Computer Consulting's name cannot be used to "without specific > prior written permission" It can be used in the limited text "This product includes software developed by OmniTI Computer Consulting", since the OAC mandates the display of this acknowledgment. You have specific prior written permission to display that acknowledgment: you have this permission in the very license text. Actually you have an obligation to do so. Without additional specific written permission, you cannot use the company name in other ways, to endorse or promote derived products. At least, this is the (not self-contradictory) interpretation that I believe it has always been intended for the 4-clause BSD license... > > The desert island does not have the paper snailmail service required to > fulfil #2 (4th clause of the license). I think the 4-clause BSD license does *not* fail the desert island test. However, it is clear that the 4-clause BSD license is GPL-incompatible. It would therefore be safer to not include 4-clause BSD licensed material in a package where other parts (or libraries) are under the GNU GPL. Even though, one might argue that the converter is just bundled with the rest, without having any derivation or linking relationship with GPL-licensed material... What I would recommend in this case is one of the following actions (in descending order of preference): • try and get in touch with OmniTI Computer Consulting and persuade them to re-license the dprof2calltree converter under the terms of the 3-clause BSD license (which does not include the deprecated OAC and is indeed GPL-compatible), but persuade them on the ground of GPL-incompatibility, deprecation, and practical issues of the OAC (not on the ground of a DFSG-freeness issue, since there is no such issue!) • try and find a GPL-compatible replacement for dprof2calltree • drop dprof2calltree from package kcachegrind, while waiting for a better resolution for the issue I hope this helps. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpjXSUSBEcEQ.pgp Description: PGP signature
Re: Maxmind GeoIP/Geolite license change
On Mon, 15 Jun 2020 21:24:45 +0200 Roberto wrote: > On Mon, Jun 15, 2020 at 08:04:47PM +0200, Francesco Poli wrote: > > The reason is that the one-way compatibility mechanism of CC-by-sa v4.0 > > is not exceptionally clear, and, without that compatibility, the > > CC-by-sa v4.0 license itself has a number of controversial clauses > > (non-free, in my own personal opinion). > > CC-BY 4.0 (without SA) may be better than CC-BY-SA in that case, > according to the FSF it's compatible and accepted as a free license (for > content which is not a program). Actually, although the FSF [claims] that CC-by v4.0 is compatible with the GNU GPL, it does not explain how the restrictions found in CC-by v4.0 can be reconciled with the GNU GPL. [claims]: <https://www.gnu.org/licenses/license-list.html#ccby> I asked the FSF to publish a reasoned analysis on this. I did so back in 2015, but nothing has been disclosed yet (as far as I know). :-( I am personally *not* convinced that CC-by v4.0 is GPL-compatible. Please note that the CC-by v4.0 has no explicit compatibility clause (contrary to CC-by-sa v4.0, which has a one-way compatibility mechanism)... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp5p5qo30MmG.pgp Description: PGP signature
Re: Maxmind GeoIP/Geolite license change
On Mon, 15 Jun 2020 11:12:29 +0100 Michael Tremer wrote: [...] > The library is licensed under LGPL GNU LGPL v2.1 it seems. Good, thanks for releasing the library as Free Software. > and the database is under the Creative Commons license. CC-by-sa v4.0 it seems. Less good, in my own personal opinion. Although Debian FTP masters consider CC-by-sa v4.0 acceptable for the main archive, and although CC-by-sa v4.0 is one-way compatible with the GNU GPL v3 , I personally consider Creative Commons licenses problematic. The reason is that the one-way compatibility mechanism of CC-by-sa v4.0 is not exceptionally clear, and, without that compatibility, the CC-by-sa v4.0 license itself has a number of controversial clauses (non-free, in my own personal opinion). I would recommend choosing a different license for the database. The GNU [GPL v2], if you want a copyleft license, or the [Expat], if you prefer a more permissive license. [GPL v2]: <https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt> [Expat]: <http://www.jclark.com/xml/copying.txt> That's my personal advice. I hope it helps. Bye and thanks for working on this project! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpHRKR3OYQGp.pgp Description: PGP signature
Re: Classification of the APSL as non-DFSG-compliant
On Mon, 20 Apr 2020 13:39:19 +0200 Tobias Frost wrote: > On Mon, Apr 20, 2020 at 01:14:15PM +0200, John Paul Adrian Glaubitz wrote: [...] > > I don't see any difference from a distribution point of view. Apple's APSL > > is even less restrictive than the GPL-2 here as it does not require you > > to share your modifications among your friends or for R The GPL-2 > > requires that, the APSL not. > > That is not the point. Excess distribution is the problem. I have to offer the > code to people I have not interacted with. > (And the license does not say anything about friends, just about RD > departements) Exactly. Dear John, as has already been told you by Tobias and Mihai, the key difference between the GNU GPL v2 and the APSL v1.2 (here) is that the GPL only requires to make source code available to recipients of object code, while the APSL requires to make source code *publicly* available, if you just send modified object code of one friend (which is a third party) or even if you just use modified object code internally within your business or organization (for anything that is not R or personal use). Moreover, the APSL always requires you to continue making source code *publicly* available for at least 12 months, while the written offer is only *one* of the options to comply with the GPL: the other option is offering source code along with object code and never having to worry again about the thing. > > > Furthermore, the question that is relevant for the dissident test - that > > was used as argument for calling the license non-free - is whether sharing > > your modifications with your friends would require you to make these > > modifications public. And that is clearly not the case. > > As said, IMHO, distributing to the friend of a dissident is considered as > Deployment. I agree with Tobias here. Quoting the [APSL v1.2]: [...] | 1.4 "Deploy" means [...] | as well as [...] | distribution of Covered Code by You to any third party in any form | or manner. [...] [APSL v1.2]: <https://opensource.apple.com/source/hfs/hfs-522.0.9/APPLE_LICENSE> [...] > But maybe Apple is willing to relicnese it to Apache 2.0, then it would be > worth a try. (ASFAIK they did so with some projets having this license) This would be a good outcome. I really hope Apple may be persuaded to re-license hfsprogs under the terms of the [Apache License v2.0]. [Apache License v2.0]: <https://www.apache.org/licenses/LICENSE-2.0.txt> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpC7X7OjePRN.pgp Description: PGP signature
Re: FreeMedForms projet
On Fri, 10 Jan 2020 04:18:26 + Paul Wise wrote: > On Fri, Jan 10, 2020 at 2:02 AM Paul Wise wrote: > > > I don't like this, people seeking source code should not have to get > > approval first. That said, I note that the source code is available > > directly from the site without approval. > > I missed seeing that the git repository containing the source is > private. I don't like that, development versions and the development > process should be public and allow external people to participate. For what it's worth, I personally pretty much agree with all the comments made by Paul in the previous two messages... Thanks to Paul for expressing all the concerns and dislikes so clearly and thoroughly. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPXIcMmyi8F.pgp Description: PGP signature
Re: Packaging text licenses
On Sun, 15 Dec 2019 14:25:47 +0100 Jonas Smedegaard wrote: [...] > As others in this thread have pointed out, Debian explicitly omits > classifying license fulltexts as "free software" or "non-free software". Frankly speaking, I cannot find a message in this thread where others pointed out that license texts are not software. But anyway... > > As I understand it, you personally classify license fulltexts as > "non-free software" and then add a rule that they are exceptionally > accepted in main under specific narrow circumstances. > > If you agree with above, Francesco, then I suggest going forward that we > talk about the "license fulltexts are non-free software but accepted > narrowly in main" as being a _proposal_ rather than current rules in > Debian. Actually, I have always thought this as the accepted Debian practice, not as a proposal of mine! The already cited [message by Glenn Maynard] shows that other people viewed it that way back in 2005. [message by Glenn Maynard]: <https://lists.debian.org/debian-legal/2005/06/msg00299.html> I am quite convinced that the same idea has been expressed on debian-legal more than once, since 2004 (the time when I became an active participant). It's just not easy to search for the evidence, since searching for keywords such as "license" and "exception" on the debian-legal archive results in an overwhelming number of false positives (where the topic under discussion was the GNU GPL and appropriate linking exceptions, e.g. to allow linking a GPL-licensed work with the OpenSSL library!). > > Perhaps that shift might also help you being less perplexed? :-) No, I am even more perplexed, after reading your reply... :-/ -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpM5_ztxgwnF.pgp Description: PGP signature
Re: Packaging text licenses
On Sat, 14 Dec 2019 17:41:14 +0100 Jonas Smedegaard wrote: > Quoting Francesco Poli (2019-12-14 17:22:09) [...] > > I don't think the exception may also apply when the license text is > > the *actual payload* of the package (for instance, a package shipping > > the text for CC-by-nc-nd-v1.0, when nothing in the package itself is > > released under that license). [...] > > That's an interesting view. > > Several packages now in Debian main contain license fulltexts without > those licensing terms being applied at all to the project covered by > that package. > > Examples: > > * licensecheck - includes license fulltexts in its testsuite I am perplexed: I fully understand the usefulness of packages such as licensecheck, decopy, and so forth, and I acknowledge the need for actual data in their test suites... But on the other hand, can non-free data be shipped in the test suite of a source package in Debian main? For many kinds of package, DFSG-free data may be specifically prepared for the test suite. But can DFSG-free data be prepared for the test suite of a program intended to identify licenses?!? How can I test whether the program is able to identify CC-by-nc-nd-v1.0 *without* feeding it the actual text of that same license?!? This looks like a really hard problem. > * libsoftware-license-perl - purpose of project is to emit licenses This seems to be even more troublesome: here the license texts are not just shipped in the source package as test suite data. They are included in the package as "functional" data, without which the package cannot accomplish its goal. Yet, a number of those license texts are non-free texts... I understand the convenience of this library, but is it really DFSG-free?!? > > I have several times discovered projects shipping with e.g. GPL-3 but > nothing in the project was licensed under that license. I find it > highly likely that there are plenty of such cases still in Debian - > including ones where the "stray" license contain a non-modification > clause (which I guess is the most likely non-Freeness in license > fulltexts. These cases really look like bugs to be fixed. If nothing in the project is licensed under the terms of the GNU GPL v3, then why does the project include the text of that license at all?!? > > Are all such packages in violation of DFSG? That's a hard question. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpdnQnnf192R.pgp Description: PGP signature
Re: Packaging text licenses
On Sat, 14 Dec 2019 14:01:18 +0100 Baptiste BEAUPLAT wrote: > On 12/14/19 1:03 PM, Jonas Smedegaard wrote: > > A rich collection of Free license fulltexts is relevant, not only for > > our users to pick from (even on a lonely island) and copy into new > > development project, but also as reference e.g. for testing license > > checkers. > > > > What is _not_ helpful in my opinion, however, is yet another manually > > curated selection of random license texts. What I see generally useful > > is to package this: https://github.com/spdx/license-list-XML > > That looks like a great list to package. I'll need input on the > repository license status from the legal team as it could be ambiguous I would be extremely cautious before including license texts as content to be shipped by a Debian package. A number of license texts are not themselves licensed under DFSG-free terms. And Debian promises to remain 100 % free, see [SC] #1. Any content of a Debian package (in main) must be free according to the DFSG. [SC]: <https://www.debian.org/social_contract> License texts are usually [considered] the sole exception, but I think the exception only applies when the license text is included in the package *for the sole purpose* of documenting the legal terms under which some part of the package is released. I don't think the exception may also apply when the license text is the *actual payload* of the package (for instance, a package shipping the text for CC-by-nc-nd-v1.0, when nothing in the package itself is released under that license). [considered]: <https://lists.debian.org/debian-legal/2005/06/msg00299.html> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp450RHm8WTt.pgp Description: PGP signature
Re: GPL2 + required to have the place to get the recent version
On Wed, 13 Nov 2019 08:00:04 -0500 Daniel Hakimi wrote: > But even the AGPL does not restrict *use*. [...] I personally think the GNU AfferoGPL v3 *does* restrict use. That's one of the main [reasons] why I think the AfferoGPL does *not* meet the DFSG. The Debian FTP Masters don't agree with me, unfortunately, but I still believe AfferoGPL-licensed works should not have entered (or continue entering) Debian main... [reasons]: <https://lists.debian.org/debian-legal/2007/11/msg00233.html> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpsxIsCfdqz2.pgp Description: PGP signature
Re: upstream changing from GPL-2+ to GPL-3+ without copyright holders permission
On Mon, 5 Aug 2019 09:38:08 -0300 Eriberto Mota wrote: > Hi folks, Hello! > > I have a basic doubt. > > A program called "test" was released by Bob over GPL-2+. This program > got contributions from Ana and Chloe. The development was stopped some > years later and, now, Ted want continue this development. However, Ted > kept the name "test" and changed the licensing to GPL-3+ without a > permission from previous copyright holders, that are inactive. Is > possible do it, only considering the plus signal in previous licensing > (GPL-2+)? As far I can tell, Ted can redistribute the program called "test" under the terms of the GNU GPL v3 or later, since he has permission to redistribute it under the terms of the GNU GPL v2 or later (and, in terms of options, GPL-3+ is a subset of GPL-2+). This means that Ted can choose to comply with the terms of the GPL v3 and he will be fine with respect to his obligations on Bob's, Ana's and Chloe's copyrighted material. Ted cannot change the fact that Bob's, Ana's and Chloe's copyrighted parts of "test" are available under GPL-2+, but Ted can do the following, if he so wishes: by continuing "test" development, Ted can release his own contributions under GPL-3+. In the newly released "test" versions, Bob's, Ana's and Chloe's contributions will be under GPL-2+, while Ted's contributions will be under GPL-3+. The net result will be that the new "test" versions will be effectively under GPL-3+ as a whole (although some parts of them will stay under GPL-2+ and will thus be redistributable under GPL-2+, assuming they may still be identified and extracted from "test"). I hope this clarifies. Obviously, what I said is my own personal understanding of the issue. I am not speaking on behalf of the Debian Project, I am not a lawyer, this is not legal advice, and so forth... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpsXlQ8I154D.pgp Description: PGP signature
Re: [License] Gsas-II
On Thu, 11 Jul 2019 22:24:33 +0200 Francesco Poli wrote: [...] > I think the debian/copyright file of the ocaml Debian package is no > longer accurate and should be reviewed and updated. > Any volunteers to file a bug report on the Debian BTS? No need to file a bug report, it seems that there already is an upload to experimental (currently in the NEW queue), with an [updated] debian/copyright file. [updated]: <https://salsa.debian.org/ocaml-team/ocaml/commit/b3cd670da16077914a0b2611407ce6b6def67b00> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpMsjNBrkhm7.pgp Description: PGP signature
Re: [License] Gsas-II
On Thu, 11 Jul 2019 07:16:42 + Landry, Walter wrote: > Ben Finney writes: > >> * 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. > > It is icky. However, Ocaml, which is in main, has a clause (3b) with a > similar effect: > > > https://metadata.ftp-master.debian.org/changelogs//main/o/ocaml/ocaml_4.01.0-5_copyright Are you referring to the following QPL clause? [...] | [3.] b. When modifications to the Software are released under this | license, a non-exclusive royalty-free right is granted to the | initial developer of the Software to distribute your | modification in future versions of the Software provided such | versions remain available under these terms in addition to any | other license(s) of the initial developer. [...] I think this clause is not so similar to the one under examination here. First of all, it does not state that you grant an "unrestricted" permission. Secondly, the right is granted "provided such versions remain available under these terms", although it also says "in addition to any other license(s) of the initial developer", unfortunately. Anyway, the [QPL] is deemed [non-free], or, at least, [controversial]. At least one package was [moved] to non-free, because of the non-freeness of the QPL. [QPL]: <https://lists.debian.org/debian-legal/2004/07/msg00157.html> [non-free]: <https://lists.debian.org/debian-legal/2004/07/msg00339.html> [controversial]: <https://wiki.debian.org/DFSGLicenses#Q_Public_License_.28QPL.29.2C_Version_1.0> [moved]: <https://bugs.debian.org/251983> Sure, ocaml is in main, but it seems to no longer be released under the terms of the QPL. It [seems] to be under the GNU LGPL v2.1 now. [seems]: <https://github.com/ocaml/ocaml/blob/74e1a85b729c81e0c3ad438acb03fafa59978886/LICENSE> I think the debian/copyright file of the ocaml Debian package is no longer accurate and should be reviewed and updated. Any volunteers to file a bug report on the Debian BTS? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpeGMu_ly6Gv.pgp Description: PGP signature
Re: [License] Gsas-II
On Wed, 10 Jul 2019 08:18:58 + MARIE Alexandre wrote: > Hello, Hello Alexandre, thanks for caring about software freedom. > > I would like to know if the license of Gsas-II is free to use. I assume you are asking whether software solely licensed under the quoted terms may comply with the DFSG. > Here is the license : > __ > General Structure Analysis System - II (GSAS-II) > OPEN SOURCE LICENSE This looks like a license specifically designed for one single software package. Not a good start. Personally, I would recommend the copyright holders to switch to a well known and well vetted license suitable for releasing Free Software (such as the GNU GPL, for instance). [...] > * 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 does not seem to meet the DFSG. I think it fails to meet DFSG#3, because, if I choose to distribute a derived work to the original sofware copyright holder, I cannot do so "under the same terms as the license of the original software": I am forced to grant them unlimited rights over my modifications, which is a much more permissive "license" than the terms of the license of the original software. > * Redistributions that include binary forms must include all relevant > source code [...] This looks non-free: it completely forbids binary distribution, even when source is made available. It only allows the distribution of a binary+source bundle. This clause would even be violated by the Debian mirror infrastructure (should GSAS-II be included in Debian), unless the source were bundled inside the binary .deb packages (which is not the usual way software is packaged for Debian...)! [...] > Thanks in advance for your help. You're welcome. P.S.: Please note that what I expressed are my own personal opinions and not an official statement from the Debian Project. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpgJLuyD4l6i.pgp Description: PGP signature
Re: Missing source in firefox-esr: EME module
On Thu, 4 Jul 2019 13:13:26 +0800 Paul Wise wrote: > On Wed, Jul 3, 2019 at 9:38 AM Mihai Moldovan wrote: > > > I wonder why no one brought it up yet, but here we go: IMHO, > > downloading pre-defined proprietary software should completely > > be disabled/removed in Firefox and the proprietary Widevine module > > be properly packaged as a package in non-free - with at most a > > Suggests dependency in the firefox(-esr) package. The nag bar might > > tell people to install this additional package. > > The Widevine license does not allow redistribution. [...] Good point. Then, the strategy could be similar to [flashplugin-nonfree]: a package (in Debian contrib) that automatically downloads and install the non-free module from the upstream distributor, and installs it... [flashplugin-nonfree]: <https://packages.debian.org/sid/flashplugin-nonfree> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpFqoDSDMv9i.pgp Description: PGP signature
Re: Missing source in firefox-esr: EME module
On Wed, 03 Jul 2019 03:28:18 +0200 Mihai Moldovan wrote: [...] > IMHO, downloading pre-defined proprietary software should completely > be disabled/removed in Firefox and the proprietary Widevine module be > properly packaged as a package in non-free - with at most a Suggests > dependency in the firefox(-esr) package. The nag bar might tell people > to install this additional package. [...] For what is worth, I personally agree. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpkkGIiuJ1Tj.pgp Description: PGP signature
Re: Report Copy of Debian Logo
On Tue, 23 Apr 2019 11:43:16 +1000 Ryan Hemsley wrote: > Hello Sir / Madam, > > I'm here to inform you a Community based on a game FiveM which is based on > GTA 5 is using your Logo as we speak under their own name. [...] I am not sure about the details of the case at hand, but you may want to read the Debian [trademark page] and, possibly, get in touch with ... [trademark page]: <https://www.debian.org/trademark> Thanks. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpd_kcJSiNeY.pgp Description: PGP signature
Re: Free Software Guidelines Question
On Thu, 4 Apr 2019 01:59:31 -0400 Wade Pinkston wrote: > Hello, and thank you for taking the time to read this (and hopefully > respond:) Hello Wade! > > My company manufactures high-end IR sensors, IR Quadrant detectors, IR > PSDs, and associated electronics. I have recently been getting more and > more requests to release a Debian package to help our customers interface > with our hardware in the Debian environment. That's interesting and good to hear: I hope you are going to satisfy the needs of your customers in the best possible way. [...] > We have no issue with offering a free software > package usable in Debian, and would very much like to make it available. This looks like great news. > The issue is our commercial competition. [...] > > So my question is this- Is there a way to release a free software package > for Debian, but maintain IP rights to it?, or at least make the code > unavailable. If so , what is the best way to do this? What you are asking for seems to be inconsistent with the very concept of free software. In a nutshell, free software has to be distributed while making source code available, and legal permissions to use/study/adapt/copy/distribute/modify the code have to be granted. Otherwise, it's *not* free software. You can find many explanations of what free software is. One such explanation was written by me: you can read the whole [essay], if you are interested. [essay]: <https://www.inventati.org/frx/essays/softfrdm/whatisfree.html> Please note that releasing free software does *not* correspond to lose the copyright on it. The copyright owner *can* release free software, while keeping his/her/its copyright on it (on the part he/she/it developed): it's just that others will get permission to do a number of things with the software. If you are worried about the competitors, one possible strategy is to compete by being the free-software-friendliest vendor in your market. If you hardware works perfectly with free firmware and free software (and does not require any proprietary firmware or software), if the end user just has to install a package from the official Debian repositories and is ready to go, then your hardware will be the most convenient for your potential customers, who will prefer your hardware over the competitors' products. Your competitors will have the possibility to follow behind and make compatible products, if they want to, but you'll have the possibility to better support your customers (by being the first to innovate on new hardware products, which will be well supported by free software from day 1, by being the most knowledgeable about the free software you develop, so that your customers will be better supported than those who buy from your competitors, and so forth...). I hope this reasoning makes sense to you and you end up deciding that releasing free software is the best way to go. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp_xXSbzSKsy.pgp Description: PGP signature
Re: Bug#903092: [RSVP] php-elisp: permission to relicense contributions required from past contributors
On Fri, 1 Feb 2019 16:46:07 -0700 Nicholas D Steeves wrote: > Dear Ola, Pontus, and Debian Legal team, Hello! > > It seems Thierry is MIA, and will not be confirming permission to > relicense his contributions to d/changelog and d/control. Please let > me know if the following blocks moving to GPL-3+ debian/* and a > machine-readable format: 1.0 debian/copyright. At this point I > suspect it does, but I am erring on the side of caution. Do I understand correctly that the content of php-elisp/debian/* is currently licensed under the terms of the GNU GPL v2 or later? If this is the case, since GPL-3+ is compatible with GPL-2+, what's wrong in keeping Thierry's contributions under GPL-2+, while the remainder of debian/* is migrated to GPL-3+ ? The effective resulting licensing status for debian/* would still be GPL-3+, although the debian/copyright file would be slightly less simple, but, oh well, I guess you could live with that... Or am I missing anything important? I hope this helps. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpLphtpm25Pg.pgp Description: PGP signature
Re: Geeqie embedding ZoneDetect timezone data
On Tue, 29 Jan 2019 14:55:03 +0100 Andreas Ronnquist wrote: > > > A package I am maintaining (Geeqie) Hello Andreas! First off, thanks for maintaining one of my favorite image viewers in Debian! > is looking to use ZoneDetect > timezone data, and geeqie upstream has actually embedded that data in > their upstream git repo. See [1] for that commit. > > I have searched Debian mailinglists, and to me it looks like this is > ok, the ZoneDetect data is licensed under ODbL 1.0, [...] > > Since I'm a bit of a noob when it comes to this, I ask here - Does this > look alright? [...] Personally, I don't think the ODbl v1.0 meets the DFSG. See [my analysis] and a [reply] by MJ Ray. [my analysis]: <https://lists.debian.org/debian-legal/2010/08/msg00015.html> [reply]: <https://lists.debian.org/debian-legal/2010/08/msg00022.html> Please note that this is just my own personal opinion. As you probably know well, the actual decision makers for the acceptability of a package in Debian are the FTP Masters, who may disagree with my analysis... I hope this helps. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpItysz6amK_.pgp Description: PGP signature
Re: Compatibility of GPLv2 and Apache v2 (OpenSSL again)
On Fri, 07 Dec 2018 17:04:22 +1100 Ben Finney wrote: > Sebastian Andrzej Siewior writes: [...] > > 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 :-) This has already been mentioned in the past: https://lists.debian.org/debian-legal/2015/09/msg1.html It was a long ongoing process. The news is that it seems to have finally come to an end... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpmikV_SmTgM.pgp Description: PGP signature
Re: Hacking License
On Sat, 1 Dec 2018 04:28:58 +0100 Giacomo Tesio wrote:
> Hi, I'm going to distribute a C library I wrote from scratch and with
> no dependencies (except for some POSIX system calls) under a new
> strong copyleft, the Hacking License.
Hello,
thanks for writing a new library and for willing to distribute it
as free software.
As far as the licensing choice is concerned, please try hard and avoid
writing your own custom license.
A newly written license, especially a strong copyleft one, adds to the
already rampant license proliferation craziness (which is bad in
itself) and is incompatible with many other licenses (thus causing more
headaches to everyone in the community).
Please do really consider adopting the GNU GPL v2, if you want a strong
copyleft license.
> AFAIK, it conforms to the DFGL and pass the three corner-case tests,
> but I'd like to know your legal opinions and criticisms, as I'm going
> to package such library for Debian too.
I don't think that software released under the "Hacking License"
complies with the Debian Free Software Guidelines (DFSG).
What follows is a list of comments and thoughts about the license text.
I am a bit in a rush, hence I may have missed some issues.
This is not a thorough analysis (and I am not a lawyer, I do not speak
on behalf of the Debian Project, I am just a Debian external
contributor).
[...]
> Hacking License
> ===
[...]
>
> 1. Definitions
> --
[...]
Some definitions are really awkward and counter-intuitive.
They may have unintended consequences on the rest of the license...
[...]
> 2. Grants
> -
>
> Permission is hereby granted to any User of the Hack to study, copy,
> use, wrap, modify and/or distribute the Hack, and to distribute any
> Derived Work under this License but with a different name and logo.
The requirement to change the name is permitted by DFSG#4, but is
discouraged.
The requirement to change logo is not as clearly permitted.
>
> Furthermore, if the Hack is a Derived Work, the Hackers grant to the
> copyright holders of the Inspiring Hack all rights, title and interests
> in any copyright the Hackers have in the Hack.
This seems to effectively transfer the rights in the Derived Work to
the copyright holders of the original work ("Inspiring Hack"),
As a consequence, the copyright holders of the original work get many
more rights on the Derived Work than anyone else.
I don't think this clause complies with the DFSG.
I would say it fails DFSG#3, since I cannot distribute a derived work
to the author of the original work under the same terms as the license
of the original work, since I am forced to grant more rights.
[...]
> 3. Conditions
> -
>
> The grants provided by this License are subject to the following conditions:
[...]
> 2. The source of the Hack shall be made available with the Hack and/or
>by other reasonable means to every User, according to this License
>and without additional constraints or requirements, such as further
>agreements, any royalty or other fee.
This seems to allow binary package distributions (as done by the Debian
mirror network) just because of the "or by other reasonable means"
phrase. I hope it can be considered enough, but I am not sure it would
hold water in a court of law...
[...]
> 4. The tools, dependencies and know-how required to perform any of the
>activities permitted by this License shall be made available to the
>User with the source of the Hack (except for those tools and
>dependencies that are already available to every User either free of
>charge or in off-the-shelf distributions of the Runtime) and without
>additional constraints or requirements, such as further agreements, any
>royalty or other fee.
This seems to be troublesome, although well-meaning.
If for instance the work is written in the Ruby programming language,
the clause could be interpreted as requiring to make a full programming
course about the Ruby language available.
[...]
> 6. No patent infringement litigation claim (excluding counterclaims and
>cross-claims) alleging that all or part of the Hack directly or
>indirectly infringes a patent shall be initialized by the User.
This is controversial and has been discussed several times on
debian-legal, with different opinions expressed by many people.
It _may_ comply with the DFSG, but I am not sure.
> 7. The User has never violated any of the previous conditions.
[...]
This lacks a forgiving provision.
I mean: it seems that a User who has done wrong once, can never be
forgiven and will never again be granted any rights by this license
(maybe even for *any* work under the Hacking License, not only for the
work the violation was about...).
I don't think this is fair.
--
http://www.inventati.org/frx/
There's not a second to
Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
On Tue, 16 Oct 2018 22:43:09 +0200 Florian Weimer wrote: > * Paul Wise: > > > For your convenience, I have included a full copy of the mail below, > > which includes a justification section as well as full license terms. > > The license appears to be an unlicensed derivative work of the GPLv3, > which is not itself licensed under a permissive license. I'm not sure > if we can distribute the license text. If not, we can't distribute > the software itself, either. I think that this derivative work is permitted, since the [conditions] established by the FSF seem to be satisfied. [conditions]: <https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL> > > There is no definition what the triggering “services” actually are. > If it is sufficient to offer precompiled binaries for download, then > this license could contaminate the mirror network. This is possibly true and could by itself ban any SSPL-licensed work from the Debian archive... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpyV2kk3O4IK.pgp Description: PGP signature
Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
On Tue, 16 Oct 2018 22:03:41 +0800 Paul Wise wrote: > Hi all, Hello Paul! > > I noticed MongoDB are pushing a new license that tries to be like the > AGPL but more expansive in what software it covers and more expansive > in what activities trigger the clauses within it. This does not sound good... > > They have posted to the OSI license review mailing list: > > http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html > > For your convenience, I have included a full copy of the mail below, > which includes a justification section as well as full license terms. [...] Thanks. Apart from the use of Unicode quotes (in stead of ASCII quotes), and from the drop of the preamble and instructions for use, the SSPL v1 differs from the GNU GPL v3 only in the content of Section 13 (plus references to the license name and steward, of course). Sections 13 reads: > 13. Offering the Program as a Service. > > If you make the functionality of the Program or a modified version > available to third parties as a service, you must make the Service > Source Code available via network download to everyone at no charge, > under the terms of this License. Making the functionality of the > Program or modified version available to third parties as a service > includes, without limitation, enabling third parties to interact with > the functionality of the Program or modified version remotely through > a computer network, offering a service the value of which entirely or > primarily derives from the value of the Program or modified version, > or offering a service that accomplishes for users the primary purpose > of the Software or modified version. > > “Service Source Code” means the Corresponding Source for the Program > or the modified version, and the Corresponding Source for all programs > that you use to make the Program or modified version available as a > service, including, without limitation, management software, user > interfaces, application program interfaces, automation software, > monitoring software, backup software, storage software and hosting > software, all such that a user could run an instance of the service > using the Service Source Code you make available. My personal [opinion] on the GNU AfferoGPL v3 is already known here on debian-legal: I think it is a troublesome license that fails to meet the DFSG. Debian [FTP Masters think] it is OK, but [I disagree] with their conclusion. [Other] [people] share some of my concerns. [opinion]: <https://lists.debian.org/debian-legal/2007/11/msg00233.html> [FTP Masters think]: <https://bugs.debian.org/495721#17> [I disagree]: <https://bugs.debian.org/495721#28> [Other]: <http://raw-output.org/20071120/agpl> [people]: <http://mjr.towers.org.uk/blog/2008/webapps#memberships> As far as the SSPL v1 is concerned, I personally think that it is even worse than the GNU AfferoGPL v3. The SSPL v1 includes an even stronger use restriction, extended to the unmodified work too, and reaching unrelated software (backup software??? hosting software??? what does this mean, anyway?). It fails to clarify the ambiguity of the term "user": if I get an "access denied" error page through a browser, am I a user of the web application? of the database server? ... I think the SSPL v1 fails to meet the DFSG. I hope MongoDB, Inc. will change its mind and stop going down this slippery slope called "Let's restrict it a little bit more!". A slippery slope started by the FSF with the GPLv3 → AfferoGPLv3 progression... I wish MongoDB could be re-licensed under the plain GNU GPL... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpI3ikvwfspF.pgp Description: PGP signature
Re: legal implications of linking to libssl/openssl
On Sun, 06 May 2018 04:08:26 + Sandro Tosi wrote: > > The situation is currently unchanged, the OpenSSL license is > > incompatible with the GNU GPL family of licenses and an exception is > > needed to allow combining code under those licenses and OpenSSL in the > > same work. > > > https://people.gnome.org/~markmc/openssl-and-the-gpl.html > > thanks Paul, i'll talk with upstream about adding such an exception to > transmission. I would like to add that an exception will also be needed for other GPL-licensed libraries (directly or indirectly) linked with transmission, if any... Moreover, I see that libssl1.1 is already among the dependencies of transmission: is the program already linked with OpenSSL, without a proper licensing exception? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPquf6iKaXQ.pgp Description: PGP signature
Re: systemd-resolved violates The Debian Free Software Guidelines
On Mon, 30 Apr 2018 04:28:07 +0200 Martin Hanson wrote: > I have posted this bug report > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896806 > that has been rejected by the maintainer. [...] While I see a possible privacy issue in using the Google public DNS servers, I am under the impression that doing so does not require to accept any Terms of Service. At least, I failed to spot any hint about that in the [instructions page](https://developers.google.com/speed/public-dns/docs/using) So, as others have already pointed out, this does not seem to be a DFSG issue. Nonetheless, I would be much happier, if packages in Debian did not rely on Google (or any other private company's) services as default, since I think this is not a recommendable strategy. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpmOecBQBqD7.pgp Description: PGP signature
Re: License of the GPL license
On Mon, 16 Apr 2018 12:13:29 +0100 Simon McVittie wrote: > On Mon, 16 Apr 2018 at 10:50:04 +0200, Giovanni Mascellani wrote: > > this question might be trivial, but I just realized that the GPL license > > is itself licensed under a license that technically does not appear to > > be DFSG compliant: > > We make an exception for the licenses of licenses, because otherwise we > basically wouldn't be able to distribute any software at all (and it > isn't completely clear whether legal texts are copyrightable anyway). I remember that this has been discussed in the past, although I cannot find the mailing list thread(s) right now. Anyway, I recall that the outcome of the discussion was the one described by Simon. Moreover, as far as the GNU GPL is specifically concerned, there is an [FSF FAQ](https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL) explaining that the text of the GNU GPL can indeed be modified, as long as some conditions are satisfied... I hope this helps. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp30uFqB3vWK.pgp Description: PGP signature
Re: JPL Planetary Ephemeris DE405
On Mon, 19 Mar 2018 09:05:51 +0100 Ole Streicher wrote: [...] > Francesco Poli <invernom...@paranoici.org> writes: [...] > > I think that a work that includes data (such as the electric charge of > > an electron) *can* be in source form, without the need to ship all the > > raw measurements that brought us to the determination of good values for > > these data, or to build-depend on the whole analysis process that > > brought us to that same determination. > > > > What's good about the definition of source is that it is flexible > > enough to cope with many corner cases. > > I see this differently: The term "source" is misleading when applied to > research data. I don't think we need to define new guidelines for assessing the freeness of scientific data. The DFSG and the definition of source may be applied to scientific data as well. This is possible because of the flexibility of the definition of source, as I said. Moreover, there is no clear-cut line between scientific data and works of authorship. The boundary is blurred, as your example about astrophotography shows... Hence, we cannot apply different "rules", depending on this blurred distinction. [...] > In science, this is however differently: The (primary) creative work > here are the research articles, and there is a whole culture around how > to value them and how to ensure freedom of science. Much older, > independently and differently from DFSG: Research articles are usually > not free [...] The fact that many technical-scientific research articles are not DFSG-free is an issue in itself, in my opinion. But this is another (long) story... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPUKGC2nO9D.pgp Description: PGP signature
Re: Updating CIDER's Research Software Agreement License For Use in Ngspice
On Sun, 18 Mar 2018 15:01:28 +0100 Holger Vogt wrote:
> >
> > Have the other issues been addressed, as well?
> > Please see my previous
> > [message](https://lists.debian.org/debian-legal/2016/10/msg00030.html)
> > for further details...
> >
>
> Yes, I am working on these items.
That's great, thanks for doing so!
>
> > the NOOVELA license (non-commercial use only, lack of permission to
> > copy, distribute and modify)
>
> Code has been rewritten and re-licensed, is now GPL
Good.
>
>
> > no license ("No license found, only copyright")
> Has been clarified, a question is still:
> 2 contributions are under 'Educational Community License 1.0' and '2.0'
> https://opensource.org/licenses/ECL-2.0
> https://opensource.org/licenses/ecl1.php
>
> Are these compatible to DFSG? I did not find them in any compatibility list.
The ECL v1.0 was discussed a long time ago in a debian-legal
[thread](https://lists.debian.org/debian-legal/2011/08/msg00014.html).
My own contribution to the thread is this
[analysis](https://lists.debian.org/debian-legal/2011/08/msg00017.html).
On the other hand, I haven't found any debian-legal discussion about
the ECL v2.0.
FWIW, the FSF
[states](https://www.gnu.org/licenses/license-list.html#ECL2.0)
that it
[...]
| is a free software license, and it is compatible with GPLv3. It is
| based on the Apache License 2.0; the scope of the patent license has
| changed so that when an organization's employee works on a project,
| the organization does not have to license all of its patents to
| recipients.
| This patent license and the indemnification clause in section 9 make
| this license incompatible with GPLv2.
[...]
I haven't found the time to analyze the ECL v2.0 and compare it with
the Apache License v2.0, though.
Maybe this can be done on debian-legal...
>
>
> > the SPICEDOC license (educational, research and non-profit purposes
> > only)
> Text is outdated, will be removed
OK.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
. Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpJRCMTN6QhC.pgp
Description: PGP signature
Re: JPL Planetary Ephemeris DE405
On Sat, 17 Mar 2018 18:54:43 +0100 Ole Streicher wrote: > Francesco Poli <invernom...@paranoici.org> writes: [...] > > If one of them (or both) are not available in Debian main (under > > DFSG-free terms), then I think the "final data" cannot be in Debian > > main, either... > > This would however prevent us from having almost *any* scientific data > in Debian: Even a simple value as the charge of an electron is based on > some raw data and some processing, which is usually not delivered when > a program provides this number. > > And the processing tools themself again contain some "final data", which > again would require (to have them free in your terms) to deliver their > raw data, and their processing chain. Which again will have the same > problem. > > This finally would mean that you need (almost) the whole scientific > (physics) history and discussion as an automated processing chain in > Debian. If this is what you meant, then I must have misread your reasoning. I apologize. I think that a work that includes data (such as the electric charge of an electron) *can* be in source form, without the need to ship all the raw measurements that brought us to the determination of good values for these data, or to build-depend on the whole analysis process that brought us to that same determination. What's good about the definition of source is that it is flexible enough to cope with many corner cases. In the "scientific data" case, changing the raw measurements and/or the analysis process is probably more like taking a new digital photograph (perhaps with a different camera, or with different camera settings, or with a changed scene), than like modifying the digital photograph with some digital "special effect" or "enhancement". In other words, it is more like recreating the data from scratch, than like modifying the existing data. Hence, what we need is probably the freedom to modify the "final data", if we like to. And also the freedom to replace it with new "final data" (obtained the way we see fit, possibly with new or additional measurements and/or new processing). Source code for the "final data" may well be the "final data" themselves, as you said. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp2SwNdPADUJ.pgp Description: PGP signature
Re: JPL Planetary Ephemeris DE405
On Thu, 01 Mar 2018 20:36:48 +0100 Ole Streicher wrote: > Francesco Poli <invernom...@paranoici.org> writes: [...] > > I think this is much like digital photographs. > > A digital photograph represents a scene with objects and/or living > > beings. > > But you can modify it to create an image that no longer represents a > > real scene (think about special effects in movies). > > See the last FAQ in my above-mentioned essay... > > Citing from there: > | Depending on which format is extracted from the digital camera and on > | which form one starts with when making modifications, the source may > | be in raw format, JPEG, or some other form... > > This would be what I call "raw data", so the original measurements, > which were used for the several analysis steps that finally lead to the > ephemeris. > > Some use cases where one would like to change the ephemeris: > > - I have an improvement in one of the processing steps, and I want to >make use of it > > - I have additional data that I want to merge in an early step of the >processing chain > > I can't do this, since I don't have the software available that produced > the final data (even when the method is described in a paper). And I > also don't have the raw data available. If a significant set of possible and reasonable modifications preferably require these "raw data" and the "processing tools", then... it really seems that these "raw data" are the source and the "processing tools" are the build chain. If one of them (or both) are not available in Debian main (under DFSG-free terms), then I think the "final data" cannot be in Debian main, either... > > The idea that one could legally "just change some numbers" is not > realistic at all: the numbers in the ephemeris data depend on each > other, and changing them by hand will just make the data > inconsistent. [...] In order to enjoy full freedom, you should also have the legal permission to mess with the data and produce an inconsistent result. Free software is not (only) about reasonable modifications. Unreasonable ones should also be allowed. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgps0pfy3lZId.pgp Description: PGP signature
Re: Updating CIDER's Research Software Agreement License For Use in Ngspice
On Sat, 17 Mar 2018 11:37:30 +0100 Holger Vogt wrote: > UC Berkeley yesterday has agreed to put CIDER under BSD (see > https://embedded.eecs.berkeley.edu/pubs/downloads/cider/index.htm). > Taking into account > ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change CIDER is > now covered by the Modified BSD license. Wow, this looks like great news! Thanks to all the people involved in this liberation effort! :-) Have the other issues been addressed, as well? Please see my previous [message](https://lists.debian.org/debian-legal/2016/10/msg00030.html) for further details... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpTb9GI04lM4.pgp Description: PGP signature
Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?
On Fri, 2 Mar 2018 22:21:01 +0100 Alex Mestiashvili wrote: [...] > Thank you all for such a detailed answers! You're welcome! > > I found the following in the FAQ[0]: > > 3.2. Is InChI open? > > It is intended that the source code is freely re-usable and a license > has been developed to reflect that. Since the InChI source code has a > normative role (i.e. it acts as the final arbiter of the correctness) it > is not freely modifiable, although it is open to anybody to view and > build an InChI binary. The answer for this FAQ does not seem to be factually correct. The license we are talking about allows modifications (see its section 2) and also allows the licensee to apply the terms of the GNU GPL v2 or later (see section 3), which, in its turn, allows modifications... I am puzzled. > > To my limited understanding this render the software non-free as it > fails for example the desert island test, though it is understandable > why they require the code to be not-modifiable. > Or am I missing the point? A work which is not modifiable fails to meet DFSG#3 and is therefore utterly non-free. However, as I said, the license under consideration does not seem to forbid modifications, as far as I can see... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgplTScIm_0If.pgp Description: PGP signature
Re: JPL Planetary Ephemeris DE405
On Thu, 01 Mar 2018 11:29:03 +0100 Ole Streicher wrote: > Ben Finney <bign...@debian.org> writes: > >> 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. > > For (scientific) data, they can't: I respectfully disagree. > DFSG requires "source code". This is true, but... > To take > its definition in the Linux Information Project (just my laziness; taken > from Wikipedia): > > | Source code (...) is the version of software as it is originally > | written (i.e., typed into a computer) by a human in plain text (i.e., > | human readable alphanumeric characters). This is not a good definition of source code. I wrote an [essay](https://www.inventati.org/frx/essays/softfrdm/whatissource.html) on this topic. [...] > Is it the preferred form of the work for making modifications (GPL def)? > > Clearly not. The preferred form would be to repeat the observations. I don't agree: repeating the observations is the preferred *method* (not *form of the work*) for *re-creating* the work from scratch. On the other hand, *making modifications* to the work requires some form of the work itself. You have to imagine the desire to alter the data (even in ways that make the data no longer be an accurate scientific representation of a phenomenon) and ask yourself: which is the best form I would start from, in order to make modifications? I think this is much like digital photographs. A digital photograph represents a scene with objects and/or living beings. But you can modify it to create an image that no longer represents a real scene (think about special effects in movies). See the last FAQ in my above-mentioned essay... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgprbDDCRVzt9.pgp Description: PGP signature
Re: JPL Planetary Ephemeris DE405
On Tue, 27 Feb 2018 22:22:48 + jonathon wrote: > On 02/27/2018 09:54 PM, Ben Finney wrote: > > That conflict needs to be resolved, IMO. Do they intend to grant all the > > DFSG freedoms to the work's recipient, or not? > > My recommendation is to go back to NASA, asking if this will be > relicenced under NOSO 2.0 Where can I find the text of the NOSA v2.0 ? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPUu3ZG2XrE.pgp Description: PGP signature
Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?
On Tue, 27 Feb 2018 09:49:20 +1100 Ben Finney wrote: > Ben Finney <bign...@debian.org> writes: > > > To the extent that text is derived from the GNU LGPL, it is a copyright > > violation: [...] > 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). Hello Ben, I assume you have read my latest [reply](https://lists.debian.org/debian-legal/2018/02/msg00034.html) in this thread. Do you think that the rules for modifications of the GPL text do not hold for modifications of the LGPL text? Could you please elaborate a bit? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpNgtworXJ7D.pgp Description: PGP signature
Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?
On Mon, 26 Feb 2018 22:51:44 +0100 Mihai Moldovan wrote: > * On 02/26/2018 10:28 PM, Ole Streicher wrote: > > The LGPL-2.1 starts with > > > > | Everyone is permitted to copy and distribute verbatim copies > > | of this license document, but changing it is not allowed. > > ^^ > > > > I am therefore wondering whether the IUPAC/... license text violates > > itself the LGPL license conditions and cannot be distributed in Debian > > at all? > > IANAL: they have not changed LGPL-2.1, but copied it and released it under a > different name. > > As far as I understand, it would only be violating LGPL-2.1, if the text was > changed, but the original name retained (since in such a case, naturally, > you'd > be getting something that isn't LGPL-2.1 under the LGPL-2.1 name). > > By changing the name as well, they made clear that this is not LGPL-2.1, so I > do > not see any violation. There's probably no violation, I think, since the FSF explicitly [permits](https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL) the creation of a modified variant of the GNU GPL, under a different name, with changed instructions-for-use, without the preamble, and without any mention of GNU. I suppose the same rules hold for the GNU LGPL... Anyway, please note that the FSF recommends against contributing to license proliferation! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpQawF4efUQh.pgp Description: PGP signature
Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?
On Mon, 26 Feb 2018 16:53:12 +0100 Alex Mestiashvili wrote: > On 02/26/2018 03:50 PM, Walter Landry wrote: [...] > > It looks a like the LGPL-2. In any event, this license is fine as is. > > If anyone wants to make modifications that are not allowed by the > > existing text, then they can modify it under GPL-2+ terms. There are > > other examples in the archive of this (e.g. CECILL). > > > > Cheers, > > Walter Landry > > > > I see. Now I also found this license (thanks to codesearch.debian.net) > in openbabel package as LGPL-2.1 compatible. Hello. This "IUPAC/InChI-Trust InChI Licence No. 1.0" appears to have been created starting from the GNU LGPL v2.1, by the following steps: 0) remove the preamble 1) change the license name 2) use the British spelling for the word "license" (that is to say, "licence") 3) add the definition of "IUPAC" 4) add one explicit clarification to clause 2c, which states that the requirement does not extend to any "work that uses the Library" 5) drop some reasoning about executable binaries as derivative works in section 5 6) relax some requirements on distribution of "works that use the Library" in section 6 7) add a new section 15 which includes a non-free restriction on how you can refer to the output of a modified library: | 15. If you modify the Library in any way whatsoever, the output from | any such modified Library may not be referred to as 'InChI' or any | similar name. Any attempt to refer to such output as 'InChI' will | automatically terminate your rights under this Licence. 8) rephrase the instructions for use of the license I think this license contributes to the (bad) license proliferation festival that we sadly continue to witness. In my own personal opinion, it includes at least one non-free restriction (in its section 15), but, luckily, is one-way convertible to the GNU GPL version 2 or later. Hence, I think that a work solely licensed under the terms of this "IUPAC/InChI-Trust InChI Licence No. 1.0" complies or may be made to comply with the DFSG. But we have to remember that such a work can be considered as DFSG-free only as long as it is not linked with GPL-incompatible works! I am not sure which is the usual practice in Debian for cases like this: should the conversion-to-GPL be explicitly performed while packaging the work and the original license just mentioned in the debian/copyright file for completeness' sake? or should the work be left as-is (with the original license in the debian/copyright file), thus relying on the possibility to apply the GPL whenever the need arises? What do other debian-legal regulars think? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpwaIvqG3j0d.pgp Description: PGP signature
Re: Bug#883731: audacious: Debian packaging has incorrect license
On Tue, 12 Dec 2017 16:39:28 -0500 Nicholas D Steeves wrote: [...] > This is one of the reasons the FSF demands copyright > assignment for their projects...they want to be able to relicense at > any point in the future without having to contact and document consent > from all contributors. Yeah, right: they want to do what they like, without asking whether the contributors are fine with their decisions... Personally, I consider this FSF copyright assignment policy a very bad practice! But I am digressing... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpj7qsgAuqRO.pgp Description: PGP signature
Re: Bug#883731: audacious: Debian packaging has incorrect license
On Sun, 10 Dec 2017 18:12:39 -0500 Nicholas D Steeves wrote: [...] > GPL-incompatible 2-clause BSD [...] A nitpick: the 2-clause BSD license is not GPL-incompatible (it's indeed compatible with the GNU GPL). It's just a distinct license with different (and much simpler) wording... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpZBvsnYN7Aq.pgp Description: PGP signature
Re: Bug#883731: audacious: Debian packaging has incorrect license
On Thu, 7 Dec 2017 22:39:41 -0500 Nicholas D Steeves wrote: > Dear Debian Legal Team, Hello Nicholas, John, and everybody else reading this. I would like to send some comments of mine, here. Please note that: not only I am not a lawyer, but, even more importantly, I am not your lawyer, nor a lawyer of the Debian Project. Also, I am not a member of the Debian Project: I am just a Debian external contributor, who happens to be a regular on the debian-legal mailing list... > > I've CCed you for my reply to this bug, because I don't have the > experience to be able to tell if Debian implicitly relicensed > Audacious as GPL-3 from 2012-2016, As far as I can tell, *maybe* the implicit re-licensing was done by distributing the audacious Debian package with the incorrect debian/copyright file. > how potentially falling out of > BSD-2-clause license compliance might have affected this, Failing to retain the license text in the package distribution is in fact lack of compliance with the 2-clause BSD license, I would say... > and also how > this should be resolved. The Debian packaging is GPL-2+, so it's > possible to move to copyright-format/1.0 if that would simplify > things. I personally think that the first thing to do is an accurate copyright and licensing status review of the audacious package, so that the debian/copyright file may be fixed to reflect the actual current state of affairs. The Audacious upstream developers may be willing to help, by clarifying any doubts upon request. This may be a perfect opportunity to switch to the [machine readable] format. [machine readable]: <https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/> After a fixed audacious package is uploaded to Debian unstable and migrates to Debian testing, the most offending issue should be solved, I suppose. At that point, the Audacious upstream developers may be willing to forgive the Debian Project for the past incorrect copyright information. If that is deemed to be needed or useful, it could be feasible to also fix the debian/copyright file for audacious version 3.7.2 in a Debian stable update (and possibly also address the same issue for oldstable)... On the other hand, this extra effort could perhaps be considered not worth doing. > Also, please reply to point 2. OTTO "ancient plugins...under > different licenses. I assume audacious-plugins will also need a > copyright review. Probably. > Please CC John and I, Bug #883731, and > debian-legal as appropriate. Done. I hope my comments may help. Bye and thanks to the Debian Multimedia Maintainers for the time they spend in maintaining a number of great Debian packages, and to the Audacious upstream developers for the time they spend in developing/maintaining that very nice audio player (that I personally use everyday!). Thank you! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgphzKv9NOUBG.pgp Description: PGP signature
Re: French gov open license
On Wed, 22 Nov 2017 16:05:58 + Ian Jackson wrote: [...] > I have read the licence PDF and it is a reasonable licence for open > data. I have read the license text too and I have some doubts. Section _Liability_ reads, in part: | The « Producer » guarantees that it makes the « Information » | available free of charge, under the freedoms and the conditions | defined by this licence. This makes me think that the license cannot be used, when the Producer distributes the Information commercially (i.e.: by charging a fee for the service of making the Information available, without of course imposing the payment of any royalty). It's true that commercial re-use is explicitly allowed in section _You are free to re-use the « Information » :_ | To exploit the « Information » commercially but I am not sure how the above warranty (that the Producer does not sell the Information) can be considered consistent with DFSG#1. Moreover I wonder what impact it may have on the alleged GPL-compatibility of the license under analysis. Another point is in section _Intellectual property rights_: | The « Producer » guarantees that the « Information » is not subject | to any « Intellectual property rights » belonging to third parties. Maybe it's just an issue with poor wording, but this makes me think that the Producer cannot use this license for Information not entirely under his/her/its "legal" control. If, for instance, the Information includes some part copyrighted by a third party, this is a no-go, even if the third party agrees to license his/her/its contribution under these terms! [...] > Commonly, we would want to know if it was GPL3+-compatible. I think > it probably is. I don't see any clauses which are not restrictions > which are already in the GPL3 in other terms, so complying with GPL3 > would also comply with this licence. > > There is one possible exception, in that the licence requires > > The re-use shall not mislead third parties or misrepresent the > content of the << Information >>, its source and its time of last > update. > > "Misrepresent the content" is a bit vague. If challenged, I would > argue that this is the same as the GPL3's requirement for "appropriate > copyright notice" perhaps read together with the GPL3 requirement for > notices of modification. I agree that the expression is a bit vague, but this could perhaps be considered a non-issue: the well known [zlib license] is [considered] GPL-compatible and it includes the following clause: | Altered [...] versions [...] must not be misrepresented as being the | original software. This clause is not identical to the above-quoted expression, but I think it's similar enough. Nonetheless, I acknowledge that the zlib wording is clearer and less vague, so perhaps you are right that this is indeed an issue, I am not sure... [zlib license]: <http://www.zlib.net/zlib_license.html> [considered]: <https://www.gnu.org/licenses/license-list.html#ZLib> As previously said, I am more worried about other clauses of this French gov open license. Finally, please note that this is yet another license that adds to the license proliferation problem. Why, oh why, the governments of some EU countries cannot help re-inventing the wheel by producing their own local legislation specific license texts?!? There are already a number of good, well-known, and simple licenses suitable for releasing non-copylefted free works: basically the [Expat license], the already cited [zlib license], the [3-clause BSD license], the [2-clause BSD license]. I am convinced that there's no need to go on producing new (contorted) license texts for the same exact purposes. [Expat license]: <http://www.jclark.com/xml/copying.txt> [3-clause BSD license]: <https://spdx.org/licenses/BSD-3-Clause> [2-clause BSD license]: <https://spdx.org/licenses/BSD-2-Clause> -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpcvQaO3FJ1D.pgp Description: PGP signature
Re: French gov open license
On Sat, 25 Nov 2017 11:16:48 +1100 Ben Finney wrote: [...] > 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. I acknowledge that a license text cannot be assessed for DFSG-freeness in a vacuum, as long as this means that we always have to keep in mind that analyzing the license text is only one step (although an important one) in the DFSG-freeness assessment process for a work. Other (already mentioned) considerations come into play, when assessing the DFSG-freeness of a given work. However, the license text analysis is usually one of the biggest steps in the assessment process and may be common to a number of different works. As a consequence, we can often factor it out, so that it is not repeated over and over again for distinct works released under the same exact license terms. In this sense, we can analyze a license text in a vacuum, provided that we then remember to take the other aspects into account, whenever we apply the analysis outcome to a specific work. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpVn0AJndcgU.pgp Description: PGP signature
Re: webcamoid - MS Corp files
On Sat, 14 Oct 2017 11:27:00 -0300 Herbert Fortes wrote: > Em 14-10-2017 10:43, Francesco Poli escreveu: > > On Sat, 14 Oct 2017 10:05:57 -0300 Herbert Fortes wrote: > > > >> Hi, > > > > Hello, > > > >> > >> I am the maintainer of Webcamoid Debian package. > > > > Thanks for maintaining that package in Debian! > > > >> Today I > >> am packaging a new version and found some files that > >> should not be in 'main'. > >> I did the package for 'stable' (7.2.1+dfsg1-5) removing > >> some of that files but not all of them. > > > > The rationale behind the removal of those files is not clear to me: > > could you please elaborate a bit? > > > > > > I found the issue (2016) on github about Ms-LPL files: > > https://github.com/webcamoid/webcamoid/issues/42 First of all, I suggest you document the rationale of the removal in the debian/copyright file, probably in Comment: field in the header, as done in [imagemagick], for instance. [imagemagick]: <https://tracker.debian.org/media/packages/i/imagemagick/copyright-8%3A6.9.7.4%2Bdfsg-16> > These files I am talking today do not declare Ms-LPL. > Only 'All Rights Reserved'. They seem to have a shortened permission notice, just because there's a "general" file in the directory, which states "All files in THIS FOLDER, and ONLY THIS FOLDER are licensed under MICROSOFT LIMITED PUBLIC LICENSE, following is a copy of the license: [...]" This file is named [COPYING]. [COPYING]: <https://anonscm.debian.org/cgit/collab-maint/webcamoid.git/tree/libAvKys/Plugins/VirtualCamera/src/dshow/VirtualCameraFilter/BaseClasses/src/COPYING?h=upstream/7.2.1%2bdfsg1=f72535363e53fb9ddce0171c26c6c4cbea633cd2> As far as the issue itself is concerned, I personally think that those files are GPL-incompatible and should be purged from the Debian package (especially from the binary packages, but also from the source package). I am not sure the issue is severe enough to need a fix in a stable update. If you are willing to prepare a fixed package for Debian stable, you may want to get in touch with the stable release team and ask them... I hope this helps. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpN1RvoznjMz.pgp Description: PGP signature
Re: webcamoid - MS Corp files
On Sat, 14 Oct 2017 10:05:57 -0300 Herbert Fortes wrote: > Hi, Hello, > > I am the maintainer of Webcamoid Debian package. Thanks for maintaining that package in Debian! > Today I > am packaging a new version and found some files that > should not be in 'main'. > I did the package for 'stable' (7.2.1+dfsg1-5) removing > some of that files but not all of them. The rationale behind the removal of those files is not clear to me: could you please elaborate a bit? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPyHAKwtYeS.pgp Description: PGP signature
Re: DFSG + Hack typeface license with transition to proposed new source file build in Debian package
On Wed, 16 Aug 2017 08:40:00 -0400 Chris Simpkins wrote: > [...] Downstream open source project font licensing from the days > prior to SIL OFL (and to some degree even after that period) is a > bit of a quagmire. Hello, I agree that font licensing is a quagmire. Well, I even go further and personally think that it is a real mess: I wish more fonts were simply released under the terms of wide-spread and well understood licenses (such as the Expat/MIT license or the GNU GPL v2 + font exception)... Doing so would spare a good number of headaches to many people! > > Item 2 is where the reserved font name declaration is located. > I have been considering modification of the language here to permit > forks to use “Hack” in the name, but not “Hack” alone for a forked > typeface. [...] Personally speaking, I would encourage you to at least relax this restriction (or, even better, to drop it entirely). That way, only one name (or no name) would be forbidden for derivative fonts and everything would be simpler... [...] > It is a downside in the typeface software development area that > is in need of repair. But it is a reality that we face. I personally think that technical issues should not be worked around by imposing licensing restrictions. If typeface development tools need to be improved in order to get better QA, then I hope they can be enhanced from a *technical* point of view. In the meanwhile, licensing restrictions should not be introduced to compensate for technical limitations. This is my personal opinion. I hope this helps. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp0DX5mzOql7.pgp Description: PGP signature
Re: System libraries and the GPLv2
On Fri, 31 Mar 2017 07:23:25 -0400 Richard Fontana wrote: > On Thu, Mar 30, 2017 at 11:37:32PM +0200, Francesco Poli wrote: > > On Wed, 29 Mar 2017 23:28:46 -0400 Richard Fontana wrote: > > > > > On Thu, Mar 30, 2017 at 05:08:24AM +0200, Carlos Alberto Lopez Perez > > > wrote: > > > > > > > Do you (or anyone else) _really_ think the copyright holders of the GPL > > > > program in question had any intention ever of not allowing their program > > > > to be used along with OpenSSL, when they where the ones implementing > > > > support for using it on the first place? > > > > > > This, I would say, encapsulates the real Fedora/Red Hat position on > > > this issue to the extent there is one. It assumes that the intent of > > > the copyright holders can be determined from their actions. > > > > What about programs that link both with OpenSSL and with a > > third party purely-GPL-licensed library? > > I don't think that would change anything, but maybe I'm overlooking > something. I think the outcome would change significantly. The copyright holders of the purely-GPL-licensed library (e.g. readline) have never granted any linking exception, explicitly or implicitly. They are not the ones who implemented support for OpenSSL in the program. Other developers designed and implemented the program, which links with the purely-GPL-licensed library and with OpenSSL at the same time. In this scenario, you can determine the intent of the program copyright holders, but what you need is a linking exception from the purely-GPL-licensed library copyright holders, not from the program copyright holders! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp4scXOCIVIR.pgp Description: PGP signature
Re: System libraries and the GPLv2
On Wed, 29 Mar 2017 23:28:46 -0400 Richard Fontana wrote: > On Thu, Mar 30, 2017 at 05:08:24AM +0200, Carlos Alberto Lopez Perez wrote: > > > Do you (or anyone else) _really_ think the copyright holders of the GPL > > program in question had any intention ever of not allowing their program > > to be used along with OpenSSL, when they where the ones implementing > > support for using it on the first place? > > This, I would say, encapsulates the real Fedora/Red Hat position on > this issue to the extent there is one. It assumes that the intent of > the copyright holders can be determined from their actions. What about programs that link both with OpenSSL and with a third party purely-GPL-licensed library? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpNVc2q2CpDS.pgp Description: PGP signature
Re: System libraries and the GPLv2
On Wed, 29 Mar 2017 14:49:48 +0200 Carlos Alberto Lopez Perez wrote: [...] > I think that any package that is essential for the base OS > (aka Priority: required) should qualify for the system exception. Well, for the record, package libssl1.0.2 is Priority: important, hence, even with this criterion, it would not qualify... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpcC8uQ2Ekz9.pgp Description: PGP signature
Re: Checking the ARL's scheme for releasing software
On Mon, 20 Mar 2017 14:15:14 + Karan, Cem F CIV USARMY RDECOM ARL (US) wrote: > Good morning, my name is Cem Karan. Hello! [...] > I have been in discussion with the Open Source Initiative (OSI, > https://opensource.org/) on their license-discuss mailing list to develop a > method that ARL can use to safely and legally release ARL-developed code as > Open Source. Marc Jones suggested on that list that I contact Debian to see > what Debian thoughts are. Thanks for doing so. What follows are my own personal opinions. Please note that I am *not* an official member of the Debian Project (I am just an external contributor) and I cannot speak on behalf of the Project. [...] > we'd like to use a scheme that was > suggested on code.mil: > > 1) All code that does not have copyright attached is released under the > Creative Commons Zero (CC0, > https://creativecommons.org/publicdomain/zero/1.0/). This looks fine to me, with the only possible caveat that CC0 explicitly refuses to waive patent rights: https://opensource.org/faq#cc-zero > > 2) ARL-controlled projects choose an OSI-approved license to accept > contributions under (e.g. Apache 2.0). If a contribution has copyright > attached, then the contributors must license the contribution under the > OSI-approved license to the ARL. Contributions that have no copyright > attached must be licensed to the ARL under CC0. OK. > > 3) The works are combined and distributed with a note similar to the > following: "The portions of this work that do not have copyright attached are > distributed under the CC0 license. The portions of this work that have > copyright attached are distributed under the Apache 2.0 license." Looks clear enough to me. > > Will this scheme meet Debian's idea of Open Source software? Personally, I think this scheme would be suitable to comply with the DFSG. Obviously, I don't know what other debian-legal regulars think, nor whether the Debian FTP Masters will consider works released according to this scheme as acceptable for the Debian main archive... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpAjgla9fW06.pgp Description: PGP signature
Re: freeness and compatibility of CeCILL-C licence
On Thu, 23 Mar 2017 10:38:37 + Ian Jackson wrote:
> Dmitry Alexandrov writes ("Re: freeness and compatibility of CeCILL-C
> licence"):
> > [Ian:]
> > > (IMO it would not be fine if it specified Russian or Chinese courts.)
> >
> > Interesting idea. Any substantiation for such a discrimination of origin?
>
> Some courts are more trustworthy than others.
Personally I don't agree with this discrimination: I think that the
normal venue selection rules should never be subverted by Free Software
licenses, regardless of how palatable may look the potential
pre-selected venue...
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpJtikLloSYo.pgp
Description: PGP signature
Re: freeness and compatibility of CeCILL-C licence
On Thu, 23 Mar 2017 02:47:43 +0300 Dmitry Alexandrov wrote: [...] > > Francesco Poli dislikes the choice of law and courts clause, but I > > think it's fine. For the record, I think a choice of law clause is acceptable. On the other hand, I consider a choice of venue clause as a non-free restriction. > > IBM PL v1.0 contains a choice of law clause and it’s listed as > suitable for Debian’s main [...]. It seems to me that the IBM PL v1.0 only includes a choice of law clause and no choice of venue. But discussing that license would take us far away from the issue at hand... > > As for arbitration clause, could anyone explain, what’s the practical > difference between ‘choice of law of N’ and stating that disputes > should be resolved in *general jurisdiction* courts of N? > IMHO, they are effectively the same. As far as I can tell, a choice of law clause only states that any dispute must be litigated following the laws of a pre-selected jurisdiction. On the other hand, a choice of venue clause insists that any dispute be litigated in the courts of a pre-selected country (or even state, region, local area, ...). If a user is sued (say, for copyright infringement) by the copyright holder, that user will be forced to travel possibly long distances in order to defend him/herself. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpZ3lyqW5AZk.pgp Description: PGP signature
Re: freeness and compatibility of CeCILL-C licence
On Thu, 23 Mar 2017 11:04:48 + Ian Jackson wrote:
> Drew Parsons writes ("Re: freeness and compatibility of CeCILL-C licence"):
> > If I'm reading that right, we can link it from BSD and LGPL libraries.
> > Currently MUMPS is in Debian used by
> ...
> > code-aster GPL2
>
> This is a problem then.
Although we seem to disagree on the DFSG-freeness of the CeCILL-C
license, I am happy to see that you agree with me on its
GPL-incompatibility and on the fact that GPL-licensed programs or
libraries linked with CeCILL-C-licensed libraries are indeed a problem.
I reported a number of such bugs [1] years ago and tried multiple
times to solve the issue for SCOTCH (which has already been mentioned
in this same thread: it's another library released under the terms of
the CeCILL-C license and often linked with GPL-licensed code).
[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;tag=scotch-license-issues;users=debian-science-maintain...@lists.alioth.debian.org
Unfortunately, the maintainers of the affected Debian packages do
not believe me and want to see an official statement from the Debian
FTP Masters. Such official statement has been requested multiple
times for years, but never seems to arrive.
I contacted the author of SCOTCH more than once, but failed to
persuade him that SCOTCH should be re-licensed (or dual-licensed)
under the GNU LGPL v2.1; he seems to be no longer willing to reply
to my e-mail messages.
>
> Is there any possibility of CeCILL being persuaded to add a GPL
> compatibility exception ? The licence already has an upgrade clause
> IIRC.
Maybe this is the way to go, thanks for suggesting this strategy!
Because of the license version upgrade clause, it would solve many
issues at the same time (not only for SCOTCH and MUMPS, but also for
other CeCILL-C-licensed works).
Maybe we should contact <le...@cecill.info> [2].
[2] http://www.cecill.info/contacts.en.html
Are you willing to help?
Please let me know, thanks for your time and for any contribution
you may provide.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpQ0P69y1Yxn.pgp
Description: PGP signature
Re: freeness and compatibility of CeCILL-C licence
On Tue, 21 Mar 2017 23:51:12 +0800 Drew Parsons wrote: > There are various discussions about the status of the CeCILL-C licence > v1 (and other CeCILL licences) in the history of this mailing list. The CeCILL-C license is a GPL-incompatible license, which may even be considered to fail to meet the DFSG. I personally consider works (solely) released under the terms of the CeCILL-C license as non-free. See https://lists.debian.org/debian-legal/2008/01/msg00171.html for an analysis of the license. It's GPL-incompatible, since it includes some restrictions not included in the GPL (at the very least, the choice of venue clause) and has no explicit conversion-to-GPL clause. Perhaps it's LGPL-compatible, but that's not especially interesting, since being LGPL-compatible is not difficult... > It's not listed at https://www.debian.org/legal/licenses/ > but when it last came up on this list, Thibaut Paumard suggested it's > fine, LGPL compatible, > https://lists.debian.org/debian-legal/2010/01/msg00064.html > Is this still the consensus? Thibaut just stated that it's LGPL-compatible. I cannot find any statement about it being "fine". > > The French scientific computing community have been been quite active, > with many packages released under CeCILL licences. Indeed, and they increased license proliferation, which is really really bad... :-( > If CeCILL-C is an acceptable licence, [...] I personally do not consider it acceptable. Please note that I am a Debian Project external contributor (I am not a member of the Project) and I do not speak on behalf the Debian Project. What I expressed are my own personal opinions. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpYbj0ql3ua2.pgp Description: PGP signature
Re: LOSLA (LEGO Open Source License Agreement 1.0)
en published > under a particular version of the License, You may always continue to > use it under the terms of that version. You may also choose to use such > Covered Code under the terms of any subsequent version of the License > published by LEGO. No one other than LEGO has the right to modify the > terms applicable to Covered Code created under this License. This is an automatic license version upgrade mechanism. We could exploit this mechanism to solve the issues of this license. If LEGO is persuaded to declare that the GNU GPL (version 2 or later) is to be considered as a new version (say, version 2.0) of the LEGO® OPEN SOURCE LICENSE AGREEMENT, then all the issues of this license will instantly be solved... Are there any volunteers for this persuasion effort? [...] > Section 13. Governing Law > > To the extent possible under applicable law, this License [...] > shall be subject to the non-exclusive > jurisdiction of the Commercial and Maritime Court of Copenhagen. [...] This seems to be a choice of venue clause. Such restrictions were discussed to death on debian-legal with several diverging opinions. My own personal opinion is that choice of venue clauses are non-free restrictions. I hope my personal comments on this license may help. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpaQd2UdTK4g.pgp Description: PGP signature
Re: Is the RAR archiver freely distributable?
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 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... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpXjTLJguHtK.pgp Description: PGP signature
Re: Freeware Public License (FPL)
On Fri, 04 Nov 2016 13:25:17 +0100 Jörg Frings-Fürst wrote: [...] > I have ask the upstream author Paul E. Jones <pau...@packetizer.com>. > Here are the answer: [...] Hi, rather than commenting on the several misconceptions and plain false statements included in the upstream author's answer, I will just recommend you to reply him something similar to the following: """"" May I suggest you a simple action that would make everyone happy? Instead of using your own custom-made license, please adopt the Expat/MIT license [1]: it is short and simple and it basically does exactly what you want, in a legally sound way; it is also well-known and easily recognizable in the Free Software community; nobody will probably annoy you again with licensing issues, if you adopt that license! Please consider switching to the Expat/MIT license: it would really make everyone happy. [1] http://www.jclark.com/xml/copying.txt """""" I hope this helps. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpKSrXGlbwn4.pgp Description: PGP signature
Re: Updating CIDER's Research Software Agreement License For Use in Ngspice
On Fri, 21 Oct 2016 04:45:53 + Eric Kuzmenko wrote:
[...]
> It was therefore not free software and did not
> comply with the Debian Free Software Guidelines, hence why it is found in
> Debian's non-free archive.
First of all, thanks for trying to liberate an important software
package for circuit simulation!
It would be really awesome, if ngspice could become Free Software.
However, please note that CIDER is apparently not the only non-free
part of the "ngspice" Debian package [1]. According to the
debian/copyright file [2] of version 26-1.1, there are other parts that
do not comply with the DFSG.
Namely, the parts under
* the NOOVELA license (non-commercial use only, lack of permission
to copy, distribute and modify)
* no license ("No license found, only copyright")
* the SPICEDOC license (educational, research and non-profit purposes
only)
Then there's the CIDER_LICENSE issue which you are trying to address.
My own personal opinion [3] is that all these issues have to be solved,
before the "ngspice" Debian package can be moved to the Debian main
archive.
I hope this may be done...
Bye.
[1] https://tracker.debian.org/pkg/ngspice
[2]
http://metadata.ftp-master.debian.org/changelogs/non-free/n/ngspice/ngspice_26-1.1_copyright
[3] I am not a member of the Debian Project, I am just an external
contributor: I don't officially speak on behalf of the Debian Project,
I just express my own personal opinion
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpsSbQVirn9U.pgp
Description: PGP signature
Re: Bug#837666: Fwd: Bug#837666: udunits: license change
On Wed, 14 Sep 2016 09:14:49 +1000 Ben Finney wrote: [...] > 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. I am not so sure that the GNU GPL v3 is so different. It's true that it grants freedom from restrictions by patents in the work held by its copyright holders, as you say (I assume you are referring to section 11), but it also forbids initiating patent litigation and it terminates the rights granted by the licensor for those who do not comply with this prohibition. Section 8 states, in part: | You may not propagate or modify a covered work except as expressly | provided under this License. Any attempt otherwise to propagate or | modify it is void, and will automatically terminate your rights under | this License (including any patent licenses granted under the third | paragraph of section 11). [...] and section 10 states, in part: [...] | You may not impose any further restrictions on the exercise of the | rights granted or affirmed under this License. For example, you may | not impose a license fee, royalty, or other charge for exercise of | rights granted under this License, and you may not initiate litigation | (including a cross-claim or counterclaim in a lawsuit) alleging that | any patent claim is infringed by making, using, selling, offering for | sale, or importing the Program or any portion of it. Maybe I am misreading something, but I don't see a huge difference between this clause of the GNU GPL v3 and the custom clause under discussion. One difference seems to be that the GNU GPL v3 forbids patent litigation related to the licensed work against *any* target. On the other hand, the custom clause under discussion only forbids patent litigation related to the licensed work against the *copyright holder or any contributor*. While I dislike this discrimination, it seems to me that the custom clause forbids *less* than what is forbidden by the GNU GPL v3. Or am I misunderstanding the clauses? [...] > 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. This recommendation is a good one, regardless of the outcome of our discussion on the custom clause. Besides, we must not forget that license proliferation is a plague that should be avoided as much as possible. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpccg15NLGOW.pgp Description: PGP signature
Re: [Individual|Corporate] Contributor License Agreement
On Tue, 13 Sep 2016 10:29:23 +0800 Paul Wise wrote: [...] > Personally, I trust the FSF, as a non-profit public interest charity, > to be a good copyright steward for Free Software code [...] Personally, I don't. The FSF has, in my own humble opinion, a bad track record of publishing and/or promoting licenses that I personally consider non-free (GFDL, AfferoGPLv3, endorsement for some Creative Commons licenses, ...). As a consequence, I don't trust the FSF to be a good copyright holder and I find the FSF's insisting on copyright transfer for all official GNU software unsettling. This is my own personal opinion on this matter. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpVFRO5ZrYbU.pgp Description: PGP signature
Re: Inclusion of PDF with CC Attr 3.0 license
On Thu, 01 Sep 2016 16:38:06 -0700 (PDT) Walter Landry wrote: [...] > It is not like it is hard to add the attribution > required by the license. Well, in my own personal opinion, CC-by-v3.0 requirements on attribution are not so easy and practical to comply with [1]. This is one of the reasons why I believe that this license fails to meet the DFSG. And not much has improved in CC-by-v4.0 unfortunately, despite my repeated attempts to persuade the license drafters [2][3][4]. [1] https://lists.debian.org/debian-legal/2007/07/msg00124.html [2] http://lists.ibiblio.org/pipermail/cc-licenses/2012-April/006729.html [3] http://lists.ibiblio.org/pipermail/cc-licenses/2012-August/007118.html [4] http://lists.ibiblio.org/pipermail/cc-licenses/2013-February/007327.html -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpf_8dqh8Iy8.pgp Description: PGP signature
Re: Inclusion of PDF with CC Attr 3.0 license
On Fri, 2 Sep 2016 00:15:11 +0100 Ian Jackson wrote: [...] > Making a modified version of a scientific paper like this > one is neither useful, nor, unless especial care is taken, ethical. I respectfully, but strongly, disagree. DFSG-free scientific papers (distributed while making source available) may be of great value to the scientific community and to the general public. There are countless kinds of modification/partial-reuse/mixing that would serve the best interest of scientific progress and/or scientific education. And even scenarios where (part of) a DFSG-free scientific paper could be turned into something completely different from a paper... As a Free Software supporter, I am convinced that none of these activities should be considered unethical, as long as no misrepresentation is going on (that is to say: as long as the derived work is clearly described as such, proper credit is given to the authors of the original paper, and the derived work is not passed off as the original paper). [...] > But Debian has taken the view that even documents like this one must > be fully free, [...] Thank goodness Debian has taken such view! My personal opinion on the case at hand follows. The Debian FTP Masters apparently consider works licensed under the terms of CC Attribution v3.0 as acceptable for the main archive. I personally disagree with them [1][2], but that's another story... [1] https://lists.debian.org/debian-legal/2010/01/msg00084.html [2] https://lists.debian.org/debian-legal/2007/07/msg00124.html The paper PDF is apparently generated from LaTeX code (which, along with the source for the images, is the source form, unless it is in its turn generated from some other format), but the source is not made available. Shipping a source-less PDF document in the (source and/or binary) Debian package would make the package unfit for the main archive. The PDF file should be shipped in the binary package, while shipping the corresponding source in the source package. The PDF file should be preferably regenerated at package build time. Otherwise, if the authors of the paper cannot be persuaded to provide the source, then the PDF file should be dropped from both the source package and the binary package. I hope this clarifies my own take on the subject. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp4oHhJGxeV0.pgp Description: PGP signature
Re: sybase license and openWatcom DFSGness
On Mon, 1 Aug 2016 12:44:20 +0200 Gianfranco Costamagna wrote: [...] > Hi Debian-Legal list :) Hello Gianfranco! > > forwarding the discussion from -devel here > > Basically, we thought OpenWatcom license wasn't DFSG for Debain standards, > and now since > I would like to put Virtualbox back in main, I'm trying to see if some > statement > clarifying the license is sufficient to make it dfsg. [...] I haven't found the time to re-read the whole detailed analysis of the license [1], but I think the issues are so many that a clarification should not be considered enough to solve them. [1] https://lists.debian.org/debian-legal/2006/07/msg00014.html It seems that nothing has changed in the last decade on the licensing front for OpenWatcom: if I am not mistaken, the compiler is still distributed under the terrible "Sybase Open Watcom Public License version 1.0" [2]. [2] ftp://ftp.openwatcom.org/pub/license.txt Please note that the license has an auto-upgrade mechanism, as implemented in section 7: | 7. Versions of the License. Sybase may publish revised and/or new versions of | this License from time to time. Each version will be given a distinguishing | version number. Once Original Code has been published under a particular | version of this License, You may continue to use it under the terms of that | version. You may also choose to use such Original Code under the terms of any | subsequent version of this License published by Sybase. No one other than | Sybase has the right to modify the terms applicable to Covered Code created | under this License. As a consequence, it should be super-easy for Sybase to fix all the licensing issues in a flash, *provided* they are willing to do so. They just have to issue a statement where they declare that they elect the Expat/MIT license [3] to be the next version (2.0) of the "Sybase Open Watcom Public License": the OpenWatcom compiler would instantly become available under the Expat/MIT license. Or maybe they want to choose the Apache License Version 2.0 [4]... [3] http://www.jclark.com/xml/copying.txt [4] https://www.apache.org/licenses/LICENSE-2.0.txt Of course, they have to be persuaded to do so, first. If anyone has good contacts inside Sybase, these could be leveraged to convince them to do this move. Good luck for the persuasion effort and thanks to anyone who is willing to help. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPH1yzr0kF9.pgp Description: PGP signature
Re: Code in lwIPv6 library under advertising requirement
On Sun, 28 Feb 2016 19:34:31 +1100 Ben Finney wrote: > Howdy all, Hello Ben! :-) [...] > By my understanding of copyright as the Debian project interprets the > conventions, a work subject to several sets of license conditions is > subject to the total set of restrictions. Indeed, this is also my own understanding of copyright laws. (With the usual warning that I am not a lawyer, and I do not speak on behalf of the Debian Project...) [...] > So is a work under conditions of the BSD 4-clause license with its > “obnoxious advertising clause”, or other license conditions with an > equivalent clause, DFSG-free? I think the answer is no. I disagree with you here: the 4-clause BSD license includes a clause that is indeed obnoxious, but *not* non-free. It meets the DFSG, as far as I can tell. It's not a recommended license, but it is acceptable for Debian main and has been actually accepted several times in Debian main, as far as I know. > > Does this mean the ‘lwipv6’ work is non-free with the inclusion of files > as per the example above? There are quite a few of them. I think the issue here is that the 4-clause BSD license is GPL-incompatible. I see three possible solution strategies (in order of decreasing desirability): A) the copyright holders for the 4-clause BSD licensed parts are contacted and asked to drop the obnoxious advertising clause for the code under consideration; if they agree, everything becomes fine and GPL-compatible or B) the 4-clause BSD licensed parts are independently reimplemented or replaced by suitable alternatives under GPL-compatible terms or C) the copyright holders for the GPLv2 licensed parts are contacted and asked to re-license their code under terms that are compatible with the various BSD licenses used in the work (including the 4-clause BSD license); if they agree, the incompatibilities are solved I hope this helps. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpiJwQ6d_fDr.pgp Description: PGP signature
Re: Questions about libntru license/ntru patent status
On Sat, 27 Feb 2016 07:03:53 -0800 Jim Wright wrote: > I would add that the OpenSSL folks have stated that they currently > intend to relicense, Yes, they stated this intention [1], but, after that, no further news came out, as far as I can tell. [1] https://www.openssl.org/blog/blog/2015/08/01/cla/ > but have unfortunately tentatively decided on yet another > GPLv2 incompatible license. Indeed, the Apache license v2.0 is GPLv3-compatible, but *not* GPLv2-compatible, unfortunately. Hence, it would only solve *some* of the countless incompatibility issues the current OpenSSL license has caused for more than 15 years. > I have asked them to reconsider using the UPL, the MIT license, > or some other permissive GPLv2 compatible license, but as yet > this has not gotten traction. I have also repeatedly written to them in order to recommend the adoption of the 3-clause BSD license [2], the Expat license [3], or the zlib license [4]. [2] https://spdx.org/licenses/BSD-3-Clause [3] http://www.jclark.com/xml/copying.txt [4] http://www.zlib.net/zlib_license.html I have never received any reply whatsoever... :-( -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpbyE6nHDPP1.pgp Description: PGP signature
Re: Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption
On Thu, 18 Feb 2016 05:02:37 + Mike Gabriel wrote: > On Mi 17 Feb 2016 21:49:54 CET, Francesco Poli wrote: [...] > > Please send the updated debian/copyright file... > > > > Oh, I must have forgotten to attach that file. Here it comes. Well, the so-called VeraCrypt License is just the TrueCrypt License version 3.0 + the Apache License version 2.0. Since both licenses apply, the situation is not really different from the one we have discussed in the previous messages of this thread... Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgppRF9dOqjyR.pgp Description: PGP signature
Re: Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption
On Wed, 17 Feb 2016 11:39:00 + Mike Gabriel wrote: [...] > (taking debian-edu-pkg-team @ Alioth into the discussion loop, as that > would be the maintainer team for VeraCrypt in Debian) OK, fine. > > On Mi 17 Feb 2016 00:17:28 CET, Francesco Poli wrote: > > > On Wed, 10 Feb 2016 18:07:48 +0100 Mike Gabriel wrote: > > > > [...] > >> 1. > >> Is VeraCrypt suitable for the non-free section of Debian? > > > > I am not sure: the TC-3.0 license is still fairly unclear (at least > > to my eyes), so I cannot really speculate on its possible > > implications... > > Hmmm... ok. I think the ftpmasters would be glad about some guidance > on why you see veracrypt (not the TC 3.0 license, see below) unfit for > Debian non-free. I have already uploaded VeraCrypt to Debian > NEW/non-free and it is waiting approval/rejection from an ftpmaster. I didn't say that veracrypt is clearly unfit for the non-free archive. I said that the TC-3.0 license is unclear, and that I am consequently not sure about the possibility to distribute a package including code under such a license (even in the non-free archive). I hope I clarified what I meant. > > Also, it'd be interesting if the upstream people of VeraCrypt can > apply any change(s) to the upstream sources, their VeraCrypt license > or whatever, to make the software fit at least for Debian non-free. If VeraCrypt upstream developers (IDRIX, I suppose) are in good terms with the copyright holders for the Truecrypt version they forked from (TrueCrypt Developers Association, I suppose) and can persuade them to agree to a re-licensing of the code-base, the outcome could be definitely interesting. Everything re-licensed under the terms of the 3-clause-BSD license would be a huge win for everyone, since it would mean the possibility to upload veracrypt to Debian main (assuming no other showstopper comes up). [...] > >> 3. > >> The new upstream maintainer also states that all novelties of the code > >> are licensed under the Apache-2.0 license, but as long as any line from > >> the original code sticks out, the licensing of the code is governed by > >> the original Truecrypt 3.0 license, right? > > [...] > > > > Then I am not sure I understand why the debian/copyright file draft > > you sent states > > Files: * > > Copyright: 2003-2011, TrueCrypt Developers Association > > 2013-2014, IDRIX > > License: TC-3.0 or Ms-PL > > > > What's Ms-PL ? Shouldn't it be Apache-2.0 ? > > Moreover, "or" means dual-licensing, but I understand this to be a > > code-mixing case: I think "and" should be used instead. > > > > See > > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > > for more details. > > Oh, I am sorry. With this mail, I have attached the latest > debian/copyright file as I have it now after having it reworked two > days ago. I should have sent an updated copy to debian-legal > immediately. Sorry for that. Mmmmh, I cannot see any attachment. Was it forgotten or lost somehow? > > As it seems, the VeraCrypt upstream people have come up with a new > license, the VeraCrypt license. See attached copyright file for details. Please send the updated debian/copyright file... [...] > > Anyway, without looking at any further details, a question arises: > > why are you packaging veracrypt for the non-free archive? what does > > it offer that tcplay doesn't? > > > > See > > https://packages.debian.org/sid/tcplay > > https://tracker.debian.org/pkg/tcplay > > I have checked tcplay and also zulucrypt-gui again. We provide > veracrypt to teachers / students at school that come from the Windows > realm mainly. For them, it is essential to recognize some pieces of > software on our Linux environment that they have become so used to on > their Windows machines. VeraCrypt (for formerly TrueCrypt) is such an > application. Teachers here in Germany have to encrypt all personal > data that they carry around, so they need _one_ cross platform tool > for that. I'd be happy to provide that piece of software to other > people in Debian (Edu). > > Working on the command line (tcplay) is not an option for the > teachers, we support here. Then I hope someone will develop a GUI front-end for tcplay, if it is so important for at least one category of users... > And personally, I just tried out > zulucrypt-gui the second time and I could not get it running as > non-root. This is probably possible, I did not spend much time on > this, but honestly, I prefer a solution that works right away. Also > ZuluCrypt feels a little nerdy, not so user friendly as VeraCrypt > currently is. Mmmmh, I see. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpPOkqxypaqw.pgp Description: PGP signature
Re: Bug#814352: ITP: veracrypt -- Cross-platform on-the-fly encryption
On Wed, 10 Feb 2016 18:07:48 +0100 Mike Gabriel wrote: [...] > 1. > Is VeraCrypt suitable for the non-free section of Debian? I am not sure: the TC-3.0 license is still fairly unclear (at least to my eyes), so I cannot really speculate on its possible implications... > . > 2. > I suppose VeraCrypt is not suitable for the main section of Debian > as the TC-3.0 license is not DFSG-compliant. I suppose > this has not changed for VeraCrypt, compared to TrueCrypt, right? Personally, I think this package should stay away from Debian main. As I said, I am not even sure it is safe to be distributed in the non-free archive. > . > 3. > The new upstream maintainer also states that all novelties of the code > are licensed under the Apache-2.0 license, but as long as any line from > the original code sticks out, the licensing of the code is governed by > the original Truecrypt 3.0 license, right? [...] Then I am not sure I understand why the debian/copyright file draft you sent states Files: * Copyright: 2003-2011, TrueCrypt Developers Association 2013-2014, IDRIX License: TC-3.0 or Ms-PL What's Ms-PL ? Shouldn't it be Apache-2.0 ? Moreover, "or" means dual-licensing, but I understand this to be a code-mixing case: I think "and" should be used instead. See https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for more details. Anyway, without looking at any further details, a question arises: why are you packaging veracrypt for the non-free archive? what does it offer that tcplay doesn't? See https://packages.debian.org/sid/tcplay https://tracker.debian.org/pkg/tcplay I hope this helps a little. Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp6wkbCRfgPW.pgp Description: PGP signature
Re: Non-Free SGML entity files
On Mon, 30 Nov 2015 21:20:21 -0500 Paul Tagliamonte wrote: > On Mon, Nov 30, 2015 at 11:23:22PM +0100, Francesco Poli wrote: > > Any other debian-legal regular willing to share his/her opinion? > > Without looking further into it (anyone have a source package I can look > at?), any license that restricts use to only that of implementing a > standard (and not modification nor derived works) is not fit for main. Dear Paul, stressware2 has already replied [1] with an example of a package including material under the license under question. Did you evaluate it? What was your conclusion? I haven't seen any follow-up from you on debian-legal about this issue... As I have previously said [2], I reported a bug against package fbreader due to an almost identical issue with the same license terms. Unfortunately, the fbreader Debian package maintainer disagrees that there is a problem and keeps closing the bug report [3]. There have been multiple attempts to obtain an opinion from FTP Masters (see the bug log), but no response yet. Could you please read the bug log and express your opinion? I would rather avoid seeing this issue pass into oblivion. Thanks for your time. [1] https://lists.debian.org/debian-legal/2015/12/msg2.html [2] https://lists.debian.org/debian-legal/2015/12/msg6.html [3] https://bugs.debian.org/807074 -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpWJtQYtiQdm.pgp Description: PGP signature
Re: Please do not compound license proliferation (was: C-FSL: a new license for software from elstel.org)
On Fri, 22 Jan 2016 14:33:42 +1100 Ben Finney wrote: > Elmar Stellnberger <estel...@elstel.org> writes: > > > I have various issues about current licenses. Just see at what makes > > this license pretty much different from other established licenses. > > Let us discuss this in detail when the license should be fit for > > approval. > > Please do not compound the already widespread problem of license > proliferation. > > If you actually want recipients of your software to exercise software > freedom, do everyone (including yourself!) a big favour, by choosing an > existing well-understood widely-implemented free software license. > > What's more, this is not the forum for discussing your own invented > license text. This forum is a service to the Debian project primarily, > and that cause is best served by strongly *discouraging* license > proliferation. I would just like to say that I fully agree with Ben's comment: license proliferation should be avoided in (almost) all cases. What's worse in the present case is that the proposed license is definitely non-free and has countless issues... Hence, I can do nothing but reiterate Ben's recommendation: please adopt an existing well-known and widely-used free software license! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpulUZqU64j7.pgp Description: PGP signature
Re: Are these copyright notices compatible with GPLv2+?
On Tue, 19 Jan 2016 12:21:46 -0800 (PST) Walter Landry wrote: > Riley Baird <bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch> wrote: [...] > > Regardless, the below clause is a non-commercial clause, which isn't > > compatible with the GPLv2: > >> //1. The users agree not to charge for the model owner code itself but may > >> //charge for additions, extensions, or support. > > I do not think this is not a problem in practice. If you add a > trivial addition to the code, then you are allowed to charge for the > code. It may be fine with respect to DSFG#1 (as well as to the other guidelines), but I think it is GPLv2-incompatible anyway, since it is a further restriction not included in the GPLv2 text... -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp4jeZojTUHA.pgp Description: PGP signature
Re: Non-Free SGML entity files
On Mon, 30 Nov 2015 21:20:21 -0500 Paul Tagliamonte wrote: > On Mon, Nov 30, 2015 at 11:23:22PM +0100, Francesco Poli wrote: > > Any other debian-legal regular willing to share his/her opinion? > > Without looking further into it [...] > any license that restricts use to only that of implementing a > standard (and not modification nor derived works) is not fit for main. I've just filed bug #807074 against package fbreader. But there are clearly other packages which include files under the same problematic license. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgprGPdcPwufg.pgp Description: PGP signature
Re: Non-Free SGML entity files
On Sun, 29 Nov 2015 23:39:19 +0100 stresswa...@ruggedinbox.com wrote: > > Please note that IANADD, I am just a Debian external contributor. > > I don't speak on behalf of the Debian Project or of the Debian FTP > > Masters: please contact them, if you want to know their opinion. > > How would I contact them? Their collective e-mail address is <ftpmas...@debian.org>, as listed in https://www.debian.org/intro/organization > > > Among other things, I noticed that also fbreader includes files under > > this same license: > > https://tracker.debian.org/media/packages/f/fbreader/copyright-0.12.10dfsg-10 > > This is what one of the files mentioned in the fbreader copyright file > says: > > > > It seems that they think that the files can be relicenced. Perhaps > because the derivation is trivial enough? Maybe they obtained a permission to derive those files from iso-pub.gml, I don't know. It's actually unclear to me, as it is not explicitly explained: they say the file is derived in part from a file with no permission to modify, so it seems that the derived file is legally undistributable (copyright violation). But, as I said, maybe there's more than what is written there... Any other debian-legal regular willing to share his/her opinion? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpaDRFyZAmP3.pgp Description: PGP signature
Re: Non-Free SGML entity files
On Sun, 29 Nov 2015 07:32:46 +0100 stresswa...@ruggedinbox.com wrote: > The package sgml-data includes non-Free files in the > sgml/entities/sgml-iso-entities*/ directories and the > sgml/html/entities/ directory under the following licence: > > 'Permission to copy in any form is granted for use with conforming >SGML systems and applications as defined in ISO 8879, provided this > notice is included in all copies.' > > Unless 'conforming SGML systems and applications' is broadly defined in > ISO 8879, then redistribution is highly restricted (I cannot check ISO > 8879, because it seems there is no gratis copy). I also think that this is a DFSG-freeness issue. Please note that IANADD, I am just a Debian external contributor. I don't speak on behalf of the Debian Project or of the Debian FTP Masters: please contact them, if you want to know their opinion. > > Files under the same licence are also included in linuxdoc-tools in the > directories iso-entities/entities/ and entity-map/sdata/ (for > example ISOtech). > > Furthermore, files in the directory > classpath/tools/resource/gnu/classpath/tools/gjdoc/dtd/ent/ in GCC are > based on these files. Among other things, I noticed that also fbreader includes files under this same license: https://tracker.debian.org/media/packages/f/fbreader/copyright-0.12.10dfsg-10 But the awkward fact is that the debian/copyright file states that a second (DFSG-free) license applies to the same files. It's not clear to me whether both licenses apply (which would mean that these files are non-free in fbreader too) or, instead, whether the recipient may choose which of the two licenses will apply (which would mean that we can choose the second license and everything is fine for fbreader). Maybe a serious bug report should be filed against fbreader about this. > > The SGML entity files are needed to build documentation for several projects. > > It seems like it would be difficult to write the SGML entity files much > differently, so it is possible that they are not copyrightable. IANAL, so I cannot say for sure whether these files may be considered as not copyrighted. I don't know whether the Debian Project Leader is willing to ask the SFLC to examine this issue... Any other opinion from debian-legal regulars? -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpfwvbwWRXhh.pgp Description: PGP signature
Re: [A]GPL vs Apache 2
On Tue, 03 Nov 2015 14:35:43 +0530 Ritesh Raj Sarraf wrote: [...] > Honestly, I can't see a reason why AGPL would > be bad, in the spirit of Free Software. [...] Personally, I see reasons why the GNU AfferoGPL v3 is bad: see my own analysis [1]. Please note that the FTP Masters disagree with me and think that the GNU AfferoGPL v3 is acceptable for main [2]. But their rationale failed to convince me [3]. [1] https://lists.debian.org/debian-legal/2007/11/msg00233.html [2] https://bugs.debian.org/495721#17 [3] https://bugs.debian.org/495721#28 -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpxGrEMJSVMb.pgp Description: PGP signature
Re: Source files
On Fri, 23 Oct 2015 12:13:52 +1100 Riley Baird wrote: [...] > But even if the person who wrote a program wrote it in such a way that > it was unreasonably difficult to understand (something which is very > unlikely), then we must say that that, even though no better form of > modification ever existed, it is non-free. Then I am afraid we will have to agree to disagree: I am convinced that a program cannot be considered non-free just because it is difficult to understand. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpzrehCLmJae.pgp Description: PGP signature
