Yandex Partnership for Search Services

In October, we asked for feedback on creating a deeper partnership with Yandex, one in which we would make Yandex search features the default  in our Firefox Russian language builds.  Over the past few months, we have listened to feedback, talked with our localizers, studied the trends of our Firefox Yandex builds, and reviewed the Yandex user experience.  All this activity led us to the conclusion that our Russian users really wanted direct access to the Yandex search services in official Firefox RU builds.  As a result, we’re planning on setting Yandex as the default search provider for the Firefox 3.1 Russian locale builds (these changes should go into the current beta for testing). This means that, upon download and launch, the Firefox Start Page for RU locale builds will use Yandex for search queries, and the search bar will default to Yandex.  Implementation details are in bug #471561 (https://bugzilla.mozilla.org/show_bug.cgi?id=471561).

Thanks for the help.

Bilski – Federal Circuit Affirms Rejection of Business Method Patent Claims

Just a quick update on a long awaited US Federal Circuit decision on patent law issued last week. The case is called In Re Bilski (PDF), which addresses business method patents, of particular importance in the software, medical, and financial domains.  In my view, it’s positive, because it constrains (v expands) what subject matter is patentable.  At issue was whether mental processes that aren’t tied to something real could be patentable. The Federal Circuit – in an en banc decision – said no, “the claims are not directed to patent-eligible subject matter.” Claim 1 of the patent at issue is shown below:

“A method for managing the consumption risk costs of a commodity sold by a commodity provider at a fixed price comprising the steps of: (a) initiating a series of transactions between said commodity provider and consumers of said commodity wherein said consumers purchase said commodity at a fixed rate based upon historical averages, said fixed rate corresponding to a risk position of said consumer; (b) identifying market participants for said commodity having a counter-risk position to said consumers; and (c) initiating a series of transactions between said commodity provider and said market participants at a second fixed rate such that said series of market participant transactions balances the risk position of said series of consumer transactions.”

The Federal Circuit is the US appellate court responsible for patent matters in the US and sits between regional federal district courts and the Supreme Court.  The case will likely be appealed to the Supreme Court, so more to come if the Supreme Court accepts the appeal, but for now, this is a positive step by the Federal Circuit. The Federal Circuit did not go so far as to say that business method patents as a whole are invalid or address software patents as a distinct category.

Below are some additional reports and analysis that may be of interest:

http://www.groklaw.net/article.php?story=20081103134949355

http://www.bingham.com/Media.aspx?MediaID=7761

http://www.sonnenschein.com/practice_areas/ipt2/pub_detail.aspx?id=48164&type=E-Alerts

http://blogs.wsj.com/law/2008/10/30/court-reverses-position-on-business-methods-patents-in-bilski-case/?mod=googlenews_wsj

Interestingly, two of the dissenting opinions both argued that the decision stifled innovation, but for completely different reasons. Perspective is everything. Judge Mayer’s dissent argued that business method patents should be declared ineligible for patent protection because affording patent protection to business methods lacks constitutional and statutory support and hinders innovation.  Conversely, Judge Newman  argued that not protecting process inventions ignores the congressional mandate to promote useful arts and sciences. Dissents aren’t law, but they provide interesting insight into how jurists may respond to arguments in future cases.

On the downside, I don’t foresee that the decision will reduce the impact of software patents as a whole going forward. It certainly won’t make it worse, which it easily could have.  But to comply with Bilski, patent applicants need only draft their claims slightly differently (as many already do) to include processors or some general purpose computer language in their claims.  Thus, applicants will still seek and likely obtain patents on methods of manipulating and processing information, as long as they are tethered to a real machine or they arguably transform something real.

Exploring Partnership with Yandex

Since before Firefox 1, search has been built into the browser because it makes the user experience better.  It *also* provides economic benefits, of course, but that’s not the reason that it was included.

