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 pgpWiRMgvfmm3.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 pgpEHLEdfqgWK.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 pgpR9auFg4Jqe.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 pgpmUAUFx6wpi.pgp Description: PGP signature
Re: Concerns about infrastructure for Alioth replacement
On Mon, 16 Oct 2017 04:28:09 + Ondřej Surý wrote: [...] > Francesco, great idea, go ahead. You would be most welcome to help with > Debian Ruby Extra packaging. Unfortunately, I have basically zero knowledge about Rails, JavaScript and Node.js: I could not be of much help in packaging GitLab. What I meant was that the time that will be spent in manually installing, manually adapting, and manually upgrading the upstream version, would perhaps be better spent in helping the maintainers to keep the Debian package up-to-date and in using the Debian package in stead of the upstream version... -- 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 pgpOE3b7ykboK.pgp Description: PGP signature
Concerns about infrastructure for Alioth replacement
Hello, I am a Debian contributor (and Alioth user). First off, I think that [replacing] Alioth with something more maintainable is a good thing to do and I am grateful to the people who are working hard to make this happen. [replacing]: <https://lists.debian.org/debian-devel-announce/2017/09/msg4.html> I read through the [minutes] of the Alioth sprint and I learned that GitLab has been chosen as the project-hosting-system to use (rather than Pagure, which was initially suggested). Well, let's hope that things go smoothly, despite the "open core" strategy followed by the company behind GitLab (a strategy that I dislike)... [minutes]: <https://gobby.debian.org/export/Sprints/AliothSuccessors2017/Minutes> In the [minutes], I read: [...] | * Decision: We are going with GitLab and we are using upstreams packages. I am a bit worried about the message that the Debian Project is sending out by refusing to use a Debian package and preferring the unpackaged upstream version. I mean: from the point of view of someone who is outside of the Project, it seems that the Debian Project itself thinks that Debian packages should be avoided! :-( | -> Debian packages are same in stable, testing and unstable, and so a | bit stale compared to upstream: [...] | - we understand and acknowledge that packaging such a big piece of software | is a lot of work, especially regarding architectural changes, but we will | need fresher versions especially if we want support (consulting) from | Gitlab, request new features to go in the CE edition, etc. Also, we are | in a hurry. I would say that this issue with the Debian packages of GitLab should be addressed by helping the Debian Ruby Extras Maintainers to improve the Debian packages and to keep them more up-to-date. After all, if you just fix an issue on your own system, the same issue will have to be fixed elsewhere again and again. On the other hand, if you help the maintainer to fix the issue *in* the Debian package, every user of the package will benefit from the fix... You probably agree that this is a basic idea behind the very concept of "distro". I understand the hurry, but I am convinced that the Debian packages of GitLab should be used as soon as possible for the Alioth replacement. | | -> Debian packages do follow the policies and standards of Debian (GOOD!), but | it means that anything you find about gitlab does NOT fit. Howtos, tips, whatever, | everything is assuming the upstream look. -> Added Maintenance Burden. This reasoning reinforces the bad message sent out by the decision to use the upstream version: it might even seem that the Debian Project itself is admitting that using Debian packages is unpractical and that Debian policies and standards make everything work in a weird way. :-( | |Note: If, at some point in the future, the package as in Debian, is the better |choice, we can switch. As I said, I really hope that this switch will happen very very soon. If possible, even before the official debut of the Alioth replacement! I hope that voicing my concerns was useful. Bye and thanks for reading so far. P.S.: I am not subscribed to the mailing lists; please Cc me on replies, if any. Thanks for your understanding! -- 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 pgpWYkgi2YzyG.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 pgpspkAvj86Rp.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 pgpr_GUmMdhPF.pgp Description: PGP signature
Re: GPL-3 openssl: provide a -nossl variant for a library
On Fri, 24 Oct 2014 06:56:39 +0800 Paul Wise wrote: [...] Bradley Kuhn says that for GPLv2-only works Debian should not consider OpenSSL to be a system library but for works where the GPLv3 can apply, SSL/TLS is likely a Standard Interface and thus subject to the System Library exception. I was pondering over this issue and I seemed to remember I had seen an opposite opinion. Now I've just found where I saw that opinion: it was quoted on debian-legal [1] back in 2007. Brett Smith (FSF Licensing Compliance Engineer) stated that OpenSSL does not qualify as (GPLv3) System Library. [1] https://lists.debian.org/debian-legal/2007/07/msg00194.html -- http://www.inventati.org/frx/ fsck is a four letter word... . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp1V0n8VMt8d.pgp Description: PGP signature
Re: Ghostscript licensing changed to AGPL
On Wed, 7 May 2014 00:05:51 +0200 Philipp Kern wrote: On Tue, May 06, 2014 at 11:05:11AM +0200, Jonas Smedegaard wrote: Ghostscript have changed its license from GPL-3+ to AGPL-3+ since version 9.07. I am really disappointed and worried by this license switch... :-( Even though the Ftpmasters consider the GNU AfferoGPL v3 as acceptable for Debian main [1], I personally think that it fails to meet the DFSG [2][3]. [1] https://bugs.debian.org/495721#17 [2] https://bugs.debian.org/495721#28 [3] https://lists.debian.org/debian-legal/2007/11/msg00233.html But anyway, even if you think the GNU AfferoGPL v3 is DFSG-free, you could agree that it poses practical issues due to uncertainty on its scope and unclear definitions... [...] Seems that these projects may link against Ghostscript, and therefore (possibly) effectively becomes AGPL-3+ with this change: [...] It's a long list of affected projects: I fear that the practical consequences of this license switch may be significant and problematic. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp855YmCQIk3.pgp Description: PGP signature
Re: Ghostscript licensing changed to AGPL
On Wed, 7 May 2014 15:56:06 +0200 Bálint Réczey wrote: 2014-05-07 14:37 GMT+02:00 Thorsten Glaser t...@debian.org: On Wed, 7 May 2014, Ian Jackson wrote: Yes. But this isn't as bad as you think, because the source availability requirement exists only if you modify the AGPL'd software. Which you may want to do, in order to patch a security issue you just found, locally, before filing it upstream. 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. Hi Bálint, I don't think there's any clause in the GNU AfferoGPL v3 that allows to delay the availability of source for remote users. I am under the impression that you would have to comply immediately after making the program accessible to remote users. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpH34pnUD5mC.pgp Description: PGP signature
Re: Berkeley DB 6.0 license change to AGPLv3
On Sat, 20 Jul 2013 15:33:41 +0200 Ondřej Surý wrote: [...] So the question remains - if I am to haggle with upstream, then what should I propose? In my own personal opinion? I would recommend persuading upstream to switch back to the previous BDB license (the one used up to Berkeley DB 5.3), or, at least, to switch to the GNU LGPL v2.1, in order to enhance compatibility with BDB-using software. I don't know whether this can succeed, though... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpxkHq5T56Rs.pgp Description: PGP signature
Re: Berkeley DB 6.0 license change to AGPLv3
On Tue, 02 Jul 2013 18:40:11 +0200 Florian Weimer wrote: * Paul Tagliamonte: On Tue, Jul 02, 2013 at 09:44:10AM +0200, Ondřej Surý wrote: Florian Weimer has correctly pointed out that Oracle has decided to change the BDB 6.0 license to AGPLv3 (https://oss.oracle.com/pipermail/bdb/2013-June/ 56.html). This hasn't been reflected in release tarball (probably by mistake), but since the AGPLv3 is not very friendly to downstream projects, we (as the Debian project) need to take a decision. What? Wait, What? What?[1] The AGPL is a DFSG free FSF approved and OSI approved free software license? We made a decision, it's *free software* and fit for main. For the record, I personally disagree with the FTP masters' decision to accept works licensed under the terms of the GNU AfferoGPL v3 into main: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721#28 But that's my own opinion, of course. The problems start when random, network-enabled, but non-web stuff switches over to the AGPL *without* implementing the Quine required by the license (which is somewhat difficult to do for a library, but at least there could be a give me a tarball interface). That makes it difficult to perform local changes and stay in compliance with the license because you have to build the source code distribution mechanism from scratch and design a process that ensures the sources and running binaries match at all times. This is indeed one of the issues of the GNU AfferoGPL v3. There are other issues, as well. My own analysis is here: https://lists.debian.org/debian-legal/2007/11/msg00233.html If those issues don't make people consider AfferoGPLv3-licensed works as non-free, I think this license should at least be considered as problematic. Especially when a fairly widely used *library* switches from a *permissive non-copyleft* license to a *highly restrictive* one (such as the GNU AfferoGPL v3), I think the change should *not* be neglected or taken lightly... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpGpH87sNz4m.pgp Description: PGP signature
Re: apt-listbugs
On Tue, 18 Oct 2011 23:45:03 +0700 Alexey Salmin wrote: Thank you, Francesco! You're welcome! :-) [...] On Tue, Oct 18, 2011 at 2:37 AM, Francesco Poli invernom...@paranoici.org wrote: [...] In your example, if I understand correctly, you upgrade nvidia-graphics-drivers and crash xserver-xorg-core. This is described by the fact that bug #642757 is assigned to nvidia-graphics-drivers, but affects xserver-xorg-core. No! That's the whole point! You upgrade xserver-xorg-core from 2:1.10 to 2:1.11 and your desktop dies because of a bug in nvidia-graphics-drivers. Ah, OK. I thought it was the other way around: I hadn't found the time to read the whole log of bug #642757, sorry. If the issue was caused by an upgrade of nvidia stuff everything would be fine: there's a bug in the nvidia package and apt-listbugs warns you about it during the upgrade. Exactly. But it's not that way in this case. There's a bug in one package and it's exposed by a new version of another. Probably that's a common scenario e.g. a bug in a script could be exposed by a newer version of interpreter or vice a verse. In this case you'll not get a warning from apt-listbugs at all. True. I don't know how common this scenario is, but it's true that apt-listbugs is not able to save your day when that happens! Unless an auxiliary bug report is filed against the package that should not be upgraded, I mean. There're some ideas coming into mind how to solve it: [...] * Create a dummy bug report on xserver-xorg-core saying e.g. xserver-xorg-core 2:1.11 is incompatible with nvidia-graphics-drivers 285.05.09-1 It may help a bit but: I think that, currently, this is the best course of action. Since xserver-xorg-core/2:1.11.1-1 is already in testing, a bug report of severity grave against version 2:1.11.1-1 should not prevent future migrations to testing of newer xserver-xorg-core versions (please correct me, if I am wrong). This bug report could be marked as blocked by #642757. It will be possible to close it, as soon as a fixed version of nvidia-graphics-drivers has migrated to testing. - Somebody should care enough to create such bug reports and close them as appropriate. True, but it seems that a good number of people care about this issue... - I doesn't depend on the actual version of nvidia-graphics-drivers installed so it will show up in the cases it shouldn't. Sure: a good descriptive bug report title would help users to determine whether they may ignore the issue or not. * Make use of the 642757 affects xserver-xorg-core record That was my original idea but it will not work as is because AFAIK currently there's not way to specify the version of package affected by some bug. So if someone have a nvidia-graphics-drivers=285.05.09-1 installed he'll be warned at ANY update of the xserver-xorg-core (even when he makes a downgrade workaround) which is just useless. MY SUGGESTION IS: - Extend the affects record in the BTS to store the version of the package affected Maybe two entirely new BTS commands should be created, with mandatory version info. Something like exposed by and hidden by (a better name should perhaps be chosen). That way, it could be agreed that: bug #nnn (assigned to package B, found in version v1) affects package A means that the bug is actually present in B/v1, but causes breakage in package A hence, do not upgrade to B/v1 or later, if you want to avoid breaking package A bug #nnn (assigned to package B, found in version v1) is exposed by E/v2, is hidden by E/v3, is exposed by E/v4 means that the bug is actually present in B/v1, but only shows up when a version of package E which exposes the bug is installed hence, do not upgrade to E/v2 or E/v4, if you want to avoid exposing the bug in package B (it is however safe to upgrade to E/v3) The versions of package E used in exposed by and hidden by would be treated exactly like version tracking (which is driven by the found and fixed commands): in other words, the changelog would be used to determine the most recent descendant of version v, among the listed exposed and hidden versions, and this descendant would determine whether version v exposes or hides the bug. - Implement a feature in the apt-listbugs to make use of this records I'll try to express this with more details: 1) There packages A of version X and B of version Y installed 2) You're trying to upgrade package B to version Z 3) There's a bug report NNN on package A=X and it affects B=Z 4) In this case apt-listbugs should warn you before upgrading B to Z What do you think? I think that, if the above idea looks good to you and others, maybe the opinion of debbugs developers should be asked. If they think it's OK, a proper wishlist bug report should be filed against the debbugs package. Only after this new feature is implemented in the BTS, I will be able to make use of it in apt-listbugs... Anyway, as said above, the simplest workaround
Re: Alioth status update, take 3
On Fri, 27 May 2011 21:58:30 +0200 Tollef Fog Heen wrote: ]] Francesco Poli | Could someone please confirm that pushing to | ssh://git.debian.org/git/apt-listbugs/apt-listbugs.git | should work as before and won't break anything? It should. Thank you very much for your kind confirmation. I've just pushed one commit and everything seems to have worked as it used to work before the alioth migration! :-) If you get errors from post-commit/post-push hooks about stuff not being installed or not working, tell us (the Alioth admins, ad...@alioth.debian.org) about it and we'll try to get it fixed. The commits mailing list (apt-listbugs-commits@l.a.d.o) received the e-mail message corresponding to the commit; I am not aware of any other post-commit/post-push hooks. I haven't seen any errors on stdout or stderr, while pushing with git (or should I look somewhere else?). I think everything went fine. | Could someone confirm that the host key is the one announced in | http://lists.debian.org/debian-devel-announce/2011/05/msg7.html | for vasks.debian.org? That should be correct, yes. I confirm! :-) Or you could grab it from the known hosts file on any debian.org host (or https://db.debian.org/machines.cgi) I am not a DD, hence I don't (think I) have access to any of those boxes... Anyway, the messages to debian-devel-announce@l.d.o were enough to check the fingerprints... Regards, Once again: thanks a lot for your kind reply! Bye. -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpM6KX6TC0lS.pgp Description: PGP signature
Re: Alioth status update, take 3
On Sat, 28 May 2011 18:23:50 +0200 Francesco Poli wrote: On Fri, 27 May 2011 21:58:30 +0200 Tollef Fog Heen wrote: [...] If you get errors from post-commit/post-push hooks about stuff not being installed or not working, tell us (the Alioth admins, ad...@alioth.debian.org) about it and we'll try to get it fixed. The commits mailing list (apt-listbugs-commits@l.a.d.o) received the e-mail message corresponding to the commit; I am not aware of any other post-commit/post-push hooks. I haven't seen any errors on stdout or stderr, while pushing with git (or should I look somewhere else?). I think everything went fine. Oops, I probably spoke too early. I received a bounce via e-mail! I am forwarding it to adminn@a.d.o ... -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp5QMmOWt6TJ.pgp Description: PGP signature
Re: Alioth status update, take 3
On Wed, 25 May 2011 00:17:46 +0200 Francesco Poli wrote: [...] I haven't yet tried to push to the following remote: ssh://git.debian.org/git/apt-listbugs/apt-listbugs.git which was what I used to push to. I am a bit uneasy in trying to push: would I break anything, if the URL were wrong? Can you confirm that this URL should work as before? With which host key? The one for vasks.debian.org, which was previously announced in http://lists.debian.org/debian-devel-announce/2011/05/msg7.html ? Sorry if I ask again, but I am getting a bit lost in trying to understand the current status of the post-migration alioth tuning/fixing... Could someone please confirm that pushing to ssh://git.debian.org/git/apt-listbugs/apt-listbugs.git should work as before and won't break anything? Could someone confirm that the host key is the one announced in http://lists.debian.org/debian-devel-announce/2011/05/msg7.html for vasks.debian.org? Thanks a lot to all alioth admins for their efforts! P.S.: Please remember to keep me in Cc on replies, since I am not subscribed to debian-devel. Thanks! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgp1b4ePkfzBi.pgp Description: PGP signature
Re: Alioth status update, take 3
On Tue, 24 May 2011 00:03:13 +0200 Stig Sandbeck Mathisen wrote: Francesco Poli invernom...@paranoici.org writes: I hope that some appropriate re-directions may be set up real soon now, so that previous URLs can continue to work as before... If you have a specific example of something that does not work, it can be fixed. Sure: $ grep '^Package\|^Vcs' debian/control Vcs-Git: git://git.debian.org/git/apt-listbugs/apt-listbugs.git Vcs-Browser: http://git.debian.org/?p=apt-listbugs/apt-listbugs.git Package: apt-listbugs $ cd ~/tmp/TEST/ $ git clone git://git.debian.org/git/apt-listbugs/apt-listbugs.git Cloning into apt-listbugs... git.debian.org[0: 217.196.43.140]: errno=Connection refused fatal: unable to connect a socket (Connection refused) The Vcs-Git URL has not worked as before for a while. Now it seems to work again: thanks for fixing this up! :-) The Vcs-Browser URL http://git.debian.org/?p=apt-listbugs/apt-listbugs.git seems to redirect to http://anonscm.debian.org/gitweb/?p=apt-listbugs/apt-listbugs.git when opened in a web browser. However the gitweb interface seems to have lost its fancy style sheet that used to be consistent with the Debian web site http://www.debian.org/ I haven't yet tried to push to the following remote: ssh://git.debian.org/git/apt-listbugs/apt-listbugs.git which was what I used to push to. I am a bit uneasy in trying to push: would I break anything, if the URL were wrong? Can you confirm that this URL should work as before? With which host key? The one for vasks.debian.org, which was previously announced in http://lists.debian.org/debian-devel-announce/2011/05/msg7.html ? -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpz8AC7aL300.pgp Description: PGP signature
Re: Alioth status update, take 3
On Mon, 23 May 2011 22:35:00 +0200 Roland Mas wrote: [...] Status update for the Alioth situation: [...] - read/write access to the repositories through SSH happen on vasks.debian.org; the repositories have adresses that look like $scm.debian.org/$scm/$project, for $scm in arch bzr cvs darcs git hg svn; - anonymous read-only access to the repositories is available by HTTP from wagner, at URLs that look like http://anonscm.debian.org/$scm/$project for $scm in arch bzr darcs git hg; - Git and Subversion also allow anonymous read-only access to the repositories through a dedicated protocol, with URLs such as git://anonscm.debian.org/$project/$project.git and svn://anonscm.debian.org/$project/; I can't seem to get the equivalent for CVS (pserver) to work right now; - repository browsers for the major SCM tools are also available from wagner, see http://anonscm.debian.org/ for the links. I apologize in advance if this is a naive question, but: does this mean that _all_ Vcs-* control fields in _all_ packages (that have them) have to be changed? Does this mean that _all_ existing personal repository clones (I am thinking about git repository clones, for instance) have to change their remote URLs (both for read-only access via specific protocol, such as git://, and for write access via ssh://)? I hope that some appropriate re-directions may be set up real soon now, so that previous URLs can continue to work as before... P.S.: Please keep me in Cc: on replies, since I am not subscribed to debian-devel. Thanks! -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpBxVaTB4vU5.pgp Description: PGP signature
Re: Bug#603711: ITP: ga -- Global Arrays Toolkit
On Tue, 16 Nov 2010 23:44:45 + brian m. carlson wrote: On Tue, Nov 16, 2010 at 06:35:30PM +0100, Michael Banck wrote: [...] - Other than as used herein, neither the name Battelle Memorial Institute or Battelle may be used in any form whatsoever without the express written consent of Battelle. I've CC'd debian-legal because of this last provision. It seems to restrict the ability to refer to the Battelle Memorial Institute in unrelated matters. For example, it would forbid me from writing a blog entry stating that Battelle is a non-profit headquartered in Columbus, Ohio, US. This is a reasonable (and otherwise legal) use of that name that this license pretends to restrict. I get the same impression. Hence, I agree that the above-quoted clause seems to be troublesome. I would strongly recommend upstream to adopt a well-known Free Software license. The one which seems to be closest to the current license is the 3-clause BSD license: http://www.debian.org/misc/bsd.license -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgptJi0i943rI.pgp Description: PGP signature
Bug#600879: RFH: apt-listbugs -- tool which lists critical bugs before each apt installation
Package: wnpp Severity: normal I request assistance with maintaining the apt-listbugs package. The other co-maintainer (Ryan Niebur) is currently almost MIA and finally told me that he no longer wants to be involved in apt-listbugs maintenance: see http://bugs.debian.org/588636 and http://git.debian.org/?p=apt-listbugs/apt-listbugs.git;a=commitdiff;h=b999e0ba2f3c03ee367e45d7e8de4abbfe892457 if you want to read the full story... I would say that the package is generally in a decent shape: it normally works as intended, lintian does not complain about it, its non-pending bug count is decreasing (see http://qa.debian.org/data/bts/graphs/a/apt-listbugs.png), I usually manage to deal with bug reports and go ahead with developing work by myself, ... However, I sometimes need help with Ruby (I am not yet the Ruby expert I would dream to be!) or with packaging techniques (I am still learning them!). Hence, I would like to find someone else who could co-maintain the package with me. The ideal candidate * has experience with the Ruby language * knows how to use Git * has Debian packaging experience * is willing to dedicate some time to this package (the amount of needed time is not big: I will mostly need some review of my work, and occasionally some help on stuff I am not too expert at) Bonus points if the candidate is a DD or a DM, since I have no upload rights (and hence I would need a sponsor for each upload, in the absence of a DD or DM co-maintainer). Thanks in advance to anyone who volunteers! The package description is: apt-listbugs is a tool which retrieves bug reports from the Debian Bug Tracking System and lists them. Especially, it is intended to be invoked before each upgrade/installation by apt in order to check whether the upgrade/installation is safe. . Many developers and users prefer the unstable version of Debian for its new features and packages. apt, the usual upgrade tool, can break your system by installing a buggy package. . apt-listbugs lists critical bug reports from the Debian Bug Tracking System. Run it before apt to see if an upgrade or installation is known to be unsafe. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101020213238.4689.51275.report...@homebrew
Re: Bug#508249: ITP: libio-pager-perl -- pipe output to a pager if destination is a TTY
On Tue, 9 Dec 2008 19:21:18 + brian m. carlson wrote: On Tue, Dec 09, 2008 at 11:19:42AM +0200, Damyan Ivanov wrote: * Package name: libio-pager-perl Version : 0.05 Upstream Author : Jerrad Pierce [EMAIL PROTECTED] * URL : http://search.cpan.org/dist/IO-Pager/ * License : other - Thou shalt not claim ownership of unmodified materials. - Thou shalt not claim whole ownership of modified materials. - Thou shalt grant the indemnity of the provider of materials. This may be a problem. I know in the past, clauses requiring indemnification were not allowed. CCing debian-legal for discussion. Please follow up there. - Thou shalt use and dispense freely without other restrictions. If those four Thou shalt sentences are the whole license text, I see other issues. There's no clear permission to distribute (DFSG#1): if dispense may be assumed to mean distribute, the fourth sentence sounds like an obligation, rather than like a grant of permission. Am I *compelled* to use and distribute libio-pager-perl?!? There's no clear permission to modify and distribute modified versions (DFSG#3). Moreover, the license text does not seem to be drafted in a legally sound manner... Is this package planned to be uploaded to main or contrib? Or is it meant for the non-free archive? As usual, my disclaimers apply: IANAL, TINLA, IANADD, TINASOTODP. P.S.: why are we refraining from Cc:ing the bug address? -- On some search engines, searching for my nickname AND nano-documents may lead you to my website... . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpr6HVE6yhLb.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Wed, 2 Jul 2008 00:13:06 -0700 Steve Langasek wrote: [...] The real issue is not that you were posting without disclaimers. The real issue is that you post to debian-legal with *content* that is inappropriate *because* you are not a lawyer or a Debian developer. When someone posts to debian-legal asking for help figuring out if a license is ok for Debian main, and you respond saying that it isn't because of license feature X; and you are well aware that the ftpmasters have previously and consciously accepted other licenses into main with that same feature, and have not been swayed by your arguments; that's not appropriate. When I am aware that the ftpmasters disagree with my own personal opinion, I try to explicitly acknowledge it. See, for instance: http://lists.debian.org/debian-legal/2008/03/msg00089.html I am not a spokesperson of the ftpmasters: I think I am allowed to contribute to this list with my own personal opinion, as long as it's clear that I am not claiming that my opinion is the official Debian position or ftpmasters' one. This list doesn't exist to serve as a soapbox for non-DDs to promote their own interpretations of the DFSG, it's here to help maintainers (and ftpmasters) figure out what packages Debian can distribute and in what section of the archive. The description of this list states: Discussions about legality issues such as copyrights, patents etc. If *only one* opinion (namely ftpmasters' one) is allowed, I cannot see what kind of 'discussions' can be held... Moreover, if the list is here to also help [...] ftpmasters [...] figure out what packages Debian can distribute and in what section of the archive, as you yourself state, then I cannot understand how this could be achieved by only reporting ftpmasters' opinions... Do we have to remind ftpmasters their own opinions?!? When you repeatedly push interpretations of the DFSG that you *know* are inconsistent with how the ftpmasters operate, that's an abuse of debian-legal, regardless of how many disclaimers you stick on the end of it. Frankly speaking, you seem to consider debian-legal as an address for ftpmasters' spokespersons. If you really believe debian-legal should only report ftpmasters' opinions, then you should propose that [EMAIL PROTECTED] becomes an alias for [EMAIL PROTECTED] ... At that point, nothing but ftpmasters' opinions would be given. I don't know how many answers would be given for the raised questions, though: ftpmasters don't seem to be much willing to explain their decisions. For instance, I explicitly asked for an explanation of the acceptance of CC-by-v3.0 in bug #431794, but ftpmasters' answer has been a deafening silence, so far... :-( -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpPNj5nkIybW.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Tue, 24 Jun 2008 18:19:49 +0200 Tollef Fog Heen wrote: * Francesco Poli [...] | If you modify a GPG public key, you obtain something that no longer | corresponds to the original private key (obviously). No, the most common modification done to a GPG public key is adding a signature to it in which case it still corresponds to the original private key. Fair enough. Even though adding a signature is more adding something to a work than modifying the existing work... Anyway, adding a signature does not require access to anything but the public key itself in the form in which it's normally distributed by keyservers. As a consequence, I would say the remainder of my previous reasoning still holds... -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpVEaMGYgYlE.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Mon, 23 Jun 2008 17:16:28 +0200 Joerg Jaspert wrote: On 11424 March 1977, Francesco Poli wrote: Important disclaimers: IANAL, TINLA, IANADD, TINASOTODP. Those are *totally* and absolutely unimportant and a waste to write. Could people please stop always writing them, its fairly clear by itself that debian-legal does NOT do any lawyers work (and whatever else people put into that crap). Its also absolutely unimportant if someone is a DD or not, it doesnt matter at all, as people are writing their own opinion about $stuff on the list, not that of Debian. I *used* to think that those disclaimers are implicit in most cases. But then, I was harshly accused of not making it clear enough that I am neither a lawyer, nor a Debian developer, that I'm not providing legal advice, and that I don't speak on behalf of the Debian Project. Other people were similarly attacked for the same reason. http://lists.debian.org/debian-legal/2006/10/msg00133.html http://lists.debian.org/debian-legal/2007/06/msg00014.html http://lists.debian.org/debian-legal/2007/06/msg00038.html http://lists.debian.org/debian-legal/2007/06/msg00092.html http://lists.debian.org/debian-legal/2007/06/msg00106.html http://lists.debian.org/debian-legal/2007/06/msg00222.html http://lists.debian.org/debian-legal/2007/06/msg00278.html http://lists.debian.org/debian-legal/2007/07/msg00062.html http://lists.debian.org/debian-legal/2007/07/msg00215.html As a consequence I began adding the disclaimers to my messages, in order to explicitly remind readers about the above facts. Now, you say that those disclaimers are a waste of time... I'm really puzzled. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp9sxzgrYHrn.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Mon, 23 Jun 2008 18:15:16 +0200 Arnoud Engelfriet wrote: Ken Arromdee wrote: On Sun, 22 Jun 2008, Francesco Poli wrote: OK, that said, if you wanted to modify a public key (in order to obtain something else), what form would you use for making modifications? I think the preferred form would be the one in which the GPG public key is distributed by keyservers or some other equivalent form (which may be losslessly obtained from the distribution form). Wouldn't the preferred form for modification be the number that's used to generate both the private and public key? No, that would be the preferred form for compromising the key! ;-) Seriously, if I want to alter the public key, I don't think I need the corresponding secret key. A public key consists of some numbers, and so does the secret key. Those two sets of numbers are somewhat correlated, but I don't need one set in order to alter some numbers in the other set... I don't think that modifying has any reasonable meaning when talking about cryptographic keys. Why not? Original public key: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.6 (GNU/Linux) mQGiBWDHQR[...]9U/rG7P6VAgfYkUYnkueiQ== =AGXn -END PGP PUBLIC KEY BLOCK- Modified work: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.6 (GNU/Linux) XQGiBWDHQm[...]9U/rG7P6VAgfYkUYnkueiQ== =AGXn -END PGP PUBLIC KEY BLOCK- Please note that I changed two characters. Maybe it's no longer a public key, but who cares? It was a public key, it has been modified... A key is a number, or a set of numbers in the case of public-key cryptography. How do you modify a number? By performing operations on it. 5454 may be modified into 5457 by adding 3. Or into 2727 by dividing by 2. As an aside, this is just what computers do all the time: they process numbers in order to compute other numbers, and so on... P.S.: now what should I do? to add disclaimers or not to add disclaimers? this is the question! ;-) -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp6OM0ePMjFx.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Mon, 23 Jun 2008 11:43:25 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: [...] But then, I was harshly accused of not making it clear enough that I am neither a lawyer, nor a Debian developer, that I'm not providing legal advice, and that I don't speak on behalf of the Debian Project. Other people were similarly attacked for the same reason. http://lists.debian.org/debian-legal/2006/10/msg00133.html http://lists.debian.org/debian-legal/2007/06/msg00014.html http://lists.debian.org/debian-legal/2007/06/msg00038.html http://lists.debian.org/debian-legal/2007/06/msg00092.html http://lists.debian.org/debian-legal/2007/06/msg00106.html http://lists.debian.org/debian-legal/2007/06/msg00222.html http://lists.debian.org/debian-legal/2007/06/msg00278.html http://lists.debian.org/debian-legal/2007/07/msg00062.html http://lists.debian.org/debian-legal/2007/07/msg00215.html Note that all of these complaints were made by the same person: Anthony Towns. There were some other people who seemed to more or less agree with Anthony Towns. But he was certainly the loudest one complaining about this. That's why the messages I was able to found out in a hurry were his ones: I didn't manage to dig the few from other people... Since Anthony used to hold a number of positions of authority in Debian, including ftpmaster and DPL, I think that Francesco's response was not irrational. Since a current ftpmaster has explicitly said that these notices are no longer necessary, Francesco can probably relent. I am not sure: adding those acronyms is not a big deal and they use (or waste!) really few bits. They seem to succeed in stopping the complaints, so maybe they are not completely useless. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpkGAtRvNQrr.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Mon, 23 Jun 2008 22:31:02 +0200 Arnoud Engelfriet wrote: Francesco Poli wrote: On Mon, 23 Jun 2008 18:15:16 +0200 Arnoud Engelfriet wrote: I don't think that modifying has any reasonable meaning when talking about cryptographic keys. Why not? Because it implies that you'd obtain something meaningful after the modification. The intent of the right to modify is that you can do something meaningful with the work. Never underestimate the unexpected results you can obtain by giving some permission to unknown people! ;-) I mean: just because you cannot think of any meaningful modifications, it does not mean that nobody will ever come up with some. Maybe someone will turn your public key into some sort of ASCII art! Or who knows what? [...] I do not see any meaningful modification I can do with someone's key block. 5454 may be modified into 5457 by adding 3. Or into 2727 by dividing by 2. Well, if that's what you want, then the key block is source enough for the purpose. Exactly. I just don't understand the point. It gets much more interesting if you want to modify, say, the name and e-mail address in an informational field in the key block. I suppose you can do that without access to the secret key. Of course at that point you would break the self-signature: at least I hope so, otherwise forging a fake public key would be too easy! ;-) -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpn1gFxXeqMD.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sun, 22 Jun 2008 12:54:09 -0600 Wesley J. Landaker wrote: [...] Actually, how are debian-keyring and debian-archive-keyring free-software, anyway? Do I get source code for the all GPG keys they contain? The most widely accepted definition of source code is the one found in the GNU GPL: the preferred form for making modifications to the work. If you modify a GPG public key, you obtain something that no longer corresponds to the original private key (obviously). You could end up with a different GPG public key or with something that is no longer a GPG public key. OK, that said, if you wanted to modify a public key (in order to obtain something else), what form would you use for making modifications? I think the preferred form would be the one in which the GPG public key is distributed by keyservers or some other equivalent form (which may be losslessly obtained from the distribution form). Hence, if I understand correctly, I think the Debian package does provide source. The /usr/share/doc/debian-keyring/copyright even says The keys in the keyrings don't fall under any copyright. Ops! This could be true, to the extent that the key generation process does not involve any creative input. However, I've seen GPG key pairs generated in such a way that the ascii-armored public key embeds readable text provided by the user. In those cases, the readable text could be creative enough to be copyrighted by its author... Moreover, GPG public keys may be accompanied by photo-ids (small images that represent photo portraits of the key owner): those photo-ids, if present, may constitute other copyrighted material... Important disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpl4UmqnbD1W.pgp Description: PGP signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Wed, 6 Jun 2007 00:55:43 +1000 Anthony Towns wrote: On Mon, Jun 04, 2007 at 07:55:18PM +0200, Francesco Poli wrote: On Mon, 4 Jun 2007 19:30:36 +1000 Anthony Towns wrote: And I mean, I know what a GR is for, why are you telling me? It's still not a *good solution* for deciding these things; it's a last resort, and the only other options we currently have a ftpmaster decides and it's obvious to pretty much everybody. I'm rather surprised to hear you saying that, since you seem to have been the proposer of GR-2006-001... Sometimes you have to choose the best of a lot of bad options. When that happens, it's often good to spend some time trying to get better options for the future. Could you please elaborate? I'm not sure I understand correctly: are you saying that you are unhappy with how GR-2006-001 worked out and that you are looking for better strategies for similar situations? -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpOdkyAGBSE6.pgp Description: PGP signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, 4 Jun 2007 20:53:11 +1000 Anthony Towns wrote: [...] To expand on that a bit more: IMHO, Debian is fundamentally about what its contributors want -- we're focussed on doing right by our users and the free software community, but ultimately, as far as Debian's concerned, the first and foremost representatives of both those groups are the users and free software community members who actually make Debian work. It seems you are implying that analyzing licenses and spending time to reply to questions sent to debian-legal is *not* a contribution to the Debian Project. If you really think that participating to debian-legal is not a contribution to the Debian Project, then please have a GR to abolish this list, so that I can stop wasting my time in dissecting issues and providing analyses that will get ignored by decision-makers. I used to be happy with the Debian Project having a transparent and open license analysis process, but it seems that this is just hypocrisy: the real decisions about which packages are acceptable for main are taken by a few people who seem to deliberately ignore any advice from debian-legal. Just like the FSF and OSI, who accept or reject licenses behind closed doors, without any real public explanation of the rationale... Your attitude towards debian-legal participants and towards non-DDs is rather insulting and does not encourage me to consider the idea of applying for the NM process. [...] And when analysis of licenses tends to amount to not much more than we've discussed this issue already, it's not free there's not much point to the debate at all, afaics. On the contrary, you could read the archived discussions and explain why you think the arguments made are invalid. I think there's not much point in repeating arguments that have already been made in the past (and are publicly archived for future reference), unless new data or counter-arguments are provided. But if no one on -legal sees what I'm trying to get at by now, I guess there's not much point to this debate either. Frankly speaking, it seems to me that you are trying to persuade debian-legal regulars to act as yes men who blindly follow what the majority of the open source community does. Hence, it seems you're trying to make debian-legal become pointless and useless. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp8eBREqCXYU.pgp Description: PGP signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, 4 Jun 2007 20:01:24 +1000 Anthony Towns wrote: [...] What I care about is having a reasonable, widely understood definition of free software that meshes with the rest of the free software and open source community, that Debian can use to work out what software we'll distribute in main. Then, I think you have to start by reconciling the open source community with the free software community: OSI and FSF already have a non-negligibly different set of accepted licenses. *Red Warning* This message is from a non-DD, non-maintainer and non-applicant. As a consequence, everything I say has to be checked and double-checked. Debian developers, instead, know the truth by definition and never say anything wrong: hence, no need to check what a DD says. Seriously, could you please stop this discrimination against non-DDs? I think Debian users should have the right to express their opinions and arguments on Debian lists: whatever they say should be considered for its merits, just like it should be done for Debian developers. It's not that users are second-class citizens or Harijans: after all the Debian Social Contract is a promise made by Debian developers to the Free Software Community (which, IMO, includes free software users). -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpa962MPShRu.pgp Description: PGP signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, 4 Jun 2007 19:30:36 +1000 Anthony Towns wrote: [...] And I mean, I know what a GR is for, why are you telling me? It's still not a *good solution* for deciding these things; it's a last resort, and the only other options we currently have a ftpmaster decides and it's obvious to pretty much everybody. I'm rather surprised to hear you saying that, since you seem to have been the proposer of GR-2006-001... [...] The official position of Debian is what we allow in main. That is to say? Bugs never happen?!? Nothing can possibly enter main by mistake or overlook?!? [...] Unfortunately, since -legal in general becomes an amorphous set of individuals who reserve the right to hold whatever opinions they like whenever questioned, there's little hope of -legal ever learning from its mistakes. Are you going to call the orwellian thought police, since I hold my *own* opinions?!? -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpFcSwbFQLaj.pgp Description: PGP signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sun, 3 Jun 2007 21:46:30 +0200 Wouter Verhelst wrote: [...] If it isn't, then the GPL is also non-free, by the very same rationale: the fact that you are required to produce source when so asked if you do distribute binaries from source under the GPL means that you are giving up a right (the right not to distribute any source) which you might otherwise have, which could be considered to be a fee. This argument is flawed. You're *not* giving up the right not to distribute any source, because you can always refrain from distributing the corresponding binaries and have no obligation to provide source. You're *not* giving up the right to distribute binaries without distributing the corresponding source, because, without a license, you would not have the right to distribute binaries in the first place (with or without source). By accepting the GPL, you instead gain the right to distribute binaries with source, and you simply do *not* gain the right to distribute binaries without source. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpEfeNTd2JPp.pgp Description: PGP signature
Re: Creative Commons 3.0 Attribution license
On Thu, 31 May 2007 18:47:37 +0200 Miriam Ruiz wrote: Hi, I plan to file an ITP and package a cute small game [...] All the game code is licensed under the GPL 2.0. Good. All the game content, sounds and graphics are licensed under Creative Commons 3.0 Attribution license ( http://creativecommons.org/licenses/by/3.0/ ). Ouch! :-( As I understand, CC-by 3.0 is DFSG-free. My personal opinion is that *none* of CC-v3.0 licenses meets the DFSG. They are *not* acceptable, IMO. See http://lists.debian.org/debian-legal/2007/03/msg00024.html http://lists.debian.org/debian-legal/2007/03/msg00023.html http://lists.debian.org/debian-legal/2007/02/msg00059.html and the threads that followed. The only potentially DFSG-freeness problem I can see is the DRM limitation, and then again GNU FDL also has it and is perfectly DFSG according to the last GR about it. I see other DFSG-freeness issues in CC-v3.0 licenses besides the anti-DRM clause, but anyway GR-2006-001 (http://www.debian.org/vote/2006/vote_001) did *not* decide anything about CC licenses, nor about license clauses in general. The decision taken by GR-2006-001 was just about the GFDL, which was (absurdly, IMO) judged acceptable (when no part of the work is unmodifiable/unremovable), without explaining why. Anyway, I prefer to ask about it first: Does anyone know if CC-by 3.0 is DFSG-free or not for sure, shall I go ahead and put it in the repositories? I personally think CC-v3.0 licensed works should *not* enter Debian main. IANADD, IANAL. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpPOi21E3FA3.pgp Description: PGP signature
Re: Sun Java available from non-free
On Mon, 22 May 2006 19:13:47 -0700 Russ Allbery wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: [...] Thie simplest solution in this case would be if Sun simply attached the FAQ as an addendum to the licence rather than stating it's not legally binding. Yeah. Not disagreeing there. Mmmh, we would end up with a contradictory license if Sun did this, because the FAQ seems to be inconsistent with the current license. Hence, no, I don't think attaching the FAQ to the license would be a good solution. The license itself should be rephrased in order to actually say what Sun meant. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpLlvKBm8keC.pgp Description: PGP signature
Re: Sun Java available from non-free
On Sun, 21 May 2006 15:55:53 -0700 Steve Langasek wrote: They didn't ask you because Debian is not a democracy and random opinions on this decision *don't* matter. What is it, then? A constitutional monarchy? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpmyX1OSsAyo.pgp Description: PGP signature
Re: Sun Java available from non-free
Marble has begun responding to concerns raised on -legal [0] and I would strongly encourage folks to work with him and other Sun folks in a positive and constructive manner so that we can further encourage Sun's current forays into the free software world, hopefully resulting in them immersing themselves completely, eventually. I really hope we can solve the issues in a graceful manner. Even better, I hope that Sun Java can become DFSG-free as quickly as possible, thus greatly improving its acceptance among the Free Software community and consequently enhancing the level of feedback and contributions that Sun can get from this cooperation. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpwggCYrflws.pgp Description: PGP signature
Re: Sun Java available from non-free
On Wed, 17 May 2006 23:09:30 -0700 Don Armstrong wrote: Executive Summary: [...] I'd recommend that ftp-masters consider pulling this package from non-free until these issues are resolved (or at least understood.) Agreed. [...] 2. License Grant. Subject to the terms and conditions of this Agreement, [...] provided that: (a) the Software and any proprietary legends or notices are complete and unmodified; This seems to cause a problem with actually packaging the software unless the Debian package counts as the Software... this seems to mean that any time that the package should be changed the maintainers need Sun to actually distribute the software to them (or otherwise grant them the ability to modify the software.) You're right: this is another major issue. (b) the Software is distributed with your Operating System, and such distribution is solely for the purposes of running Programs under the control of your Operating System and designing, developing and testing Programs to be run under the control of your Operating System; non-free is not part of Debian so we definetly don't distribute it as part of the Operating system. Right! I hadn't noticed this point before. I hereby retract my statement about 2(b) not being violated by Debian. It seems that the Debian Project is indeed violating this clause too. (c) you do not combine, configure or distribute the Software to run in conjunction with any additional software that implements the same or similar functionality or APIs as the Software; This means that we can't distribute eclispse or anything else which implements part of the Java API (or if you're going to read this clause as broadly as possible,[1] things like perl which implement similar functionality in that perl is an implementation of a cross platform language Perl.) Exactly. (d) you do not remove or modify any included license agreement or impede or prevent it from displaying and requiring acceptance; We may need to modify debconf preseeding to make sure that the user can't prevent the agreement from being shown... And that's another problem, thanks for catching it up. (f) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from (i) the use or distribution of your Operating System, or any part thereof, in any manner, or (ii) your use or distribution of the Software in violation of the terms of this Agreement or applicable law. I'm really not entirely sure what this clause is getting at, but it seems that the intention is that Debian needs to indemnify Sun for any litigation resulting by users of the package of Sun's JDK which Debian has distributed, even if Sun is grossly negligent.[2] Maybe... 4. COMPATIBILITY. If you exercise the license in Section 2, and Sun or a licensee of the Software (under section 4(b)) notifies you that there are compatibility issues [...] caused by the interaction of the Software with your Operating System, then within ninety (90) days you must either: (a) modify the Operating System in a way that resolves the compatibility issue (as determined by Sun) and make a patch or replacement version available [...] Oh, right... so if the Sun JDK is buggy, we have to modify our operating system to make it unbuggy in some way that makes Sun happy. Makes sense to me. [...] As I already said, we are in chains... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpf3FXlUc6lH.pgp Description: PGP signature
Re: Sun Java available from non-free
On Wed, 17 May 2006 11:01:26 +0200 Michael Meskes wrote: On Wed, May 17, 2006 at 08:20:14AM +0200, Jeroen van Wolffelaar wrote: Official packages of Sun Java are now available from the non-free section of Debian unstable, thanks to Sun releasing[11 Java under a new license: the Operating System Distributor License for Java (DLJ)[2][3]. This license, while still non-free, allows the Sun Java Runtime Environment (JRE) or Java Development Kit (JDK) to be distributed by Debian, with our own packaging. [...] I couldn't find ANY discussion about the license on Debian legal which surprises me a little bit, [...] How could a package under such a license be distributed by the Debian Project without even a little check with debian-legal? Does anyone think that this license is (trivially) suitable for non-free? I certainly don't. I'm really disappointed: what's the use of spending time on debian-legal, when the Project seems to ignore us? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpcsKlWN3hSX.pgp Description: PGP signature
Re: Sun Java available from non-free
On Wed, 17 May 2006 12:02:34 + Brian M. Carlson wrote: [For -legal people, the license is attached.] Thanks. [...] Also, section 4 poses a major issue. If, for any reason, the Linux kernel doesn't do something that Java requires, then we are obligated to either fix it or inform everyone who has acquired Java from us. Indeed, it seems we are in chains: whenever Sun decides that we should do it, we are bound to modifying the Debian System to satisfy their requirements and/or notifying the world about the issue. Section 10 is not possible with our infrastructure. The ftp-master scripts merely remove the package from the tag database, not the archive (at least until there are no dependencies), and not from all of our mirrors. It seems that you're right. Section 2(b) prohibits allowing people to develop software with Java that is to be run on another system. Yes, a fairly strong restriction, but not something that gets violated by the Debian Project. Users of non-free are anyway warned and advised to read licenses in order to evaluate (on a case-by-case basis) whether they can (and want to) use a package. Section 2(c) prohibits us from using the software in conjunction with C, C++, Perl, Python, or *any reasonable Turing-complete programming language*. Worse: it seems that it prohibits combining, configuring and *distributing* the Software to run in conjunction with any similar compiler. Hence it seems that the Debian Project is already violating the license, by distributing all the other DKs (such as GCC, Python, Perl, ...)! Section 12 requires that this software be in non-US/non-free. It is not, which is not only a violation of the license, but a violation of United States law. I'm not sure: | 12. Export Regulations. All Software and technical data delivered |under this Agreement are subject to US export control laws and may |be subject to export or import regulations in other countries. This seems to be a statement about facts. It may be that US export control laws don't restrict the export of the Software: if this is the case, stating that it's subject to export cotrol laws does not seem to hurt. Or am I wrong? |You acknowledge that you have the responsibility to obtain such |licenses to export, re-export, or import as may be required after |delivery to you. Please note the may be required: if no export license is required, then I'm fine (even when I acknowledged that I have the responsibility of obtaining any required export license). Is that right? This conflicts with other project policies and exposes Debian/SPI to major legal liabilities. I think that this should be removed from the archive as soon as possible, preferably before the next mirror pulse. I agree. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpeQWkYlSh4r.pgp Description: PGP signature
Re: Sun Java available from non-free
On Wed, 17 May 2006 22:56:06 +0100 Thiemo Seufer wrote: Francesco Poli wrote: On Wed, 17 May 2006 12:02:34 + Brian M. Carlson wrote: [For -legal people, the license is attached.] Thanks. [...] Also, section 4 poses a major issue. If, for any reason, the Linux kernel doesn't do something that Java requires, then we are obligated to either fix it or inform everyone who has acquired Java from us. Indeed, it seems we are in chains: whenever Sun decides that we should do it, we are bound to modifying the Debian System to satisfy their requirements and/or notifying the world about the issue. Or stop distributing, which terminates the license immediately. Yes, I should have been clearer... There are two options, if Sun decides that the Debian System is an Incompatible Operating System: (a) modify Debian until Sun is satisfied and release an update (b) stop distributing Sun Java and notify Licensees -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpOLluZSVfAl.pgp Description: PGP signature
Re: Licenses for DebConf6
On Mon, 14 Nov 2005 23:17:06 +1000 Anthony Towns wrote: Well, it's not an inaccurate description (I think), but you would use such a definition only if you think that charity is a stupid thing to do... So, if I'm parsing you right, you're saying that a person (such as myself) would only describe free software as giving up rights (such as I did) only if that person (me) thought that free software was a stupid thing to do? If that's not what you're trying to say, would you kindly look back over your argument, and retract the error? I said resembles to, which is not is equal to. My example about charity intentionally amplified the situation to make it clearer (I was hoping...). If it confused things further, I apology. Investment with no return seems (at least to me, YMMV) a stronger phrase than giving up rights. As a consequence, I didn't mean to say that you think that free software is a stupid thing to do. Just that you (well, Henning, IIRC) seemed to want to discourage people to license in a DFSG-free manner by calling it in a way that makes it appear as something better avoiding. Again, I'm not an English native speaker. Apologies if sometimes I do not choose words well enough... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpSRINepiOVt.pgp Description: PGP signature
Re: Licenses for DebConf6
On Sun, 13 Nov 2005 11:28:41 +1000 Anthony Towns wrote: On Sat, Nov 12, 2005 at 07:26:55PM +0100, Francesco Poli wrote: [...] I disagree with your calling licensing in a DFSG-free manner as giving up rights: this seems to imply that releasing DFSG-free works is something wrong or inappropriate. Uh, licensing in a DFSG-free manner *is* giving up rights. Of course it is. Maybe I didn't explain myself clearly enough, my apologies. What I meant is that using that description is suitable if you want to depict licening in a DFSG-free manner as something wrong that people should *avoid*. It resembles describing charity as investment with no return. Well, it's not an inaccurate description (I think), but you would use such a definition only if you think that charity is a stupid thing to do... [...] We shouldn't forget what an enormous act of generosity that is. Indeed, it really is. And Debian would not exist without numerous acts of generosity by many many people around the planet. Thinking that should remind everyone that giving back to the community should be considered a good thing to do, everytime it is possible... [...] If a paper/presentation/handout is interesting enough (I hope every author thinks his/her is, otherwise he/she would not give a talk at DebConf!), someone could modify it (in order to update it, improve it, translate it into another spoken language, ...) and reuse it (to give a talk in another conference, or to build a useful HOWTO, or whatever...). This mechanism would enable further spreading of good documentation on the subjects we care of. Sure -- and all those things are possible with certain classes of non-DFSG-free licenses too. Possible? Yes, but with non-free constraints and conditions that make it less likely to happen. Personally I would not spend time to create a derivative of a GFDL'd or CC-by-nc-sa'd work. The conditions to be complied with are too demanding, IMO. You might as well have said If a paper is interesting enough, someone might want to include it in Debian -- in which case I'd have to demur; I don't think my debbugs paper should be included in Debian, because as interesting as it is, it's stuck in a particular time, that, four months after the fact, is already obsolete. As far as good documentation goes, updating the inline documentation in the code would be much more valuable. OTOH, if someone wants to do that, and has an actual use for content from my paper (which seems unlikely to me), I'd be happy to bless that work under the debbugs license. So why didn't you license it in a DFSG-free manner in the first place, if you are ready to relicense upon request? Time is precious, you know: many people could be interested to build upon your paper, but be `scared' away by the license and be too busy (or shy) to try to persuade you to relicense. Maybe there are people that did so: you will never know... One of the strengths of free software is allowing unexpected and surprising uses and modifications of one's work. Think for a second about Linux. Linus Torvalds started it as a little personal project (IIRC, he initially described it by saying that it would never going to be something serious...). In that context a non-commercial license (similar to the old Minix one) could make sense. Imagine how the history could be different from the one we know, if Linus had chosen such a restrictive license... Fortunately he chose the GPLv2. [...] As a counter example, debconf5 went pretty well without those permissions. Pretty well from many points of view, but not if you count the number of DFSG-free works that were produced for the conference... Very few people chose DFSG-free licenses. What activities would you want to undertake that have been specifically blocked by the dc5 paper licensing? I don't know. I haven't even had much time to _read_ the papers. But, as I explained above: expect the unexpected... [...] Many typos and mistakes may be fixed. Some parts may be improved. Some parts may be updated, as time goes on. What is born as a paper, can become (part of) a HOWTO or similar document. Certainly this will never happen, if no permission to modify is granted. That would be the case if relicensing were impossible, but, well, it is. So your ideal situation is: everyone choses non-free licenses and then is got in touch with, asked to relicense and, after a long discussion, re-releases the paper in a DFSG-free manner. Remember that each author would need a separate (possibly) long discussion. I still think it's much simpler to get DFSG-free papers in the first place... [...] Huh? Papers are generally written *before* the conference takes place, not *after* (or does DebConf work the other way around?). How can papers talk about what happened at the conference? In the same way that astronomers can tell you that an eclipse is going to happen on a certain day at a certain time? They're
Re: Licenses for DebConf6
On Fri, 11 Nov 2005 22:30:52 -0600 Manoj Srivastava wrote: On Sat, 12 Nov 2005 10:46:24 +1000, Anthony Towns aj@azure.humbug.org.au said: [...] I don't believe I've seen anyone debate my use of the (aiui) non-DFSG-free CC ShareAlike/Attrib clause on my debbugs paper this year. I did it, last july on debian-legal[1]. I was willing to get in touch with you (=Anthony) and try to convince you to relicense the paper in a DFSG-free manner, but haven't yet found the time to do so... I was not aware that you were soliciting opinions. If you are, I find it deplorable. I saw no benefit in sharing my opinion after the fact, but am perfectly willing to do so if you think my rectitude was implicit approval. [...] and the advocacy and arguments about the DFSG are more likely to have a long term effect than the license on any paper presented at a conference. Any advocacy of the DFSG by an organization that happily accepts non-free licenses when it is convenient, smacks so much of hypocrisy to be unpersuasive. But that is just my opinion. It's my opinion, as well. That is exactly what I meant when I talked about acting consistently with our philosophy in my reply[2] to Andreas Schuldei (earlier in this thread). [1] Message-Id: [EMAIL PROTECTED] [2] Message-Id: [EMAIL PROTECTED] -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpFjISHdE7aF.pgp Description: PGP signature
Re: Licenses for DebConf6
their computing needs depend on the software. On the other hand papers at a conference just serve to document what happened at the conference, and this will never change until time machines are invented. Huh? Papers are generally written *before* the conference takes place, not *after* (or does DebConf work the other way around?). How can papers talk about what happened at the conference? I would say this will never be the case, until time machines are invented. None of the (few) DebConf5 papers I (have so far found the time to) read talks about what happened at the conference. They rather document changes in the Debian infrastructure, present new programs, teach something, and so forth... I don't see how _anyone_ are better served by having an empty slot in the conference instead of a paper, simply because the paper is not modifiable. If you see how users are better served by having a non-free package moved out of main and possibly not distributed at all by the Debian infrastructure (e.g.: Sun's Java), maybe you can catch the analogy... The valid analogy with the way we handle our OS would be to collect all papers without DFSG-free licenses in separate sessions at the conference, not to kick them out of it completely. It would be a significant step forward. At least authors would find themselves asking I'm in non-free? Why? Isn't my license OK? and some of them could be more easily persuaded to change their mind... But I honestly cannot see who that would help: The distinction between main and non-free in the OS serves to help people make decisions about which software to base their systems on, but who would make decisions about which presentation to _hear_ based on whether the _paper_ can be modified? I would certainly make decisions about which paper to _read_ based on whether the _paper_ itself is DFSG-free[1]. I've already done that with DebConf5 (you know, spare time is not very abundant here and I tend to consider time spent on free works as better spent). [1] before you call me crazy: not only on that, of course. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpvQBHMadbaM.pgp Description: PGP signature
Re: Licenses for DebConf6
On Fri, 11 Nov 2005 15:26:58 +1000 Anthony Towns wrote: On Thu, Nov 10, 2005 at 07:49:36PM -0500, Glenn Maynard wrote: FYI, a possible response might be: we care about freeness, but we pick our battle, and our battle is Debian main. I care about starving children, but I don't donate the majority of every check to feed them: there are lots of good causes, and the fact that everybody has to pick and choose their causes doesn't mean people don't care enough. (That said, I don't agree with that response: it should be no big deal for people to freely license their papers, so they can be packaged later in Debian. This isn't a big, difficult fight.) Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? I wish it were obvious to everyone, but apparently it's not. Otherwise there would not be so much non-free documentation around and we would not have to deal with its (wrong) presence in Debian main... Try to think what it would mean to Debian, if your above-quoted don't fight philosophy were applied to the Debian distribution. There would be no separate sections of the archive (main, contrib, and non-free would be all merged in one melting pot of works): there are already many GNU/Linux distros that do so... Fortunately Debian is different. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp8gxPUNgnZ7.pgp Description: PGP signature
Re: Licenses for DebConf6
On Thu, 10 Nov 2005 13:02:22 +0100 Henning Makholm wrote: [I tried to crosspost this between -legal and -devel, but apparently it never arrived on -legal. Resending...] Thanks. Scripsit Francesco Poli [EMAIL PROTECTED] Don't you agree that seeing non-free or even undistributable (no license means All Rights Reserved, with current laws!) papers at a DebConf is really a shame? I don't. Remember that non-free != evil, and that some of the arguments why free software is a good thing do not apply to expositions of scholary work or other conference contributions. IMHO, papers to be presented at a conference are documents (often pieces of documentation) that can (technically) be read, studied, adapted, copied, redistributed and improved by other people. In a manner much similar to computer programs. I think that /legally/ allowing the above operations is a good thing for both programs and papers (and many other works of authorship). Are we restarting the documentation is (not) software discussion? Again? I hope we are not... ;-) People who think that intellectual property is in and of itself an evil concept are free to license their contributions liberally. I don't think that (all) free software developers see intellectual property in and of itself as an evil concept. However, I would rather avoid the term intellectual property... But on the other hand, people who like free software for pragmatic reasons related to its being, well, software should not be forced to give away more rights than practically necessary for making the conference work. Most of those pragmatic reasons apply to conference papers too, IMHO. Anyway, nobody is forced to give a talk at DebConf6, hence nobody would be forced to publish a DebConf paper in a DFSG-free manner (even if my suggestion were accepted). I mean: some constraints *need* to be put for a DebConf anyway. For instance non-exclusive publication rights are already required. Moreover the topic of the paper cannot be arbitrarily chosen: would you accept a paper about the proprietary Microsoft tools used to deploy a Microsoft network? or about medieval history? What I suggest is just adding another (good, IMHO) constraint. For example, it is common not to want to allow derived works for conference papers. It is also common to require high fees for attending international congresses and conferences. DebConf is not doing this, though (fortunately: a big thanks to all the sponsors!). It is also common not to want to allow derived works for computer programs (see e.g. Microsoft, Sun Microsystems, Apple, Oracle, ...). Debian developers do not contribute to Debian this way, though. That does not conflict with the SC, because the papers are not going to be part of our operating system. I'm perfectly aware that we are not talking about SC violations. But complying with the SC is not the *only* good thing that DDs can do... :-) Moreover, I don't see a good reason to consider packaging DebConf papers for inclusion in Debian as an absurd idea. It could be done and could be useful. After all, we currently have several Linux Gazette issues in (sarge's) main: they have licensing problems, but if they hadn't any, I would have nothing against their presence in main. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpQygxemupEi.pgp Description: PGP signature
Re: Licenses for DebConf6
On Thu, 10 Nov 2005 12:25:11 +0100 Henning Makholm wrote: Scripsit Francesco Poli [EMAIL PROTECTED] That's why I consider this issue as an important one: every DebConf is an event through which we get public attention and can thus spread our philosophy. The message really works better if we act consistently with our philosophy, IMHO. We do not have a philosophy that says that everything ought to be DFSG-free. Do you think that a DebConf with more non-free papers and less DFSG-free ones would be a better conference? We have a philosophy that says that we only distribute things in main if they are DFSG-free. That is a different thing. I know, but why do we accept things in main only if they are DFSG-free? For a dogmatic adherence to rules written by others? Or rather for reasons that we consider as good ones and that lead to the rules detailed in the SC? I think the same reasons lead to think that papers should be accepted at a DebConf only if they are DFSG-free. Just like a Debian package doesn't enter main, until it meets Policy requirements (DFSG-freeness being one of them). DebConf papers will not be distributed in main. They are not, currently. That's why I said like and haven't filed any serious bug against the non-existent debconf-papers package... However, for the future, who knows? Someone could ITP some papers, maybe. At that point only the DFSG-free ones will be able to go in main. It will be better, if there are more of them. Actually the C4P already requires some permissions from the authors: | Debconf requires non-exclusive publication rights to papers, | presentations, and any additional handouts or audio/visual | materials used in conjunction with the presentation. And this requirement would be a no-op under your theory that a DFSG-free license for the papers is required. Therefore I conclude that your theory is wrong. Which theory? Mine is a suggestion, not a theory. If it's accepted, the C4P will obviously be modified and will drop the non-exclusive publication rights requirement (as it is actually implied by the DFSG-compliance requirement that I'm suggesting). What I suggest is simply adding one further condition. For the record, I oppose this suggestion. I cannot fully understand why, but I take note of it. Are you concerned that less papers would be submitted to DebConf6 with such a rule? In case you are: why aren't you similarly concerned that less packages will be distributed in main, if we care too much about Freeness issues? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpFpEKqbvRNG.pgp Description: PGP signature
Re: Licenses for DebConf6 [was: Re: DebConf6: Call For Papers]
[replying to a message that was directed to debian-devel only, but readding debian-legal in Cc:] On Tue, 8 Nov 2005 09:38:07 +0100 Andreas Schuldei wrote: * Francesco Poli [EMAIL PROTECTED] [2005-11-08 00:28:07]: The authors have the freedom to pick a DFSG-free license means that they *may* do so, but are not required to. Am I correct? IMHO, DebConf paper authors should be *required* to publish in a DFSG-free manner, as a condition for presenting at the conference. Don't you agree that seeing non-free or even undistributable (no license means All Rights Reserved, with current laws!) papers at a DebConf is really a shame? given your knowledge level of how debconf intents to handle things and the way you escalate this issue gives me the idea that you mainly want to raise a stink and create unrest. First of all, it is *not at all* my intention to raise stinks or create unrest. If I gave the impression of being rude, I apologize: I didn't want to. I am not an English native speaker, hence I may have chosen the wrong words or style when drafting my message; moreover I may have misunderstood something when reading the C4P (Call For Papers). So please inform yourself properly first. I visited http://debconf.org/ and failed to find any other relevant information about paper licensing, apart from the C4P itself. If you can point me to some URL where I can get first-hand info about how DebConf organizers plan to handle this kind of things, I would appreciate it. that might include to take up the issue in a friendly way with someone who is involved I think you are involved (!) and I did raise this issue with you privately (end of last August), but unfortunately the thread died out... Now your C4P for DebConf6 reminded me of the issue, so I went through it as carefully as I could searching for any indication on how it was handled. I found the above-quoted sentence (The authors have the freedom to pick a DFSG-free license) and felt it was not clear enough (again I am not an English native speaker, but many many people are not either). That is why I asked for clarification and, in case the sentence means what I'm afraid it does, I suggested a different policy... As to the friendliness, I tried hard to be as polite and friendly as I could. Again, if I failed, it's my fault: I apologize. I really appreciate your efforts to organize the best conference you can. I really *love* the idea of a conference entirely dedicated to Debian, to be held in a different place each time. That's why I consider this issue as an important one: every DebConf is an event through which we get public attention and can thus spread our philosophy. The message really works better if we act consistently with our philosophy, IMHO. or trying to submit a proposal, paper or even give a talk yourself. I really doubt I will be able to attend DebConf6, unfortunately. :-( You might also think about the organizers options when a speaker surprisingly NOT picks a DFSG free license, If the rules mandate a DFSG-free license (as I suggest), I think the only option for the organizers is to not include the paper/presentation/handout in the conference proceedings and to not distribute it through the conference website, until the licensing issue is solved. Just like a Debian package doesn't enter main, until it meets Policy requirements (DFSG-freeness being one of them). double-licenses his talk in an awkward way If you mean dual-licenses, then everything's fine as long as at least one of the chosen licenses makes the paper/presentation/handout DFSG-free. Otherwise, goto previous case. ;-) or declares before the audience that his talk must not be distributed. In that case the talk cannot be distributed through the conference website or in the proceedings. But this holds even if you do not mandate a DFSG-free license. Actually the C4P already requires some permissions from the authors: | Debconf requires non-exclusive publication rights to papers, | presentations, and any additional handouts or audio/visual materials | used in conjunction with the presentation. Hence, you already have to plan what to do, when an author does not fulfill the C4P requirements. Correct me, if I'm wrong. Also consider the legal implications of an intention or promise to release a DFSG free talk vs the actual act of releasing the work and when that happens in a legally binding way. Then consider the character of the CFP as a legaly binding document for the licenses of the actual talks of the speakers. As I said above, the publication of papers/presentations/handouts is anyway subject to some conditions. What I suggest is simply adding one further condition. I hope I clarified what I mean... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint
Licenses for DebConf6 [was: Re: DebConf6: Call For Papers]
[Added Cc: debian-legal, because the topic may be of interest there, I would say.] [No need to Cc: me, as long as you keep Cc:ing debian-legal (just to make things clear: I am subscribed to debian-legal, but not to debian-devel)] On Mon, 7 Nov 2005 10:01:48 +0100 Andreas Schuldei wrote: Fine Print Publication Rights Debconf requires non-exclusive publication rights to papers, presentations, and any additional handouts or audio/visual materials used in conjunction with the presentation. The authors have the freedom to pick a DFSG-free license for the papers themselves and retain all copyrights. The authors have the freedom to pick a DFSG-free license means that they *may* do so, but are not required to. Am I correct? IMHO, DebConf paper authors should be *required* to publish in a DFSG-free manner, as a condition for presenting at the conference. Don't you agree that seeing non-free or even undistributable (no license means All Rights Reserved, with current laws!) papers at a DebConf is really a shame? The presentations will be recorded, and may be broadcast over the Internet. Any copies of the presentation will be made available under a license like the MIT/X11 license. This refers to audio/video recordings, IIUC. It seems that the same rules adopted for DebConf5 still hold for DebConf6. Good. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpHsvUcbzJHS.pgp Description: PGP signature
Re: pine license
On Wed, 11 May 2005 03:33:41 -0400 Glenn Maynard wrote: I fully agree that we should cooperate with what copyright holders want, in general. What I remember, however, was that Pine was under a clearly Free license, and UW played word lawyer (modify and distribute, was it?) Yes, see for instance: http://www.asty.org/articles/20010702pine.html to minimize its freeness well after it was released and in wide use. I'm just saying that we should treat anyone with such a history with extreme scrutiny and skepticism, giving them no benefit of the doubt; they've lost that privilege. Agreed. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpR5lLStHysw.pgp Description: PGP signature
Re: Manpages licensed under GFDL without the license text included
On Sun, 09 Jan 2005 15:39:47 +0100 Florian Weimer wrote: I think it's enough to add an additional notice stating that the named section is reproduced in the gfdl(7) manpage, incorporated by reference. I doubt that this would satisfy clause 4.H. of the GFDL: H. Include an unaltered copy of this License. Note that it says /Include/, not /Accompany with/... -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpTWFoxDIM9f.pgp Description: PGP signature
Re: Manpages licensed under GFDL without the license text included
On Sun, 09 Jan 2005 16:53:25 +0100 Florian Weimer wrote: * Francesco Poli: On Sun, 09 Jan 2005 15:39:47 +0100 Florian Weimer wrote: I think it's enough to add an additional notice stating that the named section is reproduced in the gfdl(7) manpage, incorporated by reference. I doubt that this would satisfy clause 4.H. of the GFDL: H. Include an unaltered copy of this License. Note that it says /Include/, not /Accompany with/... Nothing in the license says that the Document must be a single file (or a single piece of paper). Yes, but what is the Document then, in the present case? The whole collection of manpages on the system? If you are going to argue this, I'm afraid that *all* of them will have to be under compatible licenses... not something that I would like to have as a target, when the GFDL is around :-( -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpydJIEn7eUs.pgp Description: PGP signature
