Search Results: "Don Armstrong"

24 August 2008

Jonathan McDowell: DebConf8 writeup

I took a note of the various talks I attended at DebConf, with the aim of writing a few notes about each so that I could try to explain to my work mates exactly what I get out of going. However I think a lot of the benefit is about general face to face contact with fellow DDs and random conversations that happen. Having worked from home for over 3 years I'm finding it quite nice to be back in an office with people working on the same things as me; there are conversations that you will have over a quick cup of coffee or in the corridor that you wouldn't bother typing on IRC or email or picking up the phone for. Debian is a lot like a large organisation full of telecommuters and DebConf provides a vital opportunity for us to have those "minor" conversations that prove quite useful and to remind each other what we're actually like in person. I didn't end up writing a lot of notes during the talks so these are just snippets after the fact. If I'd been more organised I'd have done a write up on a daily basis rather than leaving it all until the week after. A lot of the below is fragmented thoughts, but the longer I leave it the less relevant it gets and the more chance I forget something. It'd have been up faster if I hadn't been fighting Movable Type to try and get some sort of headings. Sunday
Introduction, Marga The "Welcome to DebConf" bit. Marga got up and talked about how at DebConf4 (Brazil) she hadn't been a DD and now she was and how it had been a life changing event. She'd thought she was to blame for DebConf8 in Argentina, but trawling mail archives had shown it was originally Mart n's idea. She hadn't realised at the start quite how much work it would be. Steve's DPL talk, Steve McIntyre The DPL welcomes us to DebConf and talks about Debian's achievements, some of the results of his team survey (the teams largely say they need more manpower. Not really a huge surprise.). NM/User Survey BOF, Paul Wise Paul emailed debian-user, debian-newmaint and various other places (I think) asking about people's experiences as a Debian user or applicant to New Maint. His final results aren't yet published and I got the impression a disappointing number of our users had replied. The NM problems these days seem to be largely down to a lack of AMs, at least according to the stats on nm.debian.org. Meet SPI board - bdale, maulkin, jimmy, michael, others A chance to meet those of the SPI board who were present. The usual "If you're involved with Debian you should seriously consider joining SPI". Some discussion about the fact that although SPI was originally mostly Debian these days other projects are making more and more use of it - OFTC, PostgreSQL and Madwifi for example. Not a huge amount of new information for me. I've been an SPI member for some time and I think they perform a vital role for Debian. They've had issues in the past but it's really good to see them overcome and more projects on board. Monday
http://hp.com/go/debian, bdale Bdale talks about the history of Debian and HP. And makes the point that HP aren't doing any of this to be "nice"; their primary responsibility is to their shareholders. Not surprising, but it's good that even with that criteria at the fore front Debian ends up a good idea for a large multinational. Managing 666 packages, Mart n Ferrari Mostly centered around the pkg-perl experience and the tools/workflow they have to help manage things. Impressive web tool (DEHS) to help track packages with new upstreams, issues or pending uploads. Quality Assurance in Lenny + 1 I can't remember a lot of this, which is a bit bad. I remember a discussion about whether we should release with orphaned packages, or if they should be removed. The argument for not removing them seemed to revolve around a theory that if they weren't buggy then what was the harm, the argument for was that if they were unmaintained and not really used than how did we actually know they weren't buggy, and was it reasonable that they potentially held up library transitions etc? Bugs in large packages Don Armstrong and ways in which the BTS can help people with lots of bugs. This (thankfully) doesn't affect me, but it was interesting to hear Don talk about his work on the BTS and his various ideas. I was sorry I'd missed his talk on SOAP access to it; I shall have to find time to watch the video. Tuesday
Debian and Ubuntu, Mark Shuttleworth The usual interaction with Debian stuff, including how we interact with our upstreams. If a bug is raised with an Ubuntu package then it might well be appropriate to raise it with Debian and upstream as well, but each set of people should be able to use their own bug reporting systems rather than having to go to a foreign system. I don't think it was actually said, but I guess the idea is that launchpad is the thing that will do this gluing together. He also talked about Ubuntu as an "experiment" rather than a fork of Debian; something that has potentially different ideas about how to do things but that these ideas may lead to things that should be fed back into Debian. The point was made that even if you consider Ubuntu a fork they've forked 9 times now; it hasn't been a case of forking once and diverging wildly since thast point. I have a few thoughts on all the whole Debian/Ubuntu stuff which I should really try to form into something coherant and post. I think it's important to take Mark's talk in the context of bdale's "Shareholders come first" point. Derivatives round table Didn't stay for most of this. Ubuntu, Debian-EDU (which I hadn't realised was a derivative rather than a team within Debian, but apparently there are various things it was much easier for them just to patch now and try to work towards a generic solution later), someone from Extramadura and someone from the Munich government Linux stuff. I'm sure I've missed someone off. tdebs/i18n This was a useful BOF. It helped that we said no to the usual video team requirement that if you want to speak you had to wait for the microphone. This works fine for a normal talk, but really impedes the flow of conversation in something like a BOF. tdebs are something that have partly come from a need of Emdebian to reduce installed package size and partly from the desire of the i18n team to be able to update package translations without having to do a full binary NMU of a package. We had some of the FTP team, the release team, the i18n team and Emdebian there and I think some progress has been made. There'd been various conversations had before this meeting which I think helped people think about the issues and objections so that we had answers by the time we all sat down together - an excellent example of the use of DebConf. DebConf9 C ceres Various bits of discussion about next year's DebConf in Extramadura. Temperature is likely to be an issue for me as they reckon it could easily get up to 40C! I'll melt! Venue sounds good; some queries regarding late night hacklabs and net connections to same, but I'm sure the networking team will sort it all out as usual. ;) DebConf10 bids Venezela and New York were both pitching. Lots of people don't want to travel to the US or think they'll have problems doing so (I hadn't realised there was such an issue for people from South America). I suspect various people will have issues with Venezela as well; I heard expressions of doubt over their political stability expressed. However I'd be happy to go to either (and preferably both! DebConf10 + 12 perhaps?) Speaking of which, what ever happened to the Sarajevo bid? If they're reading, have you considered DebConf11? Wednesday
A day trip to an Argentinian ranch and lunch was an asido. Fantastic food and a pleasant afternoon spent sitting in the sun chatting to people. That evening was the formal, but thanks to having stayed up until after 4 on Tuesday I had to wimp out and go to bed fairly early. Not until I'd seen the DPL dance though. :) Thursday
Internationalization in Debian I forget most of this other than pretty graphs from Christian regarding what's translated and what other languages we might have; e.g. you can consider South America to be covered largely by Spanish and Portuguese, or you can consider it to not be covered very much at all by the local indigenous languages. dh-make-webapp: yeah right! Mainly what I took away from this was "It'll never happen thanks to the fact that every web app author uses a different system" and that more work needs to be done on the web apps best practices document. I don't really do web apps, but having them easily installable on my systems is a good thing so I hope some standardisation within Debian comes from this. Best practises in team-maintaining packages Various team members got up to talk about work flow in their teams. Not unsurprisingly different things seem to work for different people. Predictable PRNG in the Vulnerable Debian OpenSSL Package Lucian giving his Black Hat talk about the OpenSSL issues we faced earlier this year. Some queries about automated testing and that it should have found this, which originally I agreed with until I thought about it - you'd have to have run > 65536 tests and compared all the data to find this; something like the FIPS tests against a single run wouldn't have shown any issues. Lucian wanted feedback on ensuring he was presenting the Debian side of things acceptably as well. Keysigning Run by Don Armstrong. Nothing to really remark except I think key signing attendance is dropping off after things like the Helsinki experience. Also I've now managed to get my new RSA key signed by keys other than my own (and I'll try to get sorted out to sign keys myself soon). Friday
LessWatts Intel's drive towards reducing power usage. Odd to hear such things from someone who wasn't Matthew Garrett and I think I'd heard most of it before. Debian technical policy update Sorry Manoj, I should have been paying more attention. Debian Policy is something I think is important, but I'm not enough of a nitpicker to really feel I can contribute a whole lot. Virtualisation in Debian - Present and future This was depressing. What I took away was "We had 2 forms of virtualisation in etch (Xen + vserver) and we're supporting neither for Lenny". As someone running a Xen machine this is problematic. The host does have the hardware support that would allow kvm, but I'm worried about smooth migration (it's a colo box). There was some mention of Xenner, which isn't packaged for Debian. I took a look at doing so but there are some worrying items in the TODO list (like, oh, locking to enable reliable SMP) and I've spectacularly failed to get it compiling so far. I should have another go. Emdebian update Neil Williams about where Emdebian is and waved his Balloon3 about. Some interest from the Openmoko guys and discussion about why it might be better than OpenEmbedded. And equally what it couldn't do that OpenEmbedded can manage (mainly very small installs; a minimal Emdebian install is 24MB+ and with X that goes up to 75MB+ I believe). netconf I'd never actually seen Martin talk about netconf before. Am impressive flow of control diagram. It all sounds quite complex for little benefit at present, but if he pulls it off then I can see it being a much more flexible replacement for the likes of Network Manager. Saturday
Lenny - The Road To Release Neil played with putting the heads of the release team on random images. And tried to tell us all how to behave during the release process in terms of what should and shouldn't be uploaded etc. Most of it is just common sense, but apparently everything he talked about he'd experienced. Also pointed out we were supposed to release in 3 weeks and didn't even have the appropriate kernel in testing yet so it's probably not going to happen. Colour me surprised. Sustainable Computing Low power consumption/affordable computing. Interesting points about the OLPC being used in the middle of nowhere with no chance of an Internet connection being close by compared to neighbours in large cities where people can't necessarily afford top of the line computers or individual connections - in this sort of scenario mesh networking is really viable in terms of getting people connected up. Multi winner voting Manoj needs pretty diagrams, probably drawn by Martin Krafft. ;) Semi-interesting discussion about multi-winner voting (e.g. SPI board elections) and how the current Debian voting system is completely tied to Debian's infrastructure eg the LDAP setup. Manoj would like to make it more generic so it could be used by other groups as well as for different sorts of votes in Debian.