In most places in the world, Google is our default search engine –the one that shows up in the search box in a default installation– and our community of users and localizers generally want that to be the case. When we think about which services to build into the browser, and partnerships as a whole, the first goal is to make sure it advances the principles of the Mozilla mission (more fully described in the Mozilla Manifesto). To me this means it has to be both consistent with the values of the project and be additive, whether to the user experience or to promoting the goals of the mission.   This is the first filter and gating to moving forward whether its a formal or informal relationship.  After that, we think about distribution – getting the Mozilla goodness to more human beings.  Once those make sense, we can look for ways the partnership can contribute to the sustainability of the project in a manner that’s consistent with our values.

In Russia, there’s an interesting situation, though: our localizers have been suggesting Yandex as the default search provider for some time. See bug 348096.  The key user benefit offered by Yandex for Russian language users is that they have focused on linguistic characteristics of Cyrillic and on Russian content to create relevant search results. The Russian user base obviously likes them a lot as well.  LiveInternet reports Yandex as having 55% of the Russian search market. Yandex also shares the first and second place for the most trafficked web property in Russia.

In June, they built a “Yandex-flavored” version of Firefox that they distribute themselves, and it’s had a big impact. Since then, users of the Yandex version of Firefox have grown to 300K+.  To date, this represents approximately 1/3 of the total Firefox Russian language user base.

This presents a unique opportunity. It’s one of the rare settings in which an indigenous search engine tuned to a particular language has turned out to be wildly popular, and where the local Mozilla community has consistently made strong, data-based recommendations for a solution unique to the Russian language.  The popularity of Yandex suggests that a number of Russian speakers may be eager to see Yandex as the default.  (Other search engines will of course be provided, as has always been the case with Firefox.)

Given the input of the localization teams, demonstrated user preference, and the existing base of Firefox users, we’re evaluating making Yandex the default search provider for Russian language builds. We’re very interested in broader community feedback to ensure we’ve considered all of the issues.

Licensing Feedback

We’re editing the language and working in the comments as appropriate.  Although there were a number of questions, not all addressed in this post, one comment asked how this proposal differs from the Fedora implementation. In its fundamental concept, it doesn’t really differ. We used some different words, referenced the MPL specifically, and took out as much extraneous material we could (material originated by Mozilla not Fedora). It was also suggested that we work in a larger open discussion with all the stakeholders who are working towards integrating web services into the linux desktop… This is an excellent suggestion which we should do.

Licensing Proposal Notice Page Screen Shot

Below is the sample notice page. The reference to the MPL should link to the document.

Below is the web services language which will open from the notice page above.

Licensing Proposal

We’ve received a lot of feedback on the licensing proposal. The commentary overwhelmingly indicated the proposed approach wasn’t good enough (that would be an understatement). We looked at it again, incorporated suggestions from the community at large and from some of the Linux distributors. The new design addresses both presentation and content. We’re still tweaking the language a bit and working on the implementation, but directionally this is where we’re going.

Presentation: There’s no click-through, or license splashed in the users face on start-up (or at any point thereafter). We’ll either include some text on the first-run page or in an info box that links to a static page in the browser that contains a notice about your rights. We’re still working through which implementation works best – so this isn’t final.  Some examples below:

Content:  There is no EULA. There are no caps except where grammatically required.  There is a notice page that points to the MPL, provides summary information on the rights that come with it, includes a statement about trademarks, and a statement about optional web services (like safe-browsing) that are not covered under the MPL.  The notice includes a link to the terms related to the services. Screenshots and text will be coming in the next hour or so.

We’ll likely see the first implementation of this in the Ubuntu builds, and depending on shipping schedules we see how this rolls out across other distributions/platforms and in our packages.

Obviously, we’ve been working with Canonical to get this worked out; however, the Red Hat and Fedora folks have also provided invaluable guidance.

Firefox EULA in Linux Distributions

We’ve been working for a while to fix some objections to both the presentation of a EULA and the content of the EULA in certain Linux distributions. The issue came to light because of a change in settings in the 3.0 builds, that turned on the EULA display at installation, similar to the Windows environment. This caused two big problems. One, it put a EULA in front of a set of end-users who are not accustomed to seeing such agreements. Second, the license grant itself was inconsistent with the values of many of the users in the Linux communities and our own. They viewed the EULA as improperly imposing restrictions on the use of Firefox. Red Hat and Fedora were staunch advocates for making a change, and helped us understand the problem and potential fixes.

