Re: call for seconds - separate proposal text for 2023/vote_002
On Wed 2023-11-22 19:31:34 +, Bill Allombert wrote: > Le Wed, Nov 22, 2023 at 07:16:48PM +0100, Bart Martens a écrit : >> >> The Debian project asks the EU to not draw a line between commercial >> and non-commercial use of FOSS. > > But the EU already does, all the time, really. This is simply not > realistic. Are you saying that the EU draws the line between commercial and non-commercial uses of *any* software, generally? Or any business process, which happens to sometimes include software? Liability rules that apply only for commercial business, whether the business deals with software or not, are not at issue here, right? If you're saying that there are EU software liability policies, that apply strictly to F/LOSS software (not software generally), and which discriminate against fields of endeavor like commercial vs. non-commercial, could you point to some examples? I'm quite ignorant of EU law, so feel free to point me to obvious examples that everyone already knows. --dkg signature.asc Description: PGP signature
Re: Renaming the FTP Masters
On Thu 2021-11-11 07:56:24 -0500, Roberto C. Sánchez wrote: > 1/ The assertion "we all can acknowledge is confused and outdated" is >far fom the case. This and other discussions on the matter are >strong evidence that "we can all acknowledge" is a >mischaracterization. I'm legitimately surprised to hear that anyone in the Debian project believes that the term "FTP master" is *not* confused and outdated. There is some subset of people who think that "master" is confused and outdated. There is another subset of people who think that "FTP" is confused and outdated. Some of us are in the intersection of those subsets. I had expected the union of those sets to be congruent with the entire project membership, thus i would have thought everyone would be able to get behind a rename of the team in accordance with the wishes of the team members themselves. Live and learn, I guess. You've made it pretty clear that you're not in the "master" subset. But I'm surprised to hear that you also are not in the "FTP" subset. On the off chance that you *are* in the "FTP" subset, i encourage you re-read my earlier postscript in that light. This is my last message on this thread. --dkg signature.asc Description: PGP signature
Re: Renaming the FTP Masters
On Sat 2021-11-06 11:32:35 +0100, Martin Steigerwald wrote: > Pierre-Elliott Bécue - 06.11.21, 11:06:58 CET: >> That being said, the name is indeed outdated, and "Debian Archive >> Team" sounds quite nice. > > Agreed. I like this name. Yes, please. "Debian Archive Team" is fine. This is fair amount of work, but it will help make debian not seem quite as archaic as I'm sure it seems to new prospective users or developers. Thus it is valuable work. But a GR does not seem necessary. The way to do this is to consult with the people already on the team and the DPL. Select a new name, figure out what work needs to be done to make the change. Make a plan, have someone to drive it, and persist. It will probably take at least a full debian release cycle. Changing names is hard, even if you don't have reactionary pushback. Many things might be touched by this: e-mail addresses; mailing lists; text in debian policy or the developer's reference; DNS labels; OpenPGP certificates; SSH host information; wiki entries; software like dupload; etc (fortunately, the archaic team name doesn't appear in the Constitution or the DFSG). Consider upgrade paths and how to deprecate the old name safely: when updating e-mail addresses, can you create an alias from the old label to the new address? How about DNS records? How should we handle mailing list archives? When/how should you send a deprecation warning when people use the old label? Have a timeline that acknowledges the work involved, and plans when to take each step. For example, changing DNS records, e-mail addresses, and cryptographic associations will probably be slower/more cumbersome than changing human-readable labels. Be prepared to revise the workplan when someone discovers some other place that the old name is embedded. You need to find someone or someone(s) who have the capacity and the skills to actually carry out the right work -- or who at least can keep track of the work and encourage/support the folks who have the permissions to do it to get it done. No one should object to this work if it's done with this kind of thoughtfulness, care, and attention to detail. Helping the project through this transition would be a great contribution to Debian, because it fixes a silly stumbling block that existing developers have already learned how to ignore, but that does actually hold the project back from welcoming new members who might have never heard of FTP (or of using the term "master" to mean administrator for a machine) before. This work is *not* the kind of contribution that maps cleanly to a facility at packaging free software for redistribution. This is a great example of why we need more than just package-maintainers as debian developers. There are probably many other parts of the project that need this kind of attention and effort, and we should absolutely *not* scare people off who want to help fix things. But let's not make it harder to fix than it already needs to be by dragging a GR into the mix as well. --dkg PS For people who are concerned that a retreat from the term "master" is somehow the language police run dangerously amok, it's worth asking why you feel so committed to the term "master" that you would fight to keep the project we all work on using terminology we all can acknowledge is confused and outdated. If someone is excited to improve the project, even if you don't have the capacity to help them do it, at least *let* them do it! signature.asc Description: PGP signature
Re: Discussion on eventual transition away from source packages
On Fri 2019-03-22 09:32:55 +0100, Lucas Nussbaum wrote: > I'm probably missing something, but it doesn't sound like a lot of work > to me? It's "just" a service that: > - gets notified of the existence of a git repo + tag to upload > - fetches that git repo + tag > - checks signature / confirm that the GPG key owner is allowed to upload > that package In case anyone is considering trying to do this, please be aware that there are several non-obvious subtleties involved in "verifying a git tag". https://public-inbox.org/git/875zsdu41d@fifthhorseman.net/ use caution! --dkg signature.asc Description: PGP signature
Re: Bikeshedding
On Mon 2019-04-01 15:17:27 -0400, Louis-Philippe Véronneau wrote: > On 19-03-31 03 h 39, Stefano Zacchiroli wrote: >> >> Statement: every Debian package must be maintained in Git on salsa and >> every Debian Developer with upload rights to the archive should have >> commit/push right to every packaging repository on salsa. > > I'm curious to how this would be implemented on Salsa. As far as I know, > DDs get added to the 'Debian' group when their accounts are created and > already have commit access on all repositories in that group. fwiw, i think team-specific repository groupings in salsa aren't particularly useful. I prefer to work on teams whose packages are already in the debian/ namespace anyway. So if i had to decide how to implement this technique, i think the simplest thing would be to move every https://salsa.debian.org/foo-team/libfoo to https://salsa.debian.org/debian/libfoo and let the debian/ grouping handle the permissions. That still leaves all the rest of salsa for user-specific projects, upstream projects, etc., which might have different permissions. Is there some reason that wouldn't address the concern you're raising? --dkg signature.asc Description: PGP signature
Re: Debian Project Leader Elections 2019: Call for nominations
On Tue 2019-03-12 08:45:46 -0700, Russ Allbery wrote: > Bdale Garbee writes: > >> Chris, thank you for your service! Two terms as DPL is a serious >> contribution and commitment to Debian, and I greatly appreciate it! > > +1. Thank you so much for everything you've done for Debian over the past > two years! Not to pile on, but i wonder whether Lamby's diligence, and his clear documentation of the workload (via Bits from the DPL at least) hasn't scared off some prospective candidates, who might now be realizing that they don't have the bandwidth to handle all of the minutae that Chris has dealt with over the last two years :) Thanks, Chris! --dkg signature.asc Description: PGP signature
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
On Thu 2016-07-21 11:15:57 +0200, Wouter Verhelst wrote: > A "Chairman" is a person. A "Chair" may be an object. > > I don't think anyone will misinterpret your proposed new wording into > thinking the TC has a physical chair that someone sits on, but the > s/Chairmain/Chair/ you apply does to me seem to introduce some > grammatical ambiguity that could make the text of the constitution less > clear than it might be. > > Since I'm not a native English speaker, I'll assume for now that it's > just me and that there's no problem; but if other people do feel the > same way about this, perhaps now's the right time to do something about > it? Once this GR passes, it's going to be hard to fix that... I'm a native english speaker. English has far worse ambiguities than this, and it is easily recognizable for what it is. No one will think that Debian is proposing that we have special rules for our furniture. At any rate, we all know what an organization ruled by furniture is called: a bureaucracy :P --dkg
Re: draft alternative proposal: fix problem at the root
On 12/02/2014 06:13 PM, Jakub Wilk wrote: > This is an interesting proposal. But it's a big change, so I think it > should be thoroughly discussed before I could second it. I agree some discussion would be useful, but seems like it's a lot simpler than all the other noodling with term-limits that has gone on thus far. What kind of thorough discussion would you like to have? It seems like the proposal is simple: * Do away with the Technical Committee entirely. The main questions this raises are: How would we deal with conflicts that would currently be addressed by the TC? Hopefully, the answers would be something like: collaboration and teamwork, negotiation, mediation, and GRs (in that order). Do we believe that those resolution mechanisms would be more or less likely to cause strife within the project (or outside the project) than would resolution by the current TC mechanism? I am grateful to the folks who have stood on the TC and have worked to help adjudicate issues as they've been brought to the committee. It seems likely that this work has come at significant personal cost to those project members. But it's also possible that they were working in an environment that served neither them nor the disputants well. What if we tried to encourage participation and larger project-wide coordination work in other ways? I'd be interested in hearing from (current and former) members of the TC, and from disputants who worked through problems with the TC. What do you think about Clint's proposal? > Also, I'd > prefer to have it as a separate GR than bundled with zack's GR. Why? The goal of Zack's GR seems to be to try to reform things that we think somehow aren't working well within the TC. The current proposals do this by trying to avoid stagnation or incumbency in the TC. Why isn't it acceptable to consider abolition of the TC itself as an option? > * Clint Adams , 2014-12-02, 21:08: >> Anyone want to sanity-check the section numbering? > > Not me! me neither :) --dkg signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 12:06 PM, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
> init systems"):
>> nevertheless, runit behaves differently when it is pid 1 than when it is
>> used in a subordinate role to another initsystem. If i'm upstream and
>> i'm building mechanisms that integrate with runit *as it behaves as pid
>> 1*, the implication seems to be that my work would not be welcome in debian.
>
> Are you saying that a daemon author would want to write code which
> only worked if runit was pid 1 ?
Consider a tool that integrates in some way with /etc/runit/1 or
/etc/runit/2 or /etc/runit/3, which are only relevant for systems with
runit as pid 1 (see runit(8) for more details). Such a tool should not
be RC-buggy just because it's useless on a system that uses systemd or
sysvinit.
> This question of daemon startup is a red herring, I think. It is
> generally easy to solve the problem with some kind of wrapper or tool,
> even if a daemon only starts up in a particular way.
so to be clear, it's not (and shouldn't be) an RC bug if a service fails
to start automatically on a system with a non-default init system, right?
>> I like both postgresql and runit, and am really happy that both these
>> things are in debian. But postgresql isn't RC-buggy just because the
>> system service doesn't start automatically when i choose to use runit as
>> pid 1.
>
> postgresql wouldn't be RC-buggy if it _never_ started automatically.
> That would just be an annoying bug.
I'm glad to hear that.
> And the GR text is quite careful: it doesn't say that failure to work
> with one init system is worse than any other bug. It is only
> _requiring a specific init system to be pid 1_ which is forbidden.
If the requirement is testing a literal string match against
/proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's
pretty silly, and surely that's *already* a bug that upstream would be
grateful for a fix. in this case, we don't need a GR.
But if the requirement is "hey, i'm not going to work without something
else on the system performing functionality X", and a given init system
*doesn't provide* functionality X, then it sounds like either a bug in
the lacking initsystem (should provide functionality X), or a
straightforward case of an explicit dependency. It could also be
resolved by making some part of the dependent package's functionality
more limited in scope, and saying "we can run but we can't to Y if we
don't have access to system functionality X". These are all legitimate
options for resolving the problem, and they're already available to
folks who want to work on them today. It sounds like the gdm issue was
actually resolved already through some combination of these approaches
(thanks to Aigars for the recap upthread). Why do we need a GR that's
unlikely to change this situation?
> That's the exactly correct criterion because it is pid 1 which you can
> only have one of. A user can have as different non-pid-1 daemon
> supervisors as they like so there is no problem with a daemon
> requiring a particular supervisor - provided that supervisor can work
> (well enough) when not pid 1.
we also limit debian systems to only one mail-transport-agent (e.g. exim
or postfix or courier, but not two of them at once), but we don't say
that mta-specific packages are RC-buggy, even if someone who has a
courier installation would really like to use a tool that currently only
integrates into postfix's mail-handling flow.
I'm going to stop commenting on this thread now and try to fix some bugs
that need fixing before the freeze.
Ian, thanks for raising the concern, and Lucas, thanks for floating an
alternative option. I hope we can spend our limited time fixing
existing bugs and working well together.
--dkg
signature.asc
Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 11:26 AM, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
> init systems"):
>> The implication here appears to be troubling for any upstream who wants
>> to rely on specific features of a given initsystem.
>
> Yes, indeed.
>
>> The implication of this proposed GR seems to be that those tools would
>> be unfit for inclusion within debian unless someone erects all the
>> additional scaffolding that runit provides (process supervision,
>> pipelined logfiles with autorotation and log msgs just sent to stderr,
>> restart on abnormal termination, no need for daemonization, clean
>> process initialization, etc), but does so outside of runit.
>
> But runit is exactly the scaffolding needed to do that, and already
> exists! runit can coexist peacefully with sysvinit, systemd, upstart,
> or whatever. There is no problem depending on runit because runit
> doesn't demand being pid 1, so it is nonexclusive.
nevertheless, runit behaves differently when it is pid 1 than when it is
used in a subordinate role to another initsystem. If i'm upstream and
i'm building mechanisms that integrate with runit *as it behaves as pid
1*, the implication seems to be that my work would not be welcome in debian.
>> This isn't surprising or specific to init systems, of course -- it's how
>> free software works.
>
> The problem with init systems is that you can have only one.
>
> If people want to make Debian derivatives that work only with a
> particular init system, that's completely fine. The reverse - trying
> to put back support for sysvinit, if it gets taken out of Debian,
> would be very very difficult.
i don't think that anyone has tried to remove support for sysvinit for
debian -- i certainly hope the sysvinit maintainers are unlikely to
leave the project or orphan the package. There may be packages that
don't work as well or integrate as well in a sysvinit-based debian
installation as they do for other choices of pid 1. But that is also
true if runit is my pid 1 -- some packages won't integrate as well with
my system if i choose this config. That doesn't mean those packages are
RC-buggy, it means i need to submit servicedirs for them and hopefully
find ways for developers to adopt them. Or to provide system service
packages that are distinct from packages containing the tools entirely
[0], so that anyone who wants to support service initialization on an
arbitrary initsystem can do so independently.
That said, i don't think that "putting back support for sysvinit" for
any given package that is unable to currently maintain it would actually
be as difficult as you make it out to be.
> As the upstream for our ecosystem, we
> in Debian have a special responsibility to retain the flexibility our
> downstreams might want.
Yes, we do. But we also have a responsibility to package and distribute
modern, upstream-maintained versions of useful free software even if
those versions have dependencies that some people might not find
preferable. We also shouldn't restrain packagers from uploading
software just because they don't have service initialization mechanisms
for every pid 1 that can possibly be used in a debian system.
I like both postgresql and runit, and am really happy that both these
things are in debian. But postgresql isn't RC-buggy just because the
system service doesn't start automatically when i choose to use runit as
pid 1.
Regards,
--dkg
[0] https://www.debian-administration.org/users/dkg/weblog/53
signature.asc
Description: OpenPGP digital signature
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On 10/17/2014 03:44 AM, Lucas Nussbaum wrote: > Hi, > > It is now clear that we will have a vote on this issue. I think that we > should use this opportunity to clarify the Project's position, and that's > not something that would be achieved if "Further Discussion" were to > win. > > I am therefore bringing forward an alternative proposal, deeply inspired > from the "Advice: sysvinit compatibility in jessie and multiple init > support" option of the TC resolution on init system coupling[1], which > was originally written by Russ Allbery[2] and was then amended by many > participants to the discussion in February 2014. > > [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html > [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html > > - begin proposal ->8 > Debian has decided (via the technical committee) to change its default > init system for the next release. The technical committee decided not to > decide about the question of "coupling" i.e. whether other packages in > Debian may depend on a particular init system. However, the technical > committee stated in #746715 that "[it] expects maintainers to continue to > support the multiple available init systems in Debian. That includes > merging reasonable contributions, and not reverting existing support > without a compelling reason." > > The Debian Project states that: > >Software should support as many architectures as reasonably possible, >and it should normally support the default init system on all >architectures for which it is built. There are some exceptional cases >where lack of support for the default init system may be appropriate, >such as alternative init system implementations, special-use packages >such as managers for non-default init systems, and cooperating >groups of packages intended for use with non-default init systems. >However, package maintainers should be aware that a requirement for a >non-default init system will mean the software will be unusable for >most Debian users and should normally be avoided. > >Package maintainers are strongly encouraged to merge any contributions >for support of any init system, and to add that support themselves if >they're willing and capable of doing so. In particular, package >maintainers should put a high priority on merging changes to support >any init system which is the default on one of Debian's non-Linux >ports. > >For the jessie release, all software that currently supports being run >under sysvinit should continue to support sysvinit unless there is no >technically feasible way to do so. Reasonable changes to preserve >or improve sysvinit support should be accepted through the jessie >release. There may be some loss of functionality under sysvinit if >that loss is considered acceptable by the package maintainer and >the package is still basically functional, but Debian's standard >requirement to support smooth upgrades from wheezy to jessie still >applies, even when the system is booted with sysvinit. > > The Debian Project makes no statement at this time on sysvinit support > beyond the jessie release. > > > This resolution is a Position Statement about Issues of the Day > (Constitution 4.1.5), triggering the General Resolution override clause > in the TC's resolution of the 11th of February. > > The TC's decision on the default init system for Linux in jessie stands > undisturbed. > > However, the TC resolution is altered to add the additional text above. > -- end proposal -->8 My understanding is that Lucas clarified "currently" to mean "in wheezy". I second this proposal. Thanks for writing it up, Lucas. --dkg signature.asc Description: OpenPGP digital signature
Re: Re-Proposal - preserve freedom of choice of init systems
On 10/17/2014 10:33 AM, Ian Jackson wrote: > If the fix is not easy then we have three options: the release team > mark it `jessie-ignore', the GNOME maintainers fix it, or GNOME is > removed from jessie. The implication here appears to be troubling for any upstream who wants to rely on specific features of a given initsystem. As a developer, i've built tools that were deliberately minimal *because* i want those tools to rely on functionality provided by the initsystem of my choice. Concretely, i've built tools that work only when you have the runit package installed and functional as the local init system. The implication of this proposed GR seems to be that those tools would be unfit for inclusion within debian unless someone erects all the additional scaffolding that runit provides (process supervision, pipelined logfiles with autorotation and log msgs just sent to stderr, restart on abnormal termination, no need for daemonization, clean process initialization, etc), but does so outside of runit. I don't think this makes sense -- we should not be rejecting upstream packages from debian just because they are designed to take advantage of features of a given init system. I'm not opposed to helping people work within the confines of whatever init system they prefer -- one of the things i love about debian is that i've been able to run machines with runit as pid 1 for many years now. But i have always understood that if i'm not using the default initsystem, and something breaks from that interaction, i probably need to fix it myself (and to submit patches to upstream and/or the debian package if i want it to work better for other people who also use runit as pid 1). This isn't surprising or specific to init systems, of course -- it's how free software works. It sounds like there are a lot of people who care about making sure things work with sysvinit -- that's great, and i hope that energy will result in more functional sysvinit-based installations. I'm happy for us to maintain a healthy diversity, and want to see that work happen. But i don't think it is (or should be) an RC bug just because your particular package doesn't support my particular initsystem. --dkg signature.asc Description: OpenPGP digital signature
Re: [all candidates] Removing or limiting DD rights?
On 03/29/2013 01:46 PM, Stefano Zacchiroli wrote: > On Fri, Mar 29, 2013 at 01:35:59PM -0400, Chris Knadle wrote: >> I'm open to other theories as to the cause. I am, however, a bit surprised >> that you'd completely dismiss the theory I've proposed so quickly. >> let you know that I regularly bump into users in Debian IRC channels saying >> things such as "I need to be involved in another bug report like I need a >> hole >> in the head." I take that as a clear signal that there's a problem. > > Well, I certainly didn't mean to imply that bug report handling is not > something we should look into improving. It's the causation relationship > between that and the decreasing number of bug reports which seems > unlikely to me. I'll be totally happy to reconsider that and I'm > generally very open to reconsider my positions. But I do think that we > need some concrete, scientific evidence, to prove causation in this > case, and I've yet to see some of it. Do we need to scientifically prove causation here? Chris is raising a good point, and a perception of hostile responses to a bug reports seems entirely plausible as a contributing factor to a decline in bug reports. It certainly wouldn't account for an increase in bug reports (i suspect the set of socially-masochistic users is a vanishingly small one :P ) For that matter, I haven't seen any concrete, scientific evidence to support zack's suggestion that derivative distributions are siphoning off our bug reports. While it seems potentially a plausible contributing factor to me, i could also see an argument that the more derivative distros we support, the *more* bug reports we should get. (e.g. because all the downstream devs are upstreaming their reports and fixes back to debian, like we want them to, right?) These are not mutually-exclusive explanations, either, and there is no single, simple cause for outcomes like a decline in the number of bug reports. I don't think that demanding "concrete, scientific evidence" is a reasonable bar for just considering what "might be one explanation for the steady drop in new bug reports" (chris's original words). --dkg signature.asc Description: OpenPGP digital signature
Re: Comments on the constitution?
On 08/30/2011 12:29 PM, Gunnar Wolf wrote: > Humm… An idea could be: I like Gunnar's proposal. Some nitpicks for clarity: > ‣ The term is defined to be for one year, with the possibility of one > automatic renewal > ‣ If by (election date + 10 months) This should be something like "between (election date + 9 months and election date + 10 months)" -- a DPL shouldn't be able to send this request at the start of their term. Or maybe, if they do people will think it is silly and say "no", and then the fact that it can be done only once per elected term will prevent them from doing so after they've proved themselves. Still, i'd prefer a strictly narrow window for this mechanism. > the DPL sends a (signed, > validated, blah) message, a simple referendum is held: secret vote > between a "yes" and a "no" (and... Further discussion? :-} ) If we have Further Discussion here, i think it would count the same as "no". > ‣ If the DPL seeking renewal gets a majority, his term is prolonged to > a second year > ‣ If the DPL does not get a majority, he can still participate in a > regular election > ‣ This mechanism can only be used once — A DPL wanting to run a third > term must win a regular (full) election I think this should be "used once for any regular full election" -- a DPL who wins a regular election, gets the extension, then wins a third election should be able to propose an extension for their 4th year (should we find some sucker^W^W^Wwonderful DPL who wants to do the job for 4 years running). --dkg signature.asc Description: OpenPGP digital signature
DPL consultations with the community [was: Re: Question to all (other) candidates]
Hi Wouter-- You probably didn't mean to have this to come out this way, but: On 03/23/2010 01:49 PM, Wouter Verhelst wrote: > Charles: > > In your platform, in the "Program" section, you mention four ideas that > could reasonable be described as being about the things that, > respectively, the DAM and NM frontdesk, the ftp-masters, and the Release > Managers (twice) are responsible for. Did you talk with these teams > about your ideas before running for DPL? This comes across as calling Charles out for not consulting other people (or at least not acknowledging their contributions). > Marga: [...] > Also, you seem to have received a great deal of help in writing your > platform. In the interest of clarity, can you shine a light on how this > happened? This comes across as calling Marga out for consulting too many other people (or at least for acknowledging their contributions too much). But you can't have it both ways ;) How much consultation with other members of the community is appropriate for the DPL? How prominently should an acknowledgment of those contributions be presented? I see no acknowledgments of outside input in your own platform. Did you consult with other members of the community in drafting it? (or did i miss it when i read your platform?) Thanks for keeping things stirred up, --dkg signature.asc Description: OpenPGP digital signature
Re: Q for all candidates: license and copyright requirements
On 03/23/2010 11:03 AM, Charles Plessy wrote: > The second option aims at clarifying what is the source of the Debian > operating > system. It is controversial. To some of us, "the Debian operating system" is at least as much about the packaged source as it is about the packaged binaries. If you were to claim that DFSG freedom only mattered for things shipped in the binary packages, and not the things shipped in the source packages, i would find that upsetting. "Our users" includes not only an individual with a single computer who never sees the source, but also derivative distributions, private organizations, system administrators, etc, all of whom may need to modify the source for their own purposes. Knowing that the source of any package in main is free is a valuable feature of the Debian operating system. --dkg signature.asc Description: OpenPGP digital signature
