|
|
Subscribe / Log in / New account

Leading items

Fedora, Mozilla, and trademarks

By Jake Edge
April 28, 2010

Trademarks and free software can make a volatile mix. It is understandable that a project would want to ensure that code shipping under its name is "the real McCoy", but modifying the source and distributing the result is a hallmark of free software. Trademark policy can place limits on what changes—for bugs, features, or even policy compliance—downstream projects can make and still use the trademarked names. The tension between the two has led some, like Debian, to re-brand Mozilla projects, so that they can ship the changes they want; some Fedora developers would like to see that distribution follow suit.

A Thunderbird crashing bug, reported by Felix Schwarz to the fedora-devel mailing list, is the proximate cause for the current controversy. Numerous Fedora users were running into the bug, and it had been patched upstream for several weeks, but there had been no release of Thunderbird for Fedora to fix the problem. Schwarz reported that the patch fixed the crash for him and others, and asked that it be pushed out: "However it is still not fixed in Thunderbird F-12 CVS. Can you please push the fix to CVS and push builds to testing/stable?"

Martin Stransky, one of the Fedora Mozilla maintainers, noted that "we're patching mozilla packages only for really critical issues because of mozilla trademarks", which caused concern that the trademarks were causing Fedora to ship a buggy Thunderbird. While the patch was available in the upstream repository, it hadn't been merged into the branch for the next release. Stransky said that he had requested that the next Thunderbird release include the fix in Mozilla's bugzilla entry, but that wasn't sufficient for some.

It turns out that the bug had been reported back in early March, but wasn't given a very high priority by the Thunderbird developers for two reasons: they couldn't reproduce it and it was not showing up with any frequency in their crash statistics. Meanwhile, since early April, it was crashing fairly frequently for Fedora users, leading to multiple bugs being filed, all of which were eventually collapsed into one with numerous commenters and "me too" posts.

But the idea that the trademark policy might prevent Fedora from shipping a working Thunderbird led to calls for rebranding the mail client (and the Firefox web browser) with different icons and names, as Debian has done. In fact, adopting the "Iceweasel" and "Icedove" names, if Debian is amenable, was one of the suggestions. Ralf Corsepius put it this way:

Thanks for providing evidence of how trademarks are being applied to void the benefits of "open source".

The obvious logical consequences of what you say would be
* either to remove the packages you are referring to from Fedora because they are effectively unmaintainable.
* or to remove the trademarks and re-brand the packages.

Fedora engineering steering committee (FESCo) member Kevin Kofler seems to be spearheading the effort to get out from under Mozilla's trademark policy. He agreed with Corsepius in a series of posts, which laid out multiple reasons that Fedora should consider renaming, including the Mozilla project's habit of bundling its own versions of system libraries—something that goes against Fedora packaging policies. He points to libpng as one example:

