Charityware

---

This page is not maintained by the OLPC team. (See: About this wiki)

---

The OLPC Foundation could set up a software development site and software store for charityware (a combination of sf.net and shareit.com, e.g. using SourceForge Enterprise Edition [1]) with the revenue going to the OLPC Foundation. A group of employed developers could help to improve open source software or locally developed software to make it sufficiently interesting to be accepted as commercial software. The enhancements could optionally be released into the open source after 5 to 10 years.

As a side-effect this could attract software developers into an OLPC community that would also develop for the OLPC laptop.

Charity license

A charity license could be a non-OSI open source license requiring, against paragraph 1 (Free Redistribution: "... The license shall not require a royalty or other fee for such sale.") of the OSI open source definition, a fee payable to the OLPC Foundation for every user of the software.

One would, of course, not try to re-license important open source software but there may be some projects for which a charity license may be very acceptable.

For the purpose of charity one could also consider offering a license with a software renting model.

Software

Linux

One could ask the Linux Foundation to recommend a voluntary (e.g.) $10 per-user licensing fee. Linux distribution vendors could offer online shops and sell the per-user licenses independent of their distributions (thus "wearing a red hat"). Hardware vendors could be asked to acquire licenses for their customers and to forward the licenses in the form of X.509 certificates or activation URLs to their customers; a participating hardware vendor could receive the permission to show a logo "Official Linux vendor" under license from the Linux Foundation. The Linux Foundation or the OLPC Foundation would have to operate a certificate authority for the purpose. Encoding the Linux version number in the certificate could motivate a need for newer certificates, at least for major releases of Linux. The CA could also sell web server certificates and signatures for imprints.

Firefox browser

An enhanced Firefox browser could, for instance, (without trying to change the license of the original Firefox) allow extension through webstarted Java add-ons and plugins. (Enhancement of Firefox could be outsourced to a Java vendor (e.g. Sun or IBM), who would in turn get a revenue share from selling a license for his VM.) The Mozilla Foundation hasn't yet shown any interest to go that way (there is a JavaXPCOM but it doesn't appear to receive attention in the main distribution) so this could be an interesting market niche. Java add-ons and plugins could then be sold in the shop, too. Webstarted add-ons could stay conveniently available once bought for an account, even after being discarded locally. Selling the browser for $0 during the first month could help to establish a user base; alternatively one could hand out a limited number of invites to contributors. (Employing the same psychological effect as artificial scarcity in laptop software: If something is scarce it may seem more valuable).

One could also try to invite the Mozilla Foundation to become an official fundraising partner of the OLPC Foundation and to develop a commercial branch of the browser for this purpose.

Travel management solution

An interesting add-on could, for instance, be a travel management solution with reservation services provided through certified OLPC travel partners, LDAP access for users and travel policies and automatic feedback to Mozilla Sunbird calendars.

Virtualized Sugar

One could also embed a nested-X server (or WiredX?) into the browser and run an OLPC emulator in a Unix jail environment (or Virtualized Sugar) from a browser add-on, with other web clients in the same virtual mesh network. The browser could then webstart OLPC activities from URLs, which is convenient for the casual user.

Lock in cache

A "lock in cache" function could allow to keep applets and other content permanently in cache, which would allow to keep online applications available like Webstart applications.

NASA World Wind

The browser could integrate the Java version of NASA World Wind as a Java extension aimed at a Geo NIC.

Wikifier

A "Wikifier" could allow to download a current index of Wikipedia and to hyperlink all indexed words encountered on a page to their corresponding articles in Wikipedia (or a local copy on a school server)

Wiktionary entries could be shown as load-on-demand bubble help in the browser, extracting only the language section for the proper language of the web page from the Wiktionary entry.

For Browse the wikifier could be a proxy on the school server.

If vocabulary is made available too conveniently can this possibly impede future capacity for remembering vocabulary?

Comment: Backing up the vocabulary learned this way to a server (when possible) would allow to keep the information past the life-time of the laptop and would allow very convenient surveys about the vocabularies learned this way. A user could also opt to make his registered vocabulary visible to an E-mentor.

The Wikifier could add vocabulary that had been looked up to a database of personal vocabulary, which could be used for vocabulary training from different applications. The database could also store the occasion (document, page) where a word had (first) been looked up, which might help to memorize the word based on the context. The browse application could also allow to highlight all previously memorized words on a page, which would allow a reader to verify if a word should be known before looking it up.

The Wikifier could also allow a persistent highlighter feature (like the greyBox template above), which could allow to mark passages of text (with the mouse) persistently and to store annotations (e.g. translations) for the marked text as bubble help.

Comment: Another form of annotation could be the in-page comment which could be linked to the HTML structure of the document by the browse application. In case of changes to the document the comments could appear as obsolete comment icons near the enclosing HTML section header, possibly in a vertical annotation bar next to the scroll bar (as found in Eclipse).

In-page comments could be displacing (taking a place in the document without content below) or floating (hovering above the document in an independent layer); the comment area could offer a toggle widget to switch between displacing and floating. An annotation feature could also allow a teacher to set annotations, possibly with a squiggly line below text and a corresponding mark in an annotation bar. Teacher/tutor annotations could be mirrored from an annotation source on another XO laptop.

ReactOS

Linux and Wine/ReactOS having compatible licenses there is a certain risk that the ReactOS kernel could diffuse into Linux in two or three years. Most people in the Linux community wouldn't like that because it would bring the Windows driver model to Linux and, consequently, (binary) Windows drivers, which would be likely to impede the development of native Linux drivers.

Changing the license of ReactOS to a charity license could prevent that. The Linux community could appreciate that and Microsoft would probably appreciate that, too: A company reselling ReactOS would have the base cost of the fee and would not be able to sell a ReactOS distribution without that. Everybody should be able to appreciate the potential fundraising effect for OLPC. A win-win-win situation, one could say.

One could, for instance, offer the ReactOS Foundation to become an official fundraising partner of the OLPC Foundation.

A possible ReactOS distribution

"Under the agreement, software developers will only pay a one-time fee of 10,000 euros, or $14,300, to gain access to Microsoft’s communications protocols, which specify how to exchange data between Windows and rival products. These protocols are trade secrets, not patents. If competitors want to license Microsoft’s patents, they must pay a per-unit royalty of 0.4 percent of the value of the product sold. Microsoft had originally demanded 5.95 percent of sales as royalties." (New York Times)

One could license from Microsoft (fundraising, not FUD-raising) what isn't finished and lower costs as ReactOS is completed. One could add KDE4 and Sugar as alternative desktop environments (shell replacements in Windows jargon). Compiling KDE4 for Qt/Windows would require a Qt developer license and as an OS vendor one could also declare the Qt library a part of one's OS, which is very plausible and would allow to sell an Eclipse-based SDK (under license from TrollTech), although one would obviously ask KDE e.V. for permission anyway. Licensing interesting commercial components, including new Microsoft features (e.g. DirectX n-1), would give the OS a long-term perspective. An interesting commercial component could be QNX Neutrino (or is that EIT?), which would give the operating system a better POSIX layer and could make the current ReactOS kernel more stable (as a set of restartable drivers and servers on a stable microkernel). One would probably choose ZFS over NTFS.