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.

Dual-licensing ("DGPL")

A dual license could allow a company to build a commercial variant of an existing open source program. The company would then have to pay a per-user fee or other fee to the OLPC Foundation to be allowed to sell that software without accompanying source code.

Details of the individual licensing models could be set by the software authors or, upon consultation, be delegated to working committees from various foundations (e.g. Linux Foundation, OLPC Foundation, Apache Software Foundation, ReactOS Foundation)

This could also be a motivation for BSD and Apache-licensed projects to switch to DGPL.

Software

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 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 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.

Preventing Winux

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 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 but shouldn't violate the GPL as long as the sources are provided. As an OS vendor one can also declare the Qt library a part of one's OS, which is very plausible and allows to sell an Eclipse-based SDK (under license from TrollTech). 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.