Foresight Archives |
|
|||
|
|
BSD, X11, MIT, Python |
MPL, LGPL, IBM, Apple |
|
|
1. can be re-licensed by anyone on any terms |
|
|
|
|
2. can distribute derived works without disclosing modifications |
|
|
|
|
3. can incorporate in a combined work with closed files or modules |
|
|
|
|
Multiple-licensing and hybrid strategies. Programs under the X, MIT, BSD and Python* licenses can be incorporated into works issued under other licenses such as the LGPL and GPL with no problems. Other open source licenses such as the MPL and IBM licenses include restrictions which make them incompatible with the GPL. Issuing under multiple licenses is however feasible, as in the Mitre Public License for their Collaborative Virtual Workspace (Mitre 1999), which allows use under either the GPL or MPL. Netscape has announced its intention to dual-license the Mozilla browser, permitting use under both the GPL and MPL licenses, and possibly also under the LGPL. Hybrid licensing models (Raymond 1999:168, Hecker 2000) are also possible, for example requiring royalties under a commercial license during an initial period before later release as open source. Examples of hybrid strategies planned in advance seem uncommon so far, but shifting to open source after initial release under a closed commercial license results in a de facto hybrid strategy.
Open source licensing for patents. Open source software may include licensing of rights to royalty-free use of relevant software patents. Controversy about the legitimacy of software patents has been accompanied by practical approaches to keep software patents from interfering with sharing of software. The Gnu General Public License (Free Software Foundation 2000) requires allowing use of patents as part of unlimited royalty free redistribution (except for possible geographic restrictions): "we have made it clear that any patent must be licensed for everyone's free use or not licensed at all." The Mozilla Public License (Netscape 2000) seeks to restrict the patent license to use as part of the original or modified code, disallowing any separate use. Both the MPL, IBM's Jikes public license (IBM 1999) and Apple's Public Source License (Apple 2001) include stipulations that anyone who makes legal challenges to the relevant patent rights of the originator or contributors forfeits their access under the license.
Open Hardware Licenses. Various groups are working to develop "open" computer hardware including motherboards and other equipment, as well as associated interfaces, drivers, designs and tools. One of the leading figures in formulating the Open Source Definition, Bruce Perens, started an Open Hardware (1999) initiative aimed at printers and other hardware needing software drivers. A variety of licenses are being used or developed in the open hardware projects.* Reviewing several of these shows a pattern of requiring disclosure of modifications. The licenses show flexibility about the extent of use with non-GPL software and proprietary equipment. The issue of combinations between open and closed software led to the creation of the LGPL. Similar combinations seem inevitable for a hardware projects, given the current predominance of proprietary hardware, though several of these projects aspire to change the situation in the longer run. Observation of these hardware efforts suggests that, for nanotechnology related initiatives, purist insistence as done in the GPL on use only with other software and hardware complying with a highly restrictive license is unlikely to be workable for hardware. However if the views of those taking part resembled participants in the open computer hardware initiatives, then they might insist on licenses which require disclosure of modifications, rather than the less restrictive approach of the BSD-type licenses.
Patent pools. The Open Patent project (Shewmaker 2000) seeks to develop a general license which could be used for software patents. The current goal for the Open Patent project seems focused on supporting Open Source software and resolving problems resulting from software patents. Participants would join patent pools created by cross-licensing. These would be designed to create leverage by offering access to successively larger pools of patents. The key incentive for participants would lie in access to a pool of patents, avoiding costs of negotiating access and paying royalties. Like the arguments for open source above, this draws on the conceptual shift to emphasize a company's role as a user of intellectual property, emphasizing the interest it has in benefiting from easier access. The current draft proposals for the Open Patent are relatively complex and ambitious, with several different pools intended to induce sharing of all types of intellectual property held by a company, not only the specific items to which rights would be granted in a particular piece of software. The core concept of developing an attractive patent pool would seem to have substantial merit for opening access to software and hardware patents, even if it started from a narrower MPL or LGPL-type license. As with requirements for disclosing modifications in software, creation of a broader patent pools might be considered a sufficiently attractive incentive to merit special attention in designing new or modified open source licenses for MNT.
Publication and antipatents. Establishing patents is a costly and uncertain process, much more difficult than establishing copyright. Publishing new knowledge into the public domain avoids the costs of establishing patent rights. Licensing mechanisms for sharing intellectual property would be most relevant for those cases where patent rights had already been established, even if only for defensive use or as assets to aid in negotiating cross-licensing agreements. For those who do not seek patent rights, defensively publishing a potentially patentable invention puts the idea into the public domain, and so, in theory, should make it unpatentable. IBM issued Technical Data Bulletins for ideas which it did not seek to patent, but wanted to be sure no one else could patent (P. Wilson 2000). Rebecca Hargrave and Carl Malamud (2000) argue in their essay, Transparent Patents, for improving availability of "prior art" and review of patent applications. They also recommend arrangements for publishing "antipatents" which disclose enough information to prevent subsequent patenting. IP.com offers services for defensive disclosure of information into the public domain. Its website presents a sophisticated discussion of strategic business advantages of putting information into the public domain.
Licenses for MNT. A license suitable for use in MNT would need to permit combination with proprietary software and hardware. The LGPL is somewhat more specific than the MPL or other restrictive licenses about the requirements for incorporation in combined works. However modular design and interaction, for example using application programming interfaces (APIs), is likely to be part of the architecture of software and hardware in nanotechnology, so the requirements in the LGPL should not create a significant obstacle. Further refinements regarding patents and patent pools might be developed. For cases where patents are obtained, for whatever reason, release under an unrestrictive BSD-type license is an option worth considering for those who hold full rights to their software and are not concerned to restrict reuse. It minimizes restrictions, confusion or hassle for those who may wish to reuse the software under the MPL, LGPL, GPL or other stricter license. For those who want to insist that modifications are shared, or who are building on software which already incorporates such disclosure requirements, then the LGPL seems to offer an appropriate and useful license for promoting open source efforts in nanotechnology. The main drawback of the LGPL is that its use is explicitly discouraged ("deprecated") by the the Free Software Foundation, based on their objective of establishing a separate body of "Free Software." This raises some questions about future support for the LGPL and how conflicts regarding the interpretation of the license might be handled.
Hardware patent licensing. The key role of physical equipment in nanotechnology means that patents are likely to play an important role, so open sourcing of nanotechnology would need to include arrangements for use of patents. This could be on a fully royalty-free basis, or might be part of patent pools or other arrangements to prevent anti-commons problems and promote accessible intellectual property. In the longer run, licenses need to be developed, or borrowed from other sources, which enable suitable release of patent rights not just for software but for physical devices and processes. One of the key objectives behind the Open Source Initiative was to clarify how public licenses could be compatible with and useful for businesses, and similar principles would apply to open source development in MNT.
Business models. In his essay The Magic Cauldron, Eric Raymond (1999) identifies several business models through which companies can profit from open source software by:
Applying the models. Most of these business models seem directly relevant to nanotechnology, showing how open source could be part of profitable business strategies. Companies could rely on a core competence in applying open source tools to specific applications. Nanotechnology will need specialized equipment and materials. Manuals, textbooks, training courses and other accessories are likely to be increasingly profitable as interest in the technology rises, offering sources of revenue for companies and experts with skills in nanotechnology. Availability of equipment capable of building nanodevices would create markets for specialized designs. All these models could encourage businesses to help finance open source development and be relevant for startup or existing businesses interested in nanotechnology.
Mixed strategies. The feasibility of open source business models does not mean that all companies could or should pursue completely open source strategies. There may well be many cases where companies would want to hold onto their "crown jewels," intellectual property which enables them to gain a major competitive advantage, or extract royalties from commercial licensing. Use of open source may be selective. The key point is that a business model relying only on proprietary intellectual property is not the only choice, and may not be the best choice. Open source alternatives deserve consideration, especially where open source helps a company to improve its core competence and better cope with change. Sometimes pursuit of exclusive intellectual property rights may be counterproductive, distract from focus on more important objectives or miss profitable opportunities that leverage the advantages of open source.
Producer alliances. Potentially the most significant opportunities for open source approaches come from the role of open source software as an input and the role it could play in ensuring access to intellectual property and preventing hostile monopolies. This draws on the key insight that most software is written for use, not sale. Companies which want to use nanotechnology to enhance their business could have strong incentives to support a coalition to develop open source nanotechnology. Rather than "betting the company" on being the first to commercialize some proprietary form of nanotechnology, companies could reduce costs, reduce risk and enhance their survival prospects by supporting joint open source efforts. This might be a very attractive strategy for large existing companies. A nanotech company willing to commit to such a strategy might be able to attract investment for itself or for efforts funded through a consortium. Such arrangements already exist in the information technology industry, which is already driving substantial investment into nanoscale engineering. A narrow consortium might develop primarily for members' use, offering access as an incentive to investors. A wider consortium backed by major players might choose to attract broader support, enhance legitimacy and avoid potential antitrust complications by using fully open source approaches.
Current industry structure. Industrial efforts for molecular nanotechnology are only in the earliest phases of gestation and the only certainty is that surprises will occur. Examining companies listed on two nanotechnology websites provides one way to take a brief look at the current structure of nanotechnology-related industry. As part of preparing this paper, thirty-four companies were identified for which information was available online and which had nanotechnology related activities (see Appendix A for the list and note on sources). Four companies have strategies closely related to development of MNT assemblers. Thirteen other companies mainly provide equipment, consulting or contract research and development for nanoscale analysis and fabrication. Seventeen companies produce nanotubes, powders, ceramics and other nanoscale materials. Most of the companies provide materials, equipment or contract R&D, all of which could potentially be compatible with either closed or open source intellectual property. Only a few companies (notably CALMEC) have strategies explicitly focused on creating intellectual property and then obtaining revenue from licensing, though many others mention possible licensing or joint ventures. Many of the companies have benefited from government support, particularly through the U.S. National Science Foundation's Small Business Innovation Research (SBIR) program. This suggests that if U.S. government policies continue to favor proprietary intellectual property rather than public domain or open source, then these policies might significantly influence industry structure. None of the identified companies yet has a business model explicitly emphasizing open source strategies.
Research business. While commercial development will become increasingly important over time, current activities are better characterized as nanoscience. Most of the relevant research and development is being done by university-based groups, much of it supported by public funding. Scientific values of sharing and publication encourage making new knowledge widely available. Pragmatic considerations may guide researchers to use open or closed source software depending on which seems most useful. However, aspirations of researchers and their universities to profit from intellectual property rights encourage closed approaches. Open source Unix programs have their roots in the Berkeley Unix operating system software, publicly funded and issued under an open source license at a time when US government policies emphasized making the results of publicly-funded research freely available to the public. Policies regarding intellectual property rights from government-funded research now strongly favor commercialization of intellectual property. Government laboratories are also under pressure to work with private corporations and use intellectual property rights as part of commercializing discoveries.
Industrial research. Notable exceptions to the primary role of universities in nanoscience are IBM, especially its Zurich lab, and Lucent's Bell Labs. Both organizations are prolific patenters, and are taking leading roles in some aspects of nanoscale science. However both currently seem to fund nanoscience as part of basic research, rather than out of immediate commercial goals. They both also have business models which are not primarily reliant on rents from monopoly intellectual property rights. Instead they emphasize providing integrated systems of hardware, software and services, with core competences that center on large scale implementation of advanced technologies. IBM's increasing support for Linux confirms the compatibility between such businesses and open source development.
Access for R&D. Open source licensing strategies might contribute to research and development which better facilitates scientific progress, and encourages commercial development to be done in ways which contribute to continued scientific advance. At present there is some tendency and tolerance for researchers to use patented techniques without permission, as part of research. However, as commercial development comes closer this risks problems if rights to the necessary patents cannot be obtained. If a critical mass of open source intellectual property relevant to molecular nanotechnology were developed, equivalent to the free versions of Unix, then this would offer security that applications could be smoothly implemented, rather than being dependent on the preferences and business tactics of a monopoly rights holder. In cases where universities and businesses conclude that their immediate and continuing needs for access to intellectual property outweigh speculative gains from royalties on intellectual property, then open source strategies would be the logical choice. To say the same thing in less abstract terms, such willingness to choose open source is what happens already in decisions to buy Linux workstations or to use free software for molecular modeling.
Business opportunities. To the extent that any conclusions can be drawn at this early stage, it appears that current industry structure shows the potential for open source approaches, although few companies appear to show an strong focus on open source approaches so far.* Consortia of industries interested in ensuring access to nanotechnology might find open sourcing a desirable strategy, especially if they represent a broad spectrum of interests or want to work in ways that do not elicit antitrust concerns and that help prevent the growth of exclusive intellectual property monopolies.
Molecular modeling is a key tool for nanotechnology. Drexler (1986) noted the potential for substantial design work to be done even before assemblers become available. Some work has been done along these lines, much of it presented in earlier Molecular Nanotechnology Conferences. The architectures within which various programs are combined could have a significant impact on the potential for open sourcing nanotechnology. Licensing could play a useful role in facilitating cumulative, cooperative efforts.
Programs. A large number of software programs are relevant to nanotechnology, ranging from detailed quantum mechanics calculations to computer-aided design (CAD) software. Many such programs have been placed in the public domain or released as open source. Given the dominance of academic researchers at the current stage of nanoscience this is unsurprising, but does show the foundations for further open source efforts. The Antas website lists over 200 software items "useful to the computational chemist" divided into 18 categories (Manunza 2000). The Scientific Applications for Linux website lists 357 items under "Chemistry, Biology and Related" software (Kachina Technologies 2000). For 67 items (19%), the list identifies whether the software is commercial, shareware or GPL. Of those so identified, 30 (45%) are commercial software, while 36 (54%) are listed as GPL, constituting 10% of the items in the list. The Linux4Chemistry site lists 259 items, 204 (79%) of which are available free of charge, at least for academic users, 45 (17%) commercial packages, one shareware and ten for which information was not available (Kuznik 2001). Interest is growing in open source approaches to science and scientific software (BNL 1999, Bioinformatics.org 2000, G. Wilson 2000).
MNT Tools. A number of molecular modeling tools have been used by groups specifically involved in efforts to develop MNT. CavityStuffer, a pre-alpha experimental tool for packing predefined spaces with branched polymers, was developed at the Institute for Molecular Manufacturing and released under the GPL (Krummenacker 1996). Zyvex, "the first MNT startup," released DiamondCAD as "an experiment in open software development" (Zyvex 1999). The package does not seem to include any licensing statement, and the web page says Zyvex is "giving away" the program, which seems to mean that it has been put into the public domain. Version 0.3 links to two commercial software packages, SolidWorks and HyperChem. An earlier version of DiamondCAD, version 0.2, which is independent of these is also available. The web page, last updated January 1999, invited modifications to be submitted, but reveals no responses. Zyvex takes a pragmatic approach to mixing open source tools (e.g. the Python programming language) with available commercial software, as indicated by its website, its actions and statements from its CEO.*
The NanoCAD design system is designed for mechanical modeling of molecules, and intended to promote development of molecular nanotechnology (Ware 2000). NanoCAD was originally released under the GPL, with a later Java applet released under a "Berkeley-esque" license, i.e., similar to BSD. The NanoCAD mailing list had 1134 messages between October 18, 1995 to August 15, 2000 from about 45 participants, indicating a significant but not large level of activity.
Among the efforts discussed on the NanoCAD list was OpenChem (2000), conceived as an open source CAD system for "investigating nanotechnology, molecular structures, machines, and phenomena." OpenChem was intended to be Open Source, but licensing does not seem to have been clearly defined. The OpenChem project is no longer active. OpenChem drew on code from NanoCAD and other packages, including RasMol. The DisMol package was also developed from NanoCAD and RasMol (McCluskey 1998). It is labeled as "freeware" and the ReadMe file includes no licensing information.
Rasmol is a public domain package for molecular visualization developed by Roger Sayle. It was originally written as part of an undergraduate university project in 1989 and after further development was made available free of charge on the internet in 1993 (Sayle and Milner White 1995). It was released with copyright notices and a statement that the program was placed into the public domain. RasMol grew to be an extremely popular package, used at over 15,000 sites. MDL Information systems later began selling commercial software which was largely based on the RasMol code (Hodgson 1996), as later did other companies. University researchers produced a number of variations and developed other software based on RasMol, some of which depended on proprietary closed code (Martz 2000), or was only distributed in binary form without source code. In September 2000 an OpenRasMol website was established, intended to unify different open source variants of RasMol (Bernstein 1999, 2000). Version 2.6 was released under a license which allows redistribution and modifications, but requires changes to be disclosed.* For those who hope that modifications will be shared, the case of RasMol offers a cautionary tale of how code released into the public domain could be commercialized and forked into different closed versions, strengthening the arguments for licensing that requires disclosure of modifications.
Early versions of the Fungimol (Freeman 2000) extensible system for atomic-scale design have recently been released under the LGPL. The system is intended to develop into a tool for MNT design work. The program architecture is designed to enable modification and extension using plug-ins. As discussed above, the LGPL permits combining code under the LGPL with other modules, so allowing development of proprietary plug-ins. The Fungimol package includes a detailed licensing notice about the terms of use for code incorporated in the program and reveals careful attention to requirements for proper licensing.
Systems architecture. Ideas about MNT systems architecture seem to be in an early stage of development. For the molecular level, there are still diverse views about how and when it is appropriate to abstract to simpler approaches than detailed quantum calculations. At higher levels, massive parallelism and complexity pose major challenges beyond current software systems architectures. The distribution of computing capacity among different levels is an issue. There is recognition that levels and modularity will be necessary, but so far few proposals analogous to such (once upon a time controversial) software abstractions as high level programming languages, the Unix kernel or the internet transport layers. Almost all experience with computers suggests that such abstractions, even ones which initially appear to have a high cost in terms of narrowly defined efficiency, can make major contributions to the productivity of software development. Even such exceptions as the stack-based Forth language, and inclusion of assembly-language within C programs, "prove the rule" by their relatively minor role and marginalization to specialized uses. The extent to which useful abstractions for modules and levels are proposed and receive some consensus support in systems architectures for MNT could have a major impact on the opportunities for open source development. This need not necessarily take the form of a "cathedral-type" masterplan for systems architecture, but instead might develop more productively through simple protocols sufficient to link different components in "evolvable systems" (Shirky 1998).
Opportunities for open source. If analogies from existing open source apply, then the best prospects for open source may lie in several areas. Reliable, open and easily improved software may be preferred for providing basic infrastructure-type services. Architectures for combining components may gain greatly from agreement on shared standards implemented through open approaches. To the extent that safety is an issue, it may be important to assure the public and regulators that safety requirements have been complied with, and disclosing source is a very transparent way to do so. Customized design of nanotechnology products could occur, even if some of the underlying technology is closed. In part this would be analogous to the way desktop publishing and other tools have greatly expanded the potential for people to directly produce what they want, rather than having to work through specialized intermediaries. A mix of open and closed software could be encouraged through software architectures which allow plug-ins, macros, APIs and other enhancements. The most likely outcome is not one of everything being open source, but one of coexistence, cooperation and competition between open and closed source.
Homebrew hardware. While access to computers is now widespread, equipment for working on the nanoscale is not as easily available. There was an initiative to develop a Homebrew STM (Rice 1995), intended to cost less than $1,000, which now seems defunct. The Simple STM Project (Alexander 2000) aims to build a simple scanning tunneling microscope that can image individual atoms for under $100. This is being developed by someone with substantial experience with scanning tunneling microscopes. The Homebrew STM relies on some patented designs, and so is not itself open source, but is an example of how at least some kinds of hobbyist access might evolve. Another ongoing STM Project (Muller 2000) has a materials budget of about $1100. The impact of "homebrew" development in leading to personal computers in the 1970s obviously gives grounds for speculation about, or at least not dismissing, major consequences from hobbyist development if it proves feasible. The ability of programmers to afford powerful computers is one of the factors which energized open source software development during the 1990s (Bennett 1999), and access to software and hardware might similarly shape the future growth of open source MNT.
AFMs and workstations. At present, atomic force microscopes and other professional nanotechnology tools are still expensive equipment sold individually to scientific laboratories and industry. The cost of hardware for most MNT-related tools is still well out of the hobbyist range. However, hobbyist type access to tools may be available to graduate students and those who have access to atomic force microscopes and other equipment as part of their studies and work. Potentially, this could offer parallels to the roots of BSD Unix, Emacs and other free software in university and corporate mainframe computers and workstations. Dependence on relatively expensive equipment is not a prohibitive barrier to the development of an open source community, though expanded access would create more favorable conditions.
Designs for the future. Several pioneering efforts have been made to apply open source approaches to software tools for nanotechnology, and a few efforts launched for hardware affordable by hobbyists and others without funds for expensive equipment. None of the MNT-oriented efforts has yet "taken off" into development of a mature and widely used application, or a large open source community.* Release of some packages into the public domain reveals a willingness to share results without limitations. No clear consensus seems to exist regarding licensing as a means to encourage others to contribute to the effort. However the use of the LGPL for Fungimol offers a useful precedent, as does the attention to creating an architecture suitable for use with plug-ins. Continued progress in other areas of nanotechnology is likely to further stimulate open source efforts, as research programs grow and the potential benefits of such software become apparent to a larger pool of potential contributors. MNT development can also be expected to benefit from open source activities in more general purpose molecular modeling software. The ways in which architecture evolves could have major implications for whether MNT systems architectures tend toward being monolithic and proprietary, or towards open systems with modularity and levels encouraging productive collaboration and competition among combinations of open source and closed source components.
One of the somewhat counterintuitive arguments for open source is that it is safer than closed source. Reliability of complex systems, security against computer viruses and other attacks, and integrity of cryptographic secrecy in communications all benefit greatly from peer review and other key elements of open source development. These advantages may also apply to nanotechnology. Talking about open sourcing nanotechnology may evoke fears about giving easier access in the future to those who might abuse the technology. Both these issues make it important to discuss the relationship between open source and safety.
Risks of not developing nanotechnology. For the long term, safety is a crucial issue for the development of molecular nanotechnology. However much of the discussion has concentrated on a few speculative scenarios of mature nanotechnology with hostile release of destructive self-replicating nanomachines (gray goo), rather than a more comprehensive approach to the range of safety issues affecting an emerging technology.* Aside from potential nanotech "weapons of mass destruction," most safety issues will be analogous to more familiar and manageable risks such as fire, arson, car crashes, airplane accidents, electric shock and food poisoning. The major difference is that good design could eliminate or drastically reduce most of the risks for nanotechnology.* Good design might make nanotechnology inherently far safer than current technologies, thus potentially creating huge opportunity costs in terms of safety and other values if nanotechnology were not deployed.
Premises. Discussion of safety in this section will be framed in terms of working hypotheses which seem generally accepted in most current thinking about risks from nanotechnology:
1. Good design could make nanotechnology safe in ordinary uses.
2. Nanotechnology could not be kept secret for long.
3. Defenses will be needed against use of nanoweapons.
Designing for safety. Despite initial worries, it has become increasingly clear that safety could be designed into ordinary applications of nanotechnology (Drexler 1990). Most products made with nanotechnology would be incapable of self-replication. Those able to replicate would usually depend on specialized inputs of materials, information and energy, without which they could not replicate. The Foresight (2000) Guidelines on Molecular Nanotechnology recommend additional measures such as designing in dependence on artificial vitamins and specialized energy sources, and requiring encrypted authorization in order to operate. In a Broadcast Architecture (Merkle 1994) individual nanomanipulators would depend on instructions from an assembler control computer and so would not be able to operate independently.
Safety through open sourcing. As discussed earlier, open source offers potential advantages for reliability through peer review to identify and correct problems. This increases the chances that software and hardware will behave as desired, and so can be designed to be safe. Design efforts can try to ensure that if problems do occur then consequences are minimized, making software and hardware fail-safe or fail-soft. Stability in the interaction of complex interrelated systems is one of the main advantages of open source versions of Unix. It is likely that open source nanotech could gain the same advantages in terms of reliable performance. Under open source it would be possible to check that safety precautions had been properly incorporated into design. Open sourcing would build on the efforts of a large community to identify problems and solve them. Given the impossibility of predicting all sources of possible failure, an open source community would be better able to rapidly respond to problems and learn how to prevent them. Thus, open source could potentially make valuable contributions to increased safety in ordinary applications of nanotechnology.
Dangers of increased availability. Analysts of nanotechnology's dangers have assumed that it would not be feasible to keep nanotechnology secret (Drexler 1986, Gubrud 1997, Freitas 2000). In contrast to initial speculations about technology that might possibly mature within a very short period of time, Kaehler's (1996) analysis convincingly argues that normal engineering learning processes are likely to constrain technical development. Technical innovation is likely to stretch out over a period of decades or longer, at least if advanced artificial intelligence is not available. While nanotech pioneers might be able to keep ahead of others, the scientific knowledge would be widely available, and any secrets would be vulnerable to spying and reverse engineering. The conclusion is that nanotechnology would become accessible to nations, groups and individuals who might use nanotech weapons for killing and destruction. Open sourcing would not create a new kind of threat. However it might make information available more quickly and so might increase the pool of individuals and groups able to use the technology. The most evocative, though far-fetched, vision of such risks is the specter of a lone sociopath able to release nanomachines which could reduce the entire biosphere to "gray goo."
Designing to prevent misuse. Unless proactive measures are taken to promote safety, open source approaches might make it easier to bypass, remove or otherwise undo safety features designed into nanotechnology. However, a strategy for designing safety can protect against abuse, particularly from individuals and groups without advanced technical skills across the range of technologies required for nanotechnology (again, at least as long as advanced artificial intelligence is not available). Simple measures such as requiring authentication and monitoring from a remote source might be sufficient to block unsophisticated attempts to misuse nanotech. If "artificial fuel sources and artificial vitamins" are essential for the workings of the available models for assemblers, than redesign to use other mechanisms, or to produce them locally would require substantial additional expertise and effort. Changing from a broadcast architecture relying on an external computer to designs with onboard processing would require even more challenging design and engineering. Designs that make it harder to develop nanoweapons, and increase the risk of failure in using them, would render nanoweapons inferior to other weapons, making development and use of nanoweapons less likely, particularly for individuals or groups with limited funds and expertise.*
Licensing for safety. If open source licenses require compliance with safety guidelines, and software packages and servers hosting them only include such software, then the best and most available tools will have safety built in, in ways that would require substantial time, effort and skills to overcome. The Foresight (2000) Guidelines recommend that:
Governments, companies, and individuals who refuse or fail to follow responsible principles and guidelines for development and dissemination of MNT should, if possible, be placed at a competitive disadvantage with respect to access to MNT intellectual property, technology, and markets.
Licensing requirements could be one tool for enforcing such restrictions on access to MNT intellectual property. This is one case where the principle of forcing derivative works to fully comply with licensing conditions of the original work would be strongly justified. Such measures cannot eliminate all risks of abuse, but could make it substantially more difficult and unlikely. The rise of the internet and its associated open standards are an outstanding example of what can be achieved through open processes for self-governance, relying on initiative, sharing of information, "rough consensus" and standards-making through "requests for comment." Similar approaches could help the community of those concerned with MNT R&D to better address safety and other issues.
Enhancing active shields. An influential, though speculative, thesis proposed in Engines of Creation has been that since nanotech weapons would ultimately be developed, an immune system-type technology of "active shields" would be needed for defense. Open source would offer the same sort of advantages for active shields against nanoweapons that it does for other design activities, by enlarging the pool of ideas and experience used to improve defenses. In the cases of computer viruses and cryptography, there are strong arguments that the advantages of sharing information about viruses, encryption algorithms and other security arrangements usually more than offset the increased risk engendered by wider knowledge of vulnerabilities and tools for making attacks.* The situation for active shields might be analogous, although it is far too early to know for sure. To the extent that this was uncertain or that closed source offered potential advantages, a pragmatic approach would be to employ a mixed strategy using both open and closed source systems, especially given that defense strategies would probably employ diverse and redundant systems.
Accelerating other safety strategies. Deterrence, arms control treaties and other international efforts could reduce the risk of development and use of nanoweapons by nations (Gubrud 1997). More broadly, the spread of democracy, prosperity and global interdependence among open societies encourages peaceful resolution of conflicts, and nanotechnology could reinforce this if benefits from the technology are widely accessible, something to which the use of open source approaches could contribute. Several more speculative strategies have also been suggested for dealing with the threat of nanoweapons. Advanced artificial intelligences might be developed and tasked to ensure safety (Yudkowsky 2000). Ubiquitous placement of tiny video cameras might enable monitoring as part of a "transparent society" (Brin 1998). "Truth Machines," (Halperin 1997) working like advanced lie detectors, might enable detection and control of dangerous individuals, including those in leadership positions. Open source could potentially accelerate the development of hardware and software needed to implement such strategies, if controversies about their technical feasibility and ethical desirability were resolved by agreement to pursue such strategies.
Open and closed levels. Analogous to current computer systems, open source applications might direct an assembler, whose internal software and hardware might be closed source. The assembler level kernel could include hardware and software for ensuring compliance with safety codes, including checking on the authenticity and integrity of higher level programs before they are allowed to operate. Higher level programs could include built-in safety characteristics, just as the Java programming language has built-in restrictions on the operations which it can perform. Designed-in restrictions might include requirements for authentication and authorization before operation, as well as reporting on location, operations and outputs and other monitoring information in accordance with safety protocols.
Nanoblocks and other limited nanotech. Even more limited forms of nanotech have been proposed and could enable safe access. Limited assemblers would be capable of making only a restricted range of products, and incapable of self-replication (Drexler 1986). In contrast to the smart, general purpose "utility fog" proposed by Hall (1996), it might be possible to make "nanoblocks" with limited capabilities, adequate to be formed into a variety of useful structures by specialized nanofabricators, guided by a programming language with built in restrictions, analogous to the Java "sandbox."* Such nanoblocks and other nanotech products might be made in specialized secure facilities, and then distributed for subsequent use. It is worth noting that even if access to assemblers were restricted, nanoblocks and limited assemblers could facilitate the creation of an open source community safely innovating designs for nanotechnology.
Advantages for safety. Safety concerns about molecular nanotechnology need to be addressed. In the short to medium term, open sourcing offers significant advantages for designing safety into ordinary applications of nanotechnology. In the longer term, nanotechnology cannot be kept secret, so dangers are largely independent of whether the technology is open or closed. Open sourcing could contribute to developing designs that are harder to misuse, making compliance with safety guidelines easier to monitor, and other means for increasing safety.
Open MNT initiatives. One of the distinguishing features of open source software development has been the demonstration of how much can be accomplished by the initiative of interested communities, without waiting for government support or policy reforms. The initiatives of diverse individuals and groups have played central roles in open source software development, and development of open source molecular nanotechnology could well be similarly diverse.
Licensing. Several strategies might be useful in promoting open MNT. Agreement on core principles, similar to those in the Open Source Definition, could reduce conflicts and encourage appropriate commercial participation. Given the importance of physical structures in nanotech, open sourcing of nanotechnology needs to address public licensing of patent rights in more detail than do current licenses, perhaps drawing on precedents from current initiatives seeking to develop open computer hardware and open publications. In some cases, patent pools with an incentive arrangement of restricted rights might help balance commercial and community interests. Some of the goals of open source could be obtained with unrestrictive software licenses such as the X11 and BSD licenses. For those who want to ensure disclosure of modifications, while still allowing modular linkage with closed software in combined works, the LGPL is an example of a suitable software license.
Business models. Companies, entrepreneurs and investors would benefit from recognizing the ways in which open source methods can synergize with business models relying on providing goods, equipment, and expert services such as customization and specialized research and development. Open source business models are likely to be more successful in a dynamic environment, less risky and more robust against unanticipated changes, compared to strategies highly dependent on closed intellectual property. One promising opportunity for exploration would lie in consortia for open research and development of MNT, funded by companies which want to ensure access to nanotech as a production technology. Among other advantages, open source methods could help avoid antitrust problems for such consortia.
Molecular engineering software. Software for MNT design seems the most promising area for further open MNT efforts. Systems architecture for software, and eventually nanodevice hardware, which incorporated suitable abstractions such as modularity and levels would help promote fruitful competition and combination of open and closed source software and hardware.
Safety. The proposed Foresight Guidelines on Research in MNT could create an important opportunity for strengthening self-governance within the MNT R&D community, at a minimum by stimulating discussion of when and how safety should be addressed. Open sourcing offers important advantages for promoting safety in MNT design.
Topics for further study. A number of areas could benefit from further research on the applicability of open source principles for MNT.
Copyright (c) 2001 by Bryan Randolph Bruns. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Later versions of this document may come under different copyright provisions, depending on publication arrangements.
Author information. Bryan Bruns holds a Ph.D. in Development Sociology from Cornell University. He has an independent practice as a consulting sociologist. He is a member of the International Association for Public Participation and the International Association for the Study of Common Property, a Fellow of the Society for Applied Anthropology and a Senior Associate of the Foresight Institute. Views expressed in the paper are those of the author and do not represent any organizations with which he is or has been affiliated. Responsibility for any technical bloopers and other errors and omissions lies with the author.
Acknowledgments. In addition to the sources specifically cited, this paper has benefited from discussions of open source at the Foresight Senior Associate Gathering, May 19-21, 2000 and from online discussions on www.nanodot.org and the NanoCAD mailing list. In a posting on the usenet sci.nanotech newsgroup on Jan 5 1995, Sean Jackson ([email protected]) suggested that nanotech designers could share their ideas via the same kind of public source licenses used for software, mentioning Linux, and Emacs and posting a brief version of the Free Software Foundation's license. This appears to be the first published suggestion that Free Software licensing be applied to nanotech. Christine Peterson, the Executive Director of the Foresight Institute participated in the discussions which resulted in the earlier Debian Guidelines being developed into the Open Source Definition, and is credited with coining the term "Open Source" for this software.
In comments on an earlier paper, Robin Green pointed out the importance of distinguishing between public domain status and open source licensing. Eric Raymond provided helpful comments in correspondence and conversation. Correspondence with Tim Freeman, author of the Fungimol software package, helped focus my attention on the relevance of the LGPL as a suitable license for MNT. Will Ware, author of NanoCAD and moderator of the NanoCAD mailing list, commented on the educational role of open source and on other issues. Eugene Leitl responded to several questions posted with an earlier draft. He and several others on the NanoCAD list contributed to interesting threads on systems architecture, vat manufacture and collaboration. Robert Nansel's comment on Nanodot pointed out the URL for John Alexander's Simple STM Page. John Alexander clarified that his STM uses patented technology, and gave a pointer to Jurgen Muller's STM Project. Roger Sayle and Herbert Bernstein discussed the lessons from RasMol and thinking behind OpenRasMol. Chris Phoenix, Pat Gratton and others also made helpful comments on drafts. A draft of this article was discussed on Slashdot on October 19, 2000 under the title "Open Source Nanotechnology." The Slashdot article was based on an editorial in Nanotechnology Magazine that cited the draft paper and recommended use of open source methods in the development of molecular nanotechnology. A poster presentation of the paper was made at the Eighth Molecular Nanotechnology Conference in Bethesda Maryland, November 3-5, 2000, and several participants made helpful suggestions on the paper and on ways to advance open source approaches to nanotechnology. A visit to the Workshop on Political Theory and Policy Analysis at Indiana University provided an opportunity get feedback on the ideas in the paper and look into the analysis of information goods and anti-commons in more depth.
Draft 0.4 posted on September 1, 2000 and announced on Nanodot and on NanoCAD list.
Draft 0.5 September 8. Reorganized with summary at beginning. Added discussion of antipatents, systems architecture and homebrew hardware.
Draft 0.6 October 16. Changed titles. Miscellaneous minor revisions, including following up on comments received.
Draft. 0.7 Reformatted references. Revisions regarding what not to open source, value of simple BSD-type licenses, potential of open source in infrastructure, safety and customization, and need for research on factors influencing software monopolies. Deleted (incomplete and somewhat inconsistent) investment and staff columns in nanocompanies list.
Draft 0.8 November 1, 2000. Converted to Microsoft Word for printed version to distribute at MNT conference and for journal submission.
Version 0.9 (html) January 12, 2000. Expanded discussion of monopoly and anti-commons in main text and notes. Added headings of BSD-type and modular licenses in Table. 1. Revised discussion of Rasmol. Added anchors and links for references. Miscellaneous minor revisions. Submitted to MNT conference archive.
0.9.1 Shifted Technanogy to nanomaterials section in nanocompany table and updated text based on table. Updated Atomasoft listing to reflect current news services.
0.9.2 Noted acceptance for Conference Proceedings. Minor update to Technology listing.
0.9.3 Added link to publication information in Nanotechnology.
Intellectual property and MNT. In a series of articles in the Foresight Update Newsletter, Elizabeth Enayati gave a useful introduction to intellectual property issues affecting molecular nanotechnology.
Scenarios. This paper largely follows the concepts, assumptions and scenarios discussed by Eric Drexler (1986) in Engines of Creation: The Coming Era of Nanotechnology. The major differences are assumptions that:
1. Safety can be designed into ordinary applications of MNT (per Drexler 1990).
2. Learning processes characteristic of other engineering R&D will constrain the rate of technological advance in MNT (Kaehler 1996).
3. MNT will continue to advance more rapidly than either general purpose artificial intelligence or radically self-improving software for design. This assumption is more debatable, but postulating strong artificial intelligence tends to shroud discussions of the future behind the veil of an unknowable technological "singularity" (Vinge 1993), while this paper focuses on intellectual property policies and strategies for MNT research and development in the short to medium term.
Cathedral and the Bazaar. Eric Raymond's essay originally appeared online in 1997, and was subsequently revised, and followed by further online essays on "Homesteading the Noosphere" and the "The Magic Cauldron." These were published in book form in 1999 and references in this paper are to the 1999 print version.
Information commons. The analysis here applies to information that is publicly shared without charge, giving it the characteristics of what economists call a public good. By contrast, closed code is kept exclusive through secrecy and protected by copyright, patent and trade secret law. If a company's proprietary software creates a competitive advantage, then its disclosure, duplication and use by rivals would subtract from the benefits to the originator. Such secret code, exclusive and useful in commercial rivalry, would have the characteristics of a private good. Site licenses, enforced by legal and technical means, may allow a specified number of users on a network to use the software, giving such licensed software the characteristics of a common pool good. Initially creating software is usually expensive, even though the marginal cost of making additional copies is near zero. It may be difficult for individual users to produce for their own use, requiring substantial scale of production or joint efforts, showing on of the reasons why it may be advantageous to provide the good as an information commons.
EXCLUDABLE Yes No Yes SUBTRACTABLE
(rival, nonjoint, nonpartitionable) Private
goods (valuable
secrets) Common pool
goods (shared network
bandwidth, server storage, etc.) No Toll goods,
Club goods (road, golf
course) Public
goods (scientific
knowledge)
secret software which provides competitive
advantages
site license for specific number of users
commercial software - closed code
publicly shared code
open source, free software
The use of information depends both on physical and technical characteristics and on the social institutions for intellectual property rights. Information can be kept secret and only be useful if others do not possess it, for example a secret treasure map (Raymond 1999). Compiling source code into binary object code enables computer programs to be distributed without sharing the original source code. Hardware, such as keys or "dongles" attached to computers, can control access, and verification software working over the internet can accomplish the same result. The use of information can be restricted by community norms and by laws on intellectual property rights, such as copyright, patents and trade secret laws which make it possible, but not necessary, to treat information as a private good. The categorization of information goods, presented in italics in the table, could be based purely on technical measures to control access, but is usually reinforced by intellectual property rights (copyright, patent and trade secrets) and contract law (licensing contracts). As discussed in the text, information is typically not subject to the congestion which affects toll or club goods. As discussed in the section on licensing, open source code is actually legally private property, with licenses giving rights to use the intellectual property. One of the advantages of open source is that it fits better with the underlying characteristics of information than does trying to treat information goods as a private property with restrictions on access and reproduction. The difficulty of restricting access to information and the frequency of win-win benefits from sharing underlie the argument that "information wants to be free" (Stewart Brand, cited in Barlow 1994).
Licenses. Descriptions of licenses and links to the web pages for the licenses can be found on the Open Source website (www.opensource.org) and the Free Software Foundation website (www.gnu.org). The online version of this paper also has direct links to sites with further information on the licenses.
Open hardware. Information on the Open Hardware initiative is at www.openhardware.org. For examples of licenses see the Open Collector (opencollector.org/hardlicense/licenses.html) and Open PPC Project (www.openppc.org/licenses.html) websites. Another interesting hardware initiative is the GNU book project, which has a special GNU++ license (www.gnubook.org).
Public domain as open source. Explicitly putting code in the public domain would fulfill the minimum requirements for the open source definition of making the source code available and allowing modification and free redistribution. (Eric Raymond, in a personal communication, agreed that this satisfies the open source definition "in a trivial sense."). The BSD-type licenses provide an explicit and standard way to make clear that others can freely modify and redistribute the source. They also allow the original owner to retain copyright, and to require that derived works acknowledge the original and retain warranty disclaimers.
Python license. Python releases before and after 1.6 are compatible with the GPL. The 1.6 release of the Python software was under a license which was still open source compliant, but not compatible with the GPL because the license stipulated the venue in which disputes would be considered.
RasMOL. Roger Sayle (personal communication) said that when he released the software he chose to put it into the public domain rather than using the GPL because "[r]equiring that all software derived from an original also be GPL would prohibit researchers making [use] of some of RasMol's innovative algorithms in their own work." A later proposal from Richard Stallman that RasMol be placed under the GPL was declined, since it would have required substantial revisions to replace the patented GIF graphics format, and might have prevented supporting the Macintosh versions of RasMol. Sayle was surprised and disappointed when companies took advantage of the release into the public domain to produce proprietary software largely based on RasMol code, rather than just using small specific parts of the program. The lack of licensing requirements also meant that as he made improvements, the companies that released commercial software based on RasMol incorporated the improvements into their private versions of the software, while not sharing their own modifications. In hindsight, Sayle feels the software should have originally been released under a GPL-style license, which is the approach now being applied in version 2.7.
The licensing for RasMol 2.7 is intended to be "simpler" and easier to understand than the GPL, but is "GPL-like" (Bernstein personal communication). The licensing notice makes clear the intention to permit modification and redistribution. Like the GPL, modified versions must comply with the original licensing, meaning that they have to stay "free" and cannot be taken private. The license notice for version 2.7 includes the RasMol 2.6 licensing notice, which somewhat confusingly seems to prohibit any reproduction or transmission of the software except for personal use, and which includes specific prohibitions on use with nuclear power and with aircraft. RasMol 2.7 uses the STAR File and Crystallographic Information Formats (CIF), for which the International Union of Crystallography (IUCr) holds patent rights and requires conformance to specific standards for reading and writing files and data. Herbert Bernstein (personal communication) has stated that concerns about this patent issue would be an obstacle to issuing RasMol under the GPL.
Nano@home. As part of trying to promote more "design ahead" to be able to take advantage of molecular assemblers once they arrive, Robert Bradbury has proposed a Nano@home project, including options to encourage resulting designs be open source (www.aeiveos.com/~bradbury/Proposals/NanoAtHome.html) . A more general proposal for studying proteins using a distributed application for Folding@Home was mentioned on Nanodot on September 29, 2000 and discussed on Slashdot on September 26, 2000.
Security and open source is discussed by Eric Raymond (1999:155). The topic of open source and security frequently comes up periodically on the Slashdot forum. A recent example of discussion about risks from easier availability of tools which might be used in attacks can be seen in commentaries on "Security Through Obscurity a GOOD Thing?" Slashdot July 7, 2000. Advantages and disadvantages of having code exposed for inspection were discussed in commentaries on "Security Focus Responds to ESR [Eric S. Raymond] Column on OSS [Open Source Software] Security, Slashdot April 17, 2000
Gray goo: For a recent discussion of gray goo and other threats from hostile replicators, see Freitas 2000.
Designing safety. The ways in which shielding and interlocks make microwave ovens far safer than gas ovens offer a simple example of the potential for good design in newer technologies to build in safety and convenience.
Inferior weapons. See Jessica Stern's (1999) The Ultimate Terrorist for a current review of factors that limit the ability and motivation of terrorists to use nuclear, biological and chemical weapons. Similar constraints of technical complexity, uncertain impacts and vulnerability to countermeasures might make potential nanoweapons harder to obtain and less likely to be used than conventional weapons, such as explosives, or other weapons of mass destruction, such as chemical weapons.
Nanoblocks were suggested by Eliezer Yudkowsky in personal communications with the author.
Mixed strategy for business. Under current intellectual property conditions, a mixed strategy able to work under both open and closed IP might be a pragmatic choice. Celera's strategy in biotechnology includes both speculative patent claims and a core business model based on providing specialized information services (as well as backing from a business whose revenue streams come from selling equipment).
Zyvex's website discusses open source and makes clear that it uses both open and closed source tools including Python. Posts by Jim van Ehr, Zyvex's CEO, on the NanoCAD mailing mailing list clearly state a pragmatic attitude towards the use of open source.
Alexander J D 2000 Simple STM Project www.geocities.com/spm_stm
Apple Computer 2001 Apple Public Source License www.opensource.apple.com/apsl/
Barlow J P 1994 The Economy of Ideas Wired 2.03
Bennett J C 1999 The End of Capitalism and the Triumph of the Market Economy www.pattern.com/bennettj-endcap.html
Bernstein H J 1999 RasMol -- Managing the Divergence of Variants in an Open Source Multiple Platform Environment openscience.bnl.gov/Abstracts/RASMOL.shtml
Bernstein H J 2000a Home Page for OpenRasMol Molecular Graphics Visualisation Tool www.OpenRasMol.org
Bernstein H J 2000b The Historical Context of RasMol Development www.bernstein-plus-sons.com/software/rasmol/history.html
Bioinformatics.org 2000 The Open Lab bioinformatics.org
BNL - Brookhaven National Laboratories 1999 Open Source/Open Science Conference openscience.bnl.gov
Brin D 1998 The Transparent Society : Will Technology Force Us to Choose Between Privacy and Freedom? (Reading, MA: Addison-Wesley)
Brooks F P 1995 The Mythical Man-Month: Essays on Software Engineering. Anniversary Edition. (Reading, MA: Addison-Wesley)
Bruns B R 2000 Nanotechnology and the Commons: Implications of Open Source Abundance in Millennial Quasi-Commons presented at the Eighth Conference of the International Association for the Study of Common Property, Bloomington, Indiana, USA, May 31-June 4, 2000
Coase R H 1990 The Firm, the Market and the Law (Chicago: University of Chicago Press)
Drexler K E 1986 Engines of Creation. (New York: Anchor Books) http://www.foresight.org/EOC/index.html
Drexler K E 1990 Afterword in Engines of Creation. (New York: Anchor Books)
Drexler K E 1999 Senior Associate Letter Letter #28 (Palo Alto, CA: Foresight Institute)
Doll J J 1998 The Patenting of DNA Science 280 689-690
Ellenbogen J C 1997 Matter as Software presented at Software Engineering and Economics Conference April 2-3, 1997 (McLean, Virginia: Mitre Corporation)
Foresight Institute 2000 Guidelines on Molecular Nanotechnology www.foresight.org/guidelines/current.html
Freitas R A 1999 Nanomedicine Vol. I. Basic Capabilities. (Austin, TX: Landes Bioscience)
Freitas R A 2000 Some Limits to Global Ecophagy by Biovorous Nanoreplicators with Public Policy Recommendations (Richardson, TX: Zyvex)
Freeman T 2000 Fungimol www.infoscreen.com/fungimol
Free Software Foundation 2000 Gnu General Public License www.gnu.org/copyleft/gpl.html
Gubrud M A 1997 Nanotechnology and International Security presented at the Fifth Conference on Molecular Nanotechnology.
Hall J S 1996 Utility Fog: The Stuff Dreams are Made of in Nanotechnology: Molecular Speculations on Global Abundance B C Crandall (ed) (Cambridge, MA: MIT Press) pp 161-184
Halperin J 1997 The First Immortal (New York: Ballantine)
Hardin G 1968 The Tragedy of the Commons Science 162 1243-1248.
Hardin G 1998 Extensions of "The Tragedy of the Commons Science 280 682-683.
Hargrave R and Malamud C 2000 Transparent Patents voice.media.org/essays/patent.html
Hecker F 2000 Setting Up Shop: The Business of Open-Source Software Draft revision 0.8 www.hecker.org/writings/setting-up-shop.html
Heller M A and Eisenberg R S 1998 Can Patents Deter Innovation? The Anticommons in Biomedical Research Science 280 698 - 701
Hodgson J 1996 GlaxoWellcome and MDL become entangled in the Web Nature Biotechnology 14 690.
IBM-International Business Machines 1999 IBM Public License Version 1.0 - Jikes Compiler www.research.ibm.com/jikes/license/license3.htm
Kachina Technologies 2000 Scientific Applications for Linux: Chemistry, Biology and Related sal.kachinatech.com/Z/2/index.shtml
Kaehler T 1996 In-Vivo Nanoscope and the "Two-week Revolution in Nanotechnology: Molecular Speculations on Global Abundance B C Crandall (ed) (Cambridge, MA: MIT Press) pp 49-60
Krummenacker
M 2000 Problems
with the Current Intellectual Pseudo "Property" (IPP) System,
especially Patents
www.n-a-n-o.com/ipr/fi-gathering2/ipp-scenarios.html
Krummenacker M 1996 CavityStuffer www.ai.sri.com/~kr/nano/cavstuf/cavstuf.html
Kuznik N 2001 Linux4Chemistry zeus.polsl.gliwice.pl/~nikodem/linux4chemistry.html
Levin R 2000 Open Source isn't Commons Slashdot June 13, 2000
Manunza B 2000 Antas: Software list and links antas.agraria.uniss.it/software.html
Marston C 2000 Avoiding the Tragedy of the Commons Slashdot June 12, 2000
Martz E 2000 Molecular Visualization Freeware: Protein Explorer, Chime & RasMol klaatu.oit.umass.edu:80/microbio/rasmol
McCluskey P 1998 Dismol: A freeware molecule display applet including source code www.rahul.net/pcm/dismol/DisMol.html
Merkle R C 1994 Self replicating systems and low cost manufacturing in The Ultimate Limits of Fabrication and Measurement Welland M E J.K. Gimzewski J K (eds) (Dordrecht: Kluwer) pp 25-32
Mitre Corporation 1999 Collaborative Virtual Workspace License (CVW) License Agreement cvw.mitre.org/cvw/licenses/source/license.html
Muller J 2000 STM Project www.e-basteln.de/index.htm
Netscape 2000 Mozilla Public License Version 1.1 www.mozilla.org/MPL/MPL-1.1.html
Olson M 1971 The Logic of Collective Action: Public Goods and the Theory of Groups (Cambridge, MA: Harvard University Press)
Open Hardware 1999 The Open Hardware Certification Program www.openhardware.org
OpenChem 2000 OpenChem www.openchem.org
Open Source Initiative 2000 Open Source Definition www.opensource.org
Ostrom E 1990 Governing the Commons: The Evolution of Institutions for Collective Action (Cambridge: Cambridge University Press)
Ostrom E, J Burger, C B Field, R B Norgaard and D Policansky 1999 Revisiting the Commons: Local Lessons, Global Challenges Science 284 278-282
Perens B 1999 The Open Source Definition in Open Sources: Voices from the Open Source Revolution (Sebastopol, CA: O'Reilly)
Peterson C 1999 Inside Foresight Foresight Update 38 2
Raymond E S 1999 The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (Sebastopol, CA: O-Reilly)
Rice J 1995 NanoTools: The Homebrew STM Page atom.snu.ac.kr/stmwebpage.html
Sayle R and E M Milner White 1995 RASMOL: Biomolecular Graphics for All Trends in Biochemical Sciences 20 374-376
Shewmaker M 2000 The Open Patent License www.openpatents.org
Shirky C 1998 In Praise of Evolvable Systems www.shirky.com/writings/evolve.html
Software Patent Institute 2000 Database of Software Technologies www.spi.org
Stern J 1999 The Ultimate Terrorist (Cambridge MA: Harvard University Press)
Vinge V 1993 The Coming Technological Singularity: How to Survive in the Post-Human Era www-rohan.sdsu.edu/faculty/vinge/misc/singularity.html
Wayner P 2000 Free for All: How Linux and the Free Software Movement Undercut the High-Tech Titans (New York: HarperCollins)
Ware W 2000 NanoCAD in Java: A freeware nanotech design system including source code world.std.com/~wware/ncad.html
Williamson O 1996 The Mechanisms of Governance (New York: Oxford University Press)
Wilson G 2000 Alchemy or Science: The Open Source to a Scientific Enlightenment in Scientific Computing World Scientific Computing 2000
Wilson P 2000 Publishing ideas March 14, 2000 oreillynet.patents newsgroup.
Yudkowsky E 2000 The Plan to Singularity singinst.org/singularitarian/PtS/plan.html
Zyvex 1999 Zyvex DiamondCAD www2.zyvex.com/DCAD/Software.html
See notes below for explanations
PRODUCTS (planned
and current) COMPANY A. MNT-ORIENTED 1.
Atomasoft news
portals; mission to develop design and simulation
services NanoInvestorNews,
NanotechNews.com, MEMS Center.com 1997 seed capital,
advice, contacts, and other support services links to
IMM 1998? taggants,
nanotubes, MEMS, AFM, quantum computers enabling
technologies for MNT, (Institute of Nanophysics) 1999? 4.
Zyvex Zybot
manipulator,Rotapod assembler, MNT assembler links to U. Texas
(Dallas) and others 1997 B. R&D AND
EQUIPMENT 1.
CALMEC patents
and trade secrets: technology licenses: fees and
royalties contract
R&D strategy to pursue
IP 1997 computers and
equipment 1939 3.
IBM computers and
other IT software consulting leader in
research 1911 consulting,
contract R&D quantum optics
& nanotech, laser scissors and tweezers 2000 5.
Mitre research
for government clients molecular
electronics. Nanosystems Group since 1992 1958 communications
systems does relevant
research, no specific nanotech program Bell
Labs 1925 7. MEC - DRAM and other
molecular electronics equipment? cooperation with
Rice, Yale & Penn State Universities 1999 ultra-precision
machine systems some
DARPA-developed technologies �1998 9.
Nanogen microchip for
biological analysis: cartridges and workstations licensing
and joint ventures contract
research child of
Nanotronics 1993 10.
Nanolab devices based on
carbon nanotubes pending
patent collaborative
research 2000 11.
Nanovation photonic
components optical
circuit design (Apollo Photonics) formerly US
Integrated Optics 1996 12.
NanoWave licensing contract
R&D position
encoders 1995 13.
SDL
Queensgate subsystem
OEM nano-positioning
and sensors 1979 C. MATERIALS 1.
Argonide powders contract
R&D applying Russian
technology 1994 2.
CarboLex single-walled
carbon nanotubes 1998 carbon
nanotubes R&D no
website 4.
eSpin polymer
fibers and webs technology
development Graphite
Fibril(TM) nanotubes metal
nanopowders Russian
technologies 1997 contract
R&D nanolayer coating
process 1986 8.
Nanocor nanosized
clay minerals for plastic resins 1995 9.
Nanomat nanocrystalline
materials and nanostructures consulting
and technical assistance Pennsylvania and
India �1999 powders
and derivative materials possible
patent licensing 1994 11.
NanoPierce nanoparticle
electrical connections website
down powders
and engineered products moving toward
large [tons] production capability 1989 precious
and base metal powders 1994 nanoscale
ceramics for fuel cells licensing
and joint ventures 1995 developing
carbon nanotube membrane for fuel cells licensing contract
R&D technology
development company 1973 16.
Powdermet powders
and other materials contract
R&D 1996 17.
Technanogy nanoaluminum
powder nanometals
engineering 2000
California Molecular Electronics Corporation
Molecular Electronics
Sources: Compiled August 5-8, 2000, from websites listed on the Nanotechnology Industries list of companies (www.homestead.com/nanotechind/companies.html), or under industry on the Loyola College Nanotechnology Database (itri.loyola.edu/nanobase/). Companies with inactive websites (e.g. Nanotechnology Development Corporation) or inaccessible websites (e.g. Nanoprobes) not included, nor are companies whose websites indicate little explicit focus on nanotech (e.g. NanoLogic) or that seem no longer active in nanotech (e.g. Xerox). These two lists were chosen as well-informed sources that provided a manageable sample which could be studied with limited research resources. Two nanotechnology companies were added later, Molecular Electronics, and Technanogy. In April 2001, Technanogy was shifted to Nanomaterials based on information supplied by the company.
The lists used do not include most suppliers of molecular modeling software (discussed separately in the paper), STM/AFM equipment and other relevant goods and services. For a list of equipment suppliers, see the EMBL website (www.embl-heidelberg.de/~altmann/companies.html#INSTRUMENTATION). The Nanotechnology Industries list of tools includes software and equipment companies not in the list above (www.homestead.com/nanotechind/tools.html). Nanotechnology potentially affects almost every company, especially those producing any kind of material goods. For longer lists of nanotechnology-related companies, (which could be studied for a more comprehensive assessment) see the Atomasoft website (www.atomasoft.com), and the Nanotechno posting on RagingBull (www.ragingbull.altavista.com/mboard/boards.cgi?board=NANOTECH&read=274). Robert Freitas' Nanomedicine page lists nanomedicine research organizations and companies (www.foresight.org/Nanomedicine/#NMResComOrg).
Products: Includes both current and projected (possibly vaporware) products. Software/IP listed only if for external sale/licensing, not just on company's own equipment/hardware products.
Comments and corrections are invited to [email protected]
Home About Foresight Blog News & Events Roadmap About Nanotechnology Resources Facebook Contact Privacy Policy Foresight materials on the Web are ©1986–2024 Foresight Institute. All rights reserved. Legal Notices. |
Web site developed by Stephan Spencer and Netconcepts; maintained by James B. Lewis Enterprises. |