Bug#716667: ITP: python-scripttest -- Helper to test command-line scripts
Package: wnpp Severity: wishlist Owner: Thomas Bechtold * Package name: python-scripttest Version : 1.2 Upstream Author : Ian Bicking * URL : https://pypi.python.org/pypi/ScriptTest/ * License : MIT Programming Lang: Python Description : Helper to test command-line scripts ScriptTest is a library to help you test your interactive command-line applications. With it you can easily run the command (in a subprocess) and see the output (stdout, stderr) and any file modifications. -- 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/20130711074617.31225.70950.report...@avocado.fritz.box
AGPLv3 Compliance and Debian Users
Hi, with the recent discussion about the AGPLv3 I am wondering what the implications for users of Debian packages are. Debian packages often contain modifications in the form of patches, since the Debian project is only a distributor it complies to the license by making available the sources of the package. However, as soon as I (as a Debian user) install such a package and that package consists of a network service with which others interact, I have to "prominently" offer my users a way to retrieve the source of the Debian package as well in order to comply with the terms of the AGPLv3. Now the problem is that Debian packages under the AGPLv3 do not do that by default and it is very easy for Debian users to accidentally violate the license terms, e.g. when installing a package of a AGPLv3 web application on a publicly accessible webserver. An example that recently came to my attention is Debian's owncloud package, there seems to be no configuration option to easily add a link to all pages, so in order to comply with the AGPLv3 I guess I would have to create my own theme that displays a link to the sources of the Debian package (probably hosting them on my own server) and to the sources of the theme itself. I think it might be surprising to most users that they cannot just install a distribution package but have to take such tedious extra steps in order to comply with the license and I do not think most are aware of that. Any thoughts on that? Lars -- 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/1373532344.16902.yahoomail...@web163806.mail.gq1.yahoo.com
Re: AGPLv3 Compliance and Debian Users
Lars Meyser writes: > An example that recently came to my attention is Debian's owncloud package, > there seems to be no configuration option to easily add a link to all pages, > so > in order to comply with the AGPLv3 I guess I would have to create my own theme > that displays a link to the sources of the Debian package (probably hosting > them on my own server) and to the sources of the theme itself. I think it > might > be surprising to most users that they cannot just install a distribution > package but have to take such tedious extra steps in order to comply with the > license and I do not think most are aware of that. By default installing into a state that isn't compliant with the license seems like an obvious bug. You should file it in the BTS. -- Arto Jantunen -- 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/8738rllbal@kirika.int.wmdata.fi
Re: getaddrinfo() return value chaos
Kurt has filed a new bug report against eglibc http://sourceware.org/bugzilla/show_bug.cgi?id=15726 which draws the developers' attention to RFC3493 which specifies the return values of getaddrinfo(). These should be as follows. > - Things work as expected: return 0 > - The nameserver replies that the hostname does not exist: EAI_FAIL > - The nameserver doesn't reply, or replies with a temporary failure: EAI_AGAIN > - You used AI_NUMERICHOST or AI_NUMERICSERV and didn't give a number: > EAI_NONAME Further discussion can best be carried on in the upstream Bugzilla ticket. -- Thomas Hood
Re: AGPLv3 Compliance and Debian Users
- Original Message - > From: Arto Jantunen > To: "debian-devel@lists.debian.org" > Cc: > Sent: Thursday, July 11, 2013 11:02 AM > Subject: Re: AGPLv3 Compliance and Debian Users > > ... > By default installing into a state that isn't compliant with the license > seems like an obvious bug. You should file it in the BTS. It is not that simple, Debian itself complies with the license and users installing the package comply with the license as long as the network-facing service is not accessible to other users. To stay with my example, I am in compliance with the AGPLv3 when I install and use the Debian owncloud package on my NAS but not when I install it on my publicly accessible webserver where other users interact with it. This is also my personal reading of the license, I would like to hear others opinions before I start filing bugs. Lars -- 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/1373535676.42287.yahoomail...@web163804.mail.gq1.yahoo.com
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 5:41 PM, Lars Meyser wrote: > It is not that simple, Debian itself complies with the license and users > installing the package comply with the license as long as the network-facing > service is not accessible to other users. To stay with my example, I am in > compliance with the AGPLv3 when I install and use the Debian owncloud package > on my NAS but not when I install it on my publicly accessible webserver where > other users interact with it. In both situations you are still in compliance with the license. > This is also my personal reading of the license, I would like to hear others > opinions before I start filing bugs. Perhaps you missed "if you modify the Program" in item "13. Remote Network Interaction;" of the AGPL? -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6EDJtRg3rsqNW6zsmS=VWM=VGBMyA_msbFQXB5V4=a=j...@mail.gmail.com
Re: AGPLv3 Compliance and Debian Users
Hi, Am Donnerstag, den 11.07.2013, 17:48 +0800 schrieb Paul Wise: > On Thu, Jul 11, 2013 at 5:41 PM, Lars Meyser wrote: > > This is also my personal reading of the license, I would like to hear others > > opinions before I start filing bugs. > > Perhaps you missed "if you modify the Program" in item "13. Remote > Network Interaction;" of the AGPL? nevertheless it would be good if AGPL programs in general, and especially as packaged in Debian, would simply also install a tarball of the (patched) sources and have a download link in the program, so that the user has do not worry about this at all. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: AGPLv3 Compliance and Debian Users
- Original Message - > From: Paul Wise > To: debian-devel@lists.debian.org > Cc: > Sent: Thursday, July 11, 2013 11:48 AM > Subject: Re: AGPLv3 Compliance and Debian Users > > On Thu, Jul 11, 2013 at 5:41 PM, Lars Meyser wrote: > >> It is not that simple, Debian itself complies with the license and users >> installing the package comply with the license as long as the > network-facing >> service is not accessible to other users. To stay with my example, I am in >> compliance with the AGPLv3 when I install and use the Debian owncloud > package >> on my NAS but not when I install it on my publicly accessible webserver > where >> other users interact with it. > > In both situations you are still in compliance with the license. > >> This is also my personal reading of the license, I would like to hear > others >> opinions before I start filing bugs. > > Perhaps you missed "if you modify the Program" in item "13. > Remote > Network Interaction;" of the AGPL? No I did not miss that, but I'm not entirely sure of the implications. So if I use a packaged version of a program which has been modified (e.g. by Debian patches) I am not obliged to make the source available? Lars -- 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/1373538597.87225.yahoomail...@web163805.mail.gq1.yahoo.com
Re: Berkeley DB 6.0 license change to AGPLv3
Scott Kitterman wrote: On Saturday, July 06, 2013 01:52:59 PM Howard Chu wrote: Florian Weimer wrote: * Howard Chu: LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of source, there's nowhere to hide any tricks anyway.) Okay, I found a snag: the 511 bytes limit on the key size. Berkeley DB's disk format does not impose a limit on key or value size (at least for B-trees). For some applications, this will introduce new error conditions, and working around this limitation requires reworking the database schema. True. There's a bit of leeway here, we can raise the key size to ~1/2 the page size if necessary. But ultimately, we don't support keys that don't fit in a single page and there are no plans to add such support. If we see enough apps that can't live with this, we may revisit the situation. I did go back and look at the plans for mdb integration in Postfix, since it's my MTA of choice. It does seem that there are some barriers to adoption: http://www.postfix.com/LMDB_README.html Are there any plans to address these issues? Yes http://www.openldap.org/lists/openldap-devel/201303/msg2.html we've been working with Wietse Venema and plan to have this addressed in our upcoming 0.9.7 LMDB release. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 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/51de90ba.2060...@symas.com
Bug#716683: ITP: rt-extension-calendar -- Calendar for Request Tracker due tasks
Package: wnpp Owner: KURASHIKI Satoru * Package name: rt-extension-calendar Version : 0.16 Upstream Author : Nicolas Chuche * URL : http://search.cpan.org/dist/RTx-Calendar/ * License : Artistic Programming Lang: Perl Description : Calendar for Request Tracker due tasks This RT extension provides a calendar view for your tickets and your reminders so you see when is your next due ticket. You can find it in the menu Search->Calendar. There's a portlet to put on your home page (see Prefs/MyRT.html) You can also enable ics (ICal) feeds for your default calendar and all your private searches in Prefs/Calendar.html. Authentication is magic number based so that you can give those feeds to other people. -- 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/2013075350.5706.86866.report...@dandelion.in.yoikaze.org
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 6:29 PM, Lars Meyser wrote: > No I did not miss that, but I'm not entirely sure of the implications. So if I > use a packaged version of a program which has been modified (e.g. by Debian > patches) I am not obliged to make the source available? I'm no expert but that would be my interpretation. Also when I asked about the basis of the network part of the AGPL during the GPLv3 talk at DebConf10 in NYC, Bradley said the AGPL was specifically based on modification, _not_ on public performance or other use. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6EBzya+EVws=obbyxH8BU=2nfgro5wiqxx9htrup6c...@mail.gmail.com
Bug#716685: ITP: libpoppler-qt5-dev -- PDF rendering library -- development files (Qt 5 interface)
Package: wnpp Severity: wishlist Owner: Granger Anthony Package name: libpoppler-qt5-dev Version : 1.0.0 URL : http://poppler.freedesktop.org/ License : GPL Programming Lang: C, C++ Description : PDF rendering library -- development files (Qt 5 interface) Poppler is a PDF rendering library based on Xpdf PDF viewer. This package contains the headers and development libraries needed to build applications using the Qt 5-based Poppler interface. -- 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/20130711122657.5355.72046.reportbug@Choco-PC
Re: AGPLv3 Compliance and Debian Users
On 07/11/2013 14:15, Paul Wise wrote:
> On Thu, Jul 11, 2013 at 6:29 PM, Lars Meyser wrote:
>> No I did not miss that, but I'm not entirely sure of the implications. So if
>> I
>> use a packaged version of a program which has been modified (e.g. by Debian
>> patches) I am not obliged to make the source available?
>
> I'm no expert but that would be my interpretation. Also when I asked
> about the basis of the network part of the AGPL during the GPLv3 talk
> at DebConf10 in NYC, Bradley said the AGPL was specifically based on
> modification, _not_ on public performance or other use.
You have to make the source available in this case. Otherwise it would
be a trivial way around the AGPL (just have a third party modify the
program and give it to you).
Section 13 (Remote Network Interaction) requires modified version to
offer access to the source. If you modify the software, but do not
provide this, you violate this license requirement and lose the right to
modify and distribute the covered work under section 8 (Termination).
And with open source software you often deal with "modified" versions,
so claiming this is a special case ("[...] was specifically based on
modification, _not_ on public performance or other use") seems a bit odd
to me.
Anyway, this discussion seems more appropriate for -legal than -devel.
CC'ed and set Reply-To accordingly.
Ansgar
--
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/51deaf47.4020...@debian.org
Re: [Popcon-developers] Encrypted popcon submissions
On Wed, Jul 10, 2013 at 11:36:02PM +0200, Daniel Leidert wrote: > Am Mittwoch, den 10.07.2013, 16:14 +0200 schrieb Bill Allombert: > > On Tue, Jul 02, 2013 at 11:27:12PM +0200, Bill Allombert wrote: > > > On Fri, Jun 21, 2013 at 05:08:08PM +0200, Bill Allombert wrote: > > > > Dear Debian people, > > > > > > > > I upload popularity-contest 1.58 which add support for encrypted > > > > submissions. > > > > For this release it is not activated by default. > > > > Please help test this feature by adding > > > > ENCRYPT="yes" > > > > to /etc/popularity-contest.conf to activate it. > > > > > > > > Once this feature has seen proper testing, we will activate it by > > > > default. > > > > > > Well, 1.58 is now is testing and I still received only an handful of > > > encrypted > > > report. I know you can do better! > > > > Indeed, I receive much more encrypted report now. > > > > A bug I like to fix before enabling encryption by default is #714917: > > gpg is creating a directory /root/gnupg with various files which are > > essentially useless since popcon do not perform any signature checks. > > > > I do not know how to fix this bug short of creating a dummy GPGHOME > > directory with useless files. > > Any help welcome! > > You don't need to create this directory. One can easily use > --homedir=/dev/null. However the most fitting answer depends on what you > want to do. Can you quote the commands please? Below is the code in /etc/cron.daily/popularity-contest GPG=/usr/bin/gpg if [ "$ENCRYPT" = "yes" ] && [ -x "$GPG" ]; then POPCONGPG="$POPCON.gpg" rm -f "$POPCONGPG" $GPG --no-default-keyring --keyring "$KEYRING" --trust-model=always \ --armor -o "$POPCONGPG" -r "$POPCONKEY" --encrypt "$POPCON" POPCON="$POPCONGPG" fi Cheers, -- Bill. Imagine a large red swirl here. -- 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/20130711133321.GC21383@yellowpig
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote:
> > I'm no expert but that would be my interpretation. Also when I asked
> > about the basis of the network part of the AGPL during the GPLv3 talk
> > at DebConf10 in NYC, Bradley said the AGPL was specifically based on
> > modification, _not_ on public performance or other use.
>
> You have to make the source available in this case. Otherwise it would
> be a trivial way around the AGPL (just have a third party modify the
> program and give it to you).
Co-author of AGPLv3 here, including the section at issue. You do not
have to make the source available in this case, in general. In unusual
cases of circumvention, like what I believe you are suggesting, the
answer might arguably be different, but in the context of ordinary
Linux distributions, when a user gets AGPLv3-licensed software that
the *distro* has modified, that software is *unmodified* from the
standpoint of that user downstream from the distro and therefore the
user needs to do something to trigger the section 13 requirement.
Otherwise you have to explain why modification was made to be the
trigger. If the modified/unmodified distinction was meant to be
meaningless, section 13 would have been drafted not to make any
reference to modification. Indeed, other Affero-like licenses
typically are broader than AGPLv3 in the sense that they work by
redefinition of 'distribution' and thus are not limited to cases where
the user has modified the software. This approach was specifically
rejected when AGPLv3 was being drafted.
> Section 13 (Remote Network Interaction) requires modified version to
> offer access to the source. If you modify the software, but do not
> provide this, you violate this license requirement and lose the right to
> modify and distribute the covered work under section 8 (Termination).
>
> And with open source software you often deal with "modified" versions,
> so claiming this is a special case ("[...] was specifically based on
> modification, _not_ on public performance or other use") seems a bit odd
> to me.
That's another issue, what does it take for the software to be
'modified' for purposes of that section, and you rightly call
attention to it. But to say that the package *as received from the
distro* triggers section 13 *inherently* is inconsistent with the
language of section 13 and the intent of the drafters.
- RF
--
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/20130711135511.ga19...@redhat.com
Re: AGPLv3 Compliance and Debian Users
On 11.07.2013 09:12, Ansgar Burchardt wrote:
On 07/11/2013 14:15, Paul Wise wrote:
On Thu, Jul 11, 2013 at 6:29 PM, Lars Meyser wrote:
No I did not miss that, but I'm not entirely sure of the
implications. So if I
use a packaged version of a program which has been modified (e.g.
by Debian
patches) I am not obliged to make the source available?
I'm no expert but that would be my interpretation. Also when I asked
about the basis of the network part of the AGPL during the GPLv3
talk
at DebConf10 in NYC, Bradley said the AGPL was specifically based on
modification, _not_ on public performance or other use.
You have to make the source available in this case. Otherwise it
would
be a trivial way around the AGPL (just have a third party modify the
program and give it to you).
Section 13 (Remote Network Interaction) requires modified version to
offer access to the source. If you modify the software, but do not
provide this, you violate this license requirement and lose the right
to
modify and distribute the covered work under section 8 (Termination).
And with open source software you often deal with "modified"
versions,
so claiming this is a special case ("[...] was specifically based on
modification, _not_ on public performance or other use") seems a bit
odd
to me.
Anyway, this discussion seems more appropriate for -legal than
-devel.
CC'ed and set Reply-To accordingly.
Ansgar
My understanding though that if Debian is the one making the
modification then Debian is the one responsible for making the source
available. If the end user is then modifying the source then they would
subsequently need to make those modifications available. I would find
having the Debian package install a tarball that could be linked to and
downloadable from the end user to be unnecessary duplication if all that
would be needed would be a link then why not just have that link point
to the source on the Debian mirror. If the end user then makes
modification it's upon them, not Debian, to ensure they are compliant
with the license agreement.
--
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/013fcdf7594e-d6170b4e-37ad-4890-80ce-afc056bd909d-000...@email.amazonses.com
Re: AGPLv3 Compliance and Debian Users
Hi, On Donnerstag, 11. Juli 2013, Jeremy T. Bouse wrote: > My understanding though that if Debian is the one making the > modification then Debian is the one responsible for making the source > available. I think this is done already, since roughly 20 years, have a look at ftp.debian.org cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: AGPLv3 Compliance and Debian Users
Hi, Am Donnerstag, den 11.07.2013, 13:41 + schrieb Jeremy T. Bouse: > I would find > having the Debian package install a tarball that could be linked to and > downloadable from the end user to be unnecessary duplication if all that > would be needed would be a link then why not just have that link point > to the source on the Debian mirror. the question is: Does Debian guarantee (or at least promise) to provide the sources for a sufficient amount of time _in the required version_?I guess with http://snapshot.debian.org/ we do (and having AGPL software in Debian include a link to there would already be very nice), but having the source shipped with the package itself would solve a this problems more elegantly, and would also work in a lonely-island-setting. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: AGPLv3 Compliance and Debian Users
On Thursday, July 11, 2013 12:26:47 PM Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 11.07.2013, 17:48 +0800 schrieb Paul Wise: > > On Thu, Jul 11, 2013 at 5:41 PM, Lars Meyser wrote: > > > This is also my personal reading of the license, I would like to hear > > > others opinions before I start filing bugs. > > > > Perhaps you missed "if you modify the Program" in item "13. Remote > > Network Interaction;" of the AGPL? > > nevertheless it would be good if AGPL programs in general, and > especially as packaged in Debian, would simply also install a tarball of > the (patched) sources and have a download link in the program, so that > the user has do not worry about this at all. The trick here is it's not just packages explicitly licensed with the AGPL that are affected. It's also packages that have an AGPL compatible license that link against anything that's an AGPL library (the specific reason libdb is an issue), so if we end up with AGPL libraries, this could be widespread. Scott K signature.asc Description: This is a digitally signed message part.
Re: [Popcon-developers] Encrypted popcon submissions
Am Donnerstag, den 11.07.2013, 15:33 +0200 schrieb Bill Allombert: [use gpg but don't write to root/.gnupg] > Below is the code in /etc/cron.daily/popularity-contest > > GPG=/usr/bin/gpg > if [ "$ENCRYPT" = "yes" ] && [ -x "$GPG" ]; then > POPCONGPG="$POPCON.gpg" > rm -f "$POPCONGPG" > $GPG --no-default-keyring --keyring "$KEYRING" --trust-model=always \ >--armor -o "$POPCONGPG" -r "$POPCONKEY" --encrypt "$POPCON" > POPCON="$POPCONGPG" > fi I suggest you add trustdb.gpg and secring.gpg to /usr/share/popularity-contest/ or (maybe even better) /etc/popularity-contest/. apt(-secure) does similar in /etc/apt. The command would then look like this: gpg --no-options --no-default-keyring --keyring [..] \ --secret-keyring /etc/popularity-contest/secring.gpg \ --trustdb-name /etc/popularity-contest/trustdb.gpg JFTR: The file secring.gpg can be avoided using --secret-keyring=/dev/null but I don't know how to suppress the creation of trustdb.gpg. Regards, Daniel -- 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/1373555758.6487.6.ca...@haktar.debian.wgdd.de
Re: AGPLv3 Compliance and Debian Users
Excerpts from Richard Fontana's message of 2013-07-11 06:55:12 -0700: > On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote: > > > I'm no expert but that would be my interpretation. Also when I asked > > > about the basis of the network part of the AGPL during the GPLv3 talk > > > at DebConf10 in NYC, Bradley said the AGPL was specifically based on > > > modification, _not_ on public performance or other use. > > > > You have to make the source available in this case. Otherwise it would > > be a trivial way around the AGPL (just have a third party modify the > > program and give it to you). > > Co-author of AGPLv3 here, including the section at issue. You do not > have to make the source available in this case, in general. In unusual > cases of circumvention, like what I believe you are suggesting, the > answer might arguably be different, but in the context of ordinary > Linux distributions, when a user gets AGPLv3-licensed software that > the *distro* has modified, that software is *unmodified* from the > standpoint of that user downstream from the distro and therefore the > user needs to do something to trigger the section 13 requirement. > > Otherwise you have to explain why modification was made to be the > trigger. If the modified/unmodified distinction was meant to be > meaningless, section 13 would have been drafted not to make any > reference to modification. Indeed, other Affero-like licenses > typically are broader than AGPLv3 in the sense that they work by > redefinition of 'distribution' and thus are not limited to cases where > the user has modified the software. This approach was specifically > rejected when AGPLv3 was being drafted. > So are you suggesting that the AGPL's protections against commercial takeover are basically moot? How would the AGPL be applied in this scenario: Company A starts a business based on unmodified MediaGoblin. They hire a firm, Consultants-R-Us, to manage their MediaGoblin code base and develop a new new video encoder. Their contract with Consultants-R-Us keeps ownership of all code in Consultants-R-Us name, and C-R-U simply gives a tarball to Company A which they then use to serve users. Can we honestly say that Company A modified the software? If not, then what is the point of the AGPL? To protect C-R-U? I am not suggesting that this is absolutely not modification by Company A. However, to a non-lawyer like me, it sure _looks_ like a big hole. -- 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/1373555743-sup-3...@fewbar.com
Why does debian-sid can't suspend by closing lid?
Hi all, Ever since after Wheezy released, with gnome-3 and systemd, I still can't suspend my laptop by closing the lid like it used to be. I remember there's a workaround that make the Suspend option in the User menu works... but that is not very comfortable. Any workarounds on this (for suspend by lid-close) by now ? Is it just gnome-3(+-systemd) ? Appreciate any pointers/clues. All the best. -arief
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 08:27:31AM -0700, Clint Byrum wrote: > Excerpts from Richard Fontana's message of 2013-07-11 06:55:12 -0700: > > On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote: > > > > I'm no expert but that would be my interpretation. Also when I asked > > > > about the basis of the network part of the AGPL during the GPLv3 talk > > > > at DebConf10 in NYC, Bradley said the AGPL was specifically based on > > > > modification, _not_ on public performance or other use. > > > > > > You have to make the source available in this case. Otherwise it would > > > be a trivial way around the AGPL (just have a third party modify the > > > program and give it to you). > > > > Co-author of AGPLv3 here, including the section at issue. You do not > > have to make the source available in this case, in general. In unusual > > cases of circumvention, like what I believe you are suggesting, the > > answer might arguably be different, but in the context of ordinary > > Linux distributions, when a user gets AGPLv3-licensed software that > > the *distro* has modified, that software is *unmodified* from the > > standpoint of that user downstream from the distro and therefore the > > user needs to do something to trigger the section 13 requirement. > > > > Otherwise you have to explain why modification was made to be the > > trigger. If the modified/unmodified distinction was meant to be > > meaningless, section 13 would have been drafted not to make any > > reference to modification. Indeed, other Affero-like licenses > > typically are broader than AGPLv3 in the sense that they work by > > redefinition of 'distribution' and thus are not limited to cases where > > the user has modified the software. This approach was specifically > > rejected when AGPLv3 was being drafted. > > > > So are you suggesting that the AGPL's protections against commercial > takeover are basically moot? No. The main problem I have been seeing is in the opposite direction: overbroad interpretations of AGPLv3, one of the reasons I am chiming in here. It is the tendency to overbreadth that is tragic. > How would the AGPL be applied in this > scenario: > > Company A starts a business based on unmodified MediaGoblin. They hire > a firm, Consultants-R-Us, to manage their MediaGoblin code base and > develop a new new video encoder. > > Their contract with Consultants-R-Us keeps ownership of all code in > Consultants-R-Us name, and C-R-U simply gives a tarball to Company A > which they then use to serve users. > > Can we honestly say that Company A modified the software? Possibly, in that case -- but that's entirely different from the distro packaging scenario. > If not, then > what is the point of the AGPL? To protect C-R-U? > > I am not suggesting that this is absolutely not modification by Company A. > However, to a non-lawyer like me, it sure _looks_ like a big hole. Just a general comment which I think is important to say: The GPL/AGPL licenses were not designed to be guaranteed to eliminate all possible creative loopholes. They *can't*. I don't recall anyone raising your hypothetical during the (relatively quiet) drafting of AGPLv3 but for GPLv3, although the specifics elude me at the moment, I recall many people, usually developers or technical users, having raised parade-of-horribles hypotheticals that belonged to this general category (essentially, a kind of conspiracy in a licensing chain to evade the requirements of the license, often by splitting 'you' into more than one licensee). The FSF's view was essentially that reasonable legal systems would likely treat such things as copyright infringement, without the license text having to spell it out. I think this was consistent with some of what the FSF had said in the past regarding interpretation of GPLv2. - RF -- 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/20130711174500.ga22...@redhat.com
Re: Pepper Flash for Chromium
Scott Leggett writes ("Re: Pepper Flash for Chromium"):
> Specifically, downloading the chrome .deb from google and doing
> anything other than simply installing it (like extracting the flash
> plugin and copying it elsewhere) would be creating a derivative work
> and is thus forbidden.
We could create a chroot specifically for containing the chrome .deb,
and install the .deb in there, and point the browser at the files.
Ian.
--
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/20958.62300.147087.892...@chiark.greenend.org.uk
Re: Pepper Flash for Chromium
El 11/07/13 13:33, Ian Jackson escribió:
Scott Leggett writes ("Re: Pepper Flash for Chromium"):
>Specifically, downloading the chrome .deb from google and doing
>anything other than simply installing it (like extracting the flash
>plugin and copying it elsewhere) would be creating a derivative work
>and is thus forbidden.
We could create a chroot specifically for containing the chrome .deb,
and install the .deb in there, and point the browser at the files.
Hi, is the first time I write in this list.
Chroot'ing would not be a some strangesolution? I only say this because
I don't know any package thatdo that, and it would download a
considerable amount of packages to build the chroot also the Chrome package.
--
Erick Birbe
@erickcion
http://erickcion.wordpress.com/
--
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/51defb89.9090...@gmail.com
Re: Why does debian-sid can't suspend by closing lid?
Hi Arief, Arief M Utama writes: > Ever since after Wheezy released, with gnome-3 and systemd, I still can't > suspend my laptop by closing the lid like it used to be. Note that wheezy does not use systemd by default. Are you 100% sure you are using systemd? Check “ps auxf” to see if systemd is your PID 1. If so, please file a bug against the systemd package. If not, please try again at debian-users. This mailing list is for development, not for user questions/issues. -- Best regards, Michael -- 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/x6fvvkudl3@midna.lan
Re: AGPLv3 Compliance and Debian Users
Excerpts from Richard Fontana's message of 2013-07-11 10:45:00 -0700: > On Thu, Jul 11, 2013 at 08:27:31AM -0700, Clint Byrum wrote: > > Excerpts from Richard Fontana's message of 2013-07-11 06:55:12 -0700: > > > On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote: > > > > > I'm no expert but that would be my interpretation. Also when I asked > > > > > about the basis of the network part of the AGPL during the GPLv3 talk > > > > > at DebConf10 in NYC, Bradley said the AGPL was specifically based on > > > > > modification, _not_ on public performance or other use. > > > > > > > > You have to make the source available in this case. Otherwise it would > > > > be a trivial way around the AGPL (just have a third party modify the > > > > program and give it to you). > > > > > > Co-author of AGPLv3 here, including the section at issue. You do not > > > have to make the source available in this case, in general. In unusual > > > cases of circumvention, like what I believe you are suggesting, the > > > answer might arguably be different, but in the context of ordinary > > > Linux distributions, when a user gets AGPLv3-licensed software that > > > the *distro* has modified, that software is *unmodified* from the > > > standpoint of that user downstream from the distro and therefore the > > > user needs to do something to trigger the section 13 requirement. > > > > > > Otherwise you have to explain why modification was made to be the > > > trigger. If the modified/unmodified distinction was meant to be > > > meaningless, section 13 would have been drafted not to make any > > > reference to modification. Indeed, other Affero-like licenses > > > typically are broader than AGPLv3 in the sense that they work by > > > redefinition of 'distribution' and thus are not limited to cases where > > > the user has modified the software. This approach was specifically > > > rejected when AGPLv3 was being drafted. > > > > > > > So are you suggesting that the AGPL's protections against commercial > > takeover are basically moot? > > No. The main problem I have been seeing is in the opposite direction: > overbroad interpretations of AGPLv3, one of the reasons I am chiming > in here. It is the tendency to overbreadth that is tragic. > > > How would the AGPL be applied in this > > scenario: > > > > Company A starts a business based on unmodified MediaGoblin. They hire > > a firm, Consultants-R-Us, to manage their MediaGoblin code base and > > develop a new new video encoder. > > > > Their contract with Consultants-R-Us keeps ownership of all code in > > Consultants-R-Us name, and C-R-U simply gives a tarball to Company A > > which they then use to serve users. > > > > Can we honestly say that Company A modified the software? > > Possibly, in that case -- but that's entirely different from the > distro packaging scenario. > Right, I want to understand AGPL's motivations is all. > > If not, then > > what is the point of the AGPL? To protect C-R-U? > > > > I am not suggesting that this is absolutely not modification by Company A. > > However, to a non-lawyer like me, it sure _looks_ like a big hole. > > Just a general comment which I think is important to say: The GPL/AGPL > licenses were not designed to be guaranteed to eliminate all possible > creative loopholes. They *can't*. > > I don't recall anyone raising your hypothetical during the (relatively > quiet) drafting of AGPLv3 but for GPLv3, although the specifics elude > me at the moment, I recall many people, usually developers or > technical users, having raised parade-of-horribles hypotheticals that > belonged to this general category (essentially, a kind of conspiracy > in a licensing chain to evade the requirements of the license, often > by splitting 'you' into more than one licensee). The FSF's view was > essentially that reasonable legal systems would likely treat such > things as copyright infringement, without the license text having to > spell it out. I think this was consistent with some of what the FSF > had said in the past regarding interpretation of GPLv2. > I don't think this is all that horrible. The sustainable model that the GPL supports is exactly this. Instead of bilking people for license fees you charge for your time in customizing, and provide them with a license that gives them and you total freedom with the code going forward. I think it is a likely reality that a company or individual will build a business on customizing AGPL code that nobody, including that code's users, will ever know about or see. It would not, in my mind, be copyright infringement as they'd be complying fully with the license terms. So my point isn't "oh look the whole thing is invalid". My point is that this loophole seems rather large. -- 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/1373568129-sup-5...@fewbar.com
Re: AGPLv3 Compliance and Debian Users
Clint Byrum wrote: Excerpts from Richard Fontana's message of 2013-07-11 10:45:00 -0700: On Thu, Jul 11, 2013 at 08:27:31AM -0700, Clint Byrum wrote: Excerpts from Richard Fontana's message of 2013-07-11 06:55:12 -0700: On Thu, Jul 11, 2013 at 03:12:39PM +0200, Ansgar Burchardt wrote: I'm no expert but that would be my interpretation. Also when I asked about the basis of the network part of the AGPL during the GPLv3 talk at DebConf10 in NYC, Bradley said the AGPL was specifically based on modification, _not_ on public performance or other use. You have to make the source available in this case. Otherwise it would be a trivial way around the AGPL (just have a third party modify the program and give it to you). Co-author of AGPLv3 here, including the section at issue. You do not have to make the source available in this case, in general. In unusual cases of circumvention, like what I believe you are suggesting, the answer might arguably be different, but in the context of ordinary Linux distributions, when a user gets AGPLv3-licensed software that the *distro* has modified, that software is *unmodified* from the standpoint of that user downstream from the distro and therefore the user needs to do something to trigger the section 13 requirement. Otherwise you have to explain why modification was made to be the trigger. If the modified/unmodified distinction was meant to be meaningless, section 13 would have been drafted not to make any reference to modification. Indeed, other Affero-like licenses typically are broader than AGPLv3 in the sense that they work by redefinition of 'distribution' and thus are not limited to cases where the user has modified the software. This approach was specifically rejected when AGPLv3 was being drafted. So are you suggesting that the AGPL's protections against commercial takeover are basically moot? No. The main problem I have been seeing is in the opposite direction: overbroad interpretations of AGPLv3, one of the reasons I am chiming in here. It is the tendency to overbreadth that is tragic. How would the AGPL be applied in this scenario: Company A starts a business based on unmodified MediaGoblin. They hire a firm, Consultants-R-Us, to manage their MediaGoblin code base and develop a new new video encoder. Their contract with Consultants-R-Us keeps ownership of all code in Consultants-R-Us name, and C-R-U simply gives a tarball to Company A which they then use to serve users. Can we honestly say that Company A modified the software? Possibly, in that case -- but that's entirely different from the distro packaging scenario. Right, I want to understand AGPL's motivations is all. I used to put similar terms on my code, back before the GPL existed. Essentially: If you modify this code, you must send your modifications back to me (the original author). The motivation is that if you fixed a bug or improved the code, you should make your improvements available to me, and I subsequently make them available to the user base at large in my next release. I don't consider this a terrible restriction - if you're using my code that you got for free, and are deriving value from it, and find a way to make it better, I think you owe it to everyone to release your improvement freely as well. If not, then what is the point of the AGPL? To protect C-R-U? I am not suggesting that this is absolutely not modification by Company A. However, to a non-lawyer like me, it sure _looks_ like a big hole. I don't see any hole. If C-R-U did the modifications then they are obligated to publish the source code, by virtue of the fact that giving the modified code to Company A is distributing it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 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/51df0553.8080...@symas.com
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 12:19:47PM -0700, Howard Chu wrote: > >Right, I want to understand AGPL's motivations is all. > > I used to put similar terms on my code, back before the GPL existed. > Essentially: If you modify this code, you must send your > modifications back to me (the original author). The motivation is > that if you fixed a bug or improved the code, you should make your > improvements available to me, and I subsequently make them available > to the user base at large in my next release. > > I don't consider this a terrible restriction - if you're using my Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2] [1]: The Dissident test [2]: The Desert Island test -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: AGPLv3 Compliance and Debian Users
Paul Tagliamonte wrote: On Thu, Jul 11, 2013 at 12:19:47PM -0700, Howard Chu wrote: Right, I want to understand AGPL's motivations is all. I used to put similar terms on my code, back before the GPL existed. Essentially: If you modify this code, you must send your modifications back to me (the original author). The motivation is that if you fixed a bug or improved the code, you should make your improvements available to me, and I subsequently make them available to the user base at large in my next release. I don't consider this a terrible restriction - if you're using my Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2] [1]: The Dissident test [2]: The Desert Island test Sure, but #2 is stupid. We didn't say "must send changes back immediately." Nor would we wish any such thing; if you're in the middle of making a long series of changes we obviously want to wait until the changes are completed and have settled down. Otherwise someone could make a case that the changes should be sent back the instant they are written, one keystroke at a time, which is ludicrous. Send changes back in a timely manner. You obtained the software somehow; therefore at some point in time a distribution channel was available to you. The next time such channel is available, send your changes back. If you're stuck on a desert island and die before such channel reopens, no one's going to sue you. I'd say #1 is borderline stupid. It is worded such that it only applies to hiding existence of a system from the government. Fair enough; I'm not the government. I've accepted many patches from anonymous senders for various code (see http://rtmpdump.mplayerhq.hu/ for example: RTMP Dump v2.4 (C) 2009 Andrej Stepanchuk (C) 2009-2011 Howard Chu (C) 2010 2a665470ced7adb7156fcef47f8199a6371c117b8a79e399a2771e0b36384090 (C) 2011 33ae1ce77301f4b4494faaa5f609f3c48b9dcf82 License: GPLv2 librtmp license: LGPLv2.1 http://rtmpdump.mplayerhq.hu/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 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/51df0d1d@symas.com
Re: AGPLv3 Compliance and Debian Users
]] Howard Chu [...] > >>> If not, then > >>> what is the point of the AGPL? To protect C-R-U? > >>> > >>> I am not suggesting that this is absolutely not modification by Company A. > >>> However, to a non-lawyer like me, it sure _looks_ like a big hole. > > I don't see any hole. If C-R-U did the modifications then they are > obligated to publish the source code, by virtue of the fact that > giving the modified code to Company A is distributing it. They're only obliged to give the source to the people they distribute the binaries to, or who accesses the system over a network, as I understnad it? So Company A gets the source from C-R-U under those terms and uses what they got, unmodified, from «upstream» and as I understand this subthread, they're under no obligation to then publish the source? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ppuolt19@xoog.err.no
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 12:53:01PM -0700, Howard Chu wrote: > >Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2] > >[1]: The Dissident test > >[2]: The Desert Island test > Sure, but #2 is stupid. We didn't say "must send changes back > immediately." Nor would we wish any such thing; if you're in the > middle of making a long series of changes we obviously want to wait > until the changes are completed and have settled down. Otherwise > someone could make a case that the changes should be sent back the > instant they are written, one keystroke at a time, which is > ludicrous. > Send changes back in a timely manner. You obtained the software > somehow; therefore at some point in time a distribution channel was > available to you. The next time such channel is available, send your > changes back. If you're stuck on a desert island and die before such > channel reopens, no one's going to sue you. > I'd say #1 is borderline stupid. It is worded such that it only > applies to hiding existence of a system from the government. Fair > enough; I'm not the government. That's not the point. The purpose of the Dissident Test is to demonstrate that distribution channels for software are not necessarily symmetric; it may be very easy for you to distribute the software, but very hard/expensive/dangerous for a recipient to distribute their modifications back to you. In the specific case of the Dissident Test, the unreasonable cost of returning the changes upstream - as opposed to distributing them to whoever you happen to be distributing binaries to (possibly no one) - is that sending those communications back may give hostile authorities information you don't want them to have, such as your location, details about the software you're modifying, or even simply the fact that you're doing something that you care about encrypting to keep them from prying. Even if you aren't otherwise doing anything the government disapproves of, the mere act of sending these changes upstream might get you labelled a spy. This is one example of why Debian says it's ok for a license to require modifications to be distributed to your downstreams, but not ok to require those changes be sent to a particular party. Users should not have to choose between complying with the license and being safe from their government; they should be *free* to exercise their rights on the code in Debian, even when they aren't free in other aspects of their lives that we don't have control over. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [Popcon-developers] Encrypted popcon submissions
On Thu, Jul 11, 2013 at 5:15 PM, Daniel Leidert wrote: > Am Donnerstag, den 11.07.2013, 15:33 +0200 schrieb Bill Allombert: > JFTR: The file secring.gpg can be avoided using > --secret-keyring=/dev/null but I don't know how to suppress the creation > of trustdb.gpg. Note that you can't use that for all gpg commands, importing a (public) key is e.g. not possible with this. You have to create an (empty) file in that case as e.g. apt-key is doing it. "Suppressing" trustdb.gpg is even harder as an empty file isn't accepted, so you have to create a temporary directory gpg can store the file in (apt-key doesn't as it eats quiet a bit of time if you have a few keys). And then you have gpg editing keyrings at times ( #687611 ) even if you just --list-keys which you might be able to stop with --no-auto-check-trustdb (I haven't had the time to test that yet; and if it really works, I find the name a bit strange but I have stopped wondering about such things). Ignoring time screws (--ignore-time-conflict) might or might not make sense depending on how much the time is important for the application in general (doesn't apply to popcon I guess, but in case someone else reads the thread). Best regards David Kalnischkies -- 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/CAAZ6_fCtK_OcAwN8CcBG21CKCoJwcoouU36KhVSn_q=6_lu...@mail.gmail.com
Re: AGPLv3 Compliance and Debian Users
Steve Langasek wrote: On Thu, Jul 11, 2013 at 12:53:01PM -0700, Howard Chu wrote: Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2] [1]: The Dissident test [2]: The Desert Island test Sure, but #2 is stupid. We didn't say "must send changes back immediately." Nor would we wish any such thing; if you're in the middle of making a long series of changes we obviously want to wait until the changes are completed and have settled down. Otherwise someone could make a case that the changes should be sent back the instant they are written, one keystroke at a time, which is ludicrous. Send changes back in a timely manner. You obtained the software somehow; therefore at some point in time a distribution channel was available to you. The next time such channel is available, send your changes back. If you're stuck on a desert island and die before such channel reopens, no one's going to sue you. I'd say #1 is borderline stupid. It is worded such that it only applies to hiding existence of a system from the government. Fair enough; I'm not the government. That's not the point. The purpose of the Dissident Test is to demonstrate that distribution channels for software are not necessarily symmetric; it may be very easy for you to distribute the software, but very hard/expensive/dangerous for a recipient to distribute their modifications back to you. In the specific case of the Dissident Test, the unreasonable cost of returning the changes upstream - as opposed to distributing them to whoever you happen to be distributing binaries to (possibly no one) - is that sending those communications back may give hostile authorities information you don't want them to have, such as your location, details about the software you're modifying, or even simply the fact that you're doing something that you care about encrypting to keep them from prying. Even if you aren't otherwise doing anything the government disapproves of, the mere act of sending these changes upstream might get you labelled a spy. This is still an unreasonable test. Again, it ignores the element of time. Send your changes at your earliest convenience. If the NSA is breathing down your neck, "convenience" might be a long time away, but that's understandable. This is one example of why Debian says it's ok for a license to require modifications to be distributed to your downstreams, but not ok to require those changes be sent to a particular party. Users should not have to choose between complying with the license and being safe from their government; they should be *free* to exercise their rights on the code in Debian, even when they aren't free in other aspects of their lives that we don't have control over. Freedom always has a price. The price of benefiting from free software should be that you help others benefit from it too. Absolving recipients of all such responsibility merely encourages parasites. Progress happens faster when everyone pitches in, there shouldn't be just a few people creating and everyone else tagging along for the ride. Even here http://people.debian.org/~bap/dfsg-faq.html 12.A.k "This freedom is one of the most important driving factors for progress in computing---and we like progress." That sentence is not talking about this particular point but the underlying concept remains - the goal for all of this is to encourage progress, not hinder it. Hoarding improvements to yourself hinders progress for society as a whole. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 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/51df3f52.9030...@symas.com
Work-needing packages report for Jul 12, 2013
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 492 (new: 3) Total number of packages offered up for adoption: 148 (new: 1) Total number of packages requested help for: 60 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: gfarm (#715446), orphaned 2 days ago Description: Gfarm file system Reverse Depends: gfarm-client gfarm2fs gfmd gfsd libgfarm-dev Installations reported by Popcon: 15 gfarm2fs (#715445), orphaned 2 days ago Description: FUSE program to mount the Gfarm file system Installations reported by Popcon: 9 muse-el (#715466), orphaned 2 days ago Description: author and publish projects using wiki-like markup Reverse Depends: planner-el Installations reported by Popcon: 263 489 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: tiobench (#715335), offered 3 days ago Description: Threaded I/O bench for Linux Installations reported by Popcon: 206 147 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1256 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache fuss-launcher goplay packagesearch Installations reported by Popcon: 75393 asymptote (#517342), requested 1595 days ago Description: script-based vector graphics language inspired by MetaPost Installations reported by Popcon: 4276 athcool (#278442), requested 3180 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 55 balsa (#642906), requested 655 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 991 bastille (#592137), requested 1069 days ago Description: Security hardening tool Installations reported by Popcon: 146 cardstories (#624100), requested 808 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 10 chromium-browser (#583826), requested 1138 days ago Description: Chromium browser Reverse Depends: chromium chromium-browser chromium-browser-dbg chromium-browser-inspector chromium-browser-l10n chromium-dbg chromium-l10n mozplugger Installations reported by Popcon: 17870 cups (#532097), requested 1496 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-daemon cups-dbg cups-filters (59 more omitted) Installations reported by Popcon: 121487 debtags (#567954), requested 1256 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2405 fbcat (#565156), requested 1275 days ago Description: framebuffer grabber Installations reported by Popcon: 155 flightgear (#487388), requested 1846 days ago Description: Flight Gear Flight Simulator Installations reported by Popcon: 557 freeipmi (#628062), requested 777 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev libipmiconsole2 libipmidetect-dev libipmidetect0 (3 more omitted) Installations reported by Popcon: 3107 gnat-4.4 (#539633), requested 1913 days ago Description: backport bug fixes from trunk (GCC 4.5) Reverse Depends: ghdl gnat-4.4 libgnat-4.4 libgnat-4.4-dbg libgnatprj-dev libgnatprj4.4 libgnatprj4.4-dbg libgnatprj4.4-dev libgnatvsn-dev libgnatvsn4.4 (2 more omitted) Installations reported by Popcon: 1404 gnat-gps (#496905), requested 1778 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 483 gnokii (#677750), requested 390 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1998 gnupg (#660685), requested 507 da
Re: AGPLv3 Compliance and Debian Users
On Thu, Jul 11, 2013 at 04:27:14PM -0700, Howard Chu wrote: > >That's not the point. The purpose of the Dissident Test is to demonstrate > >that distribution channels for software are not necessarily symmetric; it > >may be very easy for you to distribute the software, but very > >hard/expensive/dangerous for a recipient to distribute their modifications > >back to you. In the specific case of the Dissident Test, the unreasonable > >cost of returning the changes upstream - as opposed to distributing them to > >whoever you happen to be distributing binaries to (possibly no one) - is > >that sending those communications back may give hostile authorities > >information you don't want them to have, such as your location, details > >about the software you're modifying, or even simply the fact that you're > >doing something that you care about encrypting to keep them from prying. > >Even if you aren't otherwise doing anything the government disapproves of, > >the mere act of sending these changes upstream might get you labelled a spy. > This is still an unreasonable test. Again, it ignores the element of > time. Send your changes at your earliest convenience. If the NSA is > breathing down your neck, "convenience" might be a long time away, > but that's understandable. It ignores the element of time because the licenses this test was constructed in response to don't *allow* the user to do so. There is no common sense "at your convenience" rule baked into the law; if the licensor means that this should be done at the modifier's convenience, they should be spelling that out in the license - with the understanding that the licensor and licensee may not agree on what is convenient, and that it may *never* be convenient from the licensee's POV. Let's not forget that Al Capone was convicted not for murder, racketeering, or bootlegging, but for tax evasion; and that the US tax code specifies where on your tax form you are required to report income from the sale of illegal drugs. It would be ironic for a dissident to evade capture and prosecution for years, only to finally be brought up on charges of criminal copyright infringement (with or without the consent of the copyright holder!) for failing to submit their changes upstream while operating clandestinely. > >This is one example of why Debian says it's ok for a license to require > >modifications to be distributed to your downstreams, but not ok to require > >those changes be sent to a particular party. Users should not have to > >choose between complying with the license and being safe from their > >government; they should be *free* to exercise their rights on the code in > >Debian, even when they aren't free in other aspects of their lives that we > >don't have control over. > Freedom always has a price. The price of benefiting from free > software should be that you help others benefit from it too. That's your position. That's not the Debian position. We *encourage* those who benefit from free software to give back; but we decided early on as a project that *requiring* people to give back was a higher price than we were willing to accept. > Even here http://people.debian.org/~bap/dfsg-faq.html As that URL suggests, this is not an official statement of the Debian project, it's a document maintained by one individual Debian developer. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: AGPLv3 Compliance and Debian Users
Steve Langasek wrote: Let's not forget that Al Capone was convicted not for murder, racketeering, or bootlegging, but for tax evasion; and that the US tax code specifies where on your tax form you are required to report income from the sale of illegal drugs. It would be ironic for a dissident to evade capture and prosecution for years, only to finally be brought up on charges of criminal copyright infringement (with or without the consent of the copyright holder!) for failing to submit their changes upstream while operating clandestinely. Indeed. If you're a dissident fighting your own government, then complying with a license that can only be enforced by a government agency is probably the least of your worries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- 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/51df60f3.10...@symas.com