21 August 2008

Frank Lichtenheld: RC bugs in etch (Starting Stable QA, Part 1)

As everyone can see in the graph of release critical bugs, the number of RC bugs in etch had constantly risen since the release (which was already noted in some other blogs) up until last week. Since I suspected that this number included a lot of false positives, I began to triage this list last week during Debconf. I started with identifying all bugs that were filed against the version in etch, but really only meant the package in testing/unstable (but can't be interpreted correctly with version tracking alone since the version in stable, testing, and unstable is actually identical). There are a lot of reasons why an RC bug might be valid for testing/unstable, but not for stable, even though they share the same package:
Library transitions.
While most cases of library transitions can be handled with targeted binNMUs these days, there remain a few cases where a sourceful upload is needed, e.g. for renamed -dev packages and necessary source changes to adapt to new APIs.
Build-Problems caused by toolchain changes.
Newer gcc versions are often more strict about what constructs they allow. This can cause build problems in a lot of packages once the default version used is increased. Other packages that regulary cause new build problems are linux-libc-dev and dpkg-dev. Since we only require that a package is buildable in the release it is contained in, these are not valid RC bugs for stable.
Changes in the RC policy of the release team.
One example during the lenny release cycle was the use of invoke-rc.d in maintainer scripts to (re-)start daemons. Bugs were filed against a lot of packages not using invoke-rc.d before the etch release but they were only declared to be of RC severity after etch.
etc.
So as the first part of my triaging efforts I tried to identify these cases. I also looked for bugs that were listed as affecting etch due to incomplete version information (i.e. if there is no version given, the bug is assumed to affect all versions). As you can see from the bump in the graph I was able to identify about 200 bugs that met one of these conditions. We should avoid in the future to let the number of false positives grow to such large numbers. Everyone can help with that:
Maintainers
If you get bugs reported without a version number and you can verify that this bug was not present in an older version of the package, add correct "found" information. If you get a bug reported against a version that is both in stable and in testing/unstable, but not valid for stable, tag the bug appropriatly. I would recommend to err on the side of false positives though instead of on the side of false negatives!
Mass-bug filers
Most mass-bug filing that involve RC bugs should use tags to avoid creating false positives.
QA Group
Bugs filed about the proposed orphaning or removal of packages should usually be tagged, since only in very few cases these actually warrant any changes in stable.
At this point you probably ask yourself: What are the appropriate tags? This is much less clear than one might hope, since the involved tags (<suite>) changed/lost their meaning somewhat with the introduction of version tracking. Following my question about the appropriate tags on debian-release the release team and Don Armstrong for the debbugs maintainers seem to have agreed on their new meaning: A bug with suite tags affects the intersection of the set of suites indicated by its version information and the set of suites indicated by its suite tags. Next post: What about the other 600 RC bugs in stable?

18 August 2008

Jurij Smakov: DebConf8 impressions

What I liked What I did not like What I did

6 March 2008

Anthony Towns: The second half...

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:
Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey
I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…
Geez, this was meant to be briefer...

23 June 2007

Junichi Uekawa: apt-listbugs changes for easier use by clients.

Having had a little discussion with Stefano Zacchiroli aboutdebian/changelog editing and bug number completion, Idecided I'll make the 'apt-listbugs list' command a bit moreuseful.It now has two new features.--severityall option to specify all severities, and you canspecify the current version with PACKAGE/VERSIONsyntax. These functionalities should be available in the0.0.79 upload.It also uses the shiny new BTS SOAPinterface, and no longer relies on merkel.debian.org, thanks to help from Don Armstrong.To find a bug that is not yet closed on apt-listbugs 0.0.79, you'll ask for it like this: apt-listbugs list -s all apt-listbugs 0.0.79

19 June 2007

Anthony Towns: Chatting about the CDDL

Just prior to the “State of the Coffee Cup” talk on Sunday, Tom Marble sent a quick invitation to Steve Langasek, Sam Hocevar and myself to have a chat with Simon Phipps about the CDDL and some of the concerns that have been raised on the debian-legal list lately – particularly about choice of venue. Unfortunately in the ten or fifteen minutes between the mail and the meeting, we couldn’t find Sam, but we managed to grab Don Armstrong to join in instead. It’s a couple of days later, and I’m going from memory, not notes, so this is paraphrasing. Simon’s primary concern was one of predictability – Debian accepted the Mozilla Public License back when it was released (and prior to Mozilla and other software tending to get dual licensed under the GPLv2) which is what the CDDL was based on and contains almost the exact same terms. Simon’s comment was that if you’ve accepted that then, reviewing new licenses from scratch and coming up with different results really makes it hard to work with you, and worse makes it look like you’re basing your conclusions more on who proposed the license rather than what the license actually says. Don and Steve seemed to mostly appreciate that point, but still thought that choice of venue was harmful and unnecessary, and that it’d be nice if Sun – as pretty much the primary organisation currently behind any of these licenses – would take some steps to reduce that harm: limiting choice of venue to when both parties in a dispute are multinational, for example. Simon’s concern there was that updating the CDDL would require a lot of effort internally – getting buy in from all the groups in Sun using the CDDL, as well as getting the wording changes approved from the appropriate legal advisors, and convincing the lawyers of Sun’s commercial partners that the changes weren’t going to be a problem later; and committing to all that work when a new versions of the GPL is about to be released and it might be a better thing to work on getting the relevant software available under that, or even the GPLv2. On the other hand, Simon thought that making (binding) statements about Sun’s interpretation of the license seemed to (eventually) work reasonably well for the DLJ, so might be something that can be done again for this issue. And while that only counts for Sun, we can fairly easily ask if other authors of CDDLed stuff agree with Sun’s interpretation for their software, and only worry about possible problems if it turns out they don’t. That’s pretty much where we ended up I think, with Simon suggesting that we work out what exactly needs to be clarified with Tom, and then get it passed back up to Simon to get signed-off on. And hopefully that’s what’ll happen over the next little while. :) (The somewhat more interesting question of whether we can combine CDDL’ed OpenSolaris (in particular Solaris libc) with GPLed userspace tools such as dpkg to produce a Debian OpenSolaris distro is still up in the air – Sam’s currently waiting on a response from the FSF legal team on one of the questions that concerns Debian, aiui; but they’re currently flat out working on GPLv3 as you might imagine. Oh well – in the meantime, there’s always Nexenta!)

