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. Retailers 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. The Linux Foundation or the OLPC Foundation would have to operate a certificate authority for the purpose. The CA could also sell web server certificates. (See also: Geo NIC)
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).
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.
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.
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.
The browser could integrate the Java version of NASA World Wind as a Java extension aimed at a Geo NIC.
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.
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.
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 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, would give the OS a long-term perspective. An interesting commercial component could be QNX Neutrino, 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.