Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Thomas Goirand writes: > The idea is to be able to use unified tooling. Currently, we can't for > example easily do a mass-commit on all packages. Or apply a new CI test > to all packages. That wouldn't be changed by having all repositories on Salsa. You would need to require the same permissions for all packages. Some packages might even require signing some legal document to contribute to (unless you NMU them)... > In for example FreeBSD, it's a way more obvious how to contribute to > /usr/ports. In Debian, it's not. Most other distributions I know about seem to have only the packaging information (debian/*) and not the upstream source in their version control system. So more people might be familiar with this; it also also makes tree-wide changes to packaging much easier ;-) Ansgar
Re: Debian and Non-Free Services
> Subject: Free Software Needs Free Tools > > No Debian contributor should be expected or encouraged, when working > to improve Debian, to use non-free tools. Does this include: - non-free firmware on Debian hardware, - non-free software for interacting with hardware, - non-free backup systems? AFAIK Debian uses all of these and you are probably expected to deal with them when contributing to relevant parts in Debian. > This includes proprietary > web services. We will ensure this, insofar as it is within Debian's > collective control. Does this include use of proprietary CDN networks, DNS services, cloud services (such as VMs or storage) or social network services (Twitter)? Again, you probably cannot avoid them when contributing to relevant parts of the project. > For example, Vcs-Git fields in source packages must not refer to > proprietary git code management systems. Non-Debian services are > acceptable here so long as they are principally Free Software. That would just lead to packages using these to no longer including the Vcs-* fields... There are some valid reasons to host packages on services such as GitLab or GitHub such as when they are hosted there as part of the upstream project and/or for better cooperation with upstream. I would not like to make cooperation with upstream more complicated. Ansgar
Re: Debian and Non-Free Services
"Dr. Bas Wijnen" writes: > On Thu, Sep 12, 2019 at 07:49:26PM +0200, Ansgar wrote: >> > Subject: Free Software Needs Free Tools >> > >> > No Debian contributor should be expected or encouraged, when working >> > to improve Debian, to use non-free tools. >> >> Does this include: >> >> - non-free firmware on Debian hardware, >> - non-free software for interacting with hardware, >> - non-free backup systems? > > You may be correct. In that case, this GR, if passed, declares that we want to > change that. Is that controversial? The GR forbids using any of these. That is not helpful. As far as I know there is no mainstream hardware that doesn't require non-free firmware; using non-mainstream hardware is possible, but has other problems. >> > This includes proprietary >> > web services. We will ensure this, insofar as it is within Debian's >> > collective control. >> >> Does this include use of proprietary CDN networks, DNS services, cloud >> services (such as VMs or storage) or social network services (Twitter)? >> Again, you probably cannot avoid them when contributing to relevant >> parts of the project. > > Yes, it should mean that. Again, it doesn't mean people are not allowed to use > them. It means that people who don't want to use them can still contribute to > Debian. So for example, it would not be allowed to ignore the bts and only > accept bug reports through Twitter. So assume I want to avoid using non-free DNS and CDN services, but still contribute to Debian. How should that work as long as Debian uses these services? How should one contact people using non-free mail services? (mailto:non-free is probably not better than https://non-free...) Of course Debian can stop using CDN services and provide a worse experience for users, but why? Debian's goal is not to build and operate a free CDN service... Ansgar
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Enrico Zini writes: > On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote: >> But I think having recommendations available when people are new, when >> they are looking for what to do when writing new tools, when the trade >> offs don't matter, is really important. I think it's important enough >> that it's worth time for a quick vote (and I do believe we can >> efficiently handle GRs). [...] > Also, as over time my packaging practices have become outdated, I have > found it both difficult and frustrating to engage on a quest for > figuring out "how does one do this thing nowadays?"[1], and if there > were default recommendations available, I would have considered them a > boon[2]. What does stop the recommendations to be outdated in a year or two? Given the long and slow process to gather them, there will probably be a long and slow process to change them; that discourages actually changing them (too high barrier). In my opinion we already have similar problems with other standards/documentation in Debian. Ansgar
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
Ulrike Uhlig writes: > On 26.09.19 08:03, Ansgar wrote: >> What does stop the recommendations to be outdated in a year or two? >> Given the long and slow process to gather them, there will probably be a >> long and slow process to change them; that discourages actually changing >> them (too high barrier). >> >> In my opinion we already have similar problems with other >> standards/documentation in Debian. > > Just to be clear, are you saying: because we think today that we cannot > commit to maintain documentation we should rather live without it? No. > I personally believe that the current long and slow process is due to > the fact that it is the first time that this process happens. We already have a long and slow process for official technical documentation. There are things that changed a decade ago and aren't yet updated. For /recommendations/ which are much more subjective, I expect an even longer and slower process to update them if someone puts them in written form. Ansgar
Re: Merry Christmas more debian private leaks
Hi Paul, "Paul R. Tagliamonte" writes: > Very sad and disturbed by all of his behavior. I very much hope he gets the > help he needs and gets well soon. I would like to ask you to not comment on other people's mental health on public mailing lists. We don't do this for people who endorse individual violence & right of the person who is physically stronger (even though they live in a place where there is a collective agreement to leave violence to elected governments and haven't moved to countries where lynching is accepted), people who have anger management issues (and get extremely angry when they don't get what they want), or people who believe in conspiracy theories either. If you really feel sending such mails would be helpful, please only send them in private mail to the concerned party. Ansgar
Re: Merry Christmas more debian private leaks
Zlatan writes: > Can we ban this email account (and be persistent with such effort)? We should, but it's playing whack-a-mole as one can just again create a new, anonymous mail account anywhere. Targeted abusive behavior is much harder to get rid of than spam as most blocking systems can be worked around with some minimal manual effort. Even people sending spam will (sometimes) subscribe to mailing lists or impose other people; any such measures thus certainly wouldn't help when people are willing to work around these measures manually. You could moderate all mail and/or whitelist people based on DKIM-signed mails that cannot easily be forged, but that would require to spend quite some effort on boring things :-/ Ansgar
Re: Some thoughts about Diversity and the CoC
Dato Simó, threats of violence aren't welcome in Debian; if you cannot stop yourself from wishing to beat up people, I would suggest to leave the project. Thanks for your understanding, Ansgar
Re: Some thoughts about Diversity and the CoC
Ulrike, Ulrike Uhlig writes: > Ansgar, > > On 31.12.19 09:50, Ansgar wrote: >> threats of violence aren't welcome in Debian; if you cannot stop >> yourself from wishing to beat up people, I would suggest to leave the >> project. > > Stop! > > Expressing pain _is_ valid. Looks more like expressing "hate" (or "despise") to me... > Wanting to punch a wall is not beating up people. And Dato Simó said more than just wanting to punch a wall. > You completely > modified and seemingly misunderstood (intentionally or not) what Dato said. So what is the "I wish I could say I would have charged against him" supposed to suggest to the reader? Or the repeated writings how much "despise" there is for other people? Or how much the "blood boils" because of "rage"? Does that leave the impression of a non-violent person that it is (physically) safe to be around, including at real life events? (For me: "no") > It's not up to you to suggest to anyone to leave the project. Is that up to Dato? > Stop this now. Sorry, but I read that expressing pain _is_ valid. Ansgar
Re: Some thoughts about Diversity and the CoC
Philip Hands writes: > Ansgar writes: >> So what is the "I wish I could say I would have charged against him" >> supposed to suggest to the reader? [...] > That being the case, I suggest you check that what you're complaining > about wasn't just a typo. Even then the message would have been inappropriate. But I'm not really interested in discussing why "I despise person X" mails aren't very productive. So I suggest to end this thread here. Ansgar
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
Didier 'OdyX' Raboud writes: > Le mercredi, 19 février 2020, 16.17:00 h CET Sam Hartman a écrit : >> Debian is Asked to Support a Protest of a Debian Activity >> = >> >> The Montreal organizers could have simply organized an alternative for >> those who were not traveling to DC20 for whatever reason. >> That's something Debian could support with no reservations. >> >> By making the political statement in their announcement, they have >> turned the conference into a protest. It's being billed as an >> alternative to DebConf for political reasons. >> >> (…) >> >> So in effect the Debian Project is being asked to support a protest of >> its own activity. > > The crux of my strong disagreement is here: as DPL, you just _framed_ the > Montreal miniDebConf as a protest. I think the announcement by the organizers framed the conference as being organized specifically to support the BDS movement, a movement that is uncontroversially seen as antisemitic. They could have chosen not to frame the announcement this way, but they did not. So the announcement forced the question to be whether Debian should officially support such a movement or not by providing resources to events organized in support of BDS. And honestly if people want to drag the project into supporting something like the BDS movement, maybe we should rather have a GR about it (including the option to explicitly *NOT* support it). Though arguably the diversity statement should pretty much include rejecting antisemitism and thus BDS... And before people complain too much about BDS being antisemitic being controversial: a resolution passed by the German parliament includes comparisons of BDS with 'Kauft nicht bei Juden!' calls that were popular sometime last century[1]; the US has adopted [2]. These resolutions were pretty uncontroversial and adopted with very wide support from pretty much all parties: the resolution in Germany was supported by at least CDU/CSU/SPD/Grüne/FDP, so ~80%+, Die Linke had a different resolution which also included "Reject BDS movement" even in its title, so 87%+ reject BDS); the US resolution got something like 398:17 votes. And because we are talking about Canada and Toronto: Wikipedia says that Ontario in 2016 passed a motion condemning BDS as well, because "The motion was necessary because of growing concern on Ontario’s university campuses where members of BDS movements have harassed and targeted Jewish students under the guise of free speech"[3]. The two largest parties supporting the motion held 82 of 107 seats at the time. So again pretty uncontroversial. Ansgar [1]: http://dip21.bundestag.de/dip21/btd/19/101/1910191.pdf [2]: https://www.congress.gov/bill/116th-congress/house-resolution/246/text [3]: https://torontosun.com/2016/12/01/ontario-mpps-reject-bds-movement/wcm/12c5c198-aa3a-459d-b34b-2c1d47c1475a
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
Michael Banck writes: > On Thu, Feb 20, 2020 at 10:02:53AM +0100, Ansgar wrote: >> the BDS movement, a movement that is uncontroversially seen as >> antisemitic. > > Only a Sith deals in absolutes. So you are a Sith? But yes, some people also find climate change or usefulness of vaccines (autism!) controversional. I recommend reading the rest of my mail for more context. Ansgar
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
On Thu, 2020-02-20 at 17:11 +, Ian Jackson wrote: > But my main point is this: Ansgar asserted that it is uncontroversial > that the BDS movement is antisemitic. Obviously that was not true. As I wrote it's only as uncontroversional as, say, climate change or usefulness of vaccines is. Of course you will always find someone disagreeing if you look hard enough. If you have 80-90%+ of parliament, from pretty much all parties, agree on something, then it *is* pretty much as uncontroversional as it gets there. > If it were true then the Montreal team's message would be a CoC > problem. Well, it sadly is. Note that BDS in total being antisemitic doesn't imply all individuals supporting it are so. Ansgar
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
micah anderson writes: > Ansgar writes: >>> The crux of my strong disagreement is here: as DPL, you just _framed_ the >>> Montreal miniDebConf as a protest. >> >> I think the announcement by the organizers framed the conference as >> being organized specifically to support the BDS movement > > You might think that but I think you should think again, or maybe read > again, that is just plain false. Dunno, if the organizers also invite talks from the "Palestinian Campaign for the Academic and Cultural Boycott of Israel"[1] it seems more and more so. [1]: https://salsa.debian.org/debconf-team/public/mini/mtl2020/issues/24 > If you wish to debate this, then I think doing so somewhere other than > this mailing list would be prudent. Yes, maybe we should just have a GR whether Debian should welcome BDS at Debian or not. Ansgar
Re: Testing Discourse for Debian - Moderation concepts
On Mon, 2020-04-13 at 19:56 +0100, Neil McGovern wrote: > Instead of explaining it here, please have a > read of the following: > https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ > The short version is that the more a particular account interacts with > the community in a positive way, the more trust the system has about > them, and the more privileges they are afforded to assist in > moderation. I think some features of Discourse can be useful, for example moving messages to new topic, simple polls (I don't like "like" buttons...), or even editing messages to make the wording clearer instead of sending further follow-up messages. Trying to experiment with Discourse for this seems useful to me. The "trust levels" though are one of the features that I don't like: in particular "Trust Level 3 - Regular" mostly requires to constantly visit the site every day (or every other day), read x% of all posts and topics (even though they might not be relevant to your interest or in a foreign language you don't speak), ... to not get demoted again. It feels more like a customer loyality program to try to bind users to the Discourse service, like rewards for daily visits in mobile games, not anything that implies trust to somehow govern the system. The system also requires tracking active read time and such; I don't really like a system doing that... The notifications to welcome new people or that the system hasn't seem someone for some time[1] also seem designed to manipulate people into spending more time on the system. Such psychological tricks are something I would more expect from Facebook than Debian :-/ [1]: https://discourse.debian.net/t/likes-per-post-ratio/152/2 The claim of Discourse having an excellent email interface also feels exagerrated: unless I missed something[2] it seems very basic. One can send and receive messages, but quoting in replies already doesn't work as usual and any additional functionality isn't exposed at all as far as I can tell. That said I'm in principle fine with trying a mostly web-only system; just like GitLab also really needs to be used over the web. [2]: I couldn't really find much Discourse documentation, even less than for other things in Debian people say are underdocumented. > Instead, it encourages community members to flag posts. If a post receives > sufficient flags, it is then automatically hidden. Users may chose to > "unhide" the post for themseleves if they wish to view it. > > These are then sent to the moderating team to agree, disagree or > ignore the flag. What decides who is in the moderation team? That seems to be something different from the trust levels? I would also expect Discourse to have some way to entirely remove messages, or at least remove the original content fully and replace it with a notice that the message was removed; who can do that? Also the moderation team? Ansgar
Re: Testing Discourse for Debian - Moderation concepts
On Wed, 2020-04-15 at 11:21 +0100, Neil McGovern wrote:
> On Wed, Apr 15, 2020 at 11:08:45AM +0200, Martin wrote:
> > On 2020-04-15 08:56, Neil McGovern wrote:
> > > Could I point out that the email program you wrote this message
> > > in is
> > > doing the same?
> >
> > Could you elaborate on that? Ansgar seems to use
> > "User-Agent: Evolution 3.36.1-1"
> > (While I'm using mutt.) How do such UAs track reading behaviour?
>
> Evolution tracks how long you've looked at a message in order to mark it
> read. This is configurable in Preferences -> Mail Preferences -> Mark
> messages read after X seconds. My point is that one cannot simply say
> "user tracking is bad", as it may be required for actual functionality.
> User tracking is also known as "saving state" :)
I'm not concerned about marking messages read after some time and
keeping the view time in ephermal storage for that. But that's not
what Discourse does: as described elsewhere it stores all read times
persistently on the server; that would not be neccessary for marking
posts as read even on a web application.
I feel it dishonest to compare storing data persistently in a database
and evaluating it for statistical purposes (or other analytics that
people come up with to increase participation and measure community
engagement for community building) with keeping data in ephermal
storage for a short while.
Evolution also keep track of the mouse cursor, but that is something
different from recording clickstreams and evaluating them to increase
user participation as some people do. Your reply seems to put both on
the same level.
> > > Quoting does work in most circumstances. Could you explain what
> > > additional funtionality is missing?
> >
> > Speeking for myself, I find the email support in Discourse poor,
> > to the point, that I would not advertise it. It is useful for
> > notifications, but by far not en par with the web UI.
>
> Interestingly, I've generally mixed replying via email with visiting
> the
> site. I would agree that it's not en par with the web UI, but I don't
> think it ever can be, due to email being designed rather differently.
>From my tries with Discourse, it just silently stripped all quotes out
from the reply.
> > After reading more about Discourses many features ("likes"...),
> > this is completely understandable that one cannot mimic one
> > medium via the other. Trying so, will lead only to frustration.
>
> Just on this one, you can a little. Replying with a +1 will turn your
> email into a "like". Currently supported actions are:
> * +1 or like: likes the post
> * watch: watches the topic
> * track: tracks the topic
> * mute: mutes the topic
Is this documented in some discoverable place or hidden? I've still not
managed to discover any documentation for Discourse targeting the user
(compared to admin or API documentation).
Ansgar
Re: Testing Discourse for Debian - Moderation concepts
On Wed, 2020-04-15 at 08:56 +0100, Neil McGovern wrote: > The point of the trust levels is to distribute the moderation. Whatever > metric we come up with, it will involve a certain amount of actually > using the site, and engaging with the community. Looking at some topics on meta.discourse.org, people explicitly use trust levels as a "reward" tool to increase "user participation" in some metric. [1] mentions this for example, but it's not the only topic talking about reward systems or gamification in Discourse. Badges and other systems serve the same purpose. [1] https://meta.discourse.org/t/trust-level-wishlist-items/141349 > > The notifications to welcome new people or that the system hasn't seem > > someone for some time[1] also seem designed to manipulate people into > > spending more time on the system. > > Could you explain this please? I feel that having a notification (which > only appears for people who regularly interact with the site) that > someone is new to the community to be useful. I think "In a nutshell, we use computers to detect the behavior we want to see and then we use people to recognize and reward it" from the post I linked to above explains it well: the system is designed to have people say "welcome back", not because they know them, but because the computer system encourages it to further the goals of the person operating the forum (increase user participation), not because of sincere human interaction. One such system alone is probably not a problem, but taking everything together (trust level as "rewards", badges, scores, like counts, ...), Discourse certainly leaves me with the impression that it is designed to increase participation levels and time spent on the site via psychological tricks and manipulation. I don't use so-called "social" network services like Facebook because I don't like this sort of subtle manipulation, and I probably won't like Discourse much for the same reasons, even though it might be nice to use otherwise as it offers a nice feature set. I have no idea if these reward systems can be turned off for Debian's instance of Discourse. I recognize that other people will like such systems given systems like Facebook, Twitter or daily rewards for mobile games are quite popular, but some other people have mentioned they don't like the gamification aspects either. On the other hand, I like Discourse's feature set so far; the mail integration isn't that great, but at least works for basic interaction. But handling mail is complicated and like other restrictions (offline use) that's probably something I could mostly live with. So to summarize, I think technically Discourse is okay. The "rewards" and related systems would however probably not make me use the system much. Ansgar Likes per Day: 12*π Total Views:∫₋∞ᵀ viewrate(t) dt ≈ 1.3 flocks Average Read Time: 5.321 Imperial minutes, 4.323 metric minutes Total Read Time:6.917 flock Imperial minutes, 5.620 fmm Author's Read Time: Yes #Cats In Author's Room: ~2 Suggested topics: - Debian is testing Discourse [User] https://lists.debian.org/debian-user/2020/04/msg00516.html - What are your thoughts on discourse? [Devel] [Vote] https://lists.debian.org/debian-vote/2020/03/msg00046.html - ITP: python-pydiscourse [Devel] https://lists.debian.org/debian-devel/2020/04/msg00143.html - why dig ? I wanna use nslookup ! [Devel] https://lists.debian.org/debian-devel/2001/04/msg02502.html Want to read more? Browse other recent project topics on https://lists.debian.org/debian-project/2020/04/threads.html or discover all categories on https://lists.debian.org (I can do those tricks too ;-) SCNR this one time...) signature.asc Description: This is a digitally signed message part
"From" at beginning of line gets escaped (was: Re: Testing Discourse for Debian)
On Wed, 2020-04-15 at 20:18 +0900, Charles Plessy wrote: > as we discuss about proper quoting, I would like to take the opportunity > of Ansgar's email to note that each time a line starts with "From" in a > plain text email, something in the pipeline that delivers emails (at > least to me) inserts a ">" sign, which is then misinterpreted as a > quotation character. See above… Hmm, indeed. And I was wondering what was breaking the DKIM signature... Looking at the headers of my mail I find: | X-Amavis-Spam-Status: No, score=-12.6 required=4.0 | tests=DKIM_INVALID,DKIM_SIGNED, with an invalid signature, but below that (earlier in the pipeline) this signature was still valid: | X-Amavis-Spam-Status: No, score=-8.863 tagged_above=-1 required=5.3 | tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, So it looks like the lists setup somehow breaks this... I reported this problem as https://bugs.debian.org/956806 Ansgar
Re: Debian hardware support and enablement for newer devices (was ThinkPad laptops preinstalled Linux)
On Thu, 2020-06-04 at 02:31 +, Paul Wise wrote: > > As a project, how can we improve the current entry level to new > > companies wanting support for their devices? > > Is the backports archive not sufficient for this? I see it doesn't > contain mesa backports at this point and probably other hardware > enablement, but that could be fixed. I wouldn't recommend enabling backports by default for pre-installed systems as using backports is something a bit fiddly (temporarily uninstallable packages, sometimes extra pinning to pull in additional packages or manual intervention is needed, ...). Ubuntu seems to offer newer kernel and graphics drivers as separate packages in the main archive instead, see [1]. I remember support for new hardware in stable releases to be a general problem, especially short before a new release when the kernel in stable already ~2 years out. Currently I no longer administrate desktop systems with stable, but when I did so in the past it was sometimes a problem to fully support recent hardware. Ansgar [1]: https://wiki.ubuntu.com/Kernel/LTSEnablementStack
Re: Keysigning in times of COVID-19
On Thu, 2020-08-20 at 10:05 +0200, Philip Hands wrote: > Conjuring up a "mallicious DD" seems to carry with it the assumption > that only bad people do bad things, which seems naive to me. > > This conversation reminds me of the trade-offs involved in airport > security. > > One can decide to spend money on security theatre (e.g. expensive > scanners) or general resilience (e.g. more ambulances and emergency > responders) The number of airplane hijackings has gone down significantly[1] while the amount of air travel has increased by a lot (passenger-kilometers per year by more than factor 10 or so between 1970 and 2010 from some graph I found). So it seems to be effective. Maybe the "security theater" even pays for itself given planes are fairly expensive? :-) [1]: https://www.statista.com/chart/4560/airliner-hijackings-have-become-rare-events/ > In this situation, tightening up our proceedures regarding keys strikes > me as much closer to the security theater end of the spectrum, while > efforts like Reproducible Builds are at the general resilience end. One could just do both. I think I have seen, for example, automated external defibrillators in public buildings like airports. > If I were a sociopath contemplating sabotage in the Free Software > sphere, going to the effort of becoming a DD, even for the first time, > would be nowhere near the top of my list. > > Does DAM actually have any cases at all where they suspect a previously > expelled DD of trying to sneak back into the project under a new ID? > > If not, then either our proceedures are already broken enough that > temproarily slackening keysigning protocols won't make the slightest > difference, or the threat is probably not worth worrying about. If a fire alarm wasn't triggered by a fire for some time, should it be removed? Maybe the procedures just work reasonably well. Ansgar
Re: Debian and GitLab Open Source Partnership
On Mon, 2021-07-26 at 12:43 +0200, Jonathan Carter wrote: > Do you mind explaining your statement? > > As far as shipping non-free software/firmware/drivers are concerned, > the Debian Free Software Guides and Social Contract is very explicit > about what we can do in what we call Debian. It is indeed very explicit about including non-free packages if possible: +--- | We encourage CD manufacturers to read the licenses of the packages in | these areas and determine if they can distribute the packages on | their CDs. +--- I believe the licenses of most firmware should pose no problem for their inclusion on Debian's CD images. Ansgar
Re: Debian and GitLab Open Source Partnership
On Mon, 2021-07-26 at 16:56 +0200, Jonathan Carter wrote: > On 2021/07/26 15:50, Ansgar wrote: > > It is indeed very explicit about including non-free packages if > > possible: > > > > +--- > > > We encourage CD manufacturers to read the licenses of the > > > packages in > > > these areas and determine if they can distribute the packages on > > > their CDs. > > +--- > > > > I believe the licenses of most firmware should pose no problem for > > their inclusion on Debian's CD images. > > The text you quoted covers 3rd party distributors who wish to > includethe firmware on media that they would distribute (which would > not be considered official Debian media either). It doesn't say "3rd party CD manufacturers", so I assume it means all groups creating CD images. > For official media, it would go against #1 of the SC and (depending > on the exact firmware) at least #2 and #3 of the DGSG. Including files for optional use does not imply that non-free components are required, so it doesn't violate SC #1: We already include non-free packages in the archive. Surely taking the archive and putting it on a BluRay doesn't turn the free system available from the archive into a non-free system that requires use of non-free components. Obviously packages in non-free don't need to comply with the DFSG, no matter whether including in the archive or on BluRay images. Ansgar
Re: Re: A quiet reminder: please be considerate.
On Sat, 2022-03-26 at 11:18 +0100, Philip Hands wrote: > Norbert Preining writes: > > Obviously my emails have been considered spam or my email a throw-away > > one, since from my last 4 emails to d-p not a single one has arrived. > > > > Reality seems to be very different from what you and Steve have > > written. > > Well, that's odd, because I cannot find a single instance of a mail > from you being discarded, but perhaps I don't have a full set of > data, or my notmuch search foo is weak? If the mail is a false-positive for the spam filter on lists.d.o then you would not see it this way. One would have to contact listmaster with date and message-id. Ansgar
Re: Distrowatch
Hi, On Fri, 2022-06-17 at 10:37 -0400, steve wrote: > Distrowatch has broken links to download Debian. Hope this is the > right way to report it. Please contact Distrowatch for problems with their web site. They seem to have a contact address in their web site's footer. Regards, Ansgar
Re: Multi-package projects
On Fri, 2022-10-07 at 13:37 +0200, Wouter Verhelst wrote: > - After the merits and problems of the proposed new projects are > discussed, the release team decides which projects are accepted for > the next release. > (I specifically do not mention what rules the release team should > follow in deciding which projects to accept -- I trust their > judgement) This sounds like you propose to create some sort of technical steering committee which probably should not be required to be identical with the release team. But as a practical example: some people have suggested packages not shipping configuration files in /etc (including, for example, init scripts in /etc/init.d). As far as I understand some people even say it is Debian's core mission to support such new configurations to give more freedom to users. How would this work and reduce conflicts with your proposal? Would it be okay for people driving this change to, for example, just drop /etc/init.d scripts? People caring about them could make software look for them in /usr/lib/init.d or such reducing various problems with removed-but-not-purged packages. Or would the people interested in shipping less configuration files have to implement this for non- standard init systems whose usage is explored as an experiment in Debian? Some people probably also want to continue to ship configuration files as Debian does now. Should we require this to be user-configurable? Who would be required to maintain maintainer scripts to support both configurations? The group wanting to keep the old configuration or the group wanting to support the new configuration? What if some people don't want this user-configurable (hmm, make user-configurability user- configurable?)? Or should be release team just decide all of this and everyone will accept this? I don't think that would work from past experience... Ansgar
Re: Multi-package projects
On Fri, 2022-10-07 at 14:21 +0200, Timo Röhling wrote: > * Wouter Verhelst [2022-10-07 13:37]: > > I've given this some thought over the past few days, and have come > > up > > with something that I believe might work, and I would like to > > submit it > > as a proposal to see what others think. > Great idea, thank you for your thoughts! > It reminds me of the Debian Enhancement Proposals [1], which aim to > solve a similar problem. > > I have only one remark at this point: By definition, a project has a > limited scope and time frame, so at some point it has to end. For > things like /usr-merge, or any other transition, this is a good fit. I think we did try something similar for usrmerge already: the tech- ctte was asked about the switch to the new filesystem for new installations, making the new layout the only supported layout in the future and migration of existing systems. The proposal adds a few more bits reminding me of old concept of release goals (which Debian dropped), but I'm not seeing how it would avoid the problems we had (or have) with systemd or usrmerge. It hides a lot of conflict behind this simple statement: | - After the merits and problems of the proposed new projects are | discussed, the release team decides which projects are accepted for | the next release. | (I specifically do not mention what rules the release team should | follow in deciding which projects to accept -- I trust their | judgement) and assuming everyone will then accept this decision. Ansgar
Re: Fortunes-off - do we need this as a package for Bookworm?
On Sun, 2022-11-20 at 16:44 +0600, Judit Foglszinger wrote: > fortune-mod has no bugs that prevent testing migration, > it just needs a source-only upload. Hah, an easy bug to fix :-) I did that just now (1:1.99.1-7.3). Ansgar
Re: SUMMARY [Was Re: Fortunes-off - do we need this as a package for Bookworm?]
On Wed, 2022-11-23 at 12:34 -0700, Sam Hartman wrote:
> It is not necessary, but as I discussed in my long message about
> removing software from Debian, removing creative content from Debian
> has a chilling effect.
I would very much prefer explicit sexual content over Nazi symbols. So
let me make a suggestion:
If we insist on keeping Nazi symbolics in Debian, let's at least also
add explicit quotes from descriptions of Hitler + Blondi sexual
adventures (which I'm sure must exist on the internet), various form of
sexual abuse (there is enough fictional content to quote) and more in
the fortune-off package or elsewhere.
Or are explicit sexual references so bad that Nazi symbols are okay for
freedom of speech, but sexual references not?
In a related question: should we accept packages that link to, say, the
Stormfront web site in user-facing material or source code? (That's not
really hypothetical: I believe we have at least one package referencing
a page including racism and Holocaust denial.)
What about software greeting the user with a friendly "Sieg Heil" ("not
illegal in all juristictions" / "in every jurisdiction in the world"
was used as an argument earlier in the thread...)?
And for the "chilling effect": Debian makes it fairly easy to add
additional software sources; it's not like ecosystems where one or few
providers have a near monopoly like platform App stores, credit card
companies, Twitter, Amazon, ... which use their power to remove content
they don't like. And that is despite providers like Twitter, Github and
so on even having legal protections for third-party content which
Debian would not fall under, i.e., they do more control while having
less legal risks (AFAIU).
Or if you like another comparison more: Debian is more a newspaper
(with selected articles) rather than a generic communication provider
like the post office that can be used to send any information. Not
being able to publish your article in the New York Times is not a
chilling effect or censorship, the post office refusing to send certain
mail on the other hand would be.
Ansgar
--
"He [Hitler] is an extreme masochist who derives pleasure from having a
woman squat over him while she urinates or defecates on his face."
-- Walter C. Langer: A Psychological Analysis of Adolph Hitler:
His Life and Legend; PDF page 102 in
https://www.cia.gov/readingroom/docs/CIA-RDP78-02646R000600240001-5.pdf
Cooperation with the FSF?
Hi, elsewhere I heard that there was some talk (also including people from the FSF) about cooperation with the FSF. Could anybody tell a bit more what current ideas are? I just remember the fsf-collab-discuss list on Alioth with sadly died rather quickly... Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85mwaeqzs9@tsukuyomi.43-1.org
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
Hi,
Jonathan Dowland writes:
> On Mon, Oct 13, 2014 at 06:33:49PM +0200, Matthias Klumpp wrote:
>> You do understand that we have procedured at Debian to handle stuff
>> like GR proposals, right? And that procedure involves posting to
>> debian-vote, so doing that was the right thing to do.
>
> Whilst researching for a reply to a different post in this thread on -user
> (the
> thread sadly spans at least three lists), I realised that the constitution
> doesn't say where GRs should be announced, and I couldn't find any advice on
> the subject in a scan over policy, either.
>
> I think we should clearly indicate where GRs should be announced. ("Should", I
> suppose I'm arguing, not "must").
It's documented on vote.debian.org[1].
[1] <https://www.debian.org/vote/howto_proposal>
> Unless I'm mistaken, a change to Constitution (to include a reference to where
> GRs should be posted) would need to be achieved via GR.
>
> Alternatively, we could document it as a "should" in policy, although there
> may
> not yet be an appropriate section to do so.
>
> Does anyone have strong feelings on this?
I think both would be the wrong place: having technical details (such as
mailing list names) in the Constitution makes it hard to change
them. And Policy documents packaging standards for the distribution, not
procedural details for the project.
Ansgar
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbnnn7hk@deep-thought.43-1.org
Re: should debian comment about the recent 'ransomware' malware.
Henrique de Moraes Holschuh writes: > On Wed, 17 May 2017, Holger Levsen wrote: >> On Wed, May 17, 2017 at 01:59:37PM +1000, Russell Stuart wrote: >> > Microsoft users or indeed Android users, iOS users and I presume OSX >> > users get security updates installed automagically by default. >> >> that's awesome and I hope by 2019 the default stable Debian desktop install >> will do that too! > > You know, if the stuff we have in testing _rignt now_ works flawlessly, > we can (and should) add to the Release Notes in big red letters that > people ought to install it. It can even be made a post to > debian-announce and debian-security-announce (if the security team > agrees with the notion). >From my experience the current update system doesn't work flawlessly. It is error-prone to upgrade running applications and switch out parts of them while they run: many programs don't like when data files or plugins they rely on suddenly disappear. I've observed this with quite a few applications (such as Firefox, Libreoffice, zsh, emacs, ...). The breakage can result in crashes or just some features suddenly no longer working until restart. Installing updates on system startup seems less risky to me, though some people seem to dislike it for some philosophical reason. Ansgar
Re: Help
Hi, please do not sent support requests to debian-project@, instead use one of the documented channels[1]. The "how to ask questions the smart way" document[2] may also be helpful if you want others to understand your problem. Regards, Ansgar [1] <http://www.debian.org/support> [2] <http://catb.org/esr/faqs/smart-questions.html> -- 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/87ipjiobco@deep-thought.43-1.org
Re: Is there a public-facing page of the various autobuilders ? more specifically hardware specs.
Hi, I think -project@ might be a better list for this. On 02/21/2012 03:14 PM, shirish शिरीष wrote: > The info. I'm looking for is the physical infrastructure as to the > kinda specs (hardware specs of the machines) on the network are and if > they are located at diverse locations (or not). [DB] has a list of machines in use by Debian, you want to look for hosts which have listed "buildd" purpose. For bandwidth usage, you could try the munin instance maintained by DSA [MUNIN]; access details can be found on [DSA]. [DB] <http://db.debian.org/machines.cgi> [MUNIN] <http://munin.debian.org/> [DSA] <http://dsa.debian.org/> > I do know that there is a mailing list dedicated for DD,DM's > wanna-build [04] but am not sure if my query would be entertained > there (as I'm no DD,DM or even a package uploader, just an interested > user who uses stuff from Debian). Just try asking them, most people don't bite (or at least not too hard). You might also be interested in [ORG] and [TEAMS] which has a bit more information. [ORG] <http://www.debian.org/intro/organization> [TEAMS] <http://wiki.debian.org/Teams> > (Have no idea for instance if autobuilders have direct access to the > archive [05] and if they don't what kind of bandwidth is needed. I do > know that in the past vendors like HP and others have donated machines > for autobuilding and things. Hmm, I am not sure if there is much documentation about this, but as far as I know buildds usually have access to the archive (they can use mirrors as well), including packages not yet pushed to the mirror network (similar to [INCOMING] but with signed Packages indices for use with APT). [INCOMING] <http://incoming.debian.org> Regards, Ansgar -- 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/4f43b12e.3030...@debian.org
Planned changes to Debian Maintainer uploads
Hi, (Please send followup messages to -project.) The ftp team wants to change how allowing Debian Maintainers to upload packages works. The current approach with the DM-Upload-Allowed field has a few issues we would like to address: - It applies to all DMs listed as Maintainer/Uploaders. It is not possible to grant upload permission to only a specific DM. - It is tied to the source package so can only be changed with a sourceful upload. - It allows DMs to grant permissions to other DMs. We plan to instead implement an interface where developers upload a signed command file to ftp-master to grant upload permissions instead, similar to dcut. This could end up looking similar to this: --8<---cut here---start->8--- Archive: ftp.debian.org Action: dm Fingerprint: [...] Allow: a-source another-source Deny: yet-another-source Reason: We want people to say why they changed that. Action: dm Fingerprint: [...] Allow: yet-another-source Reason: ... --8<---cut here---end--->8--- Here "Allow" would add additional packages to the list of packages the Debian Maintainer (identified by his key fingerprint) may upload. "Deny" would be used to revoke this permission again[1]. Any DD may use this to grant/revoke upload permissions to existing packages (ie. at least in NEW); referring to non-existing packages will be an error (at least for Allow). [1] Having the same package in both Allow and Deny at the same time would result in revoking permissions. The "Archive" field is to prevent forwarding the commands file to another dak installation. Granting upload permissions for backports.d.o will require sending a commands file explicitly to backports-master. We will also drop the check that the DM is in Uploaders of the previous version and Changed-By of the current version. This has caused problems for DMs that have multiple uids attached to their key in the past. (This technically allows DMs to sponsor uploads to packages they have upload permissions for and to grant upload permissions to packages the DM does not maintain (yet). This should not be abused.) Please note that we currently do not know when we might get around to implement these changes. Ansgar for the ftp team pgpkXH2CA49IE.pgp Description: PGP signature
Re: Planned changes to Debian Maintainer uploads
Hi, Gunnar Wolf writes: > Hmm, this looks interesting, and useful. I'd like to add a bit as a > wishlist item: Having this DB easily queriable (i.e. a webpage where > you can query by key to see all the packages uploadable by a given > key). I agree that the information should be easily available. We can export it to a static HTML page (with optional JS to sort by package or maintainer) and to deb822 format. In addition it will be available in the DD-accessible projectb copy on ries.d.o. > And just thinking about possible complications: I *hope* we don't see > any such behaviour, but this format would allow a DD to "censor" a > given DM's activity. If I send "Deny" actions with somebody's key, it > ends up blocking that person until somebody else is convinced to send > corresponding "Allow" commands. Of course, if we see any such > behaviour (repeatedly?), I might be reprehended and maybe even locked > out of sending requests to this subsystem. Thoughts on this? As Arno said this is already a potential problem with the current interface, though I am not aware of any abuse. Blocking access to the command interface would be an option, but I hope we don't need it and would not implement it right away. > Finally, it's interesting to me (as keyring-maint) that you are > specifying the fingerprint. Of course, it makes sense. But it can make > key migration (i.e. a DM moving from a 1024D to a 4096R key, or > reacting to a key being compromised) as a more difficult thing, as the > new key would first have to be inserted by us into the live keyring > and only then the old key denied and the new one allowed. I guess we > could automate this procedure when performing the keyring push... Using fingerprints avoids dak to have perform the name -> fpr mapping without any interaction (which would probably have the same problems as we already have for people with multiple uids). Key migration is indeed a small problem as the key needs to be known to dak in order to grant upload permissions. So you can only move permissions after the new keyring is active, but maybe we could add a command to migrate between keys to make this easier. (Should this be restricted to keyring maintainers? Or only available for ftpmaster and keyring maintainers ping us[1]?) Ansgar [1] Which would be easier to implement as dak would not need to know who is a keyring maintainer. -- 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/878vftwtu8@deep-thought.43-1.org
Re: Planned changes to Debian Maintainer uploads
Hi, Tollef Fog Heen writes: > Could we have an expiration date associated with the grants? I might > grant somebody rights to a package, but want it to expire within $period > (or at least be subject to more aggressive QA/MIA checks than a normal > DD), since I'll be tied to them in a way. I agree with zack that we shouldn't require DMs to periodically renew upload permissions for every package. We already require them to reconfirm their interest to stay DM annually. Ansgar -- 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/871ullwtmn@deep-thought.43-1.org
Re: Planned changes to Debian Maintainer uploads
Hi,
Ian Jackson writes:
> Ansgar Burchardt writes ("Planned changes to Debian Maintainer uploads"):
> Your proposal simultaneously changes two things:
>
>> - It applies to all DMs listed as Maintainer/Uploaders. It is not
>>possible to grant upload permission to only a specific DM.
>
> This does involve changing the structure of the metadata.
>
> And I find it difficult to see what it would mean to list a DM as a
> Maintainer or an Uploader if they weren't supposed to be able to
> upload the package.
The same as it means for package without DM-Upload-Allowed or for
non-D[DM]s: they maintain the package. See also gregoa's mail[1] why we
would like to change this.
[1] <https://lists.debian.org/debian-project/2012/06/msg00046.html>
>> - It is tied to the source package so can only be changed with a
>>sourceful upload.
>
> This is slightly annoying but given that maintainership changes
> involve an upload too, it hardly seems fatal. Has this been a problem
> in practice ?
I think this has been answered by Gerfried's[2] and David's[3] mails.
[2] <https://lists.debian.org/debian-project/2012/06/msg00038.html>
[3] <https://lists.debian.org/debian-project/2012/06/msg00037.html>
>> - It allows DMs to grant permissions to other DMs.
>
> It is far from clear that forbidding this is the right thing to do.
Why? In my understanding upload permissions for a (package, DM) should
be granted by a DD once he is convinced that this specific DM is able to
look after the given package. DMs were never supposed to grant this to
other DMs. The fact that this is possible is an oversight in the
initial DM specification.
Ansgar
--
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/87wr3dvem7@deep-thought.43-1.org
Re: Can we change our position on CC BY 2.0 and 2.5 ?
On 01/25/2013 10:41, Charles Plessy wrote: > Le Fri, Jan 25, 2013 at 10:16:24AM +0100, Joerg Jaspert a écrit : >> On 13102 March 1977, Christoph Egger wrote: >>>> Alternatively, if we can not find a significant difference of freedom >>>> between >>>> CC BY 2.5, and CC BY 2.0, how about accepting CC BY 2.0 in Debian ? >> >> We don't want 2.5 in main, we want 3.0. So why? > > Sorry, I was mislead by the presence of 2.5 in awstats and > grub2-splashimages... I filed bugs[1][2] for these two packages. The icons in awstats are even already licensed as CC-BY-SA-3.0[3]. Ansgar [1] <http://bugs.debian.org/698921> [2] <http://bugs.debian.org/698922> [3] <http://famfamfam.com/lab/icons/silk/> -- 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/5102784b.1010...@debian.org
Re: Debian Maintainers Keyring changes
On 09/08/2013 08:58, Kurt Roeckx wrote: > On Sun, Sep 08, 2013 at 02:01:43AM +, Debian FTP Masters wrote: >> The following changes to the debian-maintainers keyring have just been >> activated: >> >> sas...@girrulat.de >> Removed key: A33FC3A59C40F1BCC3368E88FCA5101964F970D1 >> Removed key: E67DF5E7FCFAB7218C6D0FAF610711E66630FEFA >> Removed key: DA813270E09F448D18771FBE1AB9332D9E47CF19 >> Added key: B7018D75BBAD63F52395B82C5E55B31A2FEDAC22 >> Added key: FD9F764B0B28B823E02E62EF7809DD1F83DCC74A > > This looks really confusing. It's > DA813270E09F448D18771FBE1AB9332D9E47CF19 that gets removed, > the other 2 mentioned are subkeys. And it's > FD9F764B0B28B823E02E62EF7809DD1F83DCC74A that gets added > with B7018D75BBAD63F52395B82C5E55B31A2FEDAC22 as subkey. > > Can we change the output so that it's more clear that it's > about the pub or the sub key? We should be able to ignore the subkeys. The code should by now only look at the primary key fingerprint (as we don't care which subkey people use as long as it's valid). Ansgar -- 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/522db9fc.3070...@debian.org
Upstart trademark policy (was: Re: Proposed MBF - mentions of the word "Ubuntu")
Hi, Sune Vuorela writes: > Is upstart a canonical trademark? some pieces of software in the archive > with canonical trademarks in their names? SHould we consider renaming > them? According to the footer on their homepage[1], "Upstart" is a trademark of Canonical Ltd., but I could not find a usage policy for it. Canonical's trademark policy[2] doesn't mention "Upstart" specifically and is mostly concerned about the "Ubuntu" mark. For this it makes sense to require modified versions to not be called "Ubuntu", but the situation is a bit different with Upstart as Debian might need to patch it (for example due to the CLA[3], differences between Debian and Ubuntu or just backporting bug fixes). Are those modified versions still allowed to be called "Upstart"? Would Debian and Debian-derived distributions (besides Canonical's Ubuntu) need a trademark license? Or would Debian need to rename Upstart (like Iceweasel)? Ansgar [1] <http://upstart.ubuntu.com/> [2] <http://www.ubuntu.com/intellectual-property-policy> [3] <https://wiki.debian.org/Debate/initsystem/upstart#Cons> -- 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/87y54wsiqv.fsf...@deep-thought.43-1.org
Re: Reflecting on users and security updates
On 05/09/2014 16:15, Stuart Prescott wrote: > == sources.list > > Many users of stable releases don't have security.debian.org in the > sources.list. I can only wildly speculate as to how this happens... if the > installer doesn't find a network connection at install time it leaves a > pretty > weird looking sources.list and we know lots of people manage to not fix > properly. The sources.list that the installer leaves in this case is > certainly > sub-optimal. What do they end with in sources.list? It would probably be nice if there were entries like # deb http://http.debian.org/debian wheezy main # deb http://security.debian.org/debian-security wheezy/updates main (with comments) in case no network mirror is added by the installer. Maybe with a comment asking to enable *both* if network is accessible. > Why do we have a separate archive for security at all? "Separate teams" and > "hysterical raisins" are possible reasons. Not waiting for a mirror pulse to > push out updates is another. Is there any technical reason right now to > not copy security updates into the stable release at the next dinstall run > rather than waiting a few months for a point release? What would be required > to merge these and simplify life for our users? Some reasons are: The "stable" suite is signed with an offline signing key. It cannot be easily changed. Security updates should be delivered via fast and (more) secure mirrors. If someone grabs a security update for, say, ssh it is likely he is vulnerable. Delivering security updates via a trusted mirror network reduces that risk. The security archive contains updates covered by embargoes that should not be leaked. Log files and database replica for the main archive are more or less public. (Arguably one could have a private archive for just embargoed issues and push to the main archive to release them.) Having two archives makes it possible to release updates should one break. ;) And of course all the historic reasons. Ansgar -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536ce9c6.3000...@debian.org
Re: A policy on use of AI-generated content in Debian
Hi, On Thu, 2024-05-02 at 14:01 -0400, Tiago Bortoletto Vaz wrote: > I would like Debian to discuss and decide on the usage of AI- > generated content within the project. It's just another tool that might or might not be non-free like people using Photoshop, Google Chrome, Gmail, Windows, ... to make contributions. Or a spamfilter to filter out some. > You might already know that recently Gentoo made a strong move in > this context and drafted their AI policy: > > - https://wiki.gentoo.org/wiki/Project:Council/AI_policy > - https://www.mail-archive.com/gentoo- > d...@lists.gentoo.org/msg99042.html > I think that is a bad: policy we don't ban Tor because it can be used copyright violations, terrorism, stalking, hacking or other unethical things. We don't have a general ban on human contributions due to quality concerns. I don't see why AI as yet another tool should be different. Ansgar
Re: A policy on use of AI-generated content in Debian
On Thu, 2024-05-02 at 20:47 +0200, Dominik George wrote: > > t's just another tool that might or might not be non-free like people > > using Photoshop, Google Chrome, Gmail, Windows, ... to make > > contributions. Or a spamfilter to filter out some. > > That's entirely not the point. > > It is not about **the tool** being non-free, but the result of its use being > non-free. > > Generative AI tools **produce** derivatives of other people's copyrighted > works. They *can* do that, but so can humans (and will). Humans look at a product or code and write new code that sometimes resembles the original very much. The claim "everything a generative AI tool outputs is a derivative work" would be rather bold. > That said, we already have the necessary policies in place: > > * d/copyright must be accurate > * all sources must be reproducible from their preferred form of modification > > Both are not possible using generative AI. They are, just as they are for human results. The preferred form of modification can be based on the output from a generative AI, especially if it is further edited. But this is not something new: a camera or microphone records data, but we use the captured data (and not the original source) as the preferred form of modification. Sometimes even after generous preprocessing by (non-free) firmware. (We don't include human neural network data as part of the preferred form of modification either ;-)) Ansgar