Another big issue is libpng: xulrunner is bundling a forked libpng for APNG [Animated PNG] support (which isn't even available for anything else to build against, so e.g. Konqueror can't support APNG). (APNG is a nonstandard extension to PNG which Mozilla is arbitrarily pushing instead of the existing MNG format which the PNG developers are supporting. [...]) Debian is patching it to use the system libpng (which removes APNG support, so it's unlikely to pass trademark approval, ever), we aren't. This is a blatant violation of our own packaging guidelines.

Several other examples were noted by Kofler, including Thunderbird bundling Gecko, rather than using the system xulrunner, and xulrunner bundling libffi. He also expressed frustration with the integration of Mozilla projects into desktops, in particular KDE. Overall, Kofler and others are completely fed up. Bruno Wolff III doesn't see any advantages to using the trademarks:

I don't see how using Mozilla trademarks provides significant benefit to Fedora. It seems to mostly benefit Mozilla. I don't see why we should be breaking our rules to help them.

Other posters defended Mozilla, but the loudest voices were clearly those who were unhappy with the status quo. Chris Tyler pointed out several reasons that Fedora should continue using the Mozilla trademarks including the well-established Mozilla brands:

Mozilla's brands are very well-known: They have 350+ million users across multiple platforms (Windows, Mac, Linux), far more than we have in Fedora. The ability to use these apps in Fedora helps to assures new users that switching costs will be low.

Tyler also sees the trademark rules as reasonable to protect users from distributions that unintentionally introduce vulnerabilities when patching Firefox or Thunderbird. He is optimistic that things can be worked out:

Fedora has a great relationship with Mozilla. They're an amazing project filled with people that Get It, and we can work out issues with them in a cooperative way.

It is possible for Fedora to patch its version of Thunderbird or Firefox, but it must get approval from Mozilla for each patch. the team that maintains the Fedora packages for Mozilla projects only wants to go through that process for "really critical issues" as Stransky noted. Later in the thread, he outlines which issues qualify: zero-day vulnerabilities and crashes that affect everyone. Kofler is, unsurprisingly, not happy with that Mozilla policy either:

They're the ONLY Free Software upstream insane enough to require approval for EVERY SINGLE patch as a condition to use their trademark. Imagine if Linus Torvalds did that for the kernel Linux, or the GNOME and/or KDE developers for their desktop environments. It would be impossible to maintain a distro under such conditions! Why does Mozilla get that sort of preferential treatment?

Fedora also wants to control its trademarks, though, and has its own trademark guidelines which are substantially similar in spirit—at least—to those of Mozilla. Adam Williamson described it this way:

You can't modify Fedora under F/OSS principles and still call it Fedora, just like you can't modify Firefox under F/OSS principles and still call it Firefox. Both of us do this to protect the good name of the project. We'd be in an extremely glass house-y situation if we tried to 'call out' Mozilla over this. It'd be ridiculous.

Lead Mozilla package maintainer Christopher Aillon tried to clarify the situation somewhat. The "impact of the bug was misjudged", he said, which is frustrating users: "I think we have a responsibility to both Fedora and Mozilla to include a fix for it". He intends to get a fix into updates-testing for a few days to ensure there are no regressions for other users. He also defends the process that the packaging team uses:

The main purpose to get patches accepted by upstream before inclusion in Fedora is to make sure we are doing things the right way. For example, some patches may inadvertently break standards compliance, have ill side effects with JavaScript, may fix connecting to some mail servers at the expense of others, etc.

[...] We do have an agreement with Mozilla and as such, we are permitted to use the Firefox and Thunderbird trademarks. But even if we did not or it were decided those marks were not important to us, I strongly feel that we should continue do things the right way and get patches accepted upstream first.

Furthermore, Aillon stated that the trademark policy wasn't really an issue for this particular bug. In a comment on the ticket filed by Rahul Sundaram asking FESCo to look into the issue, Aillon said it was simply a misjudgment by the packaging team about the importance of the bug. FESCo discussed the matter at its April 27 meeting, but decided not to change anything with respect to the Mozilla packages.

There are a number of different issues swirling around this bug. It seems likely that if the packagers had noticed how many users were being affected, it would have been quickly patched and the larger issue might never have come up—at least temporarily. But, the problem that some—particularly strong free software advocates—have with Mozilla's trademark policy is not likely to go away.

There are some legitimate concerns regarding the ways in which the Fedora packaging guidelines are being routed around for Mozilla packages. There are also some odd, seemingly political, questions around the use of APNG, which will require Fedora to either patch APNG into libpng or ignore the "no bundled libraries" rule for Mozilla for the foreseeable future. It is, in short, something of a mess, but not enough of one to send Fedora down the Debian path.

There is hope that some of the other concerns that Kofler and others raised will improve in time. Tyler points to the recent addition of Fedora systems to the Mozilla test farm as a step in the right direction. Previously, CentOS systems, with older versions of the system libraries, were used. Testing on Fedora could well lead to better system integration as well as bundling fewer libraries in the Mozilla packages.

There doesn't seem to be any movement toward weakening the Mozilla trademark requirements, and that policy will always be anti-freedom to some. There are lots of other projects with much looser trademark guidelines; even some high-profile projects like Linux itself. Some may feel that Mozilla is overreaching, but Fedora is in no position to lecture Mozilla about trademark policies. Those who are bothered by those policies will either need to avert their eyes or find another distribution.

Comments (47 posted)

Bringing open source to schools

April 28, 2010

This article was contributed by Joe 'Zonker' Brockmeier.

The best way to ensure the spread and success of open source is to introduce the next generations of users, and potential contributors, to open source at an early age. But this isn't trivial. Aside from software suitable for young users, it takes a lot of support materials to teach a class and spread the word to educators. One of the better documented attempts at reaching students is Máirín Duffy's eight-session Inkscape class and K12 Educator's Guide to Open Source Software.

The decentralized and loosely joined nature of the open source community has its advantages, but being easy to navigate isn't one of them. A case in point: While proprietary software companies have effective and plentiful resources to encourage educators to use their products, finding open source solutions is not as straightforward. This is particularly true for educators who are largely unaware of open source options. Duffy, an interaction designer for Red Hat and contributor to Fedora, has taken a stab at mitigating the problem by designing an eight-day Inkscape class for ten 7th grade students at Blanchard Middle School in Westford, Mass. and pulling together a guide for educators as well.

In October of last year, Duffy announced to the Fedora design team list that she'd be doing a Inkscape course at a local school on behalf of Red Hat, and was seeking help to put together the lesson plans. The class was held from early January through early February.

The course spans eight 40 minute sessions focusing on a single Inkscape project. Students learn about using Inkscape to create a logo for a band. Red Hat EmbroidMe Chelmsford sponsored putting the logo on a T-shirt at the end of the projects so students could actually have something to show from the course. In addition to the lesson plans and exercises developed by Duffy, the course materials also include the Inkscape manual from FLOSS Manuals and Tavmjon Bah's Inkscape: Guide to a Vector Drawing Program.

Even though the class is Inkscape-specific, the lesson plans and posts give some idea how to create a class from scratch or by adapting existing materials.

In the course of the project, Duffy also decided to create a two-page educator's guide. The guide and class materials are released under the Creative Commons Attribution 3.0 along with Inkscape files (for the guide) and ODF (for the lesson plans) for anyone who would like to remix and redistribute the content. The guide also uses free and open source fonts, so there should be no barriers to redistribution or refining the guide.

The guide provides links to some prominent resources for open source in K12 (primary and secondary education in North America) such as the education channel on Red Hat's OpenSource.com, the Open Clip Art Library, and the Open Educational Resources Commons. It also points to sites for finding open source applications, like osalt.com, and the K12OpenSource.org application catalog.

Note that it is, as the title implies, a guide to open source and not a guide to Linux. As such, it is primarily a pointer to community resources and a few applications of interest. It also contains a few choice quotes supporting open source by educators, and links to the posts Duffy wrote to correspond with the Inkscape class she taught. Says Duffy:

In the end, functional and full-featured open source tools that can be used in the classroom today do exist, so this guide is meant to send that message as well as point to a little bit of the story of where those open source tools come from.

Though the guide and materials were created for the class, Duffy says that it should work for "any Red Hatter or really any person reaching out to K12 schools". Having these types of source materials can go a long way to helping volunteers work with schools. Duffy says that "any time we can save those volunteers in having materials ready to go saves them time they can use to do more".

The students worked with Inkscape, but on Macs running Mac OS X and using Wacom tablets donated by Red Hat. Why not go all out and try to get the students and school using Linux as well? One of the things Duffy cautions against is to push educators too hard to embrace a fully open source stack all in one go:

An important thing to note is the guide does not reference ANY Linux distros - no openSUSE EDU, no Edubuntu, but also no Fedora Education spin or the Fedora Sugar on a Stick spin. The guide is focused on open source, not Linux. This is because as we found via direct experience in running our own open source outreach program with a local middle school - programs like this can be an educator's first experience with open source. If you push too hard for a 100% open source stack, you run greater risk of something going wrong and turning the educator / school off from open source entirely. It's better to take a measured approach - rather than coming in and changing the school district's operating system (which many times is simply not practically possible), it's better to vouch for cross-platform FLOSS applications like Inkscape and OpenOffice.org, taking a more gradual/measured approach.

Is there anything missing from the open source stack that schools need? According to Duffy, there's a gap when it comes to 2D animation applications:

If there is one thing in free & open source software that's missing that schools need, it's a simple, easy-to-use 2D animation program. It's the one thing the various teachers I've talked to always ask about, and I'm always sad to have no really great answer to give them. I know there are some projects working on this (e.g., Synfig) but we're not there yet.

It's hard to encompass the entire open source ecosystem for educators in two pages. Luckily, Duffy wasn't trying to. She points out that the guide is under a Creative Commons license, and she wanted to encourage others to build on it and revise it. What about a central source for this information? The guide points to several resources, but there's no over-arching authority to point educators to. Duffy acknowledges that there's not a site or project that includes all of the information educators need, but suggests that interested parties work with the K12 open source wiki referenced in the guide.

From the posts about the class, it seems that the sessions went well and the students took to Inkscape pretty happily. The choice of a relevant project that the students could become enthused about was probably a contributing factor, and the fact that they were working with a creative tool like Inkscape. Having hands-on activities obviously helped a lot. One consideration Duffy mentioned is that it's important to plan a lot of time for exercises, and that eight class periods is much less time than one thinks.

Finally, Duffy encourages LWN readers to take the guide and lesson plans and run with them:

I'd like to ask your readers that, if they haven't considered it already, they should think about volunteering in a local school! It's extremely rewarding. Kids look at the world in a different way and that perspective shift is really refreshing and energizing.

This is encouraging work that has helped introduce ten students to open source and started them on the path to working with more open source software. However, there are still millions of school children in North America and around the world that haven't been reached yet. Duffy's guide and posts provide a good idea what to expect when working with school kids and shows that they take to FOSS pretty quickly when it is presented correctly. With any luck, Duffy's posts and example will help inspire more open source advocates to take the lead in the classroom and introduce kids to open source applications.

Comments (6 posted)

Barriers to London's open source adoption

April 28, 2010

This article was contributed by Tom Chance.

When the Greater London Authority, a city-wide body, started to look at free and open source software they had little to learn from other levels of British government. The pace of adoption has been glacial in the UK, despite recent interest in open data. Having rolled out cost-saving open source technology for some back-office systems and web sites, the GLA has found that partnership across the wider public sector introduces the biggest barriers. The need for government bodies to interface with each other has held back the aspirations of the UK's open source action plan.

The British Government and public bodies were slow in recognizing the benefits of free and open source software; it took until 2004 for the publication of the first very vague policy document promoting it. Here in London there's little sign of progress six years on, as exposed by this question from politician Darren Johnson. In February he asked the Mayor of London how "the Greater London Authority and functional bodies [are] implementing the Government's open source action plan, recently re-issued by the Cabinet Office". Those "functional bodies" work on different parts of London's city governance: economic development, transport, policing, and fire and emergency services.

With the notable exception of the Greater London Authority (GLA) itself, which has "led the way in the use of Open Source Technology", the careful answers from wider group of functional bodies betray the lack of movement. The London Development Agency "has not implemented any open source software to this point"; the Metropolitan Police Authority "review opportunities for the use of open source software... as part of their ongoing programme of continuous improvement"; Transport for London "eagerly awaits further direction as it emerges from Government".

A follow-up request by Johnson for proactive, published action plans from each of the bodies in the GLA Group was met with another vague promise to "review the Open Source plans of all the functional bodies with a view to encouraging greater take-up and increasing the level of savings".

Open source technology in the GLA

The GLA's Technology team support the elected Mayor, Assembly, and approximately 700 staff, who in turn serve a capital city of 7.56 million people. While desktop users will mostly see the standard Microsoft offering — Windows XP, Internet Explorer, Office 2003 — much of the back-office kit in the basement has long run using Red Hat Enterprise Linux.

The GLA also started to use Drupal for building web sites, starting with a few custom-made interactive web sites such as the open Datastore and the public consultation for the Climate Change Adaptation Strategy. More recently, the main GLA web site moved over to Drupal, drawing the attention of the London Assembly committee tasked with scrutinizing the GLA's budget. Why? Because they were able to drop a web site project that had run up a bill of £1.2m using proprietary software and moved over to a new Drupal web site that cost £150k.

Drupal offered other benefits in addition to the low price tag. Drupal's extensive library of modules, which enable them to easily offer more interactive web 2.0 sites, made it the most attractive option from a technical point of view. This wasn't the case in 2006, when the GLA couldn't find an open source Content Management System (CMS) that was sufficiently powerful. According to evidence [PDF] laid out to the London Assembly committee by Daniel Ritterband, the GLA's Director of Marketing, Drupal offered other long-term advantages:

In 2009 the GLA had to make a decision on whether or not it was going to continue with a project that would keep it tied into a contract with a proprietary CMS that has relatively high development costs and a limited number of support agencies in the UK, or whether or not it should start again on a free, open source platform used by millions of people globally, which would deliver better long-term value to Londoners.

David Munn, GLA Head of Technology, is certain that cost has been the major driver in these changes, and not just in the obvious headlines such as web site procurement costs. Virtualization not only reduced the hardware and electricity bills for the servers, but also reduced the need for air conditioning by two-thirds. This change also hugely reduced their carbon emissions, following a report into the total lifecycle impacts of their IT that was finished last year. The high level of scrutiny from the elected Assembly, the media, and the public forces them to bear down on costs and reduce their carbon emissions.

Within the GLA the IT Strategy barely mentions free and open source software, although Munn is certain that the approach to reducing costs and carbon emissions strongly favors it. Adoption of Linux and Drupal has largely come about because of his enthusiasm for open source, which is shared by a few other key members of staff.

Barriers to open source in the public sector

While back-office systems and web sites have been easy, progress elsewhere has been much slower.

Munn's Technology team has to enable GLA staff to work with the other functional bodies in the GLA group. Microsoft Sharepoint was deployed to share project rooms across organizations, for example. The Mayor's Office also need ready access to Transport for London's CCTV network so that they can be fully involved in any emergency situations.

The other functional bodies have their own complex relationships. The Metropolitan Police, for example, link up with 42 other territorial police forces, the national Government and a complex tapestry of other law enforcement agencies. The Police manage a poorly understood suite of databases held by multiple agencies that are accessed using custom-made software; they typically exchange basic information using quite complex Microsoft Office documents that OpenOffice.org struggles to work with; and have a range of custom software for specialized needs such as the forensic services. So far, they claim, open source technology hasn't met their needs.

These complex needs make a move to open source software difficult for the GLA as well, due to their need to interface with the Metropolitan Police. Munn and his team did consider rolling OpenOffice.org out across their desktops, but the probable backlash from staff who might, for example, struggle to work with complex Microsoft Office documents outlining police budgets running to hundreds of pages outweighed the cost savings it would achieve.

Another problem that forces the GLA's hand is the move towards "shared services", where different public bodies run off the same technology platform in order to "provide the GLA Group with a more concerted and cost-effective approach to serving London" (according to an internal GLA document). For example, the GLA has recently moved onto Transport for London's procurement and finance systems. Transport for London (TfL), who run the Tube, other parts of the public transport network, and the main road network, is substantially larger than the GLA, with some 20,000 staff managing more than 27 million journeys a day. When TfL procured those systems it went for robust, industry-standard proprietary technology. Again, they claim that open source technology hasn't met their needs.

Now the GLA is locked into these systems, with a dedicated fibre-optic cable running between the two buildings.

The GLA did investigate downsizing their in-house Technology team and sharing TfL's services, but found it would be considerably more expensive. Their small size allows them to stay nimble and low-cost, in comparison with the complexity and caution implied by the size of TfL. Had they switched, they would in all likelihood have shut down the Linux-based back-office systems and moved onto TfL's proprietary stack.

Munn sees cloud computing as a possible way of levering in more open source software in the future. He observed that younger staff will increasingly be familiar with cloud technology suites from the likes of Google, and will find the idea of the full Microsoft office suite on the computer an anachronism. Where those cloud stacks are open source, or where they break up the stranglehold that Microsoft and other proprietary vendors have, we might see progress. But they could equally see a shift from one proprietary platform to another.

In the meantime, it seems that free and open source technology won't move into the front office of the British public sector until central government forces everyone's hand, overcoming network effects that prevent bodies like the GLA from moving first.

Comments (3 posted)

Page editor: Jonathan Corbet
Next page: Security>>


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds