Re: Packaging text licenses
Quoting Francesco Poli (2019-12-15 13:01:16) > 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? Evidently it can - question is if we are breaking a rule by doing so. As others in this thread have pointed out, Debian explicitly omits classifying license fulltexts as "free software" or "non-free software". 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. Perhaps that shift might also help you being less perplexed? :-) [ dropping remaining questions until surreounding logic is clarified ] - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Packaging text licenses
Quoting Francesco Poli (2019-12-14 17:22:09) > 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> 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 * libsoftware-license-perl - purpose of project is to emit licenses 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. Are all such packages in violation of DFSG? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Packaging text licenses
Quoting Baptiste BEAUPLAT (2019-12-14 15:12:38) > On 12/14/19 2:01 PM, 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 > > I had another look around the repository. The tool used to "compile" > those XML files into text, html, json and so on is written in java > with a lot of dependencies that are not present in Debian yet. > > I am not willing to introducing dozens of new packages just to produce > a text result of those sources files. > > I'm wondering if packaging the "data" repository[1] would be > acceptable? On one hand it is generated, but one the other, it is > still plain text files. That's similar pain as for many JavaScript packages and fonts... Sure, you can try convince Debian that this project is special and don't need source. That has been tried numerous times e.g. for JavaScript packages and fonts, and I don't recommend going down that route... What I recommend i to try piece together an alternative XML processing which produces same output as the Java-based ones used upstream. I'd be happy to help with that. My preferred hacking environments are shell and perl. If yours is different then I will be of less help. Let's discuss further in the #licenses channel if interested. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Packaging text licenses
Hi Baptiste, Quoting Baptiste BEAUPLAT (2019-12-14 11:55:40) > Yesterday, I was looking for the CC-BY license text to start a new > project. > > I had to dig up to CreativeCommons's github repository to find the > text version. (I didn't want to copy/paste the HTML version on their > website). > > My question to you is: "Would it be interesting for others if I were > to create a package with missing text version of licenses?" > > Currently, in debian, we have the /usr/share/common-licenses/ that > includes a couple of one, but is missing CC- and MIT for instance. I > would find it useful to just cp the file to new projects. > > @debian-legal: How text license are qualified regarding their > licenses? Can 'legal text' can be considered as public domain and > packaged with whatever license (MIT/GPL) ? 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 If you are interested in license checkers, then please consider joining others with same interest at the irc channel #licenses on OFTC.net. Related is also https://wiki.debian.org/CopyrightReviewTools Kind regards, - Jonas Maintainer and current upstream author of Licensecheck -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: System libraries and the GPLv2
Quoting Francesco Poli (2017-03-30 23:37:32) > 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? Surely we can then asses that the intend of our upstreams in such cases is schizophrenic: They _both_ want to dillute the copyleft licensing _and_ uphold it strongly. Because our job as distributors is not to respect what upstreams explicitly dictate through licensing, but to second-guess what is _really_ going on in their minds - and when their mindset and ours do not align, then surely they cannot be trusted to mean what the say - our need for simple distribution has higher priority than their right to grant complex licensing. Right? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: System libraries and the GPLv2
Quoting Carlos Alberto Lopez Perez (2017-03-30 19:12:53) > On 30/03/17 10:44, Jonas Smedegaard wrote: > > Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24) > >> On 30/03/17 03:11, Clint Byrum wrote: > >>> Excerpts from Carlos Alberto Lopez Perez's message of 2017-03-30 02:49:04 > >>> +0200: > >>>> I understand that Debian wants to take a position of zero (or > >>>> minimal) risk, and I also understand the desire to respect the > >>>> interpretation of the FSF about the GPL (they don't think this two > >>>> licenses are compatibles). > >>>> > >>> > >>> I believe that this is a fundamental difference between RedHat and > >>> Debian. > >>> > >>> RedHat is going to do everything within the law and inside their > >>> values for a profit. Their values don't include a strict adherence > >>> to the wishes of copyright holders, but strict adherence to the law. > >>> > >>> But our values do include respect for copyright holder rights. So > >>> while we can probably get away with this legally, it's been decided > >>> (a few times?) that without the GPL licensor's consent, we can't in > >>> good faith produce a combination of OpenSSL and a GPL program. > >>> > >> > >> Just a simple question: > >> > >> 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? > > > > Yes, I believe so. > > > > As a concrete example, the Netatalk project has for many years released > > code with plugins linking to OpenSSL, but has not added an exception. > > Authors of Netatalk try to make a living out of commercial support for > > their product, and I genuinely think it is in their interest to make it > > possible to use strong crypto - for personal use - but not allow > > redistribution of binaries with strong crypto. > Do you have any link or resource that can back what you say here? You asked what I _think_ and I shared that with you. I do not speak on behalf of Netatalk, just brought it up as an example of what inspires my thinking. More specifically what makes me think they care about differentiated use cases is their blogging at some point about a NAS company using their code unfairly. but again, I mention this not as a piece of fact but as inspiration on how more generally some may deal differently with licensing. You may judge my input unreliable due to not being proven by fact, or you may judge my thinking "far out". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: System libraries and the GPLv2
Quoting Carlos Alberto Lopez Perez (2017-03-30 05:08:24) > On 30/03/17 03:11, Clint Byrum wrote: > > Excerpts from Carlos Alberto Lopez Perez's message of 2017-03-30 02:49:04 > > +0200: > >> I understand that Debian wants to take a position of zero (or > >> minimal) risk, and I also understand the desire to respect the > >> interpretation of the FSF about the GPL (they don't think this two > >> licenses are compatibles). > >> > > > > I believe that this is a fundamental difference between RedHat and > > Debian. > > > > RedHat is going to do everything within the law and inside their > > values for a profit. Their values don't include a strict adherence > > to the wishes of copyright holders, but strict adherence to the law. > > > > But our values do include respect for copyright holder rights. So > > while we can probably get away with this legally, it's been decided > > (a few times?) that without the GPL licensor's consent, we can't in > > good faith produce a combination of OpenSSL and a GPL program. > > > > Just a simple question: > > 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? Yes, I believe so. As a concrete example, the Netatalk project has for many years released code with plugins linking to OpenSSL, but has not added an exception. Authors of Netatalk try to make a living out of commercial support for their product, and I genuinely think it is in their interest to make it possible to use strong crypto - for personal use - but not allow redistribution of binaries with strong crypto. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: libbitcoin license - AGPL with clauses added by SFLC and FSF
Quoting Turkey Breast (2014-05-21 14:22:23) I've made a Bitcoin library, and am seeking inclusion into Debian. We (me and the mentor) are seeking guidance going forwards over a license issue. The basic issue is that this project uses an AGPL license with several additions, which we were given to me by the SFLC and vetted by the FSF. They fix an issue with the AGPL which is unique to Bitcoin (ability to distribute the source code when using a service), add a lesser clause and an OpenSSL exception (although we are currently transitioning away from OpenSSL). The full text is here: https://github.com/libbitcoin/libbitcoin/blob/master/LICENSE Emails from SFLC and FSF: https://wiki.unsystem.net/index.php/Libbitcoin/License Explanation of why this is necessary: http://lists.dyne.org/lurker/message/20140513.150838.39b61dfb.en.html http://lists.dyne.org/lurker/message/20140513.153343.b480ed75.en.html Debian developer's (Jonas is in CC) grievances here: https://github.com/spesmilo/libbitcoin/issues/5 Anyway if the issue is intractable, we can migrate to vanilla LGPL for inclusion into Debian. But I'm seeking here guidance on the best path for everyone in terms of software quality and our users. Here is the relevant ITP Debian bug report with discussion: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670701 I notice now an update to the license done in December 2013: https://github.com/libbitcoin/libbitcoin/commit/a57bf36 I apologize if you've already brought that change to my attention - I had the (wrong) impression from both debian and upstream issue trackers that licensing had _not_ been changed to reflect the concerns I raised and which it seems Richard Stallman agrees with me about. Great. Let's move on... - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: libbitcoin license - AGPL with clauses added by SFLC and FSF
Quoting Ian Jackson (2014-05-21 17:47:42) Jonas Smedegaard writes (Re: libbitcoin license - AGPL with clauses added by SFLC and FSF): Quoting Turkey Breast (2014-05-21 14:22:23) I've made a Bitcoin library, and am seeking inclusion into Debian. We (me and the mentor) are seeking guidance going forwards over a license issue. ... I notice now an update to the license done in December 2013: https://github.com/libbitcoin/libbitcoin/commit/a57bf36 I apologize if you've already brought that change to my attention - I had the (wrong) impression from both debian and upstream issue trackers that licensing had _not_ been changed to reflect the concerns I raised and which it seems Richard Stallman agrees with me about. I can't figure out exactly what your previous concerns were but it's good to hear that they're resolved. For the record, my concern was not the AGPL (I am a fan of that too, and will most likely use it for my packaging work when Debian ships it in common-licenses). Rather, the licensing text itself forbids editing, and previous revisions had the exceptions placed within the common AGPL license - now it is properly placed before the common license. ...as I wrote at https://github.com/spesmilo/libbitcoin/issues/5: ...it even seems to me that you are in violation of the licensing of the very license text, as it explicitly disallows editing: Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. (arguably the current revision is still in violation as the _document_ is changed if the verbatim _part_ of it containing the AGPL is now pristine, but I choose to ignore that nitpicking detail) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: libbitcoin license - AGPL with clauses added by SFLC and FSF
Quoting Paul Tagliamonte (2014-05-21 18:12:11) On Wed, May 21, 2014 at 06:06:38PM +0200, Jonas Smedegaard wrote: I can't figure out exactly what your previous concerns were but it's good to hear that they're resolved. For the record, my concern was not the AGPL (I am a fan of that too, and will most likely use it for my packaging work when Debian ships it in common-licenses). Rather, the licensing text itself forbids editing, and previous revisions had the exceptions placed within the common AGPL license - now it is properly placed before the common license. It's not a change to the AGPL text, it's an Additional permission, as defined by the (A)GPL. I see no issues, myself. In fact, it looks to clarify an issue (by rounding down, not adding further restrictions) that some consider to be problematic. Also, for clarity's sake, the AGPL text wasn't changed, the LICENSE file contains more than just the license. At least, that's what I guess by glancing at this file for a few seconds. I could be wrong. Did those few seconds involve looking at the URL I rerferenced - specifically the location of the no-communication exception _before_ that commit (i.e. around lines 408-413)? https://github.com/libbitcoin/libbitcoin/commit/a57bf36 I agree that _after_ that commit there is no problem - which is my reason to write as I did initially in this thread. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Ghostscript licensing changed to AGPL
Quoting Don Armstrong (2014-05-08 21:06:08) On Thu, 08 May 2014, Thorsten Glaser wrote: On Wed, 7 May 2014, Bálint Réczey wrote: In my interpretation in this case I would have some reasonable time to comply, i.e. I don't have to publish all 0days on my site if I run AGPL-covered software.. You only have to publish code to users who are interacting with that code. If you're deploying 0 day fixes to the internet, then you're going to have to provide access to the same code so that other people can take advantage of your fixes. On Wed, 7 May 2014, Clint Byrum wrote: The things that link to ghostscript as a library will now need to be evaluated. If they are contacted via network ports, they'll need to have source download capabilities added. This is incorrect. They only need to have this in place if they modify the AGPLed work. So if Debian provides, say, a web frontend to Ghostscript, then with AGPL Ghostscript running that web frontend as a service for others only require an interface serving its sources if the _webmaster_ changes the code for that frontend? Not if Debian makes changes to both the frontend and AGPL Ghostscript? That seems like a loophole to me: If Google wants an advantage by running better-than-ghostscript.google.com PDF convertor, they can simply let another company/organisation/person be the Debian in their chain and not need to reveal their patches to their users. What did I miss? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Ghostscript licensing changed to AGPL
Quoting Jakub Wilk (2014-05-08 21:55:45) * Jonas Smedegaard d...@jones.dk, 2014-05-08, 21:37: So if Debian provides, say, a web frontend to Ghostscript, then with AGPL Ghostscript running that web frontend as a service for others only require an interface serving its sources if the _webmaster_ changes the code for that frontend? Not if Debian makes changes to both the frontend and AGPL Ghostscript? That seems like a loophole to me: If Google wants an advantage by running better-than-ghostscript.google.com PDF convertor, they can simply let another company/organisation/person be the Debian in their chain and not need to reveal their patches to their users. You missed the hidden §18 (“No Loopholes Allowed”): https://lists.debian.org/20130711174500.ga22...@redhat.com Ah, right: The difference between programming logic and law reasoning. Thanks for reminding - makes good sense. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
Quoting Reinhard Tartler (2013-01-16 07:27:25) On Wed, Jan 16, 2013 at 1:20 AM, Jonas Smedegaard d...@jones.dk wrote: I'll setup a mechanism to have libav extend the copyright file for each binary packages, adding to header section a reasoned effective license. ...and will start do similar for all the other packages that I am involved in, as I examine copyrights and licensing for those and convert to machine-readable format. TBH, I think the best way to go from here is to extend the specification to include extra fields that cover the effective license of given binary packages, and have debhelper and similar packaging tools install appropriate package.copyright files from that. Debhelper already supports debian/package.copyright files. Copyright file format 1.0 already supports expressing effective license (by use of the header section Copyright field). The mechanism I had in mind was to generate debian/package.copyright files during build, based on debian/copyright and debian/package.copyright.in files or some such, It would be good to have a _future_ copyright file format version more clearly document the use(s) of the header section Copyright field. I find it best, however, to postpone discussing further deveopment of that file format until after the release of Wheezy. Maybe it would be good to have improved standardized mechanisms to expand/compute/whatever copyright files for binary pakages, but I personally have little imagination what that might be, as I have only now had the epiphany of how those makes sense, and have zero experience in composing them as of yet. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
Quoting Thibaut Paumard (2013-01-14 23:29:40) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 14/01/2013 23:45, Francesco Poli a écrit : On Mon, 14 Jan 2013 11:13:48 +0100 Jonas Smedegaard wrote: Quoting Charles Plessy (2013-01-14 02:55:38) On Sat, Jan 12, 2013 at 11:43 PM, Francesco Poli (wintermute) I think that the effective licensing status of the binary packages (GPL-2+ or GPL-3+) should be explicitly and clearly documented in the comment at the beginning of the debian/copyright file and, probably, in the binary package long descriptions, as well. [...] Since currently there is no better place (at least, not one I am aware of) to carry these considerations and since I am convinced that such considerations are important, I still think that the comment should be kept in the debian/copyright file and clarified. Hi, I'm surprised it has not yet been pointed out, but I have always considered the right place to document copyright information for individual binary packages is package.copyright, which ends up as simply /u/s/d/package/copyright. I'm also surprised to not find it right away in either policy or devref. Anyway, man dh_installdocs at least doccuments the technical point. An additional README.Debian at least in the relevant -dev packages does not harm. I am aware of the techical feature of debhelper to install per-package copyright files. In the past I saw that as an indication that indeed the copyright file was intended to cover both source and effective licensing. During my partitipation in defining the copyright file format 1.0, however, it was brought up that there is no such requirement for effective licensing - the current defined purpose of the copyright file apparently is only to cover copyrights and licensing or _source_. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
Quoting Steve Langasek (2013-01-15 20:59:35) On Tue, Jan 15, 2013 at 02:41:07PM +0100, Jonas Smedegaard wrote: the current defined purpose of the copyright file apparently is only to cover copyrights and licensing or _source_. That's not true. The purpose of the copyright file has *always* been to ensure that the license for a given binary package is correctly documented in that package. It's just that the safest way to ensure this is by documenting the entire license for the source package in debian/copyright and copying that file to each of the binary packages. Unfortunately we took a wrong turn somewhere and started considering debian/copyright itself the requirement, and that's a *bug*. Ahh, I think I realize now where I went wrong: the copyright file is ambiguous! Even if I recall and understand correctly that during the DEP5 process leading to copyright file format 1.0 it was pointed out that the debian/copyright is only about source, that is *not* the same as saying that the /usr/share/doc/package/copyright files are only about source. Source and effective licensing just happen to be identical in simple cases. And copyright file format 1.0 just happen to only verbosely cover source copyright (as I recall the addition of copyright field in header section was only late in the process). Apologies to previous posters who might have seen this all along and tried to point it out to me. :-/ I'll setup a mechanism to have libav extend the copyright file for each binary packages, adding to header section a reasoned effective license. ...and will start do similar for all the other packages that I am involved in, as I examine copyrights and licensing for those and convert to machine-readable format. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#698019: libav: the effective GPL-licensed status of the binary packages should be clearly documented
Quoting Charles Plessy (2013-01-14 02:55:38) On Sat, Jan 12, 2013 at 11:43 PM, Francesco Poli (wintermute) I think that the effective licensing status of the binary packages (GPL-2+ or GPL-3+) should be explicitly and clearly documented in the comment at the beginning of the debian/copyright file and, probably, in the binary package long descriptions, as well. Le Sun, Jan 13, 2013 at 09:50:58AM +0100, Reinhard Tartler a écrit : I am not happy at all with cluttering the binary package description with license blabla. I would do so only as last resort Dear Reinhard, Francesco and everybody, I think that the Debian copyright file of libav 6:9.1-1 is clear enough with its comment in the header, and that it is best to keep the license information out of the description of the package. Newest progress(?) on this is commit e3731d with this commit message: Document all licensing of binary packages in README.Debian (not partly as comment in copyright file), to avoid confusing source That change has not yet released but sits in our VCS. Could you please comment on that? Sorry, I can't figure out how to reference it at our public anoncms URL, but it is commit e3731d at git.debian.org:/git/pkg-multimedia/libav . Note that the machine-readable format also allows License fields in the header paragraph to give the license information for the package as a whole. I am aware of that. But I am not convinced that *any* of the licensing formally covered by the copyright file format 1.0 are about the licensing of _binary_ packages. It is my understanding that they all are about sources only, not effective reasoned licenses. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [Pkg-javascript-devel] MIT +no-false-attribs
On 12-03-09 at 04:34pm, Jérémy Lal wrote: * it is really easy to comply with this license. * the bug-reporting contacts can be changed easily * they don't need to be changed anyway, the npm debian package won't need any patch (i mean the one being prepared, version 1.1.x, not the one in sid, which is outdated) * the author knows perfectly well i'm willing to distribute npm unpatched, since we've talked this through a while ago. NB! The fact that npm *currently* need no patching is irrelevant. As an example, imagine a security fix NMU - i.e. a patch applied by someone not closely familiar with the package: Would easily violate the license. I therefore recommend that if npm is packaged for Debian then we take the necessary steps from the beginning even if not strictly required, to avoid future complications. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: New Adobe CMaps license free enough for Debian?
On Tue, Oct 20, 2009 at 11:22:12AM +0100, MJ Ray wrote: Jonas Smedegaard wrote: I believe that I quoted the _license_ part of a CMap source header, deliberately leaving out the _copyright_ and _disclaimer_ parts, ad I considered those irrelevant for the question at hand. I think it's probably important to have the disclaimer because some licensors have tried to slip licence restrictions or liabilities into what they labelled as disclaimers; and it's useful to know the copyright holder in case it's one of the few that insists on particular interpretations of terms like use. It also makes it slightly easier to spot common-licenses and compare with them with wdiff because they are included in debian whole. Thanks for asking. I've nothing much to add to other comments on the substantial question. ccing as originally requested. Hope that helps, It certainly helps - all the input from you guys! I will now go through my (or my where team-maintained) 90+ packages and make sure disclaimers are included. ...oh, a related question: when including disclaimer of older GPL-licenses then lintian complains that the address is wrong - but isn't it wrong of us to correct that, as then the text is no longer verbatim? (sorry if this is a FAQ somewhere) Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: New Adobe CMaps license free enough for Debian?
On Tue, Oct 20, 2009 at 12:32:36AM +0200, Francesco Poli wrote: On Sun, 18 Oct 2009 19:05:44 +0200 Jonas Smedegaard wrote: On Sun, Oct 18, 2009 at 04:03:53PM +0200, Francesco Poli wrote: [...] Mmmmh, it seems that you didn't *fully* quote the text of the new license... I believe that I quoted the _license_ part of a CMap source header, deliberately leaving out the _copyright_ and _disclaimer_ parts, ad I considered those irrelevant for the question at hand. Please do educate me if that was a) incorrectly separated, I would say you left out the third clause, which is the difference between the 3-clause BSD license and the 2-clause BSD license... Ah, ok. b) bad style to leave out those other parts for questions like this I personally think that the copyright notice is important to quote too, as we are talking about a specific work, rather than about a license in a vacuum. Moreover, the disclaimer is typically attached to the license, and is part of the legal text that grants the permissions we need. In some licenses, it is even more entwined with the rest of the legal text. I think the disclaimer should be fully quoted too. Thanks for educating me! :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
New Adobe CMaps license free enough for Debian?
Hi, The Ghostscript project includes some so-called CMap files contributed by Adobe, which until recently was shipped with a non-free license allowing only redistribution: Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. Consequently Ghostscript in Debian have shipped without those CMap files, hurting (as I understand it) handling of multibyte fonts. September 25 CMap files was updated in Ghostscript Subversion, with the following license: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Commit message indicates that Ghostscript project interpret the new license as allowing modifications. I would like to have the legal teams opinion on whether this new license is acceptable for the Debian project. I am especially concerned about the the initial limitations: do use in source form mean we are allowed only to compile the virgin code or does that also allow us to derive and compile something else? Kind regards, - Jonas co-maintainer of Ghostscript for Debian Please cc me personally on responses, as I am not subscribed to the list. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: New Adobe CMaps license free enough for Debian?
On Sun, Oct 18, 2009 at 04:03:53PM +0200, Francesco Poli wrote: On Sun, 18 Oct 2009 15:28:30 +0200 Jonas Smedegaard wrote: September 25 CMap files was updated in Ghostscript Subversion, with the following license: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Mmmmh, it seems that you didn't *fully* quote the text of the new license... I believe that I quoted the _license_ part of a CMap source header, deliberately leaving out the _copyright_ and _disclaimer_ parts, ad I considered those irrelevant for the question at hand. Please do educate me if that was a) incorrectly separated, b) bad style to leave out those other parts for questions like this or c) something else was wrong with what I did. Here is verbatim the top 43 lines of that same CMap file, rev10096 of http://svn.ghostscript.com/ghostscript/trunk/gs/Resource/CMap/78-EUC-H : %!PS-Adobe-3.0 Resource-CMap %%DocumentNeededResources: ProcSet (CIDInit) %%IncludeResource: ProcSet (CIDInit) %%BeginResource: CMap (78-EUC-H) %%Title: (78-EUC-H Adobe Japan1 0) %%Version: 10.003 %%Copyright: --- %%Copyright: Copyright 1990-2009 Adobe Systems Incorporated. %%Copyright: All rights reserved. %%Copyright: %%Copyright: Redistribution and use in source and binary forms, with or %%Copyright: without modification, are permitted provided that the %%Copyright: following conditions are met: %%Copyright: %%Copyright: Redistributions of source code must retain the above %%Copyright: copyright notice, this list of conditions and the following %%Copyright: disclaimer. %%Copyright: %%Copyright: Redistributions in binary form must reproduce the above %%Copyright: copyright notice, this list of conditions and the following %%Copyright: disclaimer in the documentation and/or other materials %%Copyright: provided with the distribution.. %%Copyright: %%Copyright: Neither the name of Adobe Systems Incorporated nor the names %%Copyright: of its contributors may be used to endorse or promote %%Copyright: products derived from this software without specific prior %%Copyright: written permission.. %%Copyright: %%Copyright: THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND %%Copyright: CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, %%Copyright: INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF %%Copyright: MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE %%Copyright: DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR %%Copyright: CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, %%Copyright: SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT %%Copyright: NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; %%Copyright: LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) %%Copyright: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN %%Copyright: CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR %%Copyright: OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS %%Copyright: SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. %%Copyright: --- %%EndComments Commit message indicates that Ghostscript project interpret the new license as allowing modifications. I would like to have the legal teams opinion on whether this new license is acceptable for the Debian project. [...] According to recent news about this re-licensing, the newly adopted license is a BSD license: http://lists.debian.org/debian-legal/2009/09/msg00044.html Oh, above thread started as a dialog with Masayuki Hatta. Odd that he did not inform his fellow package maintainers of Ghostscript... :-/ The blog post cited in the above message is: http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/ and the actual text of the new license is: http://opensource.adobe.com/wiki/display/cmap/License which is basically the 3-clause BSD license. Oh, ok. I did not recognize it as BSD license. Thanks for the clarification. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: New Adobe CMaps license free enough for Debian?
On Sun, Oct 18, 2009 at 10:24:56PM +0800, Paul Wise wrote: On Sun, Oct 18, 2009 at 9:28 PM, Jonas Smedegaard d...@jones.dk wrote: September 25 CMap files was updated in Ghostscript Subversion, with the following license: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. In addition to Francesco's mail, I'd like to ask why ghostscript is committing the CMap files to their SVN, shouldn't they just depend on them instead of making an embedded data copy? We (the Debian ghostscript team) do not include CMap files, upstream do. They include several software parts that we then avoid using - more so in recent cleanups made by me, and even more (separate packaging of jbig2dec) still pending. Masayuki Hatta is probably more knowledgable about CMap files than me. I just didn't hear from him for a long time so did not expect him to be active currently. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
ok for Redland to link against openssl?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I filed bug#488766 some months ago with no response from maintainer. Could I please have some more eyeballs on that: Am I right that Redland violates GPL? Or is it ok since Redland is dual-licensed, so it should simply always be considered as Apache licensed when used with Debian? Currently morla (ITP bug#431824) cannot be packaged as it is GPL. Should I convince upstream to dual-license, or convince Redland maintainer to extend with a GPL-compatible package non-postgres package? What do you think? Jonas P.S. Please cc me on responses, as I am not subscribed to the list. - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAki9LsYACgkQn7DbMsAkQLgVogCglsvH3hRQ+OdBr1jaSz/KSkRU iQIAn3IsDtsC7u4gdy/JBt3/9LF3TsYj =0Dew -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ok for Redland to link against openssl?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, Thanks for the quick response! On Tue, Sep 02, 2008 at 01:57:40PM +0100, Matthew Johnson wrote: On Tue Sep 02 14:17, Jonas Smedegaard wrote: Currently morla (ITP bug#431824) cannot be packaged as it is GPL. Should I convince upstream to dual-license, or convince Redland maintainer to extend with a GPL-compatible package non-postgres package? If upstream morla uses redland linked against OpenSSL then they don't have permission to distribute the resulting binaries either, so upstream probably want to know. I guess they are not directly hurt by this - only when Redland is linked against Postgres and Postgres is linked against openssl does this problem occur But I will inform upstream anyway, to be on the safe side. It would probably be enough for ether morla or both morla and redland to add an openssl exception to their GPL licence. Ah, ok. I've downgraded the bug and retitled it. Thanks. The normal response would be to convince upstream to licence appropriately for linking against an Apache licence and an OpenSSL licence. Ok. I will try convince upstream to adjust their license, then. Thanks alot for the detailed and sharp response! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAki9POIACgkQn7DbMsAkQLiXzQCfeI/M4jpJ5WdM7AZLGzS224hY uFkAn03rKBQKEfyM1Fdl1DGaPbvFeQC8 =cJXB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
