Closed Bug 821819 Opened 13 years ago Closed 13 years ago

We'd like to ship proprietary fonts in Fennec

Categories

(Firefox for Android Graveyard :: Reader View, defect, P2)

Product:
Firefox for Android Graveyard
Component:
Reader View
Platform:
All
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: jishnu, Assigned: gerv)

Details

Priority for your Team: Medium Timeframe for Completion: 2-4 weeks Goal: Make Fennec better Business Objective: Increase readability of web pages in Fennec Other Party: Font Foundry Description: Hi Luis, We would like to ship proprietary fonts with Fennec. What are the best practices around segregating font software (which is in "source" form) from open source appropriately? Brad, copied, can help out with technical details of the implementation. Thanks Jishnu
Thanks Luis, For 1, I don't think this has been done, who is the right person to talk to? For 2, I'm wondering how we indicate this to end users - could we put a license.txt in the font folder with proprietary restrictions if the font foundry agreed? For 3 - I'm working on this but will be consulting you. Right now, no flow through terms. Thanks Jishnu On 12/14/12 10:46 AM, villalu@gtlaw.com wrote: > Hi, Jishnu- > MPL makes it very easy to do this; as long as the fonts are in separate files before compilation (which they typically are, even after compilation) then there is not a problem from that perspective. Brad, if you want to shoot me a summary of what you're doing, I'd be happy to review, but it is hard to see how this could trigger an MPL problem. > > That said: > 1) As a general matter, Mozilla policy has frowned on distributing anything under a non-MPL-compliant license, unless it comes from the base OS and is necessary for interaction with the underlying OS. I assume that has been sorted out, but want to flag it just in case. > 2) You'll need to review the license presented to Fennec users through the Play store, if any. It should not imply that the entire product is MPL. > 3) The terms for purchase of the fonts may require other license notices, either in the product or surfaced through the Play store. I'd be happy to review the font license for you if that would be helpful. > > I think that's it- let me know if you have more questions. > Luis
Assignee: nobody → villalu
Status: NEW → ASSIGNED
Flags: needinfo?(villalu)
Luis - one more question: 4. Do you have visibility into how we manage build processes for the proprietary bits OS level stuff you mentioned in 1?
1) Gerv is usually the keeper of the flame on those issues. 2) We typically put that sort of thing (both for open source and quasi-proprietary licenses, in the cases where those have been allowed) in about:license. I think that would be the appropriate place here as well. That still leaves the question of what seps (if any) are taken to present about:license or similar information to users when they download from Google Play. If no license information is presented at download/install time, that is fine; but if there is something (whether about:license or something else) then that needs to be reviewed to ensure it remains accurate. 3) Great re no flow-through. 4) I think all past exceptions have been part of the base operating system, so no particular build process changes were necessary- we just told anyone who wanted to build the product to get the operating system (under whatever terms) and then build the tool. This may actually be more analogous to what is done for nightlies v. Firefox- i.e., adding branding images, strings, etc.
Flags: needinfo?(villalu)
Can whoever is proposing this help us understand why we are doing it? Last I heard, we were getting a custom font developed which we could release as open source - just as Google did for Android. That seemed like a very good path to me. Also, can we get more details of the proprietary license? Are they trying to ship the MS TT core fonts? Or something specifically licensed from a foundry? If we are specifically licensing it, why are proprietary terms necessary? Lastly, is there a reason this bug needs to be closed? If we are going to decide on what would be a fairly major change in our open source policy re: B2G (which is basically "from Gecko up, everything is open"), we should do it in the open. Gerv
Hi Gerv, this is a deck that outlines our plans for licensing these fonts. http://cl.ly/0W3u3Y3D3d17 The custom font design is a parallel effort, but one that won't be available to us for some time still. Thanks Ian
Just to make sure we are all on the same page - here are my options for the team and Ian's explanations of why other paths won't work for the business. Gerv, are you the decision maker here on the project side? Is it Harvey/Luis/Heather in their MPL roles? > 1. I know Patryk is working on an open source font with Telefonica and I just got involved to make sure the licensing works properly. If that font ends up being owned by us or under an acceptable open source license to ship with FirefoxOS, there is a good chance that it can work for Fennec as well from a legal perspective. Will these help solve the Fennec issues from a UX perspective? Patryk and I are going to be working on this together, actually. I don't know for certain yet whether or not the fonts will be appropriate for Android, simply because they aren't done yet. Designing these fonts is also going to take some time -- I can't imagine having anything ready for us to consider using until late 2013. And by then, who knows if custom fonts will be the same kind of differentiator that it could be now, where no one else is currently doing this. > 2. We can try and persuade the font shop to open source the fonts you are interested in so we can use them in our open build process. I don't realistically see that happening. Even if Fontfont agreed, the cost would be prohibitive. > 3. If 1 or 2 don't work, we may have to change the way RelEng works around Fennec builds, including security review, etc. They've started thinking about this to support other proprietary code, but I'm not sure if the end result will work for fonts or if you can wait (initial estimates were at least a month, subject to other priorities). Erin, if we're going down this path, we should set up time with John O'Duinn to explain the issue and see if he can help us. OK, can we start looking into this?
Summary: Review open source compliance for fonts → We'd like to ship proprietary fonts in Fennec
(In reply to Luis Villa [Outside Counsel; for non-law use luis@tieguy.org] from comment #3) > 1) Gerv is usually the keeper of the flame on those issues. > Got it - sorry for the questions in email cris crossed this. Assigning to you Gerv. > 2) We typically put that sort of thing (both for open source and > quasi-proprietary licenses, in the cases where those have been allowed) in > about:license. I think that would be the appropriate place here as well. > That still leaves the question of what seps (if any) are taken to present > about:license or similar information to users when they download from Google > Play. If no license information is presented at download/install time, that > is fine; but if there is something (whether about:license or something else) > then that needs to be reviewed to ensure it remains accurate. Makes sense - we can look into this once Gerv ok's this. > > 3) Great re no flow-through. > > 4) I think all past exceptions have been part of the base operating system, > so no particular build process changes were necessary- we just told anyone > who wanted to build the product to get the operating system (under whatever > terms) and then build the tool. This may actually be more analogous to what > is done for nightlies v. Firefox- i.e., adding branding images, strings, etc. Good to know thanks. Based on this, I don't think we've set up proprietary files in our build system before so this is an issue we have to clear through RelEng.
Assignee: villalu → gerv
Flags: needinfo?(gerv)
From my perspective, if we've never done this before, I'd like clear direction that including proprietary software in our open builds is something Harvey and Jay are ok with given all these complexities.
(I'd add that I think that the whole org should be carrying this particular flame; I point to Gerv not as a way for the rest of us to abdicate responsibility for acting on the Manifesto (point 7), but simply that - since there is no formal owner of this particular charge - he's been where the buck has tended to stop.)
Priority: -- → P2
Whiteboard: under discussion
It's 9pm here; hope it's OK if I look at this tomorrow or Monday morning UK time. Gerv
Flags: needinfo?(gerv)
Adding in Brendan and Damon for additional perspective and a recommendation on this from a project governance perspective. Note, we've shipped proprietary drivers before and some other low level bits. So its not like its totally new, but it is new to the extent that we're doing this not to make the product work on a platform but for enhancements of the experience. This makes me uncomfortable, unless all the other alternatives have been explored. Also - someone is going to have to own this decision publicly and explain to the community the value proposition and necessity. Would that be the product team?
Whiteboard: under discussion → under discussion
I think we need mitchell as well as myself, and johnath for good measure. Asa (another old-timer) too. I'll have to study this when I have more time, I just speed-read it. Looking forward to Gerv's thoughts. /be
Hi Harvey, Brandon, Mitchell, Damon, Asa, and Johnath -- for more context, please be sure to also read through this deck I assembled on why we want to ship fonts on Android: http://cl.ly/0W3u3Y3D3d17 Thanks!
Wow, what a great point at which to misspell Brendan's name. My apologies!
Hi everyone, Thanks for your patience. Firstly, I can definitely see the motivation here. Making text look nice, particularly at small sizes, makes the web experience better. And if the Android platform doesn't have the fonts we need, then we have to ship them. The issue is not "should we ship fonts?", the issue is "should we ship proprietary fonts?" I would like to see a well-researched written justification of why the available best-of-breed open source fonts are not suitable. The slide in Ian's deck, which gives a single pro of "Fonts are free, saves money", and 3 generic cons (without reference to any particular font) reads as dismissive. We need to investigate why Deja Vu (5000+ glyphs), Libertine (2000+ glyphs), Droid, Gentium (5500 glyphs), the Chrome OS (Croscore) fonts, the STIX fonts and the other fonts from SIL are all inadequate, and why the proprietary font we wish to license is a significant improvement for the mobile use case. In passing, I note from Wikipedia that "In 2003, the Gentium font was awarded a Certificate of Excellence in Type Design from the Association Typographique Internationale (ATypI) as one of the best designs of the previous five years." Our community would require such an explanation from us if we were to make such a significant move, and so we might as well make it a pre-requisite for making the decision rather than writing it afterwards. We should also at least get a quote for freeing the fonts which have been picked out as best before we decide it's out of the question. We are currently commissioning a font for ourselves; companies such as Red Hat and Google have done it before for multiple fonts and font families. The cost of freeing a font may not be as prohibitive as some think, and we should certainly not assume it is without asking. It's unfortunate that we seem to be considering this question now, when the Readability project has been running for some time. Earlier consideration of it might have allowed us to commission improvements to existing open source fonts, or work with SIL or other people in the free-as-in-freedom font world to work out how best to achieve this. As it stands, it seems like we have to pick from existing fonts, as there is not time to do any code work. It is true that, in the past, we have bundled missing pieces of the OS for downlevel proprietary platforms into our installer. We wrote a policy about doing so, which is here: http://www.mozilla.org/foundation/licensing/binary-components/ . That page begins: "Mozilla is and remains irrevocably committed to making free and open source software. We see this as the best way to advance our mission of preserving and promoting the open web." There are 5 key factors given there which we would consider when deciding whether to ship proprietary code; in the context of that policy, I don't believe this change meets any of them. (If you took each of them standalone, you could argue about 3 and 5, but I don't think we've done the research yet to convincingly argue this change meets those either.) I do find it very hard to see where our commitment to open source, as outlined in documents like the one above, in the Manifesto, and in the expectations of our community, would be if we did this. Everyone who buys proprietary code or data and includes in their product does so because, in their view, it makes their product better. And that would be, basically, what we were doing. If someone then said "there's this great proprietary code library we could include to make Firefox better", how would this not be a precedent? I don't think there's a meaningful line between fonts and 'code' here. In what sense would Mozilla still be an open source organization, as opposed to an organization which uses open source? While we do have a code license which allows other people to build proprietary products on top of our stuff, we have never done so ourselves - and if you asked most community members, I think they would express deep surprise that we were even considering doing so. Some (including some of our community) believe open source is a moral thing; for those who don't, it, and the community we have built around it, are still our asymmetric competitive advantage and differentiator. Mozilla without our good-will and community would fare about as well as any normal 600-person company trying to take on Microsoft, Google and Apple all at once in a highly valuable market would fare. If we blow that advantage up, we blow up any chance of succeeding in our mission long-term. This change is not proposed to enable some important new web capability, or give us a leg up in some standards battle, or some other mission-critical thing. (The hypothetical "we need to ship H.264 yesterday in order to arrest our plumetting market share and the only way we can do it is with this proprietary library" would be a much harder question, IMO.) We are doing it to make text look nicer in our product - which, while a laudable goal, is not mission critical. One thinks of Esau, who sold his birthright for a bowl of stew.[0] So I would say that I'm against. Perhaps not everyone agrees with me. So, if we did decide to do this as a temporary measure, then: - We would need to publish that well-researched written justification of why the available best-of-breed open source fonts are not suitable. - We would need a cast-iron transition plan to go back to fully open source that is convincing to the community. We would need to publish the details of our plan to get a font made, who is making it, and when they expect it to be finished. - We would need to agree exact and concrete "good enough" criteria for the font we are having designed for us, so the project didn't end up slipping near-indefinitely "because we haven't finished the Chinese glyphs" or something like that. - Once proprietary software is in a system and working, it's very hard to get it out again. There's at least one Mozilla web application which started using proprietary charting library, and the team has so far refused to take the time to take it out. We would need to agree up front that taking the font out and replacing it was non-negotiable, even if it involved engineering work. (Although in this case, I can't see why it would need that much.) - If we are trying to use this as a product differentiator, then the particular style of the font might end up becoming something which makes people think "Firefox". So, we would need to agree to give no weight to the argument which would be deployed in a year's time: "but at this stage everyone associates this font with Firefox Readability; we can't change it now". - We would have a problem because currently our binaries are licensed MPL 2. We would need to go back to either that-with-a-qualification or some sort of EULA. We'd have to choose between taking the flak for doing that on Linux (the previous EULA was a political pain in the behind), or simply not including the font on Linux platforms (and therefore taking different flak for making Linux a second-class platform). - We'd get a lot of criticism from the open source community about Firefox no longer being free software, criticism we have worked hard over the years to avoid (e.g. by relicensing our logo files as free software, while retaining trademark control). Such criticism, being true, would not be refutable. Thinking through and writing down some of these consequences makes me even more against. :-| Follow-up question: is there any effect on B2G here? Or are they still using, and planning to use, what Ian's deck refers to as the "Mozilla/Telefonica font"? Does B2G have a Readability mode? Gerv P.S. Let's knock one thing on the head, though: AFAICS I don't think there would be any build system issues with including a proprietary font. [0] http://www.biblegateway.com/passage/?search=Genesis+25:19-34&version=NIV
Hi all - I just wanted to add a few points here, supplementary to Ian's set of slides. This won't serve to address all the points made since, but may give some more context for our proposal. * Regarding "We are doing it to make text look nicer in our product - which, while a laudable goal, is not mission critical." Little we do in experience/product design is linkable in one step to mission criticality, but I believe that it does contribute. We're trying to build the highest-quality, most pleasurable to use product we can in Firefox, partly directly for our users and also to increase our marketshare. This last part certainly is mission critical. Unlike on desktop platforms or iOS, Android ships with only one font family (roboto), and it is surprisingly low-quality. The Android default browser and Chrome both use it. As a result, there's a particular opportunity to (a) be better for our users by providing a more satisfying experience of the web (possibly in a way the default browsers won't/can't follow), and (b) to have that difference in experience be something that keeps them in Firefox. After using a build with better default fonts, my reaction to seeing pages set in roboto is that it feels like the browser is just not doing as good a job rendering the web. I realize that the bottom line of the comments above doesn't actively disagree with the idea that providing higher-quality fonts at all, but I wanted to underscore that we think the value is significant, not just that it's nice to have. * Re: the moz/telefonica font -- The font being commissioned is an excellent UI font; in other words, it's legible and distinctive -- a great use for application icons and labels in chrome. It is a little too distinctive and noticeable to be a good general body text reading font. It is a font that makes its own voice heard, which is perfect for the reasons it was commissioned, but too "loud" to be a replacement default body-text font. Just as short term issues, there are currently no italic or serif fonts as part of the moz/telefonica font family, and likely won't be for about a year, by which point our competitive opportunity may have disappeared. * I'll let Ian chime in here, but the team spent quite of bit of time looking for an open option that fit our requirements. The world of high-quality type, as we found when talking to a number of other foundries, does not currently overlap very much with the world of open. * There may be a path to explore in buying or otherwise opening an existing font, but I believe that Ian explored that option here with FontShop and it was going to be very expensive. Certainly we can look at this again, if we think that we would actually be interested in pursuing it. * We'd love to swap these out for open versions when viable ones exist. In fact, we'd already started talking about that when some of the other less distinctive weights of the Moz/Telefonica font are finished, it might be possible to use the sans serif variant here instead of a proprietary font, but, again, that won't be for some time. I'd be very happy to talk more about what a transition plan would look like, there. I don't think that variation from a "signature" look of the fonts would be a big issue, given the "quiet" nature of the fonts we want to use.
I understand many of the points Gerv makes, like wondering about the research that shows there are no adequate open fonts. On the other hand I also believe that building a great product is mission-critical. We fulfill our mission by building great products that people love, and by building communities and organizations that instantiate Mozilla values. Having great products is one of the key elements that makes us successful, and different from advocacy groups.
I entirely agree that building a great product and having market share is mission-critical; but it's also part of our mission to do that product-building and market-share-getting in particular ways, even if perhaps our product is a little less good or our market share a little less high as a result. We don't mine all the data we possibly could do from our users, even if it would be useful in product decisions, because we haven't figured out how to do it without violating their privacy. We didn't try and make a deal with Adobe to bundle auto-installed Firefox with the Flash player, because we think that kind of behaviour is sleazy, and so on. We held out against H.264 significantly past the point where an effect on user satisfaction could have been demonstrated. And, I would suggest, one of the things we also don't do is build in proprietary software. I'm not saying the team hasn't done the research on the open source fonts available, but it hasn't been made available for consideration and criticism (in the constructive sense of that word). Perhaps a good way of focussing the discussion would be to ask this question: "If Mozilla decided it would not ship a proprietary font, would the team a) ship an open source font or fonts (and which ones?), or b) not ship any fonts?" Commenting on a few of Madhava's points specifically: - I'm happy to accept the Mozilla/Telefonica font is not suitable (in fact I'm not surprised); I mentioned it only because Ian's deck seemed to suggest that it was a medium-term option. Perhaps he meant some alternative weights. But also, the fact we are commissioning one shows it's not unaffordable for us to buy and free entire fonts. - "The world of high-quality type ... does not currently overlap very much with the world of open." I can believe that, but I also know that there are companies and organizations (Red Hat, Canonical, etc.) who have tried to change that. It would be wise of us to consult with them about their experiences, and see if we can get some leads as to which foundries and designers are more enlightened, and who we might be better off working with - to buy fonts outright, or to get existing fonts enhanced. And one last thought: the more I think about this, the more I fear the community reaction. A "Mozilla sells out for a bit of bling" line, while not nuanced, would have enough truth in it to be very, very difficult to counter. A lot of our more passionate contributors would see it that way. How many camel's backs would this fairly heavy straw break? And it is true that if we did this, there isn't anyone who would be able to do a single thing on the web they couldn't do before. Roboto is legible, even if it might be a bit ugly :-) Gerv
Many months ago when we started this project, we did indeed first research a number of open source fonts (including the ones Gerv listed in comment 15), but as I mentioned briefly in my deck we found all of them to be below the standard we were looking for. We were looking for fonts that are beautifully designed, have wide character support, and are neutral enough to enhance web content without making a dramatic statement about the font itself. The open fonts we looked at often fulfilled some but not all of those requirements, whereas paid fonts excelled across all of these categories. Sadly, such shortcomings are difficult to articulate simply by looking at a type specimen or looking at a list of pros and cons -- a font truly needs to be used in real life for its quality or shortcomings to be noticed and appreciated. Such comparisons in fonts would not translate very well into a research document (I actually did attempt this), and to create one seems like a red herring to me anyway, since the differences are so subtle that it would be easy for anyone not championing great product design at Mozilla to say, "Sure the paid ones look pretty, but any of the open ones seem perfectly fine to me as well." To step back, I can see Gerv's point of wanting everything we do to be open. It also appears, though, that we are now in a position where Product's interest in making a truly delightful product for our users is in direct conflict with Gerv's model of "just good enough -- even ugly is OK -- as long as we're still open", and I am troubled by this. Especially the "just good enough is OK" part. We live in a world where users have a rapidly growing appreciation for design, and to ignore that puts us at a risk of being ignored ourselves. Anyone else care to comment? Gerv's position is pretty clear, so I'm curious what anyone else might have to add here.
From a Product standpoint (and a voice that's been with Mozilla for a while) I'd like to offer my support for shipping the best font we can. I think I understand the arguments against and they are all reasonable concerns to raise. The most concerning to me is the idea that it would be a community-damaging change. I don't think that's a winning argument though and here's why. We win not because we have the best mission statement of all browser makers but because we give users the best experience. There is nothing people experience more in a browser than reading text. It's *the* fundamental experience a browser facilitates, so making reading great is not "bling" any more than not crashing is bling. Mozilla should have no problem framing this as a basic improvement to the most common browsing experience and that should be sufficient to prevent or neuter arguments that it's just bling. If we cannot talk frankly with our community about making trade-offs when "purity" comes into conflict with great user experiences, which this clearly would be, then we need to solve that problem. Maybe we can use this font issue to figure out how to have these kinds of discussion. Maybe we need a separate effort for that. Either way, the idea that "just good enough" or even "a bit ugly" user experiences are sufficient to advance Mozilla's misssion needs to be debated and, IMO, discredited.
Not much new to add, but I'll reinforce a few things if only to put an opinion on the record: - I agree that we need to build our software in line with our values. - I agree that product excellence is mission-critical. "A bit ugly but open-pure" is not where we want to end up. When those appear to be in conflict, we have to get creative and we have to use judgement. Getting creative might include paying a foundry to build new open fonts or modify existing ones, or buying and opening a font ourselves, but I understand from conversations with Ian that most foundries are not willing to do this, and that the cost can also be prohibitive. We can also use judgement, and in my judgement, distributing a proprietary font is an acceptable option to consider. We render using proprietary fonts already on desktop platforms, albeit not ones that we distribute. I don't think doing so meaningfully undermines the hackability of our product or the web, nor does it impede user choice and sovereignty. As with nearly every decision the project makes, I expect broader community reaction to be mixed, not unilateral. There will be inflammatory threads, but I think the tail is wagging the dog if we use "community reaction" as a deciding factor in this. We define our community in terms of our shared Mozilla values. We should make the right decisions to further those values (to the best of our abilities to do so), and then communicate them clearly and honestly. To me, the questions are: * Have we exhausted our options for creatively solving the problem without giving rise to this conflict? * If we have, are we even able to distribute a proprietary font without substantial technical or legal difficulty (i.e. difficulty which would outweigh the benefit)? * If we are able to distribute the font and no creative, open alternatives exist, who owns the decision? Mark Finkle is the module owner for Fennec, and I own the engineering management responsibility for the group, but I think this is more of a project policy call. That appears to put it in Brendan/Mitchell's court, though I confess the mix of code and licensing issues means I'm having trouble placing it with either one of them exclusively.
I have to support Asa and UX's point here: when our mission provides a counter argument of improving user experience, how shall we balance and prioritize? We should not assume (or just imagine) whether our hard-core community contributors will be angry or confused as of the policy change, but we do have some good data demonstrating pages are not readable, and users suffer from that. I am pretty curious about how many hard-core community members will be strongly against it vs. how many users will happily see this happen, and I am not against to do any research to understand their reaction. If we decide to do so, I'd like to have it done sooner rather than later: the more days we delay on this, the more user complains we may have, and the more users may leave us. We have built a pretty good product (Fennec) and we shouldn't stop making it even better. It is important to keep morale up for users and the product team behind it. Compared with all the features and decisions we had as a company, is this font discussion important enough to get the community to decide on? or can we trust the quality of our product/UX team to make the right decision? It is impossible to have the community buy-in on everything we choose to do.
There are a few different topics here. I'm going to respond to comment 22, and how w make decisions first, and then get into substance in my next comment. I don't see this as a "do we let the community decide" question; it's a question of who and how we decide issues where one or more of our values appear to me or are in tension. in this case the value of open source software appears to be in tension with creating the most polished possible product for the most people. When I see phrases like "the community will be upset" I generally look to see if we have values pulling in different directions. I'd like to see us develop a way of describing this -- "Value Tension" or "Value Balancing." To me this gets to the heart of the matter; whereas "the community won't like it" attributes a viewpoint to an undefined group, and pits that group against some product, or marketing, or other decision. I'm *not* blaming Gerv for this, I'm blaming myself for not having done more to create a better shared language for this type of topic. To the specific question at the end of comment 22, I don't think it's fair to anyone to ask a particular product team to make these decisions -- it's not fair to the product teams, or to the larger Mozilla. This team wasn't hired or trained or necessarily experienced in balancing Mozilla values in tension like this. They may not have the resources to lead Mozillians outside their team into a discussion and decision that will be accepted. (It's excellent if people want to develop these skills, we need more people who can do this. If you know someone who's good at this, please point me to her / him.) The current question asks how important being open source software is to our identity, and how much -- if any -- closed software can we ship before our identity as Mozilla starts to decay? It's a good question. It needs a decision maker with experience and reputation in both zeal-for-great-product and open source / free software DNA. As johnath notes, these project policy decisions come to Brendan and / or me if they can't be resolved otherwise. (You can find a paragraph about this in the Ultimate Decision Makers section here: http://www.mozilla.org/about/roles.html ). Historically Brendan and I have been able to get to the right answer enough times that people continue to feel positive about Mozilla fulfilling its mission and values, and continue to participate, either as employees or volunteers. The goal in having decision makers for the projects is to get decisions made. Not to wait for an undefined community to make (or not make) decisions. We can't get to 100% on all of our values 100% of the time; life is too dynamic for that. I'll respond on the substance in the next comment.
Now for something on the substance. I'll note we should get this discussion into a newsgroup. Right now I'm going to get my comments here so that I can figure out how to get a productive discussion, just copying all the comments into a newsgroup posting or sending everyone to the bug isn't it. Issue: Two values in tension. Value 1: Build the best product experience for appealing for people who don't know about free software and don't evaluate on that basis; Value 2: Build Mozilla products as 100% FLOSS software My bottom line: (1) I believe that right now we have *no* room to move on building a product that is the most elegant and beautiful for general consumers in every way we can possibly imagine. The market is competitive. Consumers need to experience delight with Mozilla / Firefox for us to introduce them to the web and the things we care about. Building an elegant product exciting enough to crack the market is hard on its own. (2) I believe we have *some* slight room to vary from 100% FLOSS software. Not a lot, but some, if: (a) limited in scope, time and/ or other dimensions (b) acknowledged directly as a flaw we want to improve (c) we have good, solid, publicly stated reasons, plus the research to back up why we need to do this (d) we have a roadmap to improve There should also be a way for others to build FFOS with open source fonts if they want. (3) Varying from 100% free software is risky. It's not a good precedent, and we need to manage this carefully. (4) We have done this before, managed it carefully, not used it as precedent and found a way to eventually remove the closed software. Our first crash reporter was closed source software licensed from a third party, originally by Netscape and I think later directly by the Mozilla Foundation. We shipped this in SeaMonkey, then in Firefox. We shipped it for years until we managed to create a good (better) open source alternative. Some in the Free Software community were upset about this. We made it easy to make builds that did not include these items. (I don't recall if we did 100% builds or enabled others to do so easily.) This was painful. We did it because we needed crash reporting. It will be painful again. (5) I'm not positive we have room to move as I decribe in item 2, but I think so and I'm willing to lead in this direction. (6) So *if* the conditions in 2 are met and if Brendan agrees, then I will support limited use of close source fonts. Note that I will expect the people who did the research and believe this is necessary to describe that work as part of a public discussion with me. This sort of public accountability is enlightening and also humbling, as one experiences how much Mozillians want Mozilla to succeed in the market and also remain Mozilla enough that our success matters. I will lead as described above, but I want real rigor in the work we did to verify we need closed source here.
Agh, I think I said FFOS in my last comment, rather than Fennec.
Just to throw some additional information into the discussion (I'll post to newsgroup too). 1. We can easily make builds without the proprietary fonts, and will do so for developer builds. No Fennec build (unbranded or branded) should be broken if the proprietary fonts are not used. 2. We have been using an open-source font (Open Sans) for the Fennec "Reader Mode" feature. We could provide an option to use this font for general web content as well, if we consider it better than the Android Roboto font, and I think we do.
I agree we need to get this discussion into a newsgroup. Mark says that Open Sans is considered better than Roboto - so we already have an option to improve the situation without shipping proprietary fonts. The question is not then: "shall we make things better", but "do proprietary fonts give us a significant boost even over the best open ones?" Ian says "the differences are so subtle that it would be easy for anyone not championing great product design at Mozilla to say, 'Sure the paid ones look pretty, but any of the open ones seem perfectly fine to me as well.'" If the differences are so subtle even against Roboto, they will be even more subtle versus the best open font we can find. If we are to balance our values, then we have to have some way of quantifying the "pull" of both sides. How do we decide how much better FF Sero and FF Meta Serif are than the best open alternative? Firstly, we need to decide what the team think the best open alternative is. Is that Open Sans (if so, what is the best serif font?) or something else? I think this is a key question. Then, are there ways of scientifically measuring readability? Can we deploy them? When I talk about "our community", I'm not talking about cheerleaders who it's nice to keep happy, I'm talking about the people who build our product. They are us. If our aim is to produce the best product possible for the users, we need them, and we need more people like them. And we can't pay them all. Why would anyone volunteer for Mozilla? Motives vary, but some of the best hackers are those who believe in open source. Even if you personally think that value is negotiable and compromisable-on, you need to take account of how much worse our product will be compared to what it would be if some of them stop helping us, and go and work on other projects. Will the font readability improvements more than match that? What Asa calls "purity" in quotes, other people call principles. The entire point of _principles_ is that you hold to them even when it's difficult. If you change them when they become inconvenient, they were never principles in the first place. Is "we only do open source" a principle at Mozilla? Certainly, a lot of our community and the world thinks it is. Our Manifesto seems to say it is. Our previous practice seems to say it is. Is "making the best product possible" a principle? It's a strategy. And if we define "possible" as "consistent with our principles", then I have no problem with it. It's an effective and awesome strategy, and has served us well. :-) If we start trading off privacy principles ("Look at all that lovely user behaviour data we could get to make the product better!"), openness principles, security principles, user control principles ("The Marketplace experience would be much better if we vetted all the apps and kicked out the ones which didn't work well"), open source principles or other manifesto principles in favour of product improvements, then I think we've gone astray. Gerv
Yes, we're moving into philosophies now. I'll reaffirm my earlier comment that if the conditions I mentioned are met, I believe there's some room to move. I recognize you represent a portion of the FLOSS community and so I will test this theory that there is room to move. I have always lead Mozilla to live in the gray world. We balance between a self-defined perfection of principles and the reality of the world we find ourselves in, where citizens and consumers make chooses based on very different criteria. I have to give some thought as to how to have a productive discussion; I'll turn to that shortly.
(In reply to mitchell from comment #24) Thank you for laying out this framework, Mitchell. Of those two values in tension, we in the design team mostly live our day-to-day lives in (and probably feel more viscerally) the first one; a reminder of the second is useful. (comment excerpted for responses) > (2) I believe we have *some* slight room to vary from 100% FLOSS software. > Not a lot, but some, if: > > (a) limited in scope, time and/ or other dimensions > (b) acknowledged directly as a flaw we want to improve > (c) we have good, solid, publicly stated reasons, plus the research to > back up why we need to do this > (d) we have a roadmap to improve > There should also be a way for others to build FFOS with open source fonts > if they want. I think this situation meets those terms, in that: (a) it would be scope-limited to two fonts, without which the browser would still function; and I think we can limit it in time, as we can be working on getting the additional more appropriate members of the Moz/Tel font family designed and open-sourced, and use those as soon as they're available. This means committing financially to that process, which I think is in discussion right now. (b) We can certainly acknowledge that the current situation is a flaw, or temporary measure, that we'd like to improve (c) I believe that we have this, and will certainly talk about it publicly (d) we can commit to a roadmap to improve > (6) So *if* the conditions in 2 are met and if Brendan agrees, then I will > support limited use of close source fonts. Note that I will expect the > people who did the research and believe this is necessary to describe that > work as part of a public discussion with me. This sort of public > accountability is enlightening and also humbling, as one experiences how > much Mozillians want Mozilla to succeed in the market and also remain > Mozilla enough that our success matters. I will lead as described above, > but I want real rigor in the work we did to verify we need closed source > here. I believe it, about the public accountability being enlightening and also humbling. I look forward to it with appropriate anxiety. :) Mitchell - we'll need a bit of time to assemble our research and make sure that we're making our case as clearly as we can. Also, given that you'll be leading this discussion, I'd like to get your sense of what will be considered acceptable rigor, and that you're comfortable with our research and judgement. Don't get me wrong - I'm confident of the value of our proposal; but some part of our recommendation involves our team's aesthetic judgement, and I want to make sure nobody is surprised by that once we start. If Brendan agrees and we proceed, perhaps we can go through this in early January?
Appreciate mfinkle's points about unencumbered builds and an open reader-mode font option. Also the point about investigating (and keeping current the investigation of) alternative open fonts. We need to show our homework before any decision. Gerv's point about principles sounds good, but let's be realists about what we have actually done. We have supported plugins, always, including especially closed-source and proprietary-format ones, chiefly Flash. We have not (yet, and I hope we won't ever) bundled such things. We are now using H.264 codecs shipped with the OS, as a different kind of plug-in, by default for HTML <video>. So the issue is not about pure open source as a principle that circumscribes our product configurations as used by almost all of our users. Yes, you can configure and build Firefox or (IIUC from what was written here) Fennec that way, but it isn't what our users actually depend on. So it seems to me the precise question is bundling of closed components. Mitchell typo'ed FFOS but there, just for the record, we have no choice. We are bundling closed-source pre-built components. These are generally code, not fonts, but there is no substantial difference for the issue in this bug. /be
Madhav wrote: > If Brendan agrees and we proceed, perhaps we can go through this in early January? Yes, please. Mitchell and I are talking about an ongoing medium for communicating specific instances and general princples informing how we make great open-source products, sometimes shipping hard or even bundled dependencies that happen to be closed, on a managed-exception and limited basis. This will take time but should start with the current instance. /be
(In reply to Brendan Eich [:brendan] from comment #30) > Mitchell typo'ed FFOS but there, just for the record, we have no choice. We > are bundling closed-source pre-built components. These are generally code, > not fonts, but there is no substantial difference for the issue in this bug. On that particular question: the line we've been taking there is that layers which are "ours" must be open (Gaia, Gecko and the interface layer) and Gonk is as open as we can make it, understanding that no-one, not even Google, has ever shipped (in commercial quantities) a phone with no binary hardware drivers in it. We certainly told Qualcomm we weren't interested in non-open-source patches to Gecko. It's a big business risk - if we are going to build an ecosystem of collaborating companies around this OS, we need to avoid some more equal than others as far as is humanly possible. That's without considering its negative effect on our working practices, and the community/PR angle. Gerv
Gerv: that's all true but doesn't get at my argument that FFOS is shipping some binary-only stuff. Are fonts different in kind? They are not "source", so binary (or do you disagree?). They are lower-level. FFOS includes a RIL implementation from QualComm that's an optimized replacement for an open source version that does not perform. How is that different-in-kind from this bug? Please note I am *not* advocating that we fix this bug as its summary proposes (not yet). I'm not for or against. I'm just trying to identify precedent. /be
Another idea (we seem to be falling into the mirror-the-competition trap, which hurt Netscape in the early days of Mozilla [it was more "do what AOL wants" and less "mirror IE", alas]): Whatever we do here, could we not fund a prize system for designing an open source and free font that we can use? Is there no room for innovation in the open on fonts? /be
(In reply to Brendan Eich [:brendan] from comment #33) > Gerv: that's all true but doesn't get at my argument that FFOS is shipping > some binary-only stuff. Are fonts different in kind? They are not "source", > so binary (or do you disagree?). They are lower-level. I don't think they are "lower-level". For FFOS we pinched underlying OS and hardware interface code from Android, for time-to-market and hardware compatibility reasons, based on a strong argument that without them, we'd be too little, too late. Sad, but fair enough. Fonts are, in a sense, almost the highest part of the stack - no hardware interface, interchangeable with 100 other different "implementations" at no capability cost (although some aesthetic cost or gain, depending on which you pick), used only to display info to the user. Proprietary fonts are not a /sine qua non/, as proprietary drivers are (at least in 2012). I agree fonts, as distributed, are on the binary side of the source/binary distinction. > FFOS includes a RIL implementation from QualComm that's an optimized > replacement for an open source version that does not perform. How is that > different-in-kind from this bug? There's no open source that'll do the job. I don't think that applies here. We can read text fine using the font that ships with Android. We can provide a nicer text reading experience using a different open source font than Roboto. (I am still looking for the UX team to name their best open source choice so we can make comparisons and see how much gain we would get by going proprietary.) The difference here is not between "unusable" and "usable", it's between "better" and "even better". And we don't know the magnitude of the gap. > Please note I am *not* advocating that we fix this bug as its summary > proposes (not yet). I'm not for or against. I'm just trying to identify > precedent. Even if one can find precedent, I think a better way to think about this is trajectory. When the project first started in 1998, we had Talkback. Nobody liked it - because it was flaky and, relatedly, because it wasn't free software and we couldn't fix it - and eventually we managed to replace it with Breakpad. At one point, we had to ship some MS OS graphics DLLs because MS weren't shipping them, and WebGL needed them - it was two, now it's one, and hopefully one day it'll be none again. There were no open source implementations of those DLLs, and the other option was to have WebGL not work for 33-50% (I forget) of users. In Firefox OS, we've had to accept shipping some proprietary software in order to get to market - but we've worked hard to keep it to a minimum, and tried to impress upon our partners that we think it's sub-optimal and want to move away from using it as fast as possible. Given who our partners are and the way they normally do business, this will take time. But AIUI this is what Mitchell means when she talks about bringing our values to them. We've made it clear which way we want to be going, and tried to make the case that it's better for all concerned. In all cases, with all products, I suggest that we have a general trajectory away from proprietary software. At no point that I know of have we ever taken out a working bit of free software and replaced it with a proprietary reimplementation. That seems to me to have the opposite trajectory to the one we want. Or, to talk about precedent again for a moment: if we did this, why would it not be a clear precedent for replacing the JS engine with a better-performing closed source one that we licensed, if such a thing were to come along? And if we would also be happy to do that, then I think it's clear we should no longer be an open source organization, we'd be an organization that uses open source. > Whatever we do here, could we not fund a prize system for designing an open source and free > font that we can use? Is there no room for innovation in the open on fonts? Lots, I'm sure. Again, we should talk to people who've gone down similar paths before us. The difficulty is that although the UX team appears to have been considering this for some time, we have not been doing these investigations in parallel. Gerv
Hi everyone, We did a some more digging and wanted to report back with our findings. First, to take a step back, as many of you know our original plan to improve readability on the web many months ago involved finding some way to use open source typefaces. But in our initial searches, none emerged that appropriately fulfilled all of our requirements: 1. Must be beautifully designed and very comfortably readable 2. Design must be subtle - this is an all-purpose font. Like Helvetica, it should adapt to content but not make any strong statements about itself through its appearance. 3. Must have broad character support for multiple languages (good coverage across Latin/Cyrillic/Greek character sets) We often found that either a typeface was beautiful but lacking in character support, or it had great coverage but was either unattractive or simply not appropriate as a general purpose typeface. So we moved on and started talking to font foundries about licensing fonts to use, and they delivered some of the best fonts available today. Initially, this seemed like a reasonable alternate solution, given that it is quite common to pay money to get good design, and quickly, whether it's an illustration, a photograph, an icon, a piece of graphic design or a typeface. And given that we already ship other semi-restricted items in our browser (our logo is trademarked, for example -- which I realize is slightly different but at the time we saw no real distinction), paying for fonts didn't initially seem to be a conflict to our interests as an open source organization. We have learned in this process that in fact this is a somewhat deeper and more philosophical issue -- and that even now it is up for debate as to what the Right Thing to do is -- and so here we are today. To do more due dilligence and in preparation for our newsgroup discussion, we went back and did a much deeper dive into open source typeface design. In our research, we discovered some fonts we had missed the first time around; we also learned that some of the fonts we dismissed early on for lack of character support actually stacked up much better than we thought. You can take a look at a comparison of our findings here: http://cl.ly/image/3X3J1g0I0w0v/o * Paid fonts perform exceptionally across the board * Charis (serif) was a new find, and performed suprisingly well * Gentium (serif) is a beautiful font with great character support, but its design is very distinctive and had too much of an old world feel for web content * Open Sans (sans serif) is strong across the board, and has considerably better character support than we initially thought * Source Pro, while beautifully designed, simply didn't have the range of characters we need. Given the quality of the font, it may be worth considering sponsoring the creator to fill out the rest of the characters in the typeface, not just for our use but for the open source community in general, as it is a great typeface. Even though the quality of design of the paid fonts remains superior to their open alternatives, it's a difference of A+s vs. As, whereas before it was A+s vs. Cs. Given how close they are in quality, *and* given that this initiative is a temporary solution while the design team works with an outside font foundry to design our own Mozilla-funded open source fonts, at this point UX feels that sticking to open source fonts (Charis and Open Sans) is actually a more reasonable near term solution. The question of how we resolve the tension between our values around quality of product and openness will likely rear its head again, but I don't think that we necessarily need to have it around this particular topic. I think a newsgroup thread on this topic would be better served by a situation with starker choices than this one is turning out to be. Any thoughts on (or objections to) this approach?
I agree the tension needs to be addressed. I want our products to be A+; I feel product excellence is a Mozilla value too. How to integrate this value with others like open source software is a big deal. In this case it sounds like the gap will be short term. If the product team is content, then we will address this topic in another setting.
Obviously, I'm glad that the team took the time to re-evaluate the open source font landscape, and really pleased that we have found some excellent fonts to ship. Here are some take-aways and questions I think we should consider: - Given that we are commissioning fonts, we should take some active steps to find out how we can best grow a community around them. Mozilla has very strong local community roots, and I'm sure regions of the world who use alphabets not initially covered by the fonts we are building will want to contribute or find people who can. How can we architect this for participation? Is the foundry on board with this idea, or are we on our own? What do others who have tried this before us (e.g. Ubuntu) say? - Is there work we can do to move Charis and Source Pro to A+ in the short or medium term, or are our efforts best spent working on our commissioned replacements? When do we hope the commissioned fonts will be in a shippable state? - In an ideal world, there would never be a tension between openness and quality of product, because the best thing for us would also be the open thing. And, given some lead time, we do often have the financial resources to make that so. In future, when we initially realise this tension may be arising, how can we start defusing it earlier rather than suddenly finding ourselves under deadline pressure? - How can we open up the design process, or the needs of the design team, some more without getting into bikeshedding? Charis is not that obscure a font in the open source world, and Mozilla even employs someone (Jonathan Kew) who used to work for SIL, who make it. If there had been a "call for suggestions" or similar, I'm sure it would have come up. How could we have got wider involvement earlier, to make sure that we were evaluating all the options? (One other question for Ian: the web page for Gentium says "Gentium is a typeface family designed to enable the diverse ethnic groups around the world who use the Latin, Cyrillic and Greek scripts to produce readable, high-quality publications. It supports a wide range of Latin- and Cyrillic-based alphabets."[0] Therefore, I'm surprised that it got a red cross for "Strong character support (good coverage across Latin, Greek, Cyrillic)". Can you expand on that? Is the data behind your summary slide available? I realise Gentium has other issues which make it deemed unsuitable for this use.) Gerv [0] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=Gentium
Probably best to continue discussion of product quality attributes in another form; this bug doesn't seem the right place.
(In reply to Gervase Markham [:gerv] from comment #38) > (One other question for Ian: the web page for Gentium says "Gentium is a > typeface family designed to enable the diverse ethnic groups around the > world who use the Latin, Cyrillic and Greek scripts to produce readable, > high-quality publications. It supports a wide range of Latin- and > Cyrillic-based alphabets."[0] Therefore, I'm surprised that it got a red > cross for "Strong character support (good coverage across Latin, Greek, > Cyrillic)". Can you expand on that? Is the data behind your summary slide > available? I realise Gentium has other issues which make it deemed > unsuitable for this use.) I'm not Ian, but I'll dive in anyway with a comment on Gentium. I tried a Fennec build that included Gentium Basic, and I was surprised how much I liked the look - although Gentium is quite a distinctive design, and I was initially unsure how suitable it would be as a mobile-web font. -However-, there's another with Gentium (besides the design, which may not be to everyone's taste), due to it being a work-in-progress: it's not as complete as we would wish. There's the "Gentium Basic" package, which offers the range of weights/styles we'd want (regular/bold/italic/bolditalic), but has a reduced character set and very limited OpenType support; or there's the full "Gentium Plus", with a richer character set and more complete OpenType support, but it does not yet have a bold weight. As such, neither the "Basic" nor "Plus" packages fully meet our requirements. Once the Gentium Plus family is extended to provide a bold weight, it will be a very attractive option and we may want to reconsider it at that point. For now, however, Charis is significantly more complete.
(In reply to mitchell from comment #39) > Probably best to continue discussion of product quality attributes in > another form; this bug doesn't seem the right place. True, but I'd already written my reply to Gerv! But we should take further discussion elsewhere.
Resolving this bug, as discussion is finished. I'm still very interested in exploring how we can build community around the fonts we are having commissioned. Gerv
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Whiteboard: under discussion
Given that this discussion is now concluded, is there any reason to keep this bug closed? Gerv
Status: RESOLVED → VERIFIED
No, I don't think so. Rather than opening up a Legal bug, I think this bug should be moved to a different product, maybe Firefox for Android?
Moving to Firefox for Android::Reader Mode. Gerv
Group: legal
Component: Licensing → Reader Mode
Product: Legal → Firefox for Android
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.