16 January 2007

Benjamin Mako Hill: MIT Mystery Hunt

I competed in the MIT Mystery Hunt again this year for Codex (this year, we were Codex Ixtlilxochitl). Codex has improved in the rankings every year. This time, we came in second place solving 106 of 108 puzzles in 40 hours -- only 90 minutes behind Palindrome (this year, they were Dr. Awkward). I'm very much looking forward to helping Codex improve again next year. Our team has an interesting mix of free software advocates (e.g., myself, Seth Schoen, Don Armstrong, Dave Turner) and a very large contingent from Microsoft. The effect is pretty impressive. I'm looking forward to the days when we work together on much more than just puzzles.

25 October 2006

Steve Langasek: 19 release-critical bugs were opened and 800-ish were closed

Thanks to Don Armstrong's improvements to the performance of version-tracking in the BTS and Anthony Towns's tweaks to dak, as of the middle of last week, all NMUs uploaded to Debian unstable will cause the bugs mentioned in their changelogs to be marked as closed in that version, instead of just being marked as fixed. This is a great benefit to the release process, since previously, bugfixes in NMUs were still falling off the radar as soon as they were uploaded, with no automatable way to check whether a given update stuck in unstable fixed release-critical bugs that we needed to have in testing for the release. So these guys get a big thank you from me for helping to ensure etch only ships with the bugs we want it to ship with. ;) The new setup also has the advantage that bug submitters finally get the same, real email for bugs closed in NMU as they do for bugs closed in MU, instead of being left in the dark as they were before. But that only takes care of bugs closed in NMUs that happen between now and the release -- it does nothing for the roughly 1200 RC bugs that were already fixed in prior NMUs that haven't been acknowledged by the maintainer. Who knows if any (or how many) of those are still open in etch right now? Rather hard to tell when we don't know what version closed them, isn't it? So with a lot of help from Adam Barratt this weekend, we've marked about 800 (egads) of these RC bugs as closed in the corresponding NMU versions, with a brief note to the submitters. In the next couple of days, we should find our way to the end of the list, at which point we can think about ignoring the 'fixed' tag over on turmzimmer.net. Also fixed now is bug #388431, so people should be able to stop worrying now about their users chewing up the CPU with real-time scheduling. Nothing like a maintainer upload of a base package one year in the making, being uploaded after it's been frozen. So make that... 801 bugs closed?

