Debian accepting Social Micropayment?
Hello, there is a new advent on the Internet horizon which is the social micropayment. Regular web users pay in some money and distribute that with respect to their clicks in the web. I feel that Debian should somehow participate with that, i.e. we should have links whenever we display a package in the bts or in the pts, that allows the user to flattr or otherwise support that package. The amount collected should then go to upstream. Maybe we should not do this for all packages but only when upstream asks for it. Needless to say, there should be separate opportunities for Debian and its Blends to collect money by the same mechanism. What do you think? We don't talk about much money here. At least not yet. It is more of a general decision. And it is also interesting to see what bits of Debian, beyond popcon, the users like best. Many greetings Steffen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6aa493.2080...@gmx.de
Re: Debian accepting Social Micropayment?
Hi, On Tue, Aug 17, 2010 at 05:02:43PM +0200, Steffen Möller wrote: flattr or otherwise support that package. The amount collected should then go to upstream. Maybe we should not do this for all packages but only when upstream asks for it. I guess we as a project will already run into disagreement at this point. There are two things to think about: 1) The user might think that the money goes to the Debian Developer who takes care of the package and eventually wants this as well. Eventually he might think the other way round. Can we make sure that we know at whom his money is directed? 2) Not every *developer* in our project might agree that this money should then go to upstream. After all we have packages which are *quiet* a lot of work for the Debian developers maintaining them. They might find it unfair to see users spending money (possibly on their work) which then ends in the hands of other people. Sure, they are doing open source and shouldn't expect money from it. But as soon as money is collected on a per-package-basis this topic might arise. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100817152404.ga5...@debian
Re: Debian accepting Social Micropayment?
On Tue, Aug 17, 2010 at 05:02:43PM +0200, Steffen Möller wrote: Hello, there is a new advent on the Internet horizon which is the social micropayment. Regular web users pay in some money and distribute that with respect to their clicks in the web. I feel that Debian should somehow participate with that, i.e. we should have links whenever we display a package in the bts or in the pts, that allows the user to flattr or otherwise support that package. The amount collected should then go to upstream. Maybe we should not do this for all packages but only when upstream asks for it. Needless to say, there should be separate opportunities for Debian and its Blends to collect money by the same mechanism. What do you think? We don't talk about much money here. At least not yet. It is more of a general decision. And it is also interesting to see what bits of Debian, beyond popcon, the users like best. I dislike the thought of endorsing and promoting specific monetary mechanisms, which is in reality what we do by adding such links. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Debian accepting Social Micropayment?
On 08/17/2010 05:43 PM, Jonas Smedegaard wrote: On Tue, Aug 17, 2010 at 05:02:43PM +0200, Steffen Möller wrote: Hello, there is a new advent on the Internet horizon which is the social micropayment. Regular web users pay in some money and distribute that with respect to their clicks in the web. I feel that Debian should somehow participate with that, i.e. we should have links whenever we display a package in the bts or in the pts, that allows the user to flattr or otherwise support that package. The amount collected should then go to upstream. Maybe we should not do this for all packages but only when upstream asks for it. Needless to say, there should be separate opportunities for Debian and its Blends to collect money by the same mechanism. What do you think? We don't talk about much money here. At least not yet. It is more of a general decision. And it is also interesting to see what bits of Debian, beyond popcon, the users like best. I dislike the thought of endorsing and promoting specific monetary mechanisms, which is in reality what we do by adding such links. I agree. If we go for one, then we should go for all. This is also why I would like Debian to collect the money and forward it in batches, rather than forwarding to a collection page of upstream (which we could also do). Cheers, Steffen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6ab472.3030...@gmx.de
Re: Debian accepting Social Micropayment?
Hi, On Tue, 17 Aug 2010, Steffen Möller wrote: there is a new advent on the Internet horizon which is the social micropayment. Regular web users pay in some money and distribute that with respect to their clicks in the web. I feel that Debian should somehow participate with that, i.e. we should have links whenever we display a package in the bts or in the pts, that allows the user to flattr or otherwise support that package. The amount collected should then go to upstream. Maybe we should not do this for all packages but only when upstream asks for it. I don't think we should do that. But Debian might want to use Flattr to collect donations of Flattr users (but those donations would be for Debian itself). See thread on debian-www: http://lists.debian.org/debian-www/2010/07/threads.html#00086 We should not put Flattr buttons everywhere, only in the usual donation page. That said I plan to write a software that scans the installed packages, and propose to flattr the corresponding upstream projects that are using Flattr. This would be a part of the Flattr Foss project (http://raphaelhertzog.com/flattr-foss/). Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100817192233.gb24...@rivendell
Re: Debian accepting Social Micropayment?
Steffen Möller steffen_moel...@gmx.de writes: there is a new advent on the Internet horizon which is the social micropayment. Regular web users pay in some money and distribute that with respect to their clicks in the web. I feel that Debian should somehow participate with that, i.e. we should have links whenever we display a package in the bts or in the pts, that allows the user to flattr or otherwise support that package. The amount collected should then go to upstream. Maybe we should not do this for all packages but only when upstream asks for it. So far, these systems look like a great way for the micropayment broker to make money and rather iffy for everyone else involved. I'm dubious about the desirability of the project as a whole making a substantial contribution to Flattr, which in practice is what this would mean at the moment. However, I've not researched it thoroughly, and might change my mind about this particular objection if someone can point me at a detailed financial accounting from the micropayment broker that shows: 1. Exactly how much money they're taking in from donations and from fees, with full accountability to the community for all fees and how they're being charged. 2. An overall overhead rate (meaning money that goes to the brokerage rather than to the intended projects via any means, whether it be fees or percentages) that's on the order of the overhead charged by credit card processing (less than 5%). Ideally, they should be run on the same business model as Kiva or Network for Good where they don't take *any* overhead and are instead supported entirely by separate donations directly to the non-profit micropayment broker. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aaoldnp6@windlord.stanford.edu
Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On su, 2010-08-15 at 06:25 +1200, Lars Wirzenius wrote: So we have at least three suggestions on the table now: 1. Rename Maintainer: to Contact: 2. Rename Maintainer: to Upstream-Contact: and Name: to Upstream-Name: 3. Drop both Maintainer: and Name: completely, even as optional fields All three seem to have reasonable justifications. I'd like to see if we have a rough consensus favoring one of them. Can we see a show of hands, please? (If we don't, I'll have choose myself, and then it'll be 3.) It's my assessment that the rough consensus is in favor of either 2 or 3, with 3 getting more explicit votes, but 2 not getting any resistance, and having the justification that it's useful to a number of people. Thus, I will modify the spec to implement option 2. If there are objections to this, I'll be happy to revert the change until they're discussed. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282075868.12989.122.ca...@havelock
DEP-5: general file syntax
There would seem to be at least a rough consensus that DEP-5 should follow Policy 5.1 on control file syntax. The open question how to specify that: it is my understanding that most people favor just referring to the relevant Policy section and not duplicate things in DEP-5, but since that is also my strong preference, I want to be careful. Here's my current suggestion: * We refer to Policy 5.1 by section number, section title, and URL. I don't think the policy version is necessary: if they make incompatible changes, then all Debian control files will potentially break, and DEP-5 copyright files are no exception. Including the 5.1 section verbatim in DEP-5, on the other hand, results in duplication, which is likely to result in divergence between the policy and DEP-5. * We add to DEP-5 details of how to handle values of multiline fields. We can discuss exact wording of that later (see below), if we can get consensus on the overall topic of file syntax. * Once DEP-5 is accepted, we move it into the debian-policy package; it will then be maintained via the normal policy amendment process on the debian-policy mailing list. If section 5.1 changes (including just number), the DEP-5 spec shall be changed at the same time. * We specify the debian/control Format: field to include an identifier that is not dependent on the DEP-5 URL. Currently, the spec includes a URL to the specific version of itself; this is obviously problematic. I suggest we change it by having two words in the Format: value: an unversioned URL to the spec (currently to the DEP site, but later to the debian-policy site), and a date. Comments on the above? The rest of this e-mail proposes a specific way of handling multiline values. - - - On to fields with multiline values. Well, every field can have multi-line values, but the generic rules suffice for most of them. There are three important details here: for specific fields, are newlines significant, can word-wrapping happen, and how empty lines are handled. For License, the text in the field (except the first line) should probably not be word-wrapped, newlines are significant, and definitely empty lines need to be handled in some way. The reason word-wrapping shouldn't happen is that in many cases upstream licenses use ad hoc plain text formatting conventions, such as bulleted lists, and any word wrapping will mess that up. There is already rough consensus on how to handle empty line markup (read: same as Description in debian/control). For Disclaimer, and Comment if we add that, it might be helpful to have empty lines, but word-wrapping is definitely needed. Newlines are not significant. For simplicity, I will introduce a new term, desc-escape. This refers to the escaping of content similar to the way Description does it in debian/control: each line is prefixed with a space, except empty lines are replaced with a space and period. The Policy's specification is not usable for this, I think, because it goes much further than what DEP-5 needs. Note that I've dropped the possibility of prefixing escaped lines with a TAB character. It is a needless difference from Description, and would complicate parsers. So there are three cases: * License: newlines are significant, no word-wrapping, desc-escape is used. * Disclaimer (and Comment in the future): newlines are not significant, word-wrapping is OK, desc-escape is used. * Everything else: newlines are not significant, word-wrapping is OK, desc-escape is not used. Normal RFC822-style handling of line continuations applies. In other words, for Disclaimer, a formatter would un-escape (remove leading space, replace lines with just period with empty ones), then split the resulting text into paragraphs at empty lines, and format those paragraphs in whatever manner it sees fit. I echo Charles's suggestion that we specify the way escaping is done in the section that describes the overall syntax, and then specify for each field if they use desc-escape or not, whether newlines are significant or not, whether the content can be word-wrapped or not. Comments on this part? I haven't got specific wording changes to suggest yet, I want to know if this approach is acceptable first, before we spend time on wording details. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282080573.12989.179.ca...@havelock
Re: [OT] Re: [DEP5] [patch] Renaming the ‘Maintainer’ field ‘Contact’
On ma, 2010-08-16 at 16:19 +1200, Lars Wirzenius wrote: * a 24-hour moratorium on posting about DEP-5 at all That went well. Thank you everyone for giving space to breathe. * after that is over, not discussing every possible topic at once, just a couple at a time I've commented on two topics (general file syntax, in a new thread, and globbing syntax in the existing one). I would find it practical if we could stick to those for now, unless there is something urgent. This way, I think we can more easily keep track of what's going on, and this will help build consensus much faster. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282081184.12989.188.ca...@havelock
Re: Debian accepting Social Micropayment?
Hello, On 08/17/2010 09:49 PM, Russ Allbery wrote: Steffen Möller steffen_moel...@gmx.de writes: there is a new advent on the Internet horizon which is the social micropayment. Regular web users pay in some money and distribute that with respect to their clicks in the web. I feel that Debian should somehow participate with that, i.e. we should have links whenever we display a package in the bts or in the pts, that allows the user to flattr or otherwise support that package. The amount collected should then go to upstream. Maybe we should not do this for all packages but only when upstream asks for it. So far, these systems look like a great way for the micropayment broker to make money and rather iffy for everyone else involved. I'm dubious about well certainly they get a share. the desirability of the project as a whole making a substantial contribution to Flattr, which in practice is what this would mean at the moment. I am in no way tied to Flattr. If you know something better then let's go for that. And we could indeed postpone any per-package-collection until we have some more experience with it all. Steffen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6b116f.4040...@gmx.de
Re: DEP-5: general file syntax
Le Wed, Aug 18, 2010 at 09:29:33AM +1200, Lars Wirzenius a écrit : For Disclaimer, and Comment if we add that, it might be helpful to have empty lines, but word-wrapping is definitely needed. Newlines are not significant. Hi Lars, some debian/copyright files contain extracts of correspondance between the maintainer and an upstream person, for instance when the status of some files need to be clarified. Would they be removed, transferred to a non-parsable section of the file (with a mechanism to be determined, for instance similar to DEP-3), or would they be suitable for comment fields (if we introduce them). In the case they are put in a comment field, ignoring newlines is likely to make them difficult to read. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100818012041.gb5...@merveille.plessy.net
Re: DEP-5: general file syntax
Charles Plessy ple...@debian.org writes: Le Wed, Aug 18, 2010 at 09:29:33AM +1200, Lars Wirzenius a écrit : For Disclaimer, and Comment if we add that, it might be helpful to have empty lines, but word-wrapping is definitely needed. Newlines are not significant. some debian/copyright files contain extracts of correspondance between the maintainer and an upstream person, for instance when the status of some files need to be clarified. Would they be removed, transferred to a non-parsable section of the file (with a mechanism to be determined, for instance similar to DEP-3), or would they be suitable for comment fields (if we introduce them). In the case they are put in a comment field, ignoring newlines is likely to make them difficult to read. I wonder if we should have some terminator for the machine-readable portion of debian/copyright, below which is free-form supporting material like complete e-mail exchanges and whatnot. That seems to me like the best way of handling the problem of attaching a complete e-mail exchange. Those exchanges aren't the actual license or copyright information, which can still be stated in a structured form. They're usually just defenses of why thet claimed license information is what it is (when it may, for example, contradict or supplement information included in the source files). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq38btm0@windlord.stanford.edu
Re: DEP-5: general file syntax
On ti, 2010-08-17 at 18:24 -0700, Russ Allbery wrote: Those exchanges aren't the actual license or copyright information, which can still be stated in a structured form. They're usually just defenses of why thet claimed license information is what it is (when it may, for example, contradict or supplement information included in the source files). Hmm. If the e-mails (or whatever) modify or clarify the license, should not the e-mails be considered part of the license information? License: other This software is released under the GPLv2 blahblah. . From: Upstream Author aut...@upstream.example.com Message-Id: loof.li...@upstream.example.com Date: Mon, Apr 01 2010 04:01:00 +0401 Subject: License clarification . When I say GPL I actually mean LGPL, sorry about that. If the e-mail is just a clarification to the license and does not modify it, then I guess License is not the right place. Rather than munge it into Comment, I guess we need a new field. However, how often do these things happen? If it is very rarely, we could just live with appending them to License. Having part of the file be non-machine-readable might be an option, but I have the feeling that for large debian/copyright files, it'd be easier to have these e-mails near the paragraphs that concern them, otherwise it'll get too difficult to keep track of things. So a structured approach would be my preference here. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1282108302.12989.199.ca...@havelock
Re: DEP-5: general file syntax
On Tue, Aug 17, 2010 at 06:24:39PM -0700, Russ Allbery wrote: I wonder if we should have some terminator for the machine-readable portion of debian/copyright, below which is free-form supporting material That would be the simplest way, a 'stop reading here' line for the parsers. That way anything that is supplementary can go there. It probably needs to be documented that nothing that places extra restrictions or conditions can go there though. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100818051302.ga11...@enc.com.au
Re: DEP-5: general file syntax
On Wed, 18 Aug 2010, Lars Wirzenius wrote: If the e-mail is just a clarification to the license and does not modify it, then I guess License is not the right place. Rather than munge it into Comment, I guess we need a new field. However, how often do these things happen? If it is very rarely, we could just live with appending them to License. In this case, I suspect that you have a change to the License (it's really LGPL) and you have an e-mail as evidence. So something like: File: * Licence: LGPL Evidence: From: Upstream Author aut...@upstream.example.com Message-Id: loof.li...@upstream.example.com Date: Mon, Apr 01 2010 04:01:00 +0401 Subject: License clarification . When I say GPL I actually mean LGPL, sorry about that. may be an option. [I'm thinking that in the normal case, Evidence would be assumed to be headers in the files themselves or a COPYING, COPYRIGHT, LICENSE, or similar file in the source repository, so you wouldn't include it.] It may also be important to be able to later verify PGP signatures or similar, so perhaps some simple transform to e-mail messages would be acceptable? Maybe something like: s/^(\.+)$/.$1/; s/^$/.//; s/^/ /; with the obvious reversal of: s/^ //; s/^\.(\.*)$/$1/; with non-important header removal allowed. (We probably only need From, Message-Id, Date, Subject, Content-Type?) Don Armstrong -- Do not handicap your children by making their lives easy. -- Robert Heinlein _Time Enough For Love_ p251 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100818054628.gt17...@teltox.donarmstrong.com
