Purpose: To sponsor a project for the creation, enhancement, and promotion of freely available tools and components for the continuing development and promotion of Linux and other free computer operating systems.
Delivery: Deliverable materials should be distributable under the GNU CopyLeft, with interim releases being managed using the "bazaar" concept described in Eric Raymond's article, The Cathedral and the Bazaar, preferably using some variant of "Anon-CVS" for source code management.
By using a project-oriented mandate rather than having a fixed goal ("to develop the Linux operating system and related tools"), this may allow the goals of the organization to more readily change as public needs change. If the project becomes complete, the purpose of the organization might well go away.
Regular CVS-based releases would help to maintain the accountability of programmers; it will be quite clear whether or not firstname.lastname@example.org is working on code based on the daily or weekly archive updates.
In some cases, existing projects and tools could be improved if some people had financially sponsored time to spend concentrating on them.
As the organization's mandate is to sponsor projects, it makes sense to think of a list of possible candidates. Here's a few examples including things that are fairly common on wish-lists.
Providing the authoritative Linux Web site
Motif (see: LessTif )
An "Office Productivity" suite (see: Office products )
A free Web browser with functionality comparable to Netscape Navigator (see: web browsers).
I2O support (see: I2O Links)
A free COBOL compiler (see: COBOL Overview)
Better File systems (see: Linux File Systems)
Database systems (see: Linux Relational Database Systems)
Database query tools - not unlike an "Access" clone. There exist some DBMS-specific tools; it would be desirable to have one that is database independent.
"Friendly" sysadmin tools (ala WebMin )
An X server for the new Splotch 9000 graphics card
A free accounting system (see: Linux Financial Software)
An ICA protocol server/client (See: Network Computers/ICA)
An reasonably objective system for certifying "Linux Consultants"
A "Raytraced-Penguin" commercial for use in television
A free alternative to Adobe Illustrator
Equally importantly, some of these things involve tasks that are tedious so that people that are working to build something "good enough for me to use" won't find it worthwhile to put in the additional effort to polish the results for general use.
If such projects are formally funded by a "Linux Foundation," this encourages creation of some of the fiddly things that require more work than people can do in spare time.
Some would argue that these represent products that can be sold commercially. This is indeed true. Most of the products on the list are already available for Linux in some commercial form. The fact of commercial support establishes that people are willing to put money into these sorts of applications.
Some would also argue that free software will discourage the creation of more and better commercial software. Free software has not discouraged the development of commercial databases, Web servers, text editors, and many other sorts of programs.
The presence of good and free software raises everyone's expectations.
It presents commercial enterprises with the question: " Why should I pay for your product when I can get blah for free?"
To some " free software extremists," the answer is " If there is a faintly acceptable 'free' product, I will not pay for your product."
To others that feel less strongly, the answer looks more like: "Buy our product because we offer better functionality or make it easier for you to use. " The availability of free software tools makes it easier and cheaper to develop good software, both free and commercial. Commercial enterprises can benefit from this.
We could try to have a Linux Foundation have "departments" involved in various sorts of commercial activities in order to provide funding, thus having "subsidiaries" that are of the various sorts of other organizations previously mentioned. Consulting, Internet Service, selling "Linux PCs," or selling Linux software.
I believe, however, that doing these things would direct attention away from the project activities of a LF.
The simple funding answer: Grants/Donations
A Linux Foundation should be incorporated in much the same form as similar organizations as the Free Software Foundation and The XFree86 Project, as a tax-exempt non-profit organization that can receive grants on a tax-deductible basis from both companies and individuals. "I believe that free development efforts need to be sponsored by freely given grants of funds, materials, and services."
This can include encouraging other Linux-related enterprises to sponsor free software projects either directly or by providing funding or other resources to organizations like a LF or directly to development projects. For instance, a variety of Linux-related companies (as well as some less-related organizations) have been known to sponsor projects under the GNU Public License. To cite just a few examples:
Red Hat has contributed software that they have written such as RPM, PAM, as well as the whole Red Hat distribution as GPLed products, and has founded RHAD - Red Hat Advanced Development Laboratories to produce further GUIed tools in conjunction with the GNOME Project ;
Willows released sources to "Twin," which functions as a MS-Windows WIN16 emulator, in GPLed form;
Cygnus Support, now a subsidiary of Red Hat Software, has done a lot of work on GCC-related tools, most recently including some sponsorship of EGCS .
SourceForge, run by VA Linux Systems, is a web site that provides web hosting services for a large number of Free Software projects, providing a CVS repository, mailing lists, bug tracking, message fora, and the likes.
Unfortunately, they have been moving towards somewhat more proprietary operations, witness what has been called SourceGrab.
It seems a good idea not to become overly dependent on SourceForge's services, and consider using other alternatives as well, such as:
Derived from old version of SourceForge software
Alexandria - the software that runs SourceForge
Packaging of SourceForge's software in Debian form
Based on these examples, it is quite reasonable to expect companies that profit from Linux to contribute something back to development efforts. Whether that comes in the form of funding or of freely redistributable software is not too critical.
As a not unimportant aside, I would think it preferable for commercial contributors to prefer the form of the GNU Public License (or the LGPL , for libraries) to that of the BSD style of licensing. The GPL requires that any further contributions to code also be GPLed, which means that the contributing organization can expect to themselves benefit from other peoples' contributions. In contrast, Berkeley-style licenses allow competitors to take the code, improve on it, and keep the improvements private.
Moving beyond commercial enterprises, government agencies would be perhaps the most interesting "targets" of Linux sponsorship, as various tools ( COBOL compiler, office productivity software) are of a nature that it might make sense for a governmental organization to provide some funding. Here are a few ideas:
A group of 3-4 municipalities might grant a Linux Foundation funding to develop a "free" municipal tax accounting system. The next year, other municipalities might sponsor development of additional "application modules." The next year, 200 municipalities might move to the "Linux-Tax" system, and sponsor some additional modules.
1997 would have been a nice time for such a package to be ready, in view of upcoming Year 2000 problems.
Lyno Sullivan wrote a (now inaccessible) proposal of somewhat this sort, suggesting that (apparently his locality) Minnesota should require that "all software, created with public money, and government information must be copylefted."
I expect that there is likely to be enough political opposition (Big 5 consulting firms would, no doubt, pay lobbyists to oppose it...) that the proposal is unlikely to actually pass into law.
A government department might spend $300K helping develop a "GNU COBOL" compiler rather than spending the money on commercial compilers. The next year, 10 government departments start migrating code to "GNU COBOL" to run it on license-cost-free Linux servers.
Note that the development of GNU Ada was sponsored by the US government in much this fashion. And that development of Perl was similarly sponsored by NASA/JPL. Unix hardware vendors such as HP, NeXT and Digital (and almost certainly others) have contributed equipment, monies, hardware specifications, and even some expertise towards GCC development for their platforms. Precedents exist.
A US Defense Department contract might result in creation of a SGML DTD Design Editor and an associated document editor for managing SGML documents. Integrate this together with a GPLed document database system, perhaps with some assistance at "beefing up" MMediator and the plot thickens.
Encourage a British school board to sponsor the creation of Linux-based educational software and software tools. Schools with limited funding might be early beneficiaries of "Network Computers."
A public hospital might sponsor development of a secure hospital document management system using such tools as SGML, text databases, securing data against intruders/tampering using PGP (Pretty Good Privacy).
Would it not be valuable to also have a small-scale medical practice data repository that is relatively secure, and which allows auditable transfers of data to/from the hospital systems?
These are all pretty big ideas. Almost surely not all of them will happen. But none of them are particularly outrageous.
I have heard arguments that people do not want government involved because of "government inefficiency." So long as usage of software that results from such projects is relatively unrestricted, I do not really see a problem with this. If the software is widely reusable, any initial inefficiency quickly fades to irrelevance. If it were to cost $100 Million "too much" to develop GNU COBOL, but this still leads to hundreds of millions of dollars worth of later savings in spending on software licenses, this is still an attractive tradeoff.
It has been pointed out to me that contributions to such projects should be viewed as grants rather than as charitable donations.
Pure charitable donations go out as assistance to people in poverty, with no reasonable expectation of much return beyond gratefulness. (Note that the English word "charity" was, in the early days, synonymous with "love.")
Grants, in contrast, are given to people and organizations with an expectation of valuable results.
The purpose to contributing to free software is definitely not well-characterized as "pure charity." It is appropriate to expect contributions to turn into valuable results.
In cases where someone has substantial amounts of funding to provide, it is reasonable to be even more particular about the desired result, and set up a specific commissioning. Aladdin Software, for instance, has been commissioned to produce a Display Postscript "server" particularly for use with the GNUStep project.
Here are some other funding methods that I feel are unlikely to provide substantial funding. While they may defray some costs, I do not believe that they are feasible ways to substantially fund development efforts. The Free Software Foundation, for instance, has not gotten wealthy from CD-ROM sales. The fact that there are a goodly 20 vendors selling Linux CD-ROM products and publications suggests that there is little opportunity to bring in substantial money by starting up another not-for-profit alternative.
The major alternative to "freely given contributions" is to create a "captive commercial enterprise" to provide funding, and in my experience, that doesn't work very well. Student service organizations are not typically competent to also run businesses; churches should not run bingo halls; governments should not run lotteries. This divides the organizations into pieces that have substantially differing goals, to the detriment of all.
There is, nonetheless, some limited value in having small sideline operations, so long as it is kept clear that they are not intended to do much more than defray the direct costs of providing associated public services.
A Linux Foundation could build a small distribution channel for some combination of those things that it produces. It would be logical to try to recover the costs of running the "Internet presence" via the sales of CDs and documentation.
A Web/FTP site,
Electronic media (CD-ROMS, DVD-ROMS) with Linux software in both source and binary form,
A Linux Foundation should not presume that they will receive substantial funding out of sales of media.
Commercial enterprises such as Red Hat, InfoMagic, LSL, CheapBytes, SSC, and others have shown that they can provide many of the same sorts of products very effectively at reasonable prices, which limits the "profits" that can be extracted from this mechanism. It might make just as much sense for a "Linux Foundation" to resell media from a "discount vendor" like LSL or CheapBytes.
Source Code Brokerage
<email@example.com> Rahul Miller has extended an offer to be a "source code broker" so that dealing
with GNU Public License clauses relating to the offering of source code
does not need to be burdensome to those that develop software.
It would be of some value for a "Linux Foundation" to provide similar services; they would certainly need to offer sources to software internally developed; it would be valuable to the free software community for a foundation to provide brokering services for other developers of free software.
There are occasional "wars" between those that think that the GNU Public License is the ideal way of distrbuting "free" software and those that think that the BSDL is "freer." And I have room only to mention that there are other variants of the GPL such as the Aladdin Ghostscript license and the Artistic License from Perl .
The critical difference between the BSD License and the GNU Public License: "The GPL specifies that all derivative software must also be made freely available in source form. " On the other hand, "The BSD license specifies that people are free to do whatever they want with 'BSD Licensed' code, including reselling derivative works as commercial products without any legal obligation to return the changes to the community at large. "
The GPL demands the permanent freeness of any code released under it. In effect, it makes the assumption that people want to make "free" intellectual property proprietary, and seeks to prevent that. It and its most vocal proponents seek to make a political statement to "change the world."
The BSD license approach, in contrast, makes the assumption that it is worthwhile enough to make some intellectual property "free" that people and organizations will support a useful amount of "free" software. If the code is really good, then the world is free, able, and encouraged to adopt it for all kinds of purposes. Hopefully enough people will feel morally obligated to also contribute.
As an example of advantage that comes from using the GPL , Willows have released their TWIN Windows emulation system under the GPL, which means that if anyone else improves it, and wishes to redistribute the improved system, the changes must also be made available under the GPL. This means that Willows (as well as the community at large) gains benefit of other peoples' improvements to the system. Those changes could remain proprietary with the "BSD" approach.
In contrast, by virtue of the fact that it can be used to derive "proprietary" software, BSD networking code has had a tremendous impact in the commercial world; the fact that companies may take and freely make use of the code has had the result that most TCP/IP network implementations include some components of the BSD "reference implementation" code. The GPL blocks that use of code.
<firstname.lastname@example.org> Chris Mikkelson
described this nicely (I have reworded it slightly to improve the
"The BSD/MIT style licensing is really the only thing that makes
sense for standards. Of all open standards,
almost all of the successful ones have been those with an immediately
available sample or reference implementation, licensed MIT-style. It
can be adopted immediately by both free and proprietary software.
Releasing a would-be standard implementation under the GPL hampers adoption as a component of proprietary
software, and proprietary licensing hampers adoption as a component of
free software. "
The Free Software Foundation has some fairly scathing comments about BSD License Problems, particularly relating to the typical advertising requirements in BSDL Code. They suggest that people that wish to use this sort of license instead refer to it as an XFree86-like license.
There are clearly people that are strong proponents of each approach; most of the discussions unfortunately represent fruitless "flaming" rather than useful dialog.
Both approaches are clearly viable:
On the other hand, far more people appear to be working on the GPLed Linux kernel than on any of the BSD operating system projects.
A Brief Intro to Open-Source Licencing presents a fairly nice overview of some commonly used licenses, their advantages, and disadvantages. It will eventually become an O'Reilly book on the subject by Stig Hackven.
L. Peter Deutsch is noted as the author of Ghostscript, the freely-redistributable Postscript emulator, which is distributable via the Aladdin Public License arrangement, which allows recent copies to be freely redistributed along with other free software, while other use requires paying Aladdin for a license. The software reverts to the GPL after 18 months. L. Peter Deutsch in conversation with Stig Hackven discusses the licensing of Ghostscript, and is a very interesting discussion of where software licensing has come and gone over the last 20 years. Apparently Peter has done well enough with the revenues from the Aladdin license that he will soon be able to retire...
My personal belief is that the world has room for both the GPL and BSDL models. There is value to both; in different environments, each approach has advantages. Having the multiple approaches to intellectual property permits people who want to give different things to the community to indeed do so.
GPL proponents should allow the BSDL licensing model to be free to either succeed or fail at providing useful free software to the world, and vice-versa.
If someone wants to give away different aspects of their intellectual property, that's their problem. If they prefer the GPL, that's ok. If they prefer the BSDL licensing model, that's ok.
The Free Software Foundation recently presented an essay entitled The X Windows Trap which presents their "take" on the events surrounding the decreasing "freeness" of X, particularly with the X11R6.4 release from The Open Group.
There are quite a variety of licenses out there, as described by The Open Source Licensing Page. Licenses used for "free" software include:
At this web site, discussion is ongoing concerning a new "version 3" of the GPL.
RMS has decided to deprecate the LGPL, and thus now terms it the "Lesser General Public License."
AbiSource Public License (AbiPL) - Intended to be compatible with the Mozilla Public License
Note that the latest news is that the AbiPL has been scrapped in favor of the GPL...
I tend to agree with this position; when companies use the GPL alongside some other traditional proprietary license, this seems to be used as a sort of "bludgeon" in order to, on the one hand, claim it's "open source", while, on the other hand, trying to prevent there being any community beyond the company that owns the code, exclusively.
These licenses have, between them, wide variations in the sorts of liberties that they encourage people to take in their use of code.
PUBPAT Represents the Public's Interests Against Wrongly Issued Patents and Unsound Patent Policy
If this was useful, let others know by an Affero rating