Re: Question to all candidates: GDPR compliance review
On Fri, Apr 05, 2024 at 04:38:57PM +0200, Andreas Tille wrote: > Hi Adrian, Hi Andreas, > Am Fri, Apr 05, 2024 at 12:41:17AM +0300 schrieb Adrian Bunk: >... > > Many parts of Debians Privacy Policy look questionable. > > > > For example the rights are not stated, and in addition to this being a > > formal problem there is also the question whether for example the Debian > > Data Protection team does fulfil the right to request only where > > required by law or whether all people around the world are treated > > the same. > > I need to admit I do not understand this example. the Privacy Policy lacks explicit statements of the rights like You have the right to request a copy of all personal data. that are legally required. An explicit statement would also make it clear whether or not Debian might extend such rights to people not covered by the GDPR. > > The attempts in the Privacy Policy for blanket eternal storage > > of data might not pass a legal review, especially when this might > > contain sensitive data like sexual orientation or political opinions. > > I'm not aware that those personal data are stored. If this is really > the case you have a point. During the RMS GR I was often thinking "assume RMS was living in the EU". The archives of debian-vote contain plenty of sensitive data like political opinions of RMS where it is questionable that they could be stored forever if the GDPR applied. And who in Debian would have been responsible of informing him that sensitive personal data about him is being stored by Debian that was provided by third parties? >... > > I would be glad to hear from a qualified person that I am wrong and that > > all handling of personal data by these teams is lawful. > > If I understand you correctly you want to know my opinion whether Debian > should pay some lawyer specialized in data privacy to inspect "all > handling of personal data", right? Yes. > > There is also a personal side for me: > > > > I am feeling quite unsafe in Debian due to not knowing what data people > > in positions of power in Debian who dislike me might have about me, and > > I want to request all data about me in Debian. This is also a prerequisite > > for exercising the right of rectification of inaccurate personal data if > > any data turns out to be incorrect. > > While I may be somewhat naive, I'm unaware of any positions within > Debian that hold the power to harm others. IMHO, the most troubling > aspect is your feeling that there are individuals who dislike you. If > you really feel unsafe about this situation IMHO the first step should > be to talk to some individual you are trusting inside Debian. >... If I send an email requesting all data Debian has about me to data-protect...@debian.org, will I receive a complete reply within the expected time, including all data members of delegations like the Debian Account Managers and the Community Team might have? > Kind regards > Andreas. >... cu Adrian
Question to all candidates: GDPR compliance review
Hi, this email has two parts: A short question where I would appreciate a "yes" or "no" answer from all candidates, and a longer explanation what and why I am asking. Question: If elected, will you commit to have a lawyer specialized in that area review policies and practices around handling of personal data in Debian for GDPR compliance, and report the result of the review to all project members by the end of 2024? Explanation: One might discuss whether or not Debian should aim at being better than average in the area of privacy, but compliance with the law is the minimum everyone can expect. Unlawful actions can have consequences, organizations and individuals might be subject to fines up to 20 Million Euro as well as compensation for material and non-material damage, and in some countries also prosecution under criminal law. Many parts of Debians Privacy Policy look questionable. For example the rights are not stated, and in addition to this being a formal problem there is also the question whether for example the Debian Data Protection team does fulfil the right to request only where required by law or whether all people around the world are treated the same. The attempts in the Privacy Policy for blanket eternal storage of data might not pass a legal review, especially when this might contain sensitive data like sexual orientation or political opinions. I also suspect that the Debian Account Manager and Community Teams might be abusing people by illegally processing data outside of what is being permitted by the Privacy Policy. I would be glad to hear from a qualified person that I am wrong and that all handling of personal data by these teams is lawful. There is also a personal side for me: I am feeling quite unsafe in Debian due to not knowing what data people in positions of power in Debian who dislike me might have about me, and I want to request all data about me in Debian. This is also a prerequisite for exercising the right of rectification of inaccurate personal data if any data turns out to be incorrect. I would wish that Debian itself can ensure that all handling of personal data is lawful, and that GDPR requests are being fulfilled without problems - like everywhere else. Other places with DDs also have laws protecting personal data (at least California, China, Brazil, South Africa, Singapore). I am asking specifically about GDPR since that affects me directly, but either during the GDPR review or afterwards it would of course be good to also obtain legal advice whether there are additional requirements in other jurisdictions. Thanks Adrian
Re: Question to all candidates: GDPR compliance review
On Sat, Apr 02, 2022 at 12:21:24PM +0200, Christian Kastner wrote: > On 2022-04-02 10:55, Adrian Bunk wrote: > > Where does our Privacy Policy[1] describe personal data where Debian and > > the community team are joint controllers? > > > Where does our Privacy Policy describe personal data where Debian and > > DAM are joint controllers? > > Has it been established yet that Debian fits the definition of a > controller as per Article 4 lit. 7 GDPR? > > I can see DAM, or CT, or the DPL possibly being controllers. What is the identity of DAM or CT? Likely each individual team members is a controller. If a person has suffered material or non-material damage as a result of a GDPR infringement, each controller or processor can be held liable for compensation of the entire damage (Article 82(4)). > But > without some form of officially recognized organization, I don't see how > Debian could be one. "Debian" doesn't even have an address, you couldn't > even determine which data protection authority has jurisdiction. What is "The Debian Project" in the Privacy Policy[2]? Providing the identity and the contact details of the controller is mandatory for processing of personal data (Articles 13(1)(a) and 14(1)(a)), failure to do so is subject to administrative fines of up to 20 Million Euro (Article 83(5)(b)). > This is just one of the things that, I think, would be a lot simpler if > Debian would register as an organization, hence my question [1] to the > candidates. >... This is likely required and desirable, as was also discussed in the thread starting with [3]. cu Adrian [1] Here in Finland the threshold for gift tax is 5000 Euro. [2] https://www.debian.org/legal/privacy [3] https://lists.debian.org/debian-project/2022/03/msg8.html
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 09:25:46PM +0200, Jonathan Carter wrote: > On 2022/04/01 20:28, Adrian Bunk wrote: > > Would you commit to something more specific, like that our Data > > Protection team will reply to debian-project within 3 months discussing > > all issues mentioned in the discussion at [1] so far, and with their > > reply having been proof-read by our GDPR lawyer? > > > [1]https://lists.debian.org/debian-project/2022/03/msg8.html > > That mail asks a bunch of very, very broad questions. My opinion is that > it's better to direct specific problems at the data protection team as > noodles suggested. Then let's start with some very specific questions based on the email I just sent to Sam: Where does our Privacy Policy[1] describe personal data where Debian and the community team are joint controllers? On what legal basis is the data processed? Where is the data physically stored? Who has access to the data? For what purposes might the data be used? What retention period is defined for the data? How are people being informed when data about them is being stored? Where does our Privacy Policy describe personal data where Debian and DAM are joint controllers? On what legal basis is the data processed? Where is the data physically stored? Who has access to the data? For what purposes might the data be used? What retention period is defined for the data? How are people being informed when data about them is being stored? These are specific questions about items that are supposed to be written in our Privacy Policy. > -Jonathan cu Adrian [1] https://www.debian.org/legal/privacy
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 04:57:38PM -0600, Sam Hartman wrote: > >>>>> "Adrian" == Adrian Bunk writes: > Adrian> Your "services" approach does not work for the non-trivial > Adrian> cases where Debian might be a (joint) controller of personal > Adrian> data. > > Adrian> The Debian Community Team promises confidentiality regarding > Adrian> personal information they receive about other people,[1] > Adrian> which conflicts with the legal obligation of informing the > Adrian> person about whom personal information is being processed or > Adrian> stored. > > Based on legal advice I received while acting as DPL, the above is not > correct. > Most of the information the community team process is not information we > would need to disclose in response to a GDPR subject access request. Where does Debians Privacy Policy[1] describe this personal data where Debian and the community team are joint controllers? Where is the data stored? Who has access to the data? For what purposes might the data be used? What retention period is defined for the data? > Debian has already dealt with at least one subject access request that > dealt significantly with information held by DAM in its role as a > delegated team. Where does Debians Privacy Policy[1] describe this personal data where Debian and DAM are joint controllers? > Some of that information was responsive; some of that information was > covered by exceptions. This covers only a part where Debian might be compliant with the law. >... > > If the personal information in the handwritten note did not come > > directly from the person, who at Debian is responsible to ensure that > > the person gets informed automatically about the existence of the note > > when it is written? >... Exceptions might cover not having to disclose the contents of the data in some cases, but I would still expect that the person has to be informed that information exists. See [2] for background in what context I started thinking about these issues. >... > The data protection team was looped into the process we and our lawyer > used in responding to the request. > The data protection team (and my successor as DPL) received copies of > the legal advice we received. Are you saying that all handling of personal data in Debian is following the law, or are you just trying to make me stop asking inconvenient questions? I am feeling stonewalled and stalled regarding any attempts of receiving a review of handling of personal data in Debian, with a schedule that would be appropriate for potential illegal activity. I would like to emphasize and repeat [3,4]: IANAL and it is more likely than not that some things I am writing are not correct. What I want is to see the results of a proper review by an actual lawyer. If I fail to achieve visible progress on this topic inside Debian, the obvious option for getting a second opinion is to make a formal request for all personal data about me in Debian, followed by asking my questions to the Finnish Data Protection Ombudsman. If everything I am writing is just wrong, then I will be told just that by the ombudsman. > --Sam cu Adrian [1] https://www.debian.org/legal/privacy [2] https://lists.debian.org/debian-project/2022/03/msg00010.html [3] https://lists.debian.org/debian-project/2022/03/msg8.html [4] https://lists.debian.org/debian-vote/2022/03/msg00270.html
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 09:18:53PM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk > > > Who will fulfill the request within the legal limit of one month if > > a person sends an email to data-protect...@debian.org asking whether > > Debian is a (joint) controller of any data about this person, and > > if yes requests a copy of all data? > > To make this easier for services and users, we recommend that services > use contributes.debian.org and that they then request the data from the > individual services and then point people at that. Your "services" approach does not work for the non-trivial cases where Debian might be a (joint) controller of personal data. The Debian Community Team promises confidentiality regarding personal information they receive about other people,[1] which conflicts with the legal obligation of informing the person about whom personal information is being processed or stored. Debian might be a joint controller if a member of the Debian Community Team stores personal information about a person in a handwritten note on paper (see [2] as an example of case law about handwritten notes)[3]. Will this handwritten note be available through contributors.debian.org? If the personal information in the handwritten note did not come directly from the person, who at Debian is responsible to ensure that the person gets informed automatically about the existence of the note when it is written? Same questions, with "local file" instead of "handwritten note". Same questions, with "stored on a Debian machine". Discussing such questions with a lawyer early is usually cheaper and less hassle than waiting until someone brings them up in a court case. > Cheers, cu Adrian [1] https://wiki.debian.org/Teams/Community [2] https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:62017CJ0025&from=EN [3] This court case was under the previous Directive from 1995, but the basic definitions are unchanged in the GDPR legislation that replaced it.
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 08:46:42PM +0200, Tollef Fog Heen wrote: > ]] Adrian Bunk > > > Would you commit to something more specific, like that our Data > > Protection team will reply to debian-project within 3 months discussing > > all issues mentioned in the discussion at [1] so far, and with their > > reply having been proof-read by our GDPR lawyer? > > I don't think that's something the DPL could commit to, even if they > wanted to. First of all, what you're asking for is not what the data > protection team is there for, secondly, neither the DPL nor anyone else > has the ability to commit to anyone in Debian doing anything on any > particular timeline. > > If that's what you're looking for, you're looking for a company with > staff, not a volunteer project. One option would be to outsource this work to our paid GDPR lawyer. > Cheers, cu Adrian
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 07:40:02PM +0200, Tollef Fog Heen wrote: >... > This isn't the role of the data protection team, though, any more than > owner@bugs is responsible for fixing all the bugs in all the packages. > I'm quite happy to act as a redirector (as per the first part of the > delegation) as well as advising service owners. I have below-zero > interest in auditing all our services and tracking everything relevant > to data privacy throughout Debian. >... Who will fulfill the request within the legal limit of one month if a person sends an email to data-protect...@debian.org asking whether Debian is a (joint) controller of any data about this person, and if yes requests a copy of all data? If there is no reply within one month, the person can request an order from the local supervisory authority (e.g. [1] is the online form for such requests in my country of residence). > Cheers, cu Adrian [1] https://tietosuoja.fi/en/find-out-whether-the-data-protection-ombudsman-can-help-you-rights
Re: Question to all candidates: GDPR compliance review
On Fri, Apr 01, 2022 at 07:02:15PM +0200, Jonathan Carter wrote: > Hi Adrian Hi Jonathan, >... > I'm not sure bringing in the lawyer as a first step is optimal, they are > expensive and will probably tell us a lot of things we already know. IMHO > it's better to do some initial groundwork, compile a list of issues that we > need help on, and then take that to the lawyer for further input. usually trying to solve legal issues without consulting a lawyer early ends up being more expensive. >... > So, I would appreciate it if the data protection team could look into all of > the issues we know of in Debian, but I'd also like there to be a process > where people can file issues with the data protection team. >... > So, I think it's more important to take care of known issues and low hanging > fruit before getting a lawyer involved. I also think it's a good idea to > make it easy to file issues as they are found, and would like to know if the > Data Protection team has any ideas or if they would consider implementing > anything like the above. It might not have been intended, but to me this comes across like stalling, trying to avoid addressing the big problems - we all know from our BTS that "filing issues" does not necessarily imply that anything will ever happen. Would you commit to something more specific, like that our Data Protection team will reply to debian-project within 3 months discussing all issues mentioned in the discussion at [1] so far, and with their reply having been proof-read by our GDPR lawyer? > -Jonathan cu Adrian [1] https://lists.debian.org/debian-project/2022/03/msg8.html
Question to all candidates: GDPR compliance review
The discussion starting in [1] is about privacy in Debian with a focus on the GDPR of the European Union. There seems to be a general agreement that privacy in Debian falls short of the legal minimum requirements at least in the EU. Even the exact scope of the problem is not clear. Question to all candidates: If elected, will you ask our Data Protection team and our GDPR lawyer to jointly do a review of all handling of personal data in Debian regarding GDPR compliance, and make the results of the review available to all developers? Thanks Adrian [1] https://lists.debian.org/debian-project/2022/03/msg8.html
Re: General resolution: Condemn Russian invasion of the Ukraine
On Thu, Mar 31, 2022 at 06:57:06PM +0200, Julian Andres Klode wrote: >... > At least for Taiwan and Kosovo, I think that by holding DebConfs in > those places and engaging with their self-determined governments we > have de-facto accepted them as self-determined sovereign nations. I think that you are 100% wrong on that. The handful people who are choosing Debconf locations cannot make political statements on behalf of the whole project. If a Debconf location is also considered a political statement as you imply then we have to choose Debconf locations by means of GR, starting with a GR right now whether Debian wants to consider Kosovo a self-determined sovereign nation by holding Debconf 2022 there. If Debian would ever consider Taiwan a self-determined sovereign nation, we would de facto exclude people in China from contributing to Debian. Is holding a Debconf in Israel a political statement by Debian that people in Palestine should not have to right to vote in any country? cu Adrian
Re: General resolution: Condemn Russian invasion of the Ukraine
On Thu, Mar 31, 2022 at 12:31:18PM +0200, Julian Andres Klode wrote: > Under 4.1.5 of the Constitution, the developers by way of GR are the > body who has the power to issue nontechnical statements. > > This is a proposal for Debian to issue a statement on an > issue of the day as given as an example, the recent invasion > of Ukraine. > > Text of GR > > The Debian project issues the following statement: > > The Debian project strongly condemns the invasion of Ukraine by > Russia. The Debian projects affirms that Ukrain is a souvereign > nation which includes the Donbas regions of Luhansk, as well as > Crimea, which has already been illegaly annexed by Russia. I do not believe that Debian starting issuing such statements for political issues of the day would be a good idea. Half the people on this planet are living in countries that did not approve the "Aggression against Ukraine" UN resolution, including many Debian contributors. Does the Debian project consider the territorial integrity of a country more important than the opinion of the majority of the people living in a part of the country? If the Debian project declares it considers Donbas and Crimea to be part of Ukraine, will the Debian project also declare that it considers Taiwan to be part of China? Does the Debian project support or oppose the independence of Catalonia? Kosovo is not a member of the United Nations, and many countries (including Ukraine) do consider Kosovo to be a part of Serbia. What is the position of the Debian Project on the political status of Debconf host Kosovo? Different from Kosovo and Taiwan, Palestine at least has observer status at the United Nations, and Palestine is recognized by more United Nations member countries than Kosovo and Taiwan combined. What is the position of the Debian project on the status of Palestine? Does the Debian project support sanctions against Russia? Does the Debian project support the BDS movement? Does the Debian project strongly condemn the Saudi intervention in Yemen? Are people who work for companies (co-)owned by the government of Saudi Arabia welcome in Debian? How should the Debian project treat people who participated in the invasion of the sovereign nation Iraq by the United States? There would be plenty of potential GRs for such issues of the day. Different Debian contributors do have different personal opinions on political topics like the ones above. Our Diversity Statement states that the Debian Project welcomes and encourages participation by everyone. Debian as a project expressing political opinions destroys diversity, technical collaboration in an international project works best when the project stays as far as possible away from taking sides in political topics of any kind. cu Adrian
Re: Secure, Secret, and Publicly Verifiable Voting
On Sun, Mar 06, 2022 at 11:31:22AM +, Barak A. Pearlmutter wrote: > In the discussion of the "voting secrecy" resolution, people seem to > have assumed that it is impossible for a voting system to be > simultaneously secure, tamper-proof, have secret ballots, and also be > end-to-end publicly verifiable meaning transparent verification of the > final tally, with voters able to verify that their own vote was > properly counted. (Our current system does not have secret ballots, > but does embody the other properties.) > > As it turns out, magic cryptographic fairy dust allows *all* these > properties to coexist. This is not to say that we *should* have secret > ballots. Just that we *could*, without sacrificing transparency etc. >... Isn't this how DPL elections are already done for 20 years? https://www.debian.org/vote/2002/voters.txt https://www.debian.org/vote/2002/tally.txt https://www.debian.org/vote/2021/vote_001_voters.txt https://www.debian.org/vote/2021/vote_001_tally.txt cu Adrian
Re: Draft proposal for resolution process changes
On Tue, Sep 28, 2021 at 01:38:48PM +0100, Simon McVittie wrote: >... > Also, I believe the rationale for this casting vote is the same as for > the existence of a casting vote in general: to make sure that the TC is > always able to make a decision, one way or another, and that there is > never an unresolved situation where the outcome of the vote is "there is > no decision". >... IMHO whenever there is no clear majority in the TC (let's say 3:1), the TC should use its power under 4.2.1. to propose a GR instead of making a decision. Past TC casting vote decisions that come into my mind are systemd and merged /usr. It would have been faster and less painful for the whole project had such decisions started by involving the whole project in a structured 2 week GR discussion followed by a democratic vote, instead of having years of mess and bad blood after a TC-only decision. > smcv cu Adrian
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Tue, Apr 20, 2021 at 04:41:46PM +0200, Jonas Smedegaard wrote: > Quoting Barak A. Pearlmutter (2021-04-20 16:12:16) > > Maybe looking at options 7/8 wasn't the best example, both because of > > perceived differences and because FD plays a special role. > > But with all the ballots we can find a bunch of votes that do seem to > > not use the full power of the ballot in ways that do seem a bit > > counterintuitive. > > Have a look for yourself, it's a fun exercise. > > A large number of voters stop ranking when they get to FD. I'm not > > sure why, but in many cases this renders their ballot pretty much > > powerless because options with a chance of winning are not ranked. > > > > The details are very interesting, but any discussion of the actual > > options leads back to discussing the topic of the GR proper, so I > > really don't want to go there. > > I appreciate this topic being brought up - it has affected my voting > style: Previously I thought that my voting powers stopped at FD. > > I don't think it makes sense to change the system to mandate use of all > voting power. >... Noone has suggested to remove any intentional way of voting. --12 and 8812 are equivalent when determining the result. --12 might be intentional or not knowing that voting below FD can decide the outcome. 8812 makes it clear that this is an intentional "Debian should stay out of politics" vote, with all other options considered equally bad. > - Jonas cu Adrian
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Sun, Apr 18, 2021 at 04:10:42PM -0400, Roberto C. Sánchez wrote: > On Sun, Apr 18, 2021 at 10:02:46PM +0200, Timo Röhling wrote: > > * Barak A. Pearlmutter [2021-04-18 20:30]: > > > I'm suggesting that, since we came within a razor (just ONE BALLOT, as > > > Adrian Bunk pointed out) of that situation actually occurring, we get > > > in front of things, think about it, and figure out something proactive > > > to prevent it from ever actually happening: to prevent us from ever > > > having to make such an embarrassing press release. > > Maybe a public statement in the name of all developers should require > > more than a simple 1:1 majority? > > Something like a 3:1 majority would ensure that the measure had a very > broad consensus behind it. I would like to think that it would result > in more constructive discussions. > > However, that seems likely to only work if there is a method for > drafting the statement first and then simply having an up or down vote. > The up or down vote is what Steve tried to accomplish by proposing the > GR to essentially adopt the text of the open leter. However, things > rapidly shifted as more options were added to the ballot. Whether a > "special" sort of GR is needed (one that doesn't allow for adding more > options) or an entirely different mechanism may need to be discussed. > > It isn't clear how all of it would work in practice. Nothing prevents more than one option with a 3:1 majority when there are several options that are widely considered acceptable on the ballot. In the current DPL election both candidates had a 4:1 majority. The 2019 DPL election had 4 candidates, every single candidate had at least a 6:1 majority. To make an example of a 3:1 majority requirement for public statements: Option 1: kittens are super cute Option 2: kittens are cute Option 3: kittens are not cute If option 1 has a 3:1 majority: - option 2 might also have a 3:1 majority, - but option 3 would be unlikely to have a 3:1 majority > Regards, > > -Roberto cu Adrian
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On Sun, Apr 18, 2021 at 06:58:49PM +0100, Barak A. Pearlmutter wrote: >... >... > If that arrow had been reversed (which > could be done by switching the order of two adjacent options on TWO > BALLOTS) >... On one ballot. Which brings us back to my suggestion that we should make ranking all options mandatory (with intentional equal ranking allowed) if we decide to continue using Condorcet, since this kind of decision of the whole vote can happen between the 7th and 8th choice on a ballot and the winner in the latest systemd vote was also decided between 7th and 8th choice. cu Adrian
Re: Missing Last call for votes
On Fri, Apr 16, 2021 at 05:12:33PM +0200, Kurt Roeckx wrote: > On Fri, Apr 16, 2021 at 05:53:39PM +0300, Adrian Bunk wrote: > > I noticed no No Last call for votes has been sent for either vote so far, > > which is usually sent around 48 hours before the end of a vote. > > > > Looking at graphs for past votes (e.g. [1] where one can easily see when > > the second and last calls for vote were) we seem to be disenfranchising > > between 20 and 100 DDs when no Last call for votes is sent, which is a > > significant proportion of the voting population. > > > > Many DDs might be only reading d-d-a, and might be used to using the > > Last call for votes as reminder to finally vote. > > I thought that the 48 hours was this night, not last night. I'll > sent it shortly. Thanks. > Kurt cu Adrian
Missing Last call for votes
I noticed no No Last call for votes has been sent for either vote so far, which is usually sent around 48 hours before the end of a vote. Looking at graphs for past votes (e.g. [1] where one can easily see when the second and last calls for vote were) we seem to be disenfranchising between 20 and 100 DDs when no Last call for votes is sent, which is a significant proportion of the voting population. Many DDs might be only reading d-d-a, and might be used to using the Last call for votes as reminder to finally vote. cu Adrian [1] https://www.debian.org/vote/2020/suppl_001_stats_detailed
Re: What does FD Mean
On Tue, Apr 13, 2021 at 07:43:50PM +0200, Adam Borowski wrote: >... > That's why we don't get pure donkey votes (12345678). >... With an ordered list of options, having the first 7 options ordered 1234567 is the correct choice if you favour the first option and agree with the order. Most people would insert FD somewhere in the middle, but this is not mandatory. For the systemd vote it makes sense that people voted "as much systemd as possible, but let's get a decision in any case to stop the arguing". 76542318 in that vote is the same from the other extreme position, with two adjacent options swapped in the order. cu Adrian
Re: Ways forward regarding the RMS GR
On Mon, Apr 12, 2021 at 02:20:37PM +0200, Ansgar wrote: > Adrian Bunk writes: > > Discussing and voting on a change to the constitution to make all votes > > secret could then be done in 1+1 weeks starting even before the current > > GR ends, followed by a secret vote on a new GR. > > The 1+1 weeks would only start after a proposal was made that no longer > needs changes (only minor changes do not reset the discussion period > under A.1.6). I don't think anyone already has a finished proposal in > their drawer. My statement is still true if there are a day or two discussing the exact wording before formally starting the GR. > And rushing changes to the constitution doesn't seem like a good idea. It sounds better to me than violating the constitution. It sounds better to me than changing the rules of an election after voting has already started. > Ansgar cu Adrian
Re: Ways forward regarding the RMS GR
On Mon, Apr 12, 2021 at 12:12:23PM +0200, Jonathan Carter wrote: >... > As for cancelling the vote, I see that as something that's a much more > severe route and that I won't be imposing as DPL. For that to happen > there would have to be significant consensus within the project that > would have to be able to convince our secretary. I doubt there's much > chance of that happening before the end of the vote. > > The situation might seem bleak, but it's not completely hopeless. It's > still possible for any member to vote FD above all other options if > needed >... If only individual members would do that, the only effect would be that they would hurt the options they would have otherwise voted above FD. A constitutional way out of the current mess would be a general agreement that a majority of voters votes FD first. It would be possible to vote only FD to keep your opinion secret, or fill a complete ballot if a member chooses to do so. Discussing and voting on a change to the constitution to make all votes secret could then be done in 1+1 weeks starting even before the current GR ends, followed by a secret vote on a new GR. > -Jonathan cu Adrian
Re: What does FD Mean
On Sun, Apr 11, 2021 at 11:27:28PM +0200, Timo Röhling wrote: > * Adrian Bunk [2021-04-11 20:53]: >... > > It can be hard to vote correctly in a voting system that is very > > different from what you are used to in real life, unless you are > > a nerd in voting systems. > If you ask me as someone who has never used a ranked vote before, it is > not that hard. The hard part is how the winner is determined from the > votes. I don't think many people will bother to independently verify the > results. It is not obvious that how you rank between 7 and 8 can decide the winner. Which is what happened at the latest systemd vote: 0 votes 78xx 42 votes 87xx Option 2 defeated Option 1 by 22 votes My suggestion would help people to make full use of their vote by forcing them to rank all options. Equal ranking is still possible, it would not remove your freedom to rank any number of options equally. cu Adrian
Re: What does FD Mean
On Sun, Apr 11, 2021 at 06:50:36PM +0200, Timo Röhling wrote: > > Besides, I am still unconvinced and mildly offended by the assumption > that people who voted 1--- were too stupid to do it right. >... I am not saying people were stupid. It can be hard to vote correctly in a voting system that is very different from what you are used to in real life, unless you are a nerd in voting systems. > Cheers > Timo cu Adrian
Re: Re: What does FD Mean
On Thu, Apr 08, 2021 at 10:51:26AM +0100, Barak A. Pearlmutter wrote: > Hey Adrian, Hi Barak, > > When looking at the tally of the latest systemd vote,[1] > > there are plenty of votes like > > 1--- > > > > It is obvious what these voters wanted to express, > > and that their ballot was wrongly filled due to a > > lack of understanding how our voting system works. > > That's really interesting. > > Maybe we should cobble up a GUI tool to download & correctly fill out > & sign & email a ballot? Instead of numbering items (which requires > knowing how to count) people could drag them into an order, etc. This > would allow inactive or non-uploading DDs, ones who can't manage (or > can't be arsed) to fill out and gpg-sign a ballot, to express their > valuable opinions. It could look for the right key using the > devscripts mechanisms, like ~/.devscripts DEBSIGN_KEYID and > environment variables and such. Maybe check if any available private > keys appear on the Debian keyring. That way people who haven't needed > their key in years could still vote. > > (Not sure if joking.) after thinking about it for a few days, I suggest the following change to the Constitution: +All options must be ranked. -Not all options need be ranked. -Ranked options are considered preferred to all unranked options. Voters may rank options equally. -Unranked options are considered to be ranked equally with one another. Such a change would not remove any voting options since votes like 1--- have equivalent espressions like 1222. But it would help voters who are not used to ranking from real-world elections. > --Barak. cu Adrian
Re: Re: What does FD Mean
On Thu, Apr 08, 2021 at 03:00:45PM +0500, Andrey Rahmatullin wrote: > On Thu, Apr 08, 2021 at 12:30:01PM +0300, Adrian Bunk wrote: > > Instead of "attack surface" of a complicated system I would be more > > worried about the problem that a part of our electorate does not > > understand how to vote in a way that their ballot matches what > > they want to express. > > > > When looking at the tally of the latest systemd vote,[1] > > there are plenty of votes like > > 1--- > > > > It is obvious what these voters wanted to express, > Which is? Option 1 is the only acceptable option. > > and that their ballot was wrongly filled due to a > > lack of understanding how our voting system works. > Do you mean they should have also ranked some less-preferred options above > FD or that they chose a wrong option? If option 1 (or several options at the left side of that vote) were the only ranked options on a ballot, it is hard to believe that not ranking option 8 above option 6 was intended. Regarding the majority criteria they might have voted 1--2 With Condorcet not ranking among other options is a waste of part of your vote. People preferring option 1 likely considered option 2 tolerable and clearly better than options like option 6, which would result in ballots like for example 13-2 12-3 12345--6 13456782 > WBR, wRAR cu Adrian
Re: Re: What does FD Mean
On Mon, Apr 05, 2021 at 12:15:25PM +0100, Barak A. Pearlmutter wrote: > > Making a system more complicated to try and address a specific > deficiency rarely reduces its attack surface. In this case, our voting > system involves multiple levels (quorum, majority, ranking resolution) > each with its own criteria and threshold and (due to Arrow's Theorem) > unavoidable flaws, and every feature of this sort increases the > system's attack surface to both strategic voting and to just plain > doing the wrong thing given honest votes. Moving FD around in the > ordering is an example of this, as is a quorum boycott. > > Since voting systems are necessarily vulnerable (Arrow's Theorem!) our > objective cannot be perfection, but rather good performance under > realistic conditions. >... Instead of "attack surface" of a complicated system I would be more worried about the problem that a part of our electorate does not understand how to vote in a way that their ballot matches what they want to express. When looking at the tally of the latest systemd vote,[1] there are plenty of votes like 1--- It is obvious what these voters wanted to express, and that their ballot was wrongly filled due to a lack of understanding how our voting system works. > Cheers, > > --Barak. cu Adrian [1] https://www.debian.org/vote/2019/vote_002_tally.txt
Re: Re: What does FD Mean
On Mon, Apr 05, 2021 at 06:35:52AM -0700, Felix Lechner wrote: >... > would it be better for a voting system to > quadruple-count, or otherwise strengthen, options voters rank in the > middle—thereby recognizing that a compromise between two or more sides > is always a prerequisite for peace? This is the first time Debian holds a GR for a position statement about issues of the day outside of Debian. There is a valid question whether or not a 2:1 or 3:1 majority requirement would be more appropriate for such GRs. > Kind regards > Felix Lechner >... cu Adrian
Re: What does FD Mean
On Mon, Apr 05, 2021 at 02:34:28PM +0200, Pierre-Elliott Bécue wrote: > Le lundi 05 avril 2021 à 14:07:13+0200, Marc Haber a écrit : > > On Mon, Apr 05, 2021 at 12:15:25PM +0100, Barak A. Pearlmutter wrote: > > > Making a system more complicated to try and address a specific > > > deficiency rarely reduces its attack surface. In this case, our voting > > > system involves multiple levels (quorum, majority, ranking resolution) > > > each with its own criteria and threshold and (due to Arrow's Theorem) > > > unavoidable flaws, and every feature of this sort increases the > > > system's attack surface to both strategic voting and to just plain > > > doing the wrong thing given honest votes. Moving FD around in the > > > ordering is an example of this, as is a quorum boycott. > > > > I have been a DD for nearly 20 years and I have not yet understood how > > we vote. Before I joined Debian, I thought that the way Germany votes > > for the Bundestag is a complex method. > > > > Greetings > > It's probably because I'm a mathematician, but I really enjoy our voting > system, despite it also having flaws. For me it is also mostly mathematical curiosity, and there is no situation in real-life elections where it would be relevant. Voting methods like Condorcet try to solve problems in single-round first-past-the-post systems with more than 2 candidates that are common in the UK and some former British colonies. For people living in a country like Germany where the shares of representation in parliament are based on the nationwide vote, Debian is usually the first and only contact with anything like Condorcet. cu Adrian
Re: Re: What does FD Mean
On Mon, Apr 05, 2021 at 11:46:23AM +0200, Kurt Roeckx wrote: >... > A possible solution is to drop the majority requirement > and have a quorum on the number of people that vote >... A quorum on the number of people who vote means that a vote against the proposal counts for the quorum. Assuming a quorum high enough, this gives a coordinated boycott of the vote a higher chance of defeating a proposal than voting against it. > Kurt cu Adrian
Re: What does FD Mean
On Mon, Apr 05, 2021 at 12:47:58AM +0200, Kurt Roeckx wrote: >... > But the reason for yes/no is the majority requirement. In this GR > all options have a majority ratio of 1. This means more people > need to put the option above of FD than people who put the option > below FD, or the option gets dropped. >... On a side note, there is a bug in the vote counting software or its configuration where it would generate a nonsensical result that also violates explicit wording of the constitution in a corner case. The constitution says: An option A defeats the default option D by a majority ratio N, if V(A,D) is greater or equal to N * V(D,A) and V(A,D) is strictly great >From the latest systemd GR[1]: * Option5 passes Majority. 2.185 (271/124) >= 1 * Dropping Option6 because of Majority. 0.808 (173/214) <= 1 >= 1 is not strictly great, and an option both passing the majority requirement and being dropped for failing the majority at the same time in the = 1 case would not make sense. > Kurt cu Adrian [1] https://www.debian.org/vote/2019/vote_002
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > Short and simple: > > TEXT OF OPTION 5 > > > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. > > seconded cu Adrian -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAmBoeNEACgkQiNJCh6LY mLF1ww//SyNy0I8hw+ZXb/hgPOIsyI4grdEQrLPvIaNASyybrmeWnMuLGytS5Cl9 ENDINF+AiboAuQ6b+6nOZeQl9jfHMWm0ScS62+m46tpYXq6NAgbnoQyk7zlPT3a2 RbjCLCzIELLzcsvUB9vi3cC3cBInqdRRGocl/4+8X9SbNC1vjM59d0BMkWThPFax 5AWfiIpGtjtvKUeOBeOpBQXOY6jrvIgP/2yU2I5skJOLCcqoI5epylJdxty9PsUS zzxMRatoc+l5WmJCyQzsR5UfDRX5Ik+nAqfRZm+cmwmAZvuT70Xl2plu88L4HA9Q oiP5oSO27QgunPNRfr1w5r9Z7AbKLPp1O8TycdZ19LhdTl33kPe40gMU6QfTbFHT P5almyTDmLtfJtXFSiKQi2lL3XM+PDMOkFqv60imrf7gjDksTGH4+15kS0O/bKo5 Wjq4A5PRO73dMq0jSgsXtY4C+H5SLg7zgoj54ou3bycBp3jEiSTh8dVi7mwsLVdx PLVMNsWCgRHRBpLeiJCwPl4BJxLqLAdcivT5uk2IOG/THQl+qyBY8yRxdvb4YZVg /udRDIZciH3xTToMapn07AP6qKrXNSkgWiecrujejehll+kVIPEiMedmtatGWOZI LfLcv7mLTYzvnz2sZfEwxzJLLUxlN/qcZ9Hgh12KAonj6t8Ydm8= =eN1K -END PGP SIGNATURE-
Re: Amendment to RMS/FSF GR: Option 5
On Fri, Apr 02, 2021 at 06:20:47PM +1100, Craig Sanders wrote: > > TEXT OF OPTION 5 > > > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. > > Questions to the Project Secretary: Was this email (which is not the repost email) a validly signed email proposing an amendment to the GR? If yes: Since A.2.3. of our constitution says "calls" and not "called", do you agree that a vote has not been called before the person who calls for a vote has made a statement on what they believe the wordings of the resolution and any relevant amendments are? cu Adrian
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 11:21:52PM +1100, Craig Sanders wrote: > On Sat, Apr 03, 2021 at 02:12:25PM +0200, Kurt Roeckx wrote: > > This has been discussed before. It did not reset the minimum discussion > > time. > > oh wow, a discussion. and a discussion has the power to change debian's > constitution? >... Kurt is right on that, but it might have been more helpful if he had copied the relevant part of our constitution: A formal amendment may be accepted by the resolution's proposer, in which case the formal resolution draft is immediately changed to match. If a formal amendment is not accepted, or one of the sponsors of the resolution does not agree with the acceptance by the proposer of a formal amendment, the amendment remains as an amendment and will be voted on. > craig cu Adrian
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 01:56:32PM +0200, Kurt Roeckx wrote: > On Sat, Apr 03, 2021 at 10:38:23PM +1100, Craig Sanders wrote: > > On Sat, Apr 03, 2021 at 09:33:48AM +0200, Kurt Roeckx wrote: > > > On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > > > > Short and simple: > > > > > > > > TEXT OF OPTION 5 > > > > > > > > > > > > Debian refuses to participate in and denounces the witch-hunt against > > > > Richard > > > > Stallman, the Free Software Foundation, and the members of the board of > > > > the > > > > Free Software Foundation. > > > > > > > > > > > > > > The discussion period is over, no new options will be added. > > > > Since when is it over? > > > > The DPL changing the *minimum* discussion period is a minimum only, it > > does not set a maximum. > > A vote has been called. For the record, I would like to state that Kurt is doing the right thing by being a neutral project secretary who executes the rules. If decisions made by people other than Kurt make it impossible for this option to be an amendment, then he is not to blame. > Kurt cu Adrian
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 01:08:50PM +0200, Micha Lenk wrote: > Hi Adrian, > > Am 03.04.21 um 10:25 schrieb Adrian Bunk: > > Craig, if you make this a new separate GR I will be glad to sponsor it. > > Do you (or anybody actually) have a idea how to deal best with the old RMS > GR if this one is formally accepted? One option would be to run both in parallel. The anti-witch-hunt option would have been option [G] had there not been a public request that someone should call for a vote 1.5 hours after the unsigned version of this amendment was proposed, it would sound logical to ask for it to be voted at the same time even now that it has been forced to turn this into a separate GR. > Regards, > Micha cu Adrian
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 09:33:48AM +0200, Kurt Roeckx wrote: > On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > > Short and simple: > > > > TEXT OF OPTION 5 > > > > > > Debian refuses to participate in and denounces the witch-hunt against > > Richard > > Stallman, the Free Software Foundation, and the members of the board of the > > Free Software Foundation. > > > > > > The discussion period is over, no new options will be added. Craig, if you make this a new separate GR I will be glad to sponsor it. > Kurt cu Adrian
Re: Amendment to RMS/FSF GR: Option 5
On Sat, Apr 03, 2021 at 03:19:02AM +1100, Craig Sanders wrote: >... > i'm down to one package these days, dlocate, which i work on when i'm able. i > uploaded a new version of it a few months ago - the upload completed OK, but > the new version never went into unstable. I have no idea why it just vanished, > probably some change to the upload procedure that I haven't had the energy to > explore yet. There is a common pitfall that uploads signed with a key that is expired in the keyring are silently dropped at some point during processing. > craig cu Adrian
Re: Nuance Regarding RMS
Hi Barak, thanks a lot for this nuanced view. On Thu, Apr 01, 2021 at 11:51:59AM +0100, Barak A. Pearlmutter wrote: >... > He’s remarkably stubborn in technical matters even when outside his > domain of expertise and completely wrong. >... The traits that make RMS appear awkward are the same that made him create the GNU project and the FSF, and without RMS being the way he is Debian would not exist. cu Adrian We acknowledge the role of the GNU project in our system and like to think of Debian as "Son of GNU". Bruce Perens, Debian Project Leader
Re: Nuance Regarding RMS
On Thu, Apr 01, 2021 at 11:20:03PM +0200, Wouter Verhelst wrote: >... > The open letter does not state that RMS should be ejected from the free > software movement in general, or from the FSF specifically. Were that > the case, I would agree with you that it was wrong. Instead, it merely > states that he should be removed from leadership positions, both in the > FSF and in the GNU project. >... The open letter you support starts with: Richard M. Stallman, frequently known as RMS, has been a dangerous force in the free software community for a long time. He has shown himself to be misogynist, ableist, and transphobic, among other serious accusations of impropriety. These sorts of beliefs have no place in the free software, digital rights, and tech communities. You want Debian to make a public statement that Debian considers Richard M. Stallman "misogynist, ableist, and transphobic". You want Debian to make a public statement that Richard M. Stallman is a "dangerous force in the free software community" for whom there is "no place in the free software community". cu Adrian
Re: Willingness to share a position statement?
On Thu, Mar 25, 2021 at 03:38:40PM -0700, Steve Langasek wrote: >... > It is an > infringement of the freedom of association of all other Debian developers if > we are not able to exclude someone based on the views they express and the > actions they take. > > Labor rights are entirely different from "freedom of association". In many jurisdictions associations cannot expel a member without proper reason and due process, and being expelled from an association can be contested in regular courts. cu Adrian
Re: Willingness to share a position statement?
On Thu, Mar 25, 2021 at 09:38:56PM +, Steve McIntyre wrote: >... > We *entirely* have the freedom to discriminate based on > what people say and do around us. We're not a government. We are *not* > in the situation where we *have* to support people saying things that we > believe to be bad, wrong and hurtful. It is *entirely* within our > rights to evaluate people by their words and actions and to decide > whether we wish to talk or work with them in future. >... You are saying companies should always have the right to fire employees if they join an union. cu Adrian
Re: Willingness to share a position statement?
On Wed, Mar 24, 2021 at 12:38:25PM +, Steve McIntyre wrote: >... > On Wed, Mar 24, 2021 at 12:32:31PM +0100, Gerardo Ballabio wrote: > >Matthias Klumpp wrote: > >> Inclusivity and tolerance does not mean we have to accept every opinion as > >> equally valid. > > > >Equally valid -- no. > >Legitimate to express -- yes. > > > >I am really worried about the increasing trend (not specific to > >Debian) towards demanding that people who hold "dissenting" opinions > >be removed from their positions, excluded from the public debate, and > >even fired from their jobs, which if universally applied would make > >them unable to earn a living. That is what dictatorial regimes do -- > >often while maintaining a facade of freedom: "Nobody is being > >prevented from speaking, we're just making their life miserable > >because we don't like what they're saying". That's exactly what's > >happening with the current political correctness storm. Say one bad > >word and your life might be ruined. > > Freedom of speech does *not* mean freedom from consequences. Discrimination based on opinion is a human rights violation equal to discrimination based on skin colour or gender. Everyone is entitled to all the rights and freedoms set forth in this Declaration, without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status. Universal Declaration of Human Rights I do consider it deeply disturbing that many Open Source Code of Conducts are basically a rewording of this part of the Universal Declaration of Human Rights - but without protection against discrimination based on opinion. > If you say unpopular, controversial things then it's entirely > reasonable that people around you may evaluate you based on what > you've said. They may decide that they don't want to listen to you any > more. They may decide that they don't want to work with you any more, >... Your position reminds me of times in my home country when train drivers and postmen were fired by the democratic government just for being a member of a communist party. And of some other events a few decades earlier. cu Adrian Yesterday it was Donald Trump who was banned, and tomorrow, it could be somebody else who has a very different point of view. Bernie Sanders
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
On Wed, Jun 03, 2020 at 06:39:53PM +, Stefano Rivera wrote: >... > It's only a couple of months before the conference that contracts have > to be finalized, flights booked, and money paid. June 8 was picked as a > latest possible date for that decision. >... The standard procedure for putting such a decision immediately on hold is proposing a GR sponsored by 10 developers. There is a 100% chance this would have happened. The actual DebConf20 decision would have been the GR result in July. Martin deserves more appreciation for giving the DebConf organizers an advance warning that a GR was being prepared. > SR cu Adrian
Re: Debian Project Leader Election 2020 Results
On Sun, Apr 19, 2020 at 05:01:39PM +0200, Kurt Roeckx wrote: > On Sun, Apr 19, 2020 at 04:06:14PM +0300, Adrian Bunk wrote: > > On Sun, Apr 19, 2020 at 02:18:16PM +0200, Debian Project Secretary - Kurt > > Roeckx wrote: > > >... > > > The details of the results are available at: > > > https://vote.debian.org/2020/vote_001 > > >... > > > > The constitution says: > > > > A.6.3.2. > > An option A defeats the default option D by a majority ratio N, if > > V(A,D) is greater or equal to N * V(D,A) and V(A,D) is strictly great > > The text is incomlete, see #896067 I was thinking "strictly great" could be a technical espression, but the complete text expresses the same I was reading into it. Which AFAICS means the information on the DPL election page is wrong (as said, without practical consequences in this case). > Kurt cu Adrian
Re: Debian Project Leader Election 2020 Results
On Sun, Apr 19, 2020 at 02:18:16PM +0200, Debian Project Secretary - Kurt Roeckx wrote: >... > The details of the results are available at: > https://vote.debian.org/2020/vote_001 >... The constitution says: A.6.3.2. An option A defeats the default option D by a majority ratio N, if V(A,D) is greater or equal to N * V(D,A) and V(A,D) is strictly great The result says: Majority Option1 passes Majority. 8.853 (301/34) >= 1 Option2 passes Majority. 3.211 (244/76) >= 1 Option3 passes Majority. 1.552 (194/125) >= 1 Doesn't the "strictly" mean that for N = 1 (simple majority) the requirement is > 1 instead of >= 1 ? It doesn't change the outcome in this case, it just looked odd that a draw against None Of The Above would be sufficient for a majority. cu Adrian
Re: Q to all candidates: increase diversity with DDs outside Europe and USA
On Mon, Apr 01, 2019 at 07:35:56PM +0700, Martin Michlmayr wrote: >... > The DPL can encourage an inclusive community and cultural > understanding. Just creating more awareness about stumbling blocks > that people face helps because it many cases people simply have no > idea (e.g. the visa issue mentioned above). I've definitely learned a > lot through my involvement in Debian. (And after spending a few months > in the southern hemisphere last year, I'm less likely to write > "summer" and "winter" to refer to certain months ;) >... Should Debconf move away from always being held when there is winter in the Southern Hemisphere and summer vacation only for people living in the Northern Hemisphere? cu Adrian BTW: One of the example pictures in the English Wikipedia article "Frost" is from Curitiba in late July. -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Are Martin and Sam's platforms equivalent?
On Tue, Mar 26, 2019 at 07:06:26PM -0400, Sam Hartman wrote: > > "Jose" == Jose Miguel Parrella writes: > > Jose> The question is _what_ would be up for discussion, given it's > Jose> only a year. > > In the discussions here, three items have come up that resonate with me > significantly: > > 1) Can we recommend/require dh > 9? > > 2) Do we want to more strongly recommend that people have packages in > Git repos on Salsa? > > 3) An eventual Git-based source format. > > Note that I've discussed these as pure items about policy around > packaging. However, embedded in these discussions will be questions of > work flow and collaboration. > > So, at a minimum, I'd like to try and lead discussions on these 3 items. > The specific discussions will be very different, but I think they will > all be valuable discussions in helping make it easier to contribute to > Debian. They might be relevant for people already in Debian. If you want to "make it easier to contribute to Debian" for non-DDs, I'd say they are mostly irrelevant and the actual problems are elsewhere: 1. Non-DDs getting single changes into Debian If you are not a DD, there is no process to get a change into Debian if the maintainer is MIA or is one of those maintainers who ignores the BTS and only uploads new upstream versions. Note that I am not talking about contoversial changes NAKed by the maintainer, I am talking about 10 year old clearly correct patches or "New upstream version" bugs that are rotting in the BTS. Whether a patch is rotting in the BTS or is rotting in a MR on salsa doesn't really make a difference on the underlying problem. 2. Package sponsorship Any mentoring outreach aimed at finding new contributors should start with no longer frustrating the people who have already started to contribute. They might stop their contributions. There are too few people reviewing packages at sponsorship-requests, but proper and timely reviews would be very important both for not frustrating new contributors and ensuring that new contributors are learning to do high-quality packaging. Spending any resources on finding new contributors who are starting at zero doesn't really make sense as long as people who are already contributing have to wait months for getting their ITPs reviewed and uploaded (and then have to wait additional months while the package is in NEW). > I'm sure other issues will come up, but those three are specifically > items that people in the -vote discussion seem open to discussing more > broadly and that I think are real pain points. >... My points are non-issues for DDs participating in a -vote discussion, but are real barriers for people who are beginning to contribute. Coming from the Debian bubble, it was a surprising experience when the first patch I submitted to Yocto was on the master branch a day later. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Q: NEW process licence requirements
On Tue, Apr 03, 2018 at 11:30:23AM +0800, Paul Wise wrote: > On Sun, Apr 1, 2018 at 6:11 AM, Adrian Bunk wrote: > > > What is the big (legal) difference between distributing something > > from the Debian group on the Debian machine salsa.debian.org, and > > distributing the same from a different Debian machine? > > The big difference appears to be the Social Contract (and DFSG), which > we generally don't seem to apply to alioth/salsa, especially because > they often contain full upstream development history, which might or > might not contain non-free material. No, this is not about the Social Contract, the DFSG, or any other policies how we choose to divide our archive. After a non-free package passes NEW it will be distributed by Debian machines and Debian mirrors, just as we have pledged in the Social Contract. Non-free material is not a problem here. Non-distributable material is what we are talking about. > bye, > pabs cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Q: NEW process licence requirements
On Mon, Apr 02, 2018 at 10:57:24AM +0100, Chris Lamb wrote: >... > The other, critical, factor nobody has raised is time. Why not > assume good faith here? After all, which is more likely - the FTP > team are sitting around doing nothing and happy/enjoying the current > state of affairs, or too busy with life/family/work and the quotidien > admin tasks & other breakages that they don't have as spare cycles as > we would like to work on this? >... This is not about assuming bad faith, more about bad priorities. There are plenty of cases where people get annoyed by the NEW handling, and when you say that the ftp team needs a thick skin that is also due to many people thinking "Why did the idiots in the ftp teams do this with my work?". >From outside copyright handling in NEW ranges from How did this package pass NEW with this copyright problem that is obvious when looking at debian/copyright? through What the legal reason that the ftp team insists on adding all author attribution to debian/copyright for GPLv2 software? to What is the legal reason that adding all author attribution is not required for src:linux to pass NEW? >From outside all this appears arbitrary and unfair, and you might be underestimating the amount of frustration it causes. Some cases might be an ftp team member making a mistake. Many cases might be people not understanding why something is required for legal reasons. Most of us have more Debian TODO items than available Debian time. Waiting for spare cycles might therefore not be a good way forward for something that causes widespread frustration. You were calling it "imposing an ultimatum", I would rather call it "agree with the ftp team on a deadline". cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Q: NEW process licence requirements
On Sun, Apr 01, 2018 at 10:36:23PM +0200, Joerg Jaspert wrote: > On 14994 March 1977, Adrian Bunk wrote: > > > Since Debian distributing whatever random people upload to salsa > > is fine for you, I fail to see the point why you would consider > > distributing what is in the DD-only NEW a huge problem. > > It is not fine. But I've chosen to not go down the road that would be > needed here. I've got enough on my plate, I can't put this on. The sensible time for anyone to bring up this topic would have been during or before the Alioth replacement sprint. I am not involved with salsa, but this kind of changes tend to be a lot less work when they are included in the planning phase, instead of changes to a heavily used running system. > If someone does go down the road, then any project creation on salsa > would possibly end up needing to be vetted by an admin (or a new team > doing this, or a combination of new team and NEW handling, as parts of > this surely could be merged then). If someone does go down the road, the most likely result will be to decommission salsa: With a bureaucratic process in place that might take weeks just for getting a new git tree approved, most people would consider external places like GitHub much more attractive and use these instead. At that point it might no longer make sense to spend scarce Debian resources on server maintainance and contents vetting. > Right now, the handling of stuff on salsa follows what was done for > alioth "It may have a .debian.org, but its not run by Debian, so the > project chose to ignore parts of the problems with it". And implicitly > either put it onto the shoulders of the alioth admins, or the individual. So in case of problems with contents on salsa, we expect that the salsa administrators will pay all legal expenses out of their own pockets without any support from Debian? > There is an argument for this having changed now, with the new setup, > yes, but following that opens such a big can, I don't want to do this. > Thats something the DPL might want to get some informed (ie. lawyers) > opinion on, how free that service can be. > > I would love for the outcome of that to be something like "It's fine if > open, as long as there is a contact that quickly disables reported > $legalfoo violations". If that's the outcome, it would be great. > Also, in a way we do assume people NOT intentionally putting bad stuff > up, though the current system does make it farely easy to play bad here. This a fair assumption for the DD-only NEW, but not for salsa. > bye, Joerg cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Q: NEW process licence requirements
On Sat, Mar 31, 2018 at 11:03:00PM +0200, Joerg Jaspert wrote: > On 14993 March 1977, Adrian Bunk wrote: > > > As an example for a rule that does not make sense, recently a member of > > the ftp team stated on debian-devel that the contents of NEW cannot be > > made available to people outside the ftp team since it might not be > > distributable, and that this is not expected to be changed. > > Like it or not, but there *is* a big difference in the project making > something available for the big wide world (which a public NEW would > be), or a user putting it somewhere readable for everyone even though > the latter might be using project resources too. What is the big (legal) difference between distributing something from the Debian group on the Debian machine salsa.debian.org, and distributing the same from a different Debian machine? > Sure, this is an > argument for making salsa restricted too and have NEW processing on any > project there, and be safe(r). *I* dont want that >... Someone uploads something to NEW, and Debian does currently not make it available for the big wide world. Someone uploads something to salsa, and Debian does make it available for the big wide world. Uploading to NEW is restricted to DDs. Uploading to salsa is not restricted. Since Debian distributing whatever random people upload to salsa is fine for you, I fail to see the point why you would consider distributing what is in the DD-only NEW a huge problem. In a sidenote, the trivial way to solve "make the contents of NEW available to more people" would be making the Vcs-Browser: link available at [1] (it is already visible at the subpage for each package). For the vast majority of packages in NEW, this will point to the Debian machine that already makes the contents available for everyone. > bye, Joerg cu Adrian [1] https://ftp-master.debian.org/new.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Q: NEW process licence requirements
On Sat, Mar 31, 2018 at 09:44:45AM -0700, Russ Allbery wrote: > Adrian Bunk writes: > > > The ftp team has repeatedly stated that it is working as a team and > > that decisions are not arbitrary decisions by individual team members. > > > This implies that for tasks like NEW handling there exist guidelines > > in some form, that might need some polishing before publication. > > People often assume there's some sort of "real" documentation for what is > and isn't acceptable, but it's being kept secret from the rest of the > project, and point to the above as a justification for that belief. > > However, I think it's worth realizing this isn't necessarily true. A > group can share a consensus opinion without having written documentation > in the case where training is via mentorship and apprenticeship rather > than through written instruction. And I believe that's exactly the case > for FTP master. The team arrives at the same practices because they are > taught the same practices through apprenticeship, IRC discussions, and > corrected practice, not because there's some secret reference manual. > > So yes, in some sense there are some guidelines, but they could well be > entirely unwritten tribal knowledge that has been communicated through > innumerable fragmentary IRC conversations and in-person chats. Which > means that turning them into something that can be given to the rest of > the project as reference is still extremely difficult. It is also a technical process that is executed ~ 1000 times each year, by 10 different people. > Unfortunately, due to the nature of this ongoing discussion, there's also > now a ton of *pressure* around the first release of that document. It > would be met with a ton of scrutiny and discussion, which makes it even > harder to be the one to put oneself on the line and try to write down > unwritten tribal knowledge, possibly incorrectly or incompletely. The main problem might well be whether it has to justify all past actions of the tribe as correct under the new rules, or whether it is seen as part of an effort that might result in changed rules. I already mentioned "contents of NEW cannot be made available" as an example of tribal knowledge that stopped making sense years ago. I also suspect there might be tribal rules that are strictly applied to all packages, except some packages like src:linux that are too important to be rejected. In such cases it might be most convenient for the tribe to simply delay everything until the day when the President of the United States releasees his tax returns. Perhaps not even intentionally, but it can be painful when you have to question whether some things you have enforced for years actually make sense. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Q: NEW process licence requirements
On Fri, Mar 30, 2018 at 10:55:30PM +0100, Chris Lamb wrote: > Hi Adrian, Hi Chris, >... > I have always instinctively felt such things to be antithetical to the > spirit of Debian development so should only be applied in extreme > circumstances. With respect to the frustrations expressed here and > elsewhere, I don't believe we have reached that point just yet. > > > > rules that appear to be pointless and only designed to create > > additional work set by people with absolute powers > […] > > reasons that appear to be arbitrary and pointless, or there > > is nitpicking > […] > > a real risk that people might be leaving the project > > I'm afraid I simply can't reply without making a more general comment > with respect to this kind of argument style. > > Don't get me wrong, I *completely* understand and empathise with the > frustrations here, but do we really want to a culture in Debian where > it is acceptable to publically belittle others' efforts using such > emotionally loaded words or in such a combatitive / adversarial manner? you omitted the relevant part from my email: > BTW: When I use the word "appear" this means that something is > perceived as being this way, and it is possible that there > is a good reason that is just not communicated properly. For many people who are not a member of the ftp team, the actions of the ftp team have a clear adversarial effect on both the work and motivation. When something does "appear to be arbitrary and pointless" the problem might be either an actual arbitrary decision or just a lack of communication regarding the rationale. > I'm sure many Developers have thick skins and perhaps even take pride > in conversing in an "objective" way, but do we really think this is best > way as a Project to get things done? I personally don't and I believe > that the silent majority not find satisfication, purpose or enjoyment > from such a community. > > If you will permit me to exaggerate for a moment, if anybody is leaving > the Project it is due to sustained exposure to such low-level > toxicity. :( There are two orders of magnitude of people more in the project that need a thick skin due to the toxity of the intransparent NEW handling of the ftp team than there are members in the ftp team. The silent majority just tends to be on the "follow the orders of the ftp team no matter whether they make sense" side of things, since there is nothing short of a GR a normal DD could do about it. Publishing the rules with a clear rationale would bring transparency, reducing the frustration about this. In some cases it would be clear why the ftp team makes some decisions, in other cases it might even reveal that a rule does not make sense and could be abolished. As an example for a rule that does not make sense, recently a member of the ftp team stated on debian-devel that the contents of NEW cannot be made available to people outside the ftp team since it might not be distributable, and that this is not expected to be changed. It was quickly pointed out to this member of the ftp team that most of the time exactly this contents is already publicly distributed by Debian on alioth/salsa by the time it enters NEW. There are options to improve the situation for everyone in Debian (including the ftp team) once there is transparency on the rules and the rationale. >... > With regard to your request for a timeline or schedule, whilst targets > of this kind can often help prioritisation and focus work, applying my > best judgement I do not believe that imposing an ultimatum on the ftp- > team to be the best way forward here. >... The ftp team has repeatedly stated that it is working as a team and that decisions are not arbitrary decisions by individual team members. This implies that for tasks like NEW handling there exist guidelines in some form, that might need some polishing before publication. The ftp team is granted powers over the work of all people in Debian directly from the DPL, and the only person in the project who is able to push for improvements in this area is the DPL. The only alternative would be a GR to override the DPL decision regarding the ftp team delegation, and no matter the outcome this would be ugly. It is therefore disappointing when a DPL candidate tries to wiggle out of making a commitment to get such a longstanding conflict inside the project resolved within a reasonable amount of time. > Best wishes, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Q: NEW process licence requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Mar 29, 2018 at 09:58:16AM +0100, Chris Lamb wrote: >... > Just as one example, the NEW queue process certainly has some of these > "Chesterton's Fences" [0] at the moment, and making it more transparent > and descriptive in places would — even without changing any underlying > process at all, which I do note is also being discussed — would vastly > improve the sentiment about that. >... As delegation the ftp team gets its powers directly from the DPL, so (except for a GR) there is noone except the DPL with the power to push for improvements. A constant source of frustration is the intransparent licence checking process in NEW, and intransparency regarding what the ftp team considers mandatory for debian/copyright. In real life most of us are used to having to comply with pointless rules, and the motivation for doing so is the money we get. In a volunteer project there is less incentive to follow rules that appear to be pointless and only designed to create additional work, set by people with absolute powers to enforce their decisions. There is a real risk that people might be leaving the project out of frustration caused by such intransparent decisions. Some packages get rejected for reasons that appear to be arbitrary and pointless, or there is nitpicking on things where it isn't clear for what legal reason the ftp team requires these. Other packages where even a cursory look at debian/copyright reveals huge problems pass NEW with no complaints and in no time. IMHO it would be good to have: 1. documented what exactly the requirements are for debian/copyright 2. documented for what legal reasons they are required 3. a clear rule that the above is applied to all packages without any exceptions Do you agree that this would be desirable? If yes, what would you consider a reasonable schedule for the ftp team delegation to provide and implement this? Thanks Adrian BTW: When I use the word "appear" this means that something is perceived as being this way, and it is possible that there is a good reason that is just not communicated properly. - -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlq+k68ACgkQiNJCh6LY mLGQMRAApd69D6q0oTO6Z2MiEWb3surgX0EhF4w3Q7rFDjaGTcCXBd1fgvkr4Kjm RRFWAyjID36pXIMdz5RCsPUczhBToGJIOWs6nDr8qKJ42XdGvVe9NYEHL+K6KmFb dSf9fEfTmivRUUiHH9KIVM9ERlwcRgc6aZzMbHDf8PV+W3dpQe4lyUN9/lxJvkPr 3obLKULZpA7rw1xS6A8nRuFrOXr49IP/xmQO2VeU8gsNIth+v1uCSRLwUaV+s1Nq L3mGcRE8rk2zu4i9a7D3gqnGmfhpojiUScz/feO7H/PetiU07TIqJhnyL0Oljj+U qvbhq8TJyTGboQy/cU2wgEx7tyg8/ml3yg47Y8W+UlIS0aRZ00ZSTzAmSs/WgfS0 9JRhSIpHDjvcuT3I2PWZWkXa11iR2/BwP51762dlZkfu2DdWbi4xAtmE0bJalcPd 7OOY+XUr975YX3EdyJMDmsv1hzNYwUOD6TTnXVrP/Wh8feAZlIwp9I0PjnC8MDuo njRemIC6H177Yrjud4ZwerSDcVwmNuuXly8+JosuAvBXEOclIzFaaG+iVPZvnvcV g5DwtpZv1uTufZP9TEcIsRWByi4yNFoDf4jmQ/n5fxlZqPpxcPxQF2R3Imp0eqQ1 6vZKqhFBzxmjz7z358ogHngxkj+W614iuPujRVaNLCrqj7RaS5I= =C8c8 -END PGP SIGNATURE-
Re: Question for DPL candidates: Teetotaler outreach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 31, 2017 at 07:31:44PM +0100, Chris Lamb wrote: >... > Whilst I've learnt over the years to accept that terms such as "go for a > pint" aren't meant to be taken 100% literally and — at least in the UK — > not drinking alcohol at social functions is becoming less of of a big deal, > I can totally relate that terms like "beersigning", the generic "I'll buy > you a beer" thank-you response and the general assumption that you would > imbibe can be a little frustrating and possibly even triggering. >... > After all, not drinking > alcohol hardly implies a diet consisting entirely of Coca-Cola. >... When something is advertised as "beersigning" on a Debian mailing list, what non-alcoholic beverages can one expect to be available at the venue? cu Adrian - -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAljfwvEACgkQiNJCh6LY mLGMehAAheyb9fmDoSG0pBrmXUXALf+T/ZqXoci/76QrzFe9wDUOgRoeklyuIgw1 bsk29FA5ARIe9PNIAJih4tLpTLlg3Ta/wsVbuPWUJ2oFr1w8tay+y2Hks4OWb6FU IBXTG4YxuyI/bd6PKER2Y+NN3xXBVs/m7xMTsfM5AhwEjkl9XUa0pGSR+dfNsVcf dvUVGzL1plv3/XtfgLmFJ16DRmJOmisdaB7Twq6kTKxl1OiPwTeipwNrAMDOR1D/ HUwa5ADLa6KFj5PxoGoKTfCBVi8Uo/piMpchSjvLgzDnhqQ6uux34MR6ueQWLdHh e2fhSBZ/OKq788dz2S85tKwEntI6Q/5EpWDoF/D7hUDiGoci/rILvwIQ/+L7AC0X j69YliCtfdYKKsOGCsM7D2bSVLcf7uMj/K8FM/gzqABThg/V1FdOsDtyAYZVJmfx e6kS0aC6ypYX+OQP4xnWIMQIgKKOBH6sTWdeXeBpPYvo9O2awjWUMoss3+J3H8Do 21Zj7iIlDhvghTPC1k+OAEe4EGoM5/+wW+R0b824oLg8uAvkNE5TQAtuR441MqoZ tp/CVEIPuq4hgHAPjoEN5+7NhvtMzmANPWwT/x5cf4W0dhkDC2Sp3gnAZpHohFs/ W6bukNzV0m6wy/W2ZnQkCKS4I9JdyDZtWMt5scsAmDE0GFf2fVk= =buXi -END PGP SIGNATURE-
Question for DPL candidates: Teetotaler outreach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, first of all thanks a lot for running. Both of you consider outreach important. People not drinking alcohol are half of all adults in the world, but we are under-represented in free software. Unfortunately far too many people mistake alcohol for a social lubricant, and might not even notice that for many people terms like "beersigning" do not at all sound like fun. How do you plan to create a more welcoming environment for people not drinking alcohol, and reach out to teetotalers? Thanks Adrian - -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAljeaV8ACgkQiNJCh6LY mLE+9xAAvLQLH1haNBZeISopCHf1t3uYXH+CivkZwk39aUVNX6dKtwmmo3u+7XaM LveK/ciMM9p5Y8O26nGmvq+Aj/Kt4vKH4ULaAyC3eDWMb5Jt1Wpx3w9MXXVkDsJ5 VD+Lhqvnb7EcX3ilsvESWJZvSGLkrD5fOo6X7vqO6TrA0vfqwMWWHwvj3uXKPwFn Out9h+yW+oLiWROHzRaGR7fBfWI4SL/ONJmQ2GO+XquIyS32nzgKen2TbxZgAVwt 7fHOZIlFvR25j5F6lFyJc8Wz/fSgrW167eZV3gsDMHRBLrHG/cciM0XkbZaPFBtq 6JmBd3KLghvOV4GkmGcIOX9a7BfhSfMWd53XqZs75CYhBwnRJpbHHGozczAUDOcs dyxLm63ZnlitHUSBwSNxMWOmrgVxhwdd2wmFM3xqutpgOnvDTYlsVjARUT73x2tk +uR33cj5tTYNIscQw2p4Bs3z1HeQaxME8pEItLS50JXtLqi1fsRr+OILQfb/kV58 tXI8hZC0wuSrD5ABGM62OKlfcRgCJ/Gt35KHXX2kVGuNqzmr00+WTVIVmaXFUCxb 8lw3bCDAyZuSZGw9L1hT5gupp7BympUs8lLJyJ1+9WPBpvrwG9VYp/gWYhAWsUaY J1ANTgpFtIZbaFN2vt+p8eqxJ/x3VV3xKRhWIdZb5B406gWuz5c= =gga0 -END PGP SIGNATURE-
Re: Some questions for the DPL candidates
On Wed, 7 Mar 2001, Sven LUTHER wrote: > On Tue, Mar 06, 2001 at 10:31:00PM -0500, Branden Robinson wrote: > > html2latexConvert HTML markup to LaTeX markup > > > > Hrm, I don't actually use this. I should probably remove it. The > > license is quite definitely non-free. Can someone suggest > > alternatives? We could also attempt contacting the author, Nathan > > Torkington. It was copyrighted 7 years ago, and the profile of > > free licensing has risen considerably since then. > > Well, you could try out hevea, it is in main (at least in unstable) and should > do what you like : > > Package: hevea >... > Description: A fast and powerful LaTeX to HTML translator >... hevea is exactly the opposite (LaTeX -> HTML) of html2latex ... > Friendly, > > Sven Luther cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig.
Re: Some questions for the DPL candidates
On Wed, 7 Mar 2001, Sven LUTHER wrote: > On Tue, Mar 06, 2001 at 10:31:00PM -0500, Branden Robinson wrote: > > html2latexConvert HTML markup to LaTeX markup > > > > Hrm, I don't actually use this. I should probably remove it. The > > license is quite definitely non-free. Can someone suggest > > alternatives? We could also attempt contacting the author, Nathan > > Torkington. It was copyrighted 7 years ago, and the profile of > > free licensing has risen considerably since then. > > Well, you could try out hevea, it is in main (at least in unstable) and should > do what you like : > > Package: hevea >... > Description: A fast and powerful LaTeX to HTML translator >... hevea is exactly the opposite (LaTeX -> HTML) of html2latex ... > Friendly, > > Sven Luther cu Adrian -- Nicht weil die Dinge schwierig sind wagen wir sie nicht, sondern weil wir sie nicht wagen sind sie schwierig. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