Upon review, they were right. So over the past few months we’ve redrafted the license agreement and changed the presentation requirements. This was a significant change for us from a licensing perspective, perhaps long overdue in the eyes of others. We believe the new terms address the objections we heard from both a substantive and presentation perspective. The plan was to post about it this week, so I guess that part is coming true, but not quite the setting I’d imagined.

The new agreement (shown below) isn’t yet in the builds, but here’s what it does:
• Makes the license grant parallel to the MPL;
• It has optional terms that govern services provided by Mozilla through the browser (e.g. anti-malware and anti-phishing services). A user may opt of the services and continue using the browser;
• The license grant excludes trademark rights; and
• The license doesn’t require explicit click through.

It is essentially structured in two portions, one dealing with the code, and one dealing with the services. The first part describes the license applicable to the code itself. The second part contains terms that govern use of optional services. From a presentation perspective, we’re of the view that it’s good for users to easily be able to see the license terms associated with their software; however, this doesn’t mean it has to be a poor user experience. We have adopted an approach that tries to conform to the way the distributor presents license info. In cases where there is only a first run page presented, we’ve proposed language to inform the user that there is a license agreement, and they can click a link to view the terms. In other cases, like corporate builds where an IT administrator is already presented with EULA terms, we’ve asked distributors to include the terms with the terms that are already presented.

Over the next few days, we’ll review any comments, and re-evaluate the draft language in light of the feedback.

MOZILLA FIREFOX LICENSE AGREEMENT, September 2008 (DRAFT)

This Mozilla Firefox License Agreement (“Agreement”) applies to the accompanying executable code version of the Mozilla Firefox browser and related documentation (such executable version and documentation are referred to herein collectively as the “Product”). The [Insert Distributor Name] distributes the Product, which includes modifications made to source code originally made available by Mozilla (such source code, including those modifications, but excluding any trademarks or logos of Mozilla, is referred to herein as the “Corresponding Source”). The Corresponding Source, which you may use, modify and distribute, is available to you free of charge under the Mozilla Public License and certain other open source software licenses (collectively “Open Source Licenses”).

During the Mozilla Firefox installation process, and at later times, you may be given the option of installing additional components from third-party software providers. The installation and use of those third-party components may be governed by additional license agreements instead of this Agreement.

The Product is made available to you under the terms of this Agreement. By using the Product, you are consenting to be bound by this Agreement. If you do not agree to the terms and conditions of this Agreement, do not use the Product. The Product also utilizes website information services (“Services”), such as safe-browsing features, which are made available by the Mozilla Corporation (“Mozilla”) under the terms herein, and which shall only apply if you use the Services. If you do not agree to the terms applicable to the Services in Paragraph 6 – 10, you may continue to use the Product subject to the remaining provisions of this Agreement provided that you disable the Services on the Security Tab of the Preferences.

1. License Grant. Except as set forth below in Paragraph 2 (“Trademarks & Notices”), the Product is licensed to you under the terms of the Mozilla Public License, version 1.1, found at http://www.mozilla.com/MPL/ (“MPL”) which are incorporated herein by reference. This Agreement will also govern any upgrades to the Product provided by [Distributor] and originating from Mozilla that replace and/or supplement the original Product, in which case the term “Product” also refers to such upgrades, unless such upgrades are accompanied by a separate license, in which case the terms of that license will govern. Nothing in this Agreement will be construed to limit any rights granted to you under the Open Source Licenses with respect to the Corresponding Source.

2. Trademarks & Notices. Mozilla, Firefox, and the Firefox logo (collectively “Trademarks”) are registered trademarks of Mozilla in the U.S. and other countries. This Agreement does not grant you any right to use the Trademarks, apart from the use necessarily occurring in your installation and execution of the Product. If you modify the Product as permitted by the Open Source Licenses, you must remove or replace all images and files containing the Trademarks. You may not remove or alter notices in or on the Product (i.e. copyright or other notices) except as expressly provided in Exhibit A of the MPL or required by this paragraph. Except as set-forth in this Agreement, no other rights or licenses are granted.

3. Export Control. The Product and its use is subject to applicable export/import restrictions, laws and regulations of the United States.

