This paper was first published in the "Proceedings of the Thirteenth SSI/Princeton Conference on Space Manufacturing May 7-9, 2001", described at: http://www.ssi.org/13-2001.html
A REVIEW OF LICENSING AND COLLABORATIVE DEVELOPMENT
WITH SPECIAL ATTENTION TO THE DESIGN OF
SELF-REPLICATING SPACE HABITAT SYSTEMS
Paul D. Fernhout and Cynthia F. Kurtz
Kurtz-Fernhout Software
Chappaqua, NY
Abstract
The continued exponential growth of technological capacity since the 1970s has removed most technical limits to group collaborations on space settlement issues. To remove social limits, groups must be explicit about the licensing terms of individual contributions and the collected work, for example putting their contributions in the public domain, or under a license like the BSD license or GPL as a conscious act. The most successful space related collaborations in the future will be ones that make these principles part of their daily operations. One result of such collaborations will be a distributed library of simulations and knowledge including specific detailed designs for self-replicating space habitat systems.
Introduction.
Most people attending this conference want to see space settlement happen. It would be preaching to the converted to speak, for example, about how self-replicating Bernal spheres (J.D. Bernal, 1928, "The World, the Flesh, and the Devil: Three Enemies of the Rational Soul") might house a trillion humans across the solar system by 3000 AD through exponential growth (making nonsense of projections of limits to growth), or how humanity might terraform Mars over an even longer time period, or of how technological and social spin-offs from space studies might benefit humanity here on Earth in the short term (as they already have). We all know these things. What we are all looking for is ways to collaborate with like-minded individuals in the grand endeavor of space settlement.
At this moment nearly every engineer on earth has a powerful and globally networked computer in his or her home. Collaborative volunteer efforts are now possible on an unprecedented scale. Moores's Law predicts continued reductions (see for example the writings of Raymond Kurzweil at http://www.kurzweilai.net/ or Hans Moravec at http://www.frc.ri.cmu.edu/~hpm) in the cost of bandwidth, storage, CPU power, and displays - which will lead to computers a million times faster, bigger or cheaper in the next few decades. Collaboration software such as for sending email, holding real-time video conferences, and viewing design drawings is also reducing in cost; much of it is now effectively free. This means there are now few technical or high-cost barriers to cooperation among engineers, many of whom even now have in their homes (often merely for game playing reasons) computing power and bandwidth beyond anything available to the best equipped engineers in the 1970s.
However, the internet is already littered with abandoned collaborative projects. Productive collaboration requires more than technology; it requires the sustained energy of many positive contributions and interactions, which arise from common goals and mutual trust. The refinement of commonly shared purposes and principles takes time and work. Intellectual property licensing is often overlooked, primarily because collaborators would rather be working toward a common goal than arguing legal issues. An appropriate licensing strategy based on a shared purpose and principles helps to build and maintain trust and promote spontaneous participation. But there are many licensing options, each with compelling arguments for its use, making it difficult for collaborators to choose the best licensing strategy for their needs. In the long term, these issues can make or break a collaborative effort. It is our hope that more spontaneous productive collaboration will occur if the entire space-settlement community is better informed on these issues.
Fostering cooperation
Past efforts in space settlement have focused on the role of government (NASA http://www.nasa.gov) or large commercial entities (GE, Boeing) in developing space settlements. More recent efforts have focused on bootstrapping private or non-profit efforts (SpaceDev, SpaceHab, LunaCorp http://www.lunacorp.com, Artemis) which might lead to the development of space settlements someday. However, the reality is that given today's economic and political mythology, space settlement is not and will not soon be a priority.
How does the individual space enthusiast fit into this picture? Most often, he or she is seen as a lobbying agent for Congress, an individual investor, a dues-paying member of a non-profit society, or even a torch-bearer carrying on the flame to a new generation. These roles are important, but they only indirectly impact technological advances leading to space settlement. By contrast, the fields of astronomy and paleontology have in recent years undergone a revolution in working with talented amateurs. For example, large numbers of comets and asteroids have been detected by amateur astronomers, some of whom have better equipment than some professionals.
We believe that thousands of individuals (such as the people at this conference) are ready and willing to make compromises in their own lives to nurture the space settlement dream at the grassroots level - but in a more direct way than has been attempted thus far. In particular, individuals could collaborate on the iterative development of detailed space habitat designs and simulations using nothing more than the computers they already have at home for playing games. While excellent progress has been made on the general engineering design of space habitats (in terms of basic physics and proof-of-concept projects), many of the details remain to be worked out. There have been individual attempts in some of these areas (e.g., the SSI Matrix effort), but a persistent collaborative community has not yet coalesced around constructing a comprehensive and non-proprietary library of such details.
What sort of things could such a far-flung collaboration produce? We envision a collaboratively developed and universally available library http://www.kurtz-fernhout.com/oscomak of detailed CAD files, simulations and scenarios that describe the required manufacturing processes, products and machines, ecological web management practices, and means for bootstrapping space settlements from asteroidal, lunar, or Martian ore. For example, such a library could form the knowledge component of a self-replicating space habitat system capable of duplicating itself from asteroidal ores and sunlight like a huge algae cell in space, such as was envisioned by J.D. Bernal in the 1920s.
One reason more cooperation on such a library hasn't happened to date is that the various societies people support have (seemingly) very different objectives. For example, numerous space-settlement related efforts (such as SSI, the Mars Society http://www.marssociety.org, the Living Universe Foundation http://www.luf.org, PERMANENT http://www.permanent.com, and the Artemis Project http://www.asi.org) each have a different approach towards space settlement. Since so many bright people want similar things, the question arises of how we can work together to help all of these projects develop. Rather than argue whether L5 or Mars or the asteroids or the Moon or the rings of Saturn should be humankind's first space settlement, we could be asking what is common between those efforts so that that groundwork can be shared.
The open source example
Consider a few examples of direct collaborative creation from the "open source” and "free software" communities: Linux, Apache, Sendmail, GCC, Python, Squeak, Tek, Emacs, Forth, DrScheme, Slashdot http://www.slashdot.org, Everything2 http://www.everything2.org, DMOZ http://dmoz.org (the Open Directory Project), SETI-at-home, the Educational Object Economy http://www.eoe.org, and SourceForge http://sourceforge.net. All of these are examples of user communities that have spontaneously grown around some sort of technical artifact such as an application, web site, or programming language. These projects together include hundreds of thousands of participants. SourceForge alone has over 153,000 registered developers and 19,000 open source projects.
Think of what the space settlement community could accomplish in terms of detailed designs with just a few hundred intensely cooperating people over the course of a decade, let alone what 153,000 could accomplish in that same time. But what if we could get a comparable group of people across the Earth involved in a project like space settlement in their spare time? With a viable set of designs, the space settlement dream would be ready to go if somehow a billion dollars were to make itself available, say to actually build and launch an automated seed to construct a space habitat out of a near-earth asteroid (complete with a space shuttle fleet to land on Earth and pick up residents, similar to an idea arising from the 1980s NASA summer study).
But frankly, a billion dollars is not enough to design such a thing. It might take a trillion dollars of design and simulation work to get to the point where there would be a high likelihood that only a billion dollars would be enough to make something like that physically happen. At typical engineer costs of $300K per person year including overhead, we are talking about needing roughly 300,000 person-years of design effort to get to the point where only a billion dollars stands in the way of the first self-replicating space settlement. Or, ten years of 300,000 people around the world working on the project in four hours of their spare time each week. That's only double the number of developers registered on SourceForge, and many of them put a lot more than four hours a week into their projects.
Probably the average person who might participate in such an endeavor already spends four hours a week watching Star Trek and Babylon 5. If we could make the project as captivating as those television shows, we might have a functioning space settlement by the beginning of the next decade. Commercial efforts like Ultima Online already have tens of thousands of users who pay on a monthly basis to participate in virtual worlds. This is not to say that there have been no collaborative efforts in the space settlement community; but it is to say that we feel the potential is much greater than what has been realized thus far.
Participation
There are two levels at which we can look for participation: the individual and the organizational levels.
At the individual level, participants could include retired engineers, practicing engineers, hobbyists, dedicated members of existing space organizations, home schoolers, K-12 students, college students, graduate students, teachers, faculty, independent scholars, open source software developers, non-profit staff members, and government employees. To an extent, this group already cooperates by generating the large volume of messages on the sci.space.* newsgroups. These individuals might have many different reasons for participating, which might include a deep interest in the subject, a desire to learn, a desire to demonstrate technical ability, a desire for sociality, and a desire to give back to the community. On the other hand, specific issues might frustrate individual desires to contribute. These might include limited time, limited interest, limited attention, limited inspiration, limited value returned by the effort, social pressures not to contribute, and restrictive agreements with employers. In the past, cathedral builders would work on cathedrals for generations, handing work down from parent to offspring. In our world today, widespread patience of this magnitude seems hard to imagine.
At the organizational level, participants might include the Space Studies Institute http://www.ssi.org, the Living Universe Foundation, the Artemis project, the Mars Society, and other existing organizations with interest in space settlement issues. The United Nations, the World Bank, IBM, NASA, General Electric, Boeing, Verizon, and various other non-profits and for-profit enterprises might also participate to the extent that a part of the effort aligns with their immediate interests or needs. These organizations will tend to participate for such reasons as good publicity, access to potential employees, an immediate need for a specific piece of technology only the collaboration can support, or a desire to level the playing field to reduce competitors' proprietary strengths (such as is for example one factor behind IBM's support of Linux). On the other hand, specific issues might frustrate organizational desires to contribute. These might include fear of losing members or employees, fear of legal ramifications such as liability, and fear of spending limited resources on projects seemingly outside of their charter and over which they have limited control.
Let us take it as a given that of the people and organizations who might be able to participate, at least a fraction will find the benefits of contributing exceed the costs and that a number of participants will step forth. At that point other issues related to interactions between participants may arise that limit successful collaboration. These include clashes of individual egos, lack of trust, incompatible licenses for various works produced, limited bandwidth for communications, lack of agreement on open standards, lack of tools, lack of agreement on purpose and principles of operation, disagreement over possible financial returns, lack of supporters outside the direct effort, liability issues for contributions, the need for private space for individual achievement, active disruption by vested interests, a culture that promotes individual success over group success, and an outdated model of the "lone genius" working in isolation.
Overcoming or at least minimizing the impact of these interaction issues requires attention to organizational form and intellectual property licensing agreements. Let us now consider three models of increasing complexity of intellectual property (IP) production - the independent scholar, the centralized production group, and the collective association - and their implications for licensing.
Individual IP production
The simplest way new IP is produced is that a person reads a variety of documents, thinks about the ideas remembered from those documents, and then creates some new artifact embodying the derived ideas such as a document. Since copyright only covers ideas in tangible form (such as text), this effort is currently legal. Issues could still arise, such as when a person's memory is accurate enough to create exact copies, or where the individual explicitly plagiarizes, but these are rare. Most of the individual's own internal communications don't produce any artifacts, and those that are produced (like index cards with notes) are obviously owned by the individual.
For direct use of texts and other tangibles, the legal doctrine of "fair use" is involved. Fair use is a complex topic, but as a rough guide, fair use typically involves including only small parts of a larger work as a small part of a new whole. Of course, nothing is ever completely original because all works draw from a stock of words and ideas that have been collaboratively developed by humans over the past thousands of years. To reduce the risk of plagiarism and to facilitate an economy of reference and prestige based on citation, academic scholars formalize the individual IP creation process, for example by placing ideas as they are encountered onto index cards, by footnoting the original source of an idea discussed in a new work, and by adhering to explicit fair use standards.
The world wide web has greatly changed individual IP production, because linking to original source materials reduces the need to directly include portions of the works cited. Generally permission is not required to include a web link (URL) to a document in another document. A link includes the cited material in the new work, but in an indirect way that makes the cited material immediately available while skirting some of the legal issues of direct inclusion. This creates a quantitative change in speed of access to related works, which in turn creates a qualitative difference in the way documents such as emails and web pages are produced and used. Exactly how links may be legally used (based on how the linked work is represented) is a matter of continued legal review. And there is still value in direct inclusion. Many links eventually break; and if the new work requires direct revision of included works (texts, sounds, CAD files, or images), linking is not a sufficient method of inclusion.
Centralized IP production
A more complex way of producing IP is to get a group of people together, typically as employees of a corporation, but possibly also as members of any form of centralized organization. Unlike the case of individuals basically talking to themselves or writing notes to themselves, these individuals will express themselves to others with typically tangible documents (e.g., notes or email). Other individuals will receive these documents and then create new works.
In this model, typically individual employees or members sign agreements assigning most or all rights to the IP they produce to the ownership of the central body. So a large pool of documents can be produced by a large pool of people and persist over time as individuals come and go. Because all the work is owned by one immortal and non-human entity, there is little need to be concerned about the legal status of internal communications or derivations from them, as long as all the contributors sign over their intellectual property to the central body. The central body is able to make decisions about how to apply its intellectual property without needing to consult individual contributors.
Typically such entities construct internal legal boundaries and policies for treating externally-owned intellectual material, typically by avoiding it, or failing that, paying to obtain an explicit license for the entity to include it in its internal operations under specific rules. Even non-profit entities like the Free Software Foundation http://www.fsf.org (FSF) may use this model. For example, all developers of FSF GNU software explicitly grant copyright to the FSF, which as owner can then legally defend the software or ensure it can interoperate under whatever future licensing terms it wishes to issue. To insure integrity, the FSF broadly admonishes its contributors not to plagiarize other works.
Collective IP production
Now consider the case of collaborators who do not all work for the same company and have not all signed an agreement assigning their IP to a single owner. This is the most likely configuration for the thousands of individuals who would like to collaborate on a space settlement design library. To the extent that each individual in such a group acts as an independent scholar (translating copyrighted material into ideas in their head and then back into original materials), the community may proceed on a legal basis without a need for licensing. They may, for example, distribute documents only to peers, who use the documents only by reading them and thinking about them. This is similar to the model that underlies much of scientific publication.
There are obvious limits to this approach when attempting to apply it to the collaborative development of technical artifacts. For example, community participants often want to include parts of other contributors' efforts in their works (say by quoting part of an email in a new email to someone else). Sometimes this is covered by "fair use"; but for significantly large uses it will not be. Collaborators may even want to collaborate so closely and in such a fine-grained way (say by alternately editing the same document) that it may become unclear what part of the contribution is made by either party, or whether a clean distinction should be made at all, such as when a paragraph is partially written multiple times, creating a chain of derived works. As another example, a complex CAD file might be modified on numerous occasions by numerous people.
Of course, many collaborators informally share authorship of works. However, this can create complicated legal tangles of which contributors should be aware. In order for the combined work to be legally redistributed, all authors must agree on how it may be used. In addition, if contributors want others to be able to safely make derived works from the collaborative product, all authors must take pains to make sure the product has a clearly titled legal pedigree. Explicit licenses governing contributions minimize the likelihood of such problems arising. If all contributors do not agree (ideally before collaborating) that the result will be licensed under specific terms, the work product will be a dead end as far as continued improvements by others.
If contributions are structured in a modular way, such that clear boundaries exist, then each module may have its own license. However, on a practical basis, only certain types of contributions may be practically treated as modules, such as complete documents, program files, CAD files, and so on. And if modules have conflicting licenses, or licenses that don't permit derived works, then continued collaboration may be made more difficult. Common agreed-upon licenses within collaborative communities can prevent the need for a chain of licenses to accompany each copyrighted work and its derived works as it progresses through a network of authors.
Note that if all collaborators continually put their new works into the public domain on creation, this problem of needing to worry about licenses does not occur. However, authors usually do not do this for various reasons. Typically they want to protect their creative expression from incorporation into other works in ways they do not approve of or in ways that do not compensate them financially or otherwise.
Authors may distribute new copies or versions of existing works under new licenses. However, on a practical basis, large groups of authors rarely change the license of a finished product because all participating authors would have to agree to the new terms. For this reason it is important to get the license right the first time.
Termites and collective organizational forms
Termites build their nests through “chaordic” http://www.chaordic.org self-organization based on simple rules For more details and an interesting perspective on applying these ideas to management, see Gareth Morgan: http://www.imaginiz.com/provocative/organize/termites.html. Individual termites build short stacks of grains of sand. Eventually two stacks fall against each other to make an arch. The termites near the arch become excited and build on the arch until it becomes a tunnel. Eventually these tunnels link up to build huge nests that may last for decades.
The termite model is worth thinking about in the context of individuals collaborating to build a design for a space settlement. Many projects begin by attempting to build a pre-architected nest in a top-down fashion. What they discover is that none of the termites want to build what has been laid out. A bottom-up termite-like approach might work better to attract collaborators. It is less risky for collaborators to build their own little piles the way they like, and to then offer the results under terms they choose to the rest of the world (which accepts or rejects it as the world sees fit), than it is to build a custom part they have less interest in as part of a grand design which may or may not ever be complete enough to use. The simple rules of termite interaction make it possible for a giant termite nest to arise from the efforts of individuals. Agreements in any collaborative community perform a similar function. Without the right agreements, all you will have is a lot of little piles of sand, not a nest the whole community can use.
What we need are some good rules for any space settlement project so we can be good space settlement termites. Intellectual property licensing issues are the most important rules in creating collaborative works. More than anything, one should do everything possible to avoid creating well intentioned rules that diminish this sort of self-organizing behavior.
Intellectual Property Issues
Intellectual Property (IP) includes things like copyrights, patents, trade secrets, and trademarks. These are legal and social constructions that reflect the dominant societal myths about motivation and cooperation; and they have changed over time. Many ancient cultures did not believe the individual had any right to their creative ideas or expressions. Such ideas were considered to be given by a god or inspired by a muse and were to be used by any and all. In the U.S. Constitution, copyrights and patents were created not because it was thought people had the right to own information, but to “promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries.” Thus copyrights and patents were actually created to increase the store of public domain knowledge. This is as opposed to the generally accepted belief in the U.S.A. of a right to own land or tools. (Trade secrets and trademarks are more similar to "owned" things, since they may in theory be held privately forever.)
Under U.S. laws, as a supposed incentive to engage in a creative endeavor, the owner of intellectual property may decide under what terms it may be licensed by others. That is, the owner may extend some of their exclusive rights to copy or use something to another for some consideration or none at all. The owner may also attempt to impose conditions on subsequent transfers of the intellectual property, or attempt to prevent such transfers to another party entirely. We are used to the concept of being able to buy a book and sell it (as a used book) to someone else. The internet challenges some of these traditions; for example, many e-book licenses don't allow you to resell an e-book.
Under current laws, all created information (even this document) will at some point enter the public domain. It may take 100 years or more in some cases, but it will happen. The long-term constitutional intent of copyright and patent law is to increase the public domain store of knowledge. Unfortunately, however, copyright and patent owners have repeatedly lobbied for extensions of copyrights, the latest success being the Sonny Bono Copyright Term Extension Act of 1998. Some argue that the rise of the internet implies the opposite - that copyrights and patents should be instead shortened to a decade or less in order to promote the kind of cooperation that the internet makes possible.
Various projects like Project Gutenberg http://sailor.gutenberg.org are doing a great job of taking works that have fallen out of copyright and making them accessible on-line. On a practical near-term basis, the only way to provide a large quantity of current technical information in the public domain or under open source licenses would be through a large group effort, either obtaining permission one item at a time (and coordinating those permissions) or creating new material.
Distinguishing code, content, and collection
Any sufficiently complex project will generate at least three different types of copyrighted materials which may be licensable: code, content, and collection. “Code” refers to actual executable programs and source; “content” refers to ideas and concepts crystallized in email, video, transcripts and other documents; and “collection” refers to specific compilations of code and content with perhaps an index or other organization and structure. For example, a development effort related to space habitats might produce both simulations (code) and numerous emails discussing them (content). Further, the effort might create a CD-ROM collection of selected simulations and email discussions related to them, along with an associated index.
These three types of material do not all have to be under the same license. Even for each type, items in it do not necessarily all have to be under the same license. For code, some could be distributed under the GPL license and some under the BSD license. For content, manuals might require attribution under an open content license, email might require inclusion without alteration, and a page of links might be placed in the public domain. For collections, multiple collections might be released, each with a different license - perhaps one restricting redistribution without payment and another allowing redistribution of subsets of the database. Cooperating individuals and organizations should decide what licenses they want to use for code, content, and collection and make a commitment to placing materials under those licenses.
Choosing appropriate licenses
So the first two large questions for any effort to develop IP related to space settlement are: (1) How many different systems embodying collections of code and content will there be, and will all these systems be under the same license? (2) For any given system, will the three areas (code, content, collection) be under different licenses?
In addition to those two large questions, for all licenses to be chosen or written, here are some smaller questions. Will the licenses provide any warranty? Are derived works allowed? How viral will they be, or what parts will be viral? Will they restrict distributions to any class of user? Will they require legal restrictions on distribution or use? Do they require making explicit the originality or IP status of contributions? What will they say about patents embodied or described? Will they require attribution or limit modifications or removal of opinions? Will there be special classes of contributors who have more rights than others? Are there restrictions related to advertising? Who could be sued if something goes wrong? How are creation dates maintained to know when parts go into the public domain? Will there be a provision that suggestions from users can be added to the product? How will these licenses interact with existing licenses? Will the licenses include a termination clause?
There are obvious answers to many of these questions based on the desire to minimize risk to the person or group granting the license. These are typically reflected in most open source licenses, such as the X/MIT license. A large issue, which can be seen to divide open source collaboration into two camps (GPL vs. BSD/MIT/Python, etc.), is whether the license should contain a "viral" provision for "infecting" derived code or content.
Licensing issues can be divisive and one needs to tread carefully. Any sufficiently large project may end up using a variety of material licensed under a variety of terms. Also, under what we call a “termite” model empowering individuals, it is likely that individual contributors will make new material available under a variety of terms. The proper handling of these materials will have to be part of the principles of any group. One value of the GPL license (despite its drawbacks) is both that it is widely known and that it makes the licensing of derived works clear. This lessens the burden of having to negotiate new licenses for every contribution, having to make assumptions about the license status of each minor contribution, or having to educate every contributor about licenses in detail. [Update: Some more details on licensing issues were earlier discussed by one of us on a mailing list post archived here.]
The decision-making process in licensing must be collective, in part to compensate for errors, biases, and omissions. It is not always clear what license is best in terms of getting industry participation, attracting independent developers, managing content fairly, maximizing intellectual capital appreciation, and avoiding legal liability. That is one reason there are the many different licenses in existence (and yet everyone begs "please don't make yet another license for review"). A first step in deciding on a license is to decide what the creators of the license (and other participants) want to accomplish (the goals of the project). Once that is done, one can choose or create licenses most likely to accomplish those goals. When creating any license, one is to an extent crafting a "constitution" for a collaborative effort. Of course, the organizations that work with such systems may themselves have their own constitutions, and one needs to be aware of the extent to which those constitutions will complement or clash.
The simplest possible agreement on licensing is to place the entire project into the public domain. A project agreement can simply be a statement that "everything contributed is placed in the public domain". Discussing why the group should or should not do this will lead to an understanding of how people working on the project feel about issues like IP, ownership, trust, recognition, control, hope, fears, lawyers, history, collaboration, and so on.
Communication tools and data standards
Collaboration is best supported by extensible tools which store data in well-understood and open data formats. One example of an open source extensible tool is Squeak http://www.squeak.org Smalltalk. It runs on a wide variety of operating systems including Windows, Macintosh, and Linux. It has an active user community interested in a wide variety of topics including educational simulation. It supports email, web browsing and real-time collaboration.
Any long term collaboration will produce many works which will be shared and refined over a long period of time, during which tools may change. It is imperative that the work produced be independent of any specific proprietary format (such as Microsoft Word Doc file format). Some non-proprietary formats include XML, SGML, HTML, and ASCII. Additionally, specific protocols used by open source tools, even if they are only used by one tool, can be considered open formats, since the tool could conceivably be modified to output in different formats, and since one can understand the file format because the source of the tool that produced it is available. The key thing is that the data is in a well understood format that can be migrated to better formats used by better tools as they become available.
In the future, people may develop tools that better track what specific piece of intellectual property is under what license, making more feasible the management of large projects with numerous licenses. Such tools might give one the option to, say, eliminate from a distributed collection all material with specific objectionable licenses.
What can be learned from open source communities
What follows is a cursory overview of open source development efforts. There are both successes and cautionary tales to consider, but it is important to remember that large numbers of people are already collaborating and have been doing so for years. Collaboratively developed language communities include Lisp, Scheme, Forth, GCC, Python (JPython, CPython, Stackless), and Squeak. Collaboratively developed operating systems include IBM VM software (before the mid 1980s Object-Code-Only policy) and recently Linux and Sun's JINI. Collaboratively developed applications include Apache, Mozilla, Tek, Emacs, Sendmail, and the BI Open Hyperdocument System. Collaboratively developed web sites include Everything2, DMOZ (the Open Directory Project with 2,565,276 sites, 35,850 editors, and 360,320 categories), Slashdot, the Educational Object Economy, and SourceForge (with over 19,000 projects and 153,000 registered developers). The community centered around the Free Software Foundation's GPL license has produced many of the applications that run on Linux. Individuals belonging to standards committees like the IEEE Standards Committee or World Wide Web Consortium (W3C) have cooperated to create standards. Even the journal The Economist has noticed the open source movement and its effect on the economy with an article in its April12th, 2001 issue http://www.economist.com/surveys/displayStory.cfm?story_id=568269.
This sort of effort need not be constrained to just programming or standards. There are also fairly open collaborative communities centered around non-programming issues. For example, Village Earth http://www.villageearth.org produces the Appropriate Technology CD-ROM, which grew from an effort to collect 10,000 documents on appropriate technology and make them available on Microfiche (indexed by the Appropriate Technology Sourcebook). The non-profit Isles Inc. http://www.isles.org, which was originally conceived to create habitable islands in the Caribbean, has been for decades actively engaged in rehabilitating parts of Trenton, New Jersey through community gardens and related efforts. The Foresight Institute http://www.foresight.org has helped coordinate work on nanotechology, including issues relating to its safe use. The Humanities Library http://www.humaninfo.org is creating a vast library of information for use in developing nations, primarily from UN documents put under the GPL license or other licenses allowing free redistribution. [Update: See also the Buckminster Fuller Institute's Comprehensive Design initiative.]
Some well-documented successes have been the Free Software Foundation's GNU tools and General Public License (GPL), Linux http://www.linux.org (which included GNU tools), and Apache http://www.apache.org, the most popular web server. Since so much coverage exists on these projects, we will not review these in detail. But in general, each has a clear license that covers works created in a modular fashion by a large number of people who share somewhat common purposes. By contrast, consider IP issues that have affected three smaller open source projects in which we have participated.
The Squeak Smalltalk project has encountered issues because of a non-modular and monolithic distribution and because of a lack of clarity as to what license various contributions are under (in part because of this monolithic distribution). This makes Squeak more risky for large scale ventures to use. It's not that these risks can't be managed with effort; it is just that they create another hurdle for participation in the community.
Another collaborative project, an effort to create an “Open Hyperdocument System” led by the Bootstrap Institute http://www.bootstrap.org (BI), has suffered from an initial centralized IP license strategy. Stanford University and BI wanted to ensure that they could rebroadcast a video course related to the effort, so they required each participant in the effort to agree to a blanket “permission to use” on any contribution for any purpose. This blanket permission included a provision making the contributor liable for all costs if someone sued either Stanford or the BI because of the contribution made by that participant. The permission statement included no language that allowed the contributor to withdraw the contribution, for example if it was found to unintentionally infringe a software patent. While this seemed like a sensible legal strategy for Stanford, it also created an unequitable ownership model and a large liability for contributors. This has reduced the likelihood people would want to contribute significant works to that project.
As a third example, the Python http://www.python.org programming community went through a period where the Python license was suddenly re-interpreted to cover only the work done by the project's lead developer (Guido van Rossum) prior to his employment at a particular non-profit (CNRI). At about the same time Guido van Rossum decided to move to another organization, CNRI changed the Python licensing terms, claiming that new contributions to Python were never formally licensed. This caused an uproar in the community of contributors. This is still an ongoing problem because the new license is not considered to be compatible with the GPL. [Update: This Python GPL incompatability issue was resolved shortly after this was originally written.]
All of these projects (Squeak, Bootstrap, and Python) have quite interesting and vibrant communities, are worthy of support, and are moving to resolve these issues. We have participated in all of them and gained much from that participation. We bring up the issues we have experienced in participating in them only as cautionary examples of what can go wrong if licensing issues are not addressed well at the start of an effort, with continual follow-through during the life of the effort.
Current space-related collaborations
There are several space-settlement related collaborations hosted by organizations such as SSI, the Artemis Society, LunaCorp, the Living Universe Foundation (LUF), the Mars Society, PERMANENT, and NASA. There are also many discussions about space settlement on internet newsgroups. We can divide these collaborations into two large categories: general and advocacy-related collaboration.
The first category involves supporting various collaborations related to space settlement without one specific vision. This includes NASA and the activity on internet newsgroups. NASA and space newsgroups on the surface seem like broad collaborations, but they demonstrate what can happen without proper attention to licensing for continued collaboration.
At NASA, almost anything developed by NASA employees is effectively put into the public domain (since they are government employees). However, the bulk of NASA development is done by NASA contractors, and current rules allow such contractors to retain the IP rights to anything they produce for NASA. Typically the only requirement is that the government has a royalty-free license to use the work for government endeavors. The net effect is that most space related government supported works such as the design of the NASA space shuttle are not put into the public domain, but instead are effectively owned piecemeal by the contractors. This means that if a thousand collaborators wanted to get together and improve the space shuttle design, they could not do so without acquiring licenses from every contractor involved.
In internet newsgroups, there is a presumption that each individual message may be archived, copied, or quoted. However, in the absence of explicit licenses for each and every post, anyone who uses such posts to make significant derived works risks moving beyond “fair use”. The fair use boundary is fuzzy, and this lack of precision prevents the use of the newsgroup model for collaborative development of large works.
The second category of collaboration involves promoting a specific vision of space settlement, with attendant detailed scenarios. Variations within the second category include the location of interest (e.g. Mars, the Moon, the Asteroids, or the rings of Saturn) and the bootstrap process that will make the settlement viable (e.g. selling power, materials, microgravity, entertainment, mementos, tourism, or even effectively condos). In order to fund their continued operations, these organizations typically take donations and/or sell goods, services, or intellectual property related to their mission. The organizations include non-profits (e.g. SSI, the Mars Society, LUF), for-profits (SpaceDev, SpaceHab, LunaCorp), primarily individual efforts (PERMANENT), and mixes (the Artemis Society and spinoffs). Most of these groups effectively are centralized producers of intellectual property.
What IP issues do these space-settlement related collaborations face? Essentially, each organization produces intellectual property with a plan to sell it to maintain a revenue stream to support continued operations. Whether that IP is in the form of newsletters, conference proceedings, broadcasts from the international space station, lunar theme-park designs, or CD-ROMs with images and software makes little difference. In order to sustain their missions, these organization directly or indirectly create high barriers to the use of their intellectual property for other derived works. The fact that they might charge for a copy of a CD-ROM is not the problem; the problem is that someone cannot take these images and reorganize them in new ways in a derived work without explicitly obtaining permission. But on the other hand, there is no way the creating organization can give blanket permission for derived works without reducing its own revenue stream. The internet makes possible far-flung collaborations on space settlement, but the approach of selling IP creates a basic conflict between an organization's larger mission (to promote space settlement) and the details of how it realizes that mission. How can this conflict be resolved?
There are no easy answers to the question of who should fund space settlement organizations. In practice, support comes from multiple sources such as government grants, foundation grants, individual donations, and sales of intellectual property. However, it is in the decision to sell IP (implying the restriction of its distribution and the ability of others to create derived works) that perhaps most space settlement organizations take a wrong turn as far as promoting their larger mission. Participating in the kinds of “open source” collaborations the internet makes possible requires that organizations forgo erecting high barriers to IP use and adopt “open source” licenses for some or all of their works. An organization might be rightfully concerned that it will have fewer members if all of its newsletters and conference proceedings are online (with some permission to create derived works). On the other hand, broader distribution sometimes engenders broader support. And if the freely available intellectual property is of high quality, it may become the definitive reference platform from which other efforts are built. Proprietary intellectual property that doesn't fit into the larger ongoing collaboration may be passed by or reinvented.
The most collaborative project thus far in terms of distributed IP production using the internet is arguably the Living Universe Foundation (derived from Marshall Savage's The Millennial Project). LUF maintains a collaboratively developed web site (called a WIKI) where all users can edit pages from their web browser. LUF's project origination policy is fairly decentralized. This is the organization that most closely approximates an idea of fine-grained collaborative development towards specific space settlement goals.
However, even the LUF could potentially increase the degree of collaboration through more attention to intellectual property issues. For example, the LUF web site puts the user on notice that all material is copyrighted by the foundation or the authors. The terms of service (from the hosting provider) give no explicit rights to use any of the web site content in any way. This parallels to an extent the situation of an internet newsgroup. One of the LUF projects is to make a related simulation, and the licensing for that project is under discussion. We would suggest that LUF needs to grapple with these issues further. The fact that they are discussing open source licensing options for their simulation is very encouraging.
One issue with LUF is that many of the ideas and initial imagery on the web site are drawn from the book The Millennial Project, which is itself a copyrighted work. While that author has given LUF permission to use some parts of that work, it is not clear how far that permission extends to further derivative works. This is another example of how intellectual property issues can quickly bog down collaboration. The point of this is not to denigrate LUF, which is trying to accomplish great things and has a committed number of volunteers who put much effort into the project. The point is to say that even the energy of committed volunteers is not enough until these intellectual property issues are addressed. Otherwise, LUF risks encountering the same issues that have impeded the progress of many other collaborative projects.
It is important to realize that there are “invisible” collaborators in any project. Invisible collaborators look at a project and discard it because of some flaw they see in its approach or its agreements. We believe that proper up-front attention to intellectual property licensing issues and the mutual trust they support may help turn some “invisible” collaborators into real collaborators.
Some rough-and-ready rules
Based on our experiences with the above organizations and others, these are six IP-related needs individuals and organizations must address to promote collaboration:
Modularity distinguishes clear boundaries between contributions and allows them to fall under independent licenses. Modularity may not always be possible with finely linked systems (such as email threads or interwoven objects). To the extent that modularity is possible and promoted, problematical contributions, such as ones without clear licenses or ones that infringe other intellectual property, can be cleanly removed and/or replaced.
SourceForge provides free web hosting for over 19,000 open source projects. An indirect benefit of SourceForge has been to force all 19,000 of those projects to be explicit about the terms of their license in order to gain the benefits of SourceForge. Not all projects on SourceForge are software related, so it could conceivably serve as a resource for efforts to collaboratively design space settlements as long as they are willing to share their results under a specific open source license.
Conclusion
This paper outlines many of the factors that must be taken into account in collaborating on the design of space settlement. Hopefully this information will help inspire individuals to take their own steps to establishing productive collaborations with others who have similar goals. We are not lawyers; these are our own hard won views on these issues, not any sort of legal advice. This document in not intended to be a definitive source of information about intellectual property law. Rather, it is intended to spark discussion in the large space settlement community, which will hopefully involve qualified intellectual property lawyers who can address these issues with legal precision.
References (HTML links now embedded in the text above)