25 September 2006

Evan Prodromou: 2 Vend miaire CCXV

Happy new year, everyone! I was away over the weekend, working hard on Ignition 2006, and I missed the big day here in front of the computer. Instead I was out under the stars with Montreal Burners, having Burning Man fun out in the wt:Eastern Townships. I'm not sure if it happened this year, but I think next year it would be great to have a Debian:BSP in wt:Black Rock City. OK, sure, it'd be super-nerdy, and the connectivity is pretty spotty, but there are some long, hot afternoons out there and I know that there are at least two DDs that are on the Playa pretty regularly (me and Don Armstrong). I wonder if there are more? I wonder if we had a BSP, if lots more would show up? tags:

Usability So, my current computer usability problem has to do with the rockin' secure shell program OpenSSH. Here's what happens: I'm on a box and I have a new login goin' on. And I have to ssh to another box, and I get the message:
Enter passphrase for /home/evan/.ssh/id_rsa: 
This happens because I haven't run ssh-add when I logged in, to store the passphrase for the key with the current ssh-agent. So now I have two options:
  1. enter my password and then possibly forget to run ssh-add before running ssh again
  2. kill the current ssh instance, run ssh-add, then run ssh again
Both options suck. What would be nice is if I could enter my passphrase, and have that count as if I had run ssh-add. Like, after I enter it, the ssh client could say:
Add this key to your current ssh-agent session [Y/n]?
...and then ssh would add the key, like ssh-add does, and continue with the login. Wouldn't that be great? I think this is the biggest usability problem I run up against in my daily work life. Which, y'know, is pretty good. [You might want to look into libpam-ssh] [See also http://advogato.org/person/mbrubeck/diary.html?start=90 ] tags:

Wikimania 2007 in Taipei I have to say that I'm a little wistful that wt:Alexandria wasn't chosen for Wikimania 2007. We had a really good bid to hold the event in Alexandria at the Bibliotheca Alexandrina, the "new" Library of Alexandria. I was getting pretty excited about going to the Mediterranean next year. But I think that Taipei is going to be a fantastic place to hold Wikimania, too. Holding the event in wt:East Asia will make it much easier for people there , in wt:Southeast Asia, and in wt:Australia or wt:New Zealand to come to the event. A Wikimania in East Asia will focus attention on the non-English-language and non-European efforts of the Wikimedia Foundation. Taiwan also has a really strong local Wikimedian group, with Wikimedia Taiwan soon on its way. Finally, a Wikimania in wt:Taiwan will re-emphasize the wp:Blocking of Wikipedia in mainland China. Jimmy Wales has said on the record that Wikimedia will not censor its Chinese-language projects to comply with the PRC's firewall (the so-called wp:Great Firewall of China), and I'm sure an official event in the ROC will further highlight that point. Personally, I'm looking forward to a trip to Taipei, which will be a good excuse for some more exploration of Taiwan. And I want to congratulate the Taipei bid team. I was impressed by the amount of work that went into the Alexandria bid, and I'm sure they did a lot of work for Taipei, too. I know the Alexandria crew is optimistic for next year: starting the steps for making a Wikimedia local chapter in Egypt, and continuing to develop relationships with the local technology companies as sponsors. Should be interesting... it might be worth a trip after all! tags:

23 September 2006

Junichi Uekawa: Using soap in ruby.

In hacking apt-listbugs and getting something usable out ofdebian.org machines, and to fight against the inertia of notallowing direct access to db-h, I decided to give theSOAPbackend a try.Apart from the problem of non-existing documentation and non-functional implementation,with much help from Don Armstrong, I got something working.Due to the fact that only one HTTP request is required for obtaining the bunch of bug reports, it might be actually suited for apt-listbugs. I'm a bit worried about the load, tho'.soap4r was also very much painful to work with, with its lack of useful documentation.

4 September 2006

Branden Robinson: Managing Debian's Trademark

On 21 August, Don Armstrong, a Debian developer, accepted my offer to serve as my delegate in handling trademark issues vis-à-vis the DCCA. As an employee of a DCCA member company, I found it wise to avoid the perception of a conflict of interest. I should stress that any such perception would merely have been conjectural, however; at no point have I been asked by anyone to put my thumb on the scales, as it were, and deal with the DCCA or any of its member organizations in a preferential way. It is widely understood within the Debian Project that our existing trademark policy, originally formulated in 1998, is too vague, and has not scaled well to suit Debian's much greater degree of success and market penetration (on its own, and in the form of derivatives) seven years later. However, grappling with the issue has proven challenging for Debian's membership. I believe this is mainly because the Free Software hackers that comprise our organization have tended to self-educate to a far greater extent on copyright law, and even patent law, than they have on trademark law. Recently (within the past year or so), Debian gained access via its U.S.-affiliated charitable organization, Software in the Public Interest, Inc. to a pro bono legal counsel who understands the Free Software culture. Debian's difficulty with trademark management is not unique — we have been on the other side of this problem when dealing with the Firefox and AbiWord trademarks, since we customize the codebases of these software projects in our GNU/Linux distribution, but ship them with their names (and logos) intact. It so happens in these cases that the originators of the software (who hold the trademarks) approve of our modifications. One of the essential pillars of software freedom, however, is the user's right to make modifications that the authors or rights-holders in the software may not agree with. Free Software hackers can feel, with some justification, that it is misleading to uphold the freedom of a work on the one hand (by using a copyright license such as the GNU GPL), and take it away with the other (by asserting a trademark on some essential aspect of the work, such as its name). It is true that a work can be renamed, or descriptive text changed, to identify itself as distinct from an "official" version of the work, but this in turn, it is feared, can damage perceptions of the work through at least two mechanisms. Firstly, disclaimers about unofficial status may be unnerving to users who aren't schooled in the vagaries of trademark law, in which — at least in the United States — you are expected to aggressively defend your mark lest you lose a future infringement case you bring against a well-heeled defendant. Users may mistake strident proclamations of unofficial, unendorsed status in a piece of software as a warning that it is unsuitable for use, or has known severe flaws. Secondly, aggressive use of trademarks, or even just the tension observed above between giving with a copyright license and taking away with a trademark license, may lead some distributors to rename a work, obscuring its origins to the casual user. This can happen pre-emptively, before a distributor even knows whether the modifications they have made (or think they might make in the future) have met with any objection from the trademark holders in that work. The "freedom to fork" (i.e., make a derived version unendorsed by the original author) is an essential part of Free Software, and while Free Software hackers' sense of community generally leads them to eschew forking in favor of compromise and consensus, occasionally a fork ends up growing the userbase or improving the overall quality of the Free Software landscape. A hacker may fear that brash trademark assertions by an author constitute mere lip service towards the freedom to modify the work without changing its name, and may be tempted to fork it, leaving the trademark encumbrance behind. Even among those who do not guard their software freedoms quite so jealously, the fear can exist that a simple difference of opinion over some technical programming detail, such as choice of sorting algorithm or graphical toolkit, will escalate to the point where the trademark license on the work (implicit or otherwise) is withdrawn. This is the inverse of the previous situation — instead of a modifier choosing to fork a work, the original author of a work (or, at any rate, the holder of the trademark associated with it), can force the modifier to fork. The dilemma this imposes upon the people creating the modified versions — revert your existing change or be legally compelled to make an additional one — can rub people the wrong way. When forking occurs, for whatever reason, and even in the relatively benign case of "rebranding" to remove legally protected marks, the threat exists that the competitive strength of the corresponding software will be diluted. Imagine if each of four major GNU/Linux distributors rebranded their version of Mozilla Firefox, calling it instead things like "Lizardfox", "Hatfox", "Swirlfox", and "Hearstfox". How many users would deduce that the web browsers in question were all "really" Mozilla Firefox, each one with a fig leaf placed delicately over it so that the legally-minded types at the Mozilla Foundation and the distributors could wink at each other? Even the somewhat savvy GNU/Linux user may be more confused than one might expect, given that other names used for Mozilla's suite of applications include Sunbird and Thunderbird, yet there is an independent Free Software project called Firebird, which was established prior to the Mozilla Foundation's adoption of its product naming scheme. "What's in a name?", you may ask. They're important because they are simple labels we can use to refer to Free Software success stories. There's a lot of Free Software to talk about; the phenomenon of copyleft does much to ensure a competitive culture. It's difficult to achieve an unnatural monopoly in this environment, because anyone who steers a software project in a direction the users don't want to go has to cope with the prospect of seeing a group of those users organize their own community based around a derived version that does what they want. The hypothetical hydra-headed Firefox situation described above, however, is an example of false competition, because the distributors were compelled to distinguish their Web browsers for legal, rather than technical, reasons. In actuality, Mozilla Firefox is a good example of what's right about Free Software, not just because of its licensing but because a web browser is a familiar concept to nearly every computer user today. Free Software's early successes were more esoteric — GNU Make, the GNU Compiler Collection, the GNU C Library, GNU Emacs, and even the Linux kernel are not pieces of software that the general user can easily conceptualize. It is beneficial — to say nothing of convenient — to refer to the leading freely-licensed web browser as "Mozilla Firefox" rather than "a suite of mostly-compatible, similarly-named Web browsers shipped by the various GNU/Linux distributors". Those who seek to foment confusion and FUD about Free Software would doubtless capitalize on such a situation. These issues are challenging but not insuperable. A coherent policy will enable the community to establish a set of common practices, whereas now there are few conventions in the trademark arena. Ultimately, it is my hope that Debian will be able to promulgate a trademark policy that not only satisfies our needs, but serves as a model for others. To establish a successful policy, I suspect we need to build one up from basic concepts, and formulate explicit answers to fundamental questions. Originally published 2005-09-14.
Updated 2005-10-15 to add licensing in comments.

30 August 2006

Felipe Augusto van de Wiel: 29 Aug 2006

To infinity, and beyond! -- Buzz

[Debian]
I should write about this a few days ago but didn't have the time. Sorry. Well, these are great news (at least for me), a few days ago I sent the second part of my T&S and already got approved. My AM (Hi Cl ment) also pointed out a few changes that were needed in my packages that are already fixed and uploaded; Cl ment already sent the report and considering that, I'm now waiting for the Front Desk to review my application (and after that, DAMnation. I'm happy! I also finish the adoption of xless and levee. I still have to finish the MyPasswordSafe adoption, but before I have to fix a RC bug related to the use of sudo as the gain-root command (instead of fakeroot) in the alpha buildd. Thanks neuro that already give me a few tips on how to solve it.

Following the random ideas season:
  • Next week, Extremadura will host the i18n Debian people, the idea is to discuss lots of ideas, specially i18n Infrastructure, but not only discuss, also code a lot!
  • I do not like the idea to have sourceless firmware in main and I really like Don Armstrong proposal on that subject.
  • I still have to finish the desproxy, tuxfrw and thumbs packaging work to get it in time for etch.
  • I'm wondering how a tally sheet with more than 10 choices looks like


[Anti-SPAM season]
Like a lot of people already did, in the last two weeks I've been fighting SPAM in my company and also on the server of Free Software Projects that I'm part of the System Administration Team. In most cases I'm using postfix with clamscan and postgrey, but I will switch to amavisd-new to use SpamAssassin (with razor/pyzor). But I'm still studying the various alternatives in a Debian Sarge system.


Hey silva, thank you! (Journeyer certification).

Next.

Previous.