4. Termination. If you breach any provision of Paragraphs 1 -3, including the terms of the MPL incorporated by reference, your right to use the Product will terminate immediately and without notice.

5. Privacy Policy. The Mozilla Firefox Privacy Policy is made available online at http://www.mozilla.com/legal/privacy/, as that policy may be updated from time to time.

6. Website Information Services. Mozilla grants you the right to use and access the Services via the Product subject to all of the terms of this Agreement. Mozilla and its contributors, licensors and partners work to provide the most accurate and up-to-date phishing, malware and other information via the Services. However, they cannot guarantee that this information is comprehensive and error-free: some risky sites may not be identified, and some safe sites may be identified in error. This Agreement also governs the use of Services made available to you as a result of your installing any executable software upgrades to the Product provided to you by Mozilla, where those Services replace or supplement the Services provided through the use of the Product. In such a case, “the Product” shall also refer to such installed upgrades. However, if such upgrades are accompanied by a separate agreement from Mozilla, the terms of that agreement will govern the use of the Services.

7. Disclaimer of Warranty. The PRODUCT AND SERVICES ARE PROVIDED “AS IS” WITH ALL FAULTS. TO THE EXTENT PERMITTED BY LAW, MOZILLA AND MOZILLA’S DISTRIBUTORS AND LICENSORS HEREBY DISCLAIM ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, including without limitation warranties that the Product and Services are free of defects, merchantable, fit for a particular purpose and non-infringing. You bear the entire risk as to selecting the Product and Services for your purposes and as to the quality and performance of the Product and Services. This limitation will apply notwithstanding the failure of essential purpose of any remedy. Some jurisdictions do not allow the exclusion or limitation of implied warranties, so this disclaimer may not apply to you.

8. Limitation of Liability. Except as required by law, MOZILLA AND ITS DISTRIBUTORS, DIRECTORS, LICENSORS, CONTRIBUTORS AND AGENTS (COLLECTIVELY, THE “MOZILLA GROUP”) WILL NOT BE LIABLE FOR ANY INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL OR EXEMPLARY DAMAGES ARISING OUT OF OR IN ANY WAY RELATING TO THIS AGREEMENT OR THE USE OF OR INABILITY TO USE THE PRODUCT OR SERVICES, including without limitation damages for loss of goodwill, work stoppage, lost profits, loss of data, and computer failure or malfunction, even if advised of the possibility of such damages and regardless of the theory (contract, tort or otherwise) upon which such claim is based. THE MOZILLA GROUP’S COLLECTIVE LIABILITY UNDER THIS AGREEMENT WILL NOT EXCEED THE GREATER OF $500 (FIVE HUNDRED DOLLARS) AND THE FEES PAID BY YOU TO MOZILLA UNDER THIS AGREEMENT (IF ANY). Some jurisdictions do not allow the exclusion or limitation of incidental, consequential or special damages, so this exclusion and limitation may not apply to you.

9. U.S. Government End-Users. This Product is a “commercial item,” as that term is defined in 48 C.F.R. 2.101, consisting of “commercial computer software” and “commercial computer software documentation,” as such terms are used in 48 C.F.R. 12.212 (Sept. 1995) and 48 C.F.R. 227.7202 (June 1995). Consistent with 48 C.F.R. 12.212, 48 C.F.R. 27.405(b)(2) (June 1998) and 48 C.F.R. 227.7202, all U.S. Government End Users acquire the Product with only those rights as set forth therein (including all rights to use this Product that are granted under the MPL).

10. Miscellaneous. (a) This Agreement, including the MPL, constitutes the entire agreement between Mozilla and you concerning the subject matter hereof, and this Agreement may only be modified by a written amendment signed by an authorized executive of Mozilla. (b) This Agreement will be governed by the laws of the state of California, U.S.A., excluding its conflict of law provisions. (c) This Agreement will not be governed by the United Nations Convention on Contracts for the International Sale of Goods. (d) If any part of this Agreement is held invalid or unenforceable, that part will be construed to reflect the parties’ original intent, and the remaining portions will remain in full force and effect. (e) A waiver by either party of any term or condition of this Agreement or any breach thereof, in any one instance, will not waive such term or condition or any subsequent breach thereof. (f) Except as required by law, the controlling language of this Agreement is English. (g) You may assign your rights under this Agreement to any party that consents to, and agrees to be bound by, its terms; the Mozilla Corporation may assign its rights under this Agreement without condition. (h) This Agreement will be binding upon and inure to the benefit of the parties, their successors and permitted assigns.

Partner Update

Just a quick update on some of the activities going on in the partnership space…
There are a couple of initiatives in play. First, we’re developing a long term plan that would set goals for the partnership function, and more importantly a framework to consistently evaluate new opportunities so that we can direct our efforts in the areas that will yield the greatest impact. We’ll need to answer questions like: are there partners that can support new services and features (like in Labs) that we should engage with? which distribution channels (if any) create the best distribution in a manner that’s consistent with our values? are there other revenue models we should consider? which ones are compatible with our values and make a positive difference? how are they prioritized? etc.

In all cases, the priorities we’re driven by are: i) advancing the mission – be it user experience, features, functionality, or values; ii) distribution – getting the Mozilla goodness to not only those who want it but also to those who need it; and iii) sustainability – making sure we have the resources to continue to make an impact 5, 10, and 15 years out. Note, this doesn’t mean every partnership has to serve all needs, although mission is paramount and no engagement should detract from the mission. It also doesn’t mean all distribution is driven solely via partnerships (there are many other product and marketing initiatives across the project that make a huge difference). In this phase, I’d also expect we’re going to be somewhat in a trial and error mode (hopefully less error) to find the best models and partnerships that provide the greatest return with the least drag.

The second involves tuning the parameters that define how we engage with partners. Historically, we’ve allowed some changes to Firefox distributed via 3rd parties, but we haven’t updated those criteria lately. As market dynamics have changed over the years, we need to make sure that we’re protecting the right aspects (user experience, functionality, UI, values, and features that define Firefox and the brand) and making room to accommodate partner needs in areas that are less important and that do not compromise the brand. Obviously, that’s a much longer discussion. Margaret Tallman and Kev Needham are leading this effort and soliciting feedback on a draft proposal. I’d expect a a draft set of partner guidelines to be shared soon for broader input.

Finally, we’ll be updating our customized partner distributions from 2.x to 3.0.2. There are approximately 20 distributions in several locales that should be updated prior to the release of 3.1. With the major update for our general release completed, and the impending release of 3.0.2, we’re ready to go. We’ll be working with QA and the Release Engineering team to prepare, test, and deploy major updates to those partner distributions in October. If there are questions pertaining to the Partner Major Updates, please contact Kev Needham (kev at mozilla dot com).

More to come…ideas and input welcome.

Prior aRt and Software Patents

We’ve just begun a new project at Mozilla to create a tool that can help defend against invalid software patents.  The project is currently sponsored by Mozilla and Emily Berger of the EFF. The problem is that when patents are asserted or enforced, it’s difficult, expensive, and time consuming to find the references (documents or other software/systems) that contain the elements of the asserted patent claims, also known as prior art. Finding prior art is often one of the key defenses to claims of patent infringement; however, this part of the  process is archaic, subjective, resource intensive, and inefficient. The result is that valuable resources are diverted from innovation and R&D to non-productive patent defense costs  (when I practiced as a patent litigator, no doubt I didn’t think it was non-productive).  The harm goes beyond hard costs, even the mere specter of an infringement claim can stall and delay the adoption of technology and products, or impose additional costs in the form of royalties and damages that has the same effect.

This is great for the legal industry, but not so good for those who are defending against such claims. A key  assumption underlying the project is that non-patented commercial and non-commercial software developments present a huge, and untapped, reservoir of prior art which software patents should be – and currently are not– tested against.  There are many other good efforts to improve the patent process, some like the P2P project focused on improving the patent examination process, and others focused on changing the legal framework, such as the Patent Reform Act.  These are good efforts, but there are other opportunities for improvement.

Our goal is to spec out the project, build a beta and see if it works. If it does, we’ll extend and enhance, if not, we’ll try something else. The details of the project are at: http://wiki.mozilla.org/Legal:Prior_Art#Summary.