|
Workshop on Software Tools for HPC Systems
Intellectual Property Issues |
 
|
|
|
|
|||
 |
|
||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
Working Group Members
|
|
||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
|
Introduction
|
A working group was convened to discuss the legal/ethical responsibilities, intellectual ownership, and liability issues that would need to be addressed in establishing a national center for software tools associated with high-performance computing (HPC). The group's members included representatives from academic, industrial, and federal organizations involved in HPC. (One participant, Frederica Darema, had participated in the HPSST task force where the concept of such a center was first addressed.) A list of charter questions was furnished as a starting point for the group's discussions. This summary presents the general scope of deliberations over the three-day period. Rather than following the chronological order topics were addressed, it groups the issues and recommendations in terms of three major topics:
|
||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
|
Why Intellectual Property is Problematic for the Proposed center
|
By its very nature, the concept of a national center implies issues with regard to multiple "owners" of intellectual property. Regardless of the specific products to be delivered by the center, or the specific processes by which they are delivered, at least one of the following conditions will apply:
That is, unless the center designs and develops products from scratch and performs all distribution tasks, multiple organizations will have to be involved. Given the current climate for IP, that in turn implies problematical issues of ownership and liability. The center, as laid out in the plenary Workshop discussions, itself constitutes a multi-agency effort, as it is likely to be funded by more than one HPCC agency. Currently, each agency imposes its own set of IP requirements. An anecdote was supplied concerning a joint development effort funded by DOE but involving two national laboratories. The project ultimately foundered because the labs were managed by different contractors, who could not arrive at IP agreements - despite pressure from their common funding agency. The Working Group concluded that it would be extremely helpful to the whole concept of the center if the HPCC agencies could come to agreement on the basic IP issues involved in jointly sponsored ventures (see Recommendations). The group attempted to identify precedents, among recent efforts in the software development community, for how the center's IP problems might be addressed. The National High-Performance Computing Software Exchange (NHSE) sidesteps basic ownership issues by not distributing software, but rather providing pointers to the original software owners; it essentially functions as a clearinghouse. It was the consensus of the group that this model did not make sense for the center, since it would essentially duplicate an existing effort. Instead, the center should provide some type of output. NASA's COSMIC effort provides Beta code in return for a nominal licensing agreement, allowing others to test and even modify the software. If the software is taken to product status, however, ownership (including any enhancements added by beta licensees) reverts to the original developers and the licenses can be revoked. Similar examples were cited of companies releasing (revocable) alpha source code, to obtain early reactions from users or in cases where there are no immediate plans for further development of the software. As a precedent for the center, this approach was considered too restrictive, since it would assume that all software would be developed strictly in-house, rather than obtained from, or developed in collaboration with, other groups. We chose to view the overall process in very general form. The center would accept inputs from some other community (e.g., academia), perform some development or enhancement activities, and release some form of outputs to the user community and/or to the software industry for productizing. In terms of the process inputs, basic IP questions arise:
The outputs are also subject to some elementary issues of IP:
Specific ideas for dealing with these questions are outlined in later sections. The group also considered this process from the viewpoint of liability. Here, it was felt that there are a significant number of precedents establishing the desirability of disclaiming all liability with regard to software correctness or appropriateness when applied to specific tasks. The fact that multiple organizations might be involved does not appear to have particular impact, as long as the center maintains appropriate disclaimers. Another potential problem is the fact that individuals involved either in developing the inputs, or in the center's own activities, might be privy to non-disclosure information from one or more vendors. The group eventually decided that this was not, strictly speaking, a problem for the center; rather, it was up to each individual to abide by the conditions of the non-disclosure agreements into which he or she had entered. The issue of "copyleft" was also of concern to the group. Under this type of agreement, the adopter of a software component agrees that any time the new work is distributed, complete source code will be made available. Although this does not entirely preclude distribution of software in binary format, it does require that the software developer (in this case, the center) guarantee that source is freely available. Copyleft can pollute the code, in the sense that it may preclude combination of a tool prototype with certain third-party components (i.e., that put restrictions on source code distribution). It may also make it impossible for companies to commercialize the software. |
||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
|
Alternative Models for the center and Their Implications for IP
|
As the plenary discussion of the proposed center had left some doubts about its precise role in the development and hardening of software tools, the group spent some discussed several possible models of operation. Where possible, individuals described precedents for the models and indicated the IP issues that had been raised in each case. In all, five likely models were identified. Each is described below, together with our conclusions about the ramifications for IP. "Consumers' Union" Model As discussed by the group, this model would constitute an independent review board to test and evaluate software tools. Like the Consumers' Union, reviews would be made publicly available in order to help users determine a priori whether or not a software tool was likely to be of help to them. Two precedents were noted. First, NHSE had originally stated that objective reviews would form an important part of their process. In fact, NHSE has served as a Web-based clearinghouse for information, simply providing pointers to Web pages belonging to industry and research developers, and occasionally serving as a distribution site for shareware. As was pointed out by members of the group, NHSE's decision not to take a more active reviewing role was due largely to IP problems. Cited as a second precedent was the Parallel Tools Consortium's proposal for a related effort, whereby users would contribute evaluations of current tools. Such evaluations would, theoretically, help other users determine the probable usefulness in new situations. Again, a decision was made not to pursue this project, because of liability problems. The publishing of evaluation reports is fraught with difficulties of fairness and liability. This is particularly troublesome for software, where there are no accepted standards objectively measuring to what extent a product possessed "quality" or "usefulness". Nor can a new product simply be compared with existing ones, if there is no consistent baseline set for comparison (as is the case with software tools). Essentially, then, any evaluation can be criticized for lack of objectivity. Further, there is no established test suite against which to exercise tools. The precedent of the Ada validation test suite was cited in this regard. It was noted that, in addition to the availability of a general test suite, the Ada situation involved validation by an independent agency established solely for this purpose. However, test results were not published per se; the public notification simply indicated which compilers had been fully validated (but nothing about their relative performance, nor even how many compilers had failed the tests). The group concluded that while the experiences of a software tools center might eventually lead to the possibility of establishing sufficient test suites and objective testing techniques, such an approach was not really feasible at the present time. Independent Testing center Model Discussion of the Ada validation scheme led naturally to a model where software testing was performed, but the results were kept private (other than perhaps a certification that some tool had passed muster). In this case, tool developers - most likely those from industry - could pay a membership fee or testing fee, submit their software, and receive complete reports as to where it passed or failed the tests. While the model could be self-sustaining financially, it was not clear to the group why a national center was necessary. It was pointed out that in fact, some universities and centers already function in this role, providing testing and evaluation services for a fee. Overall, the group felt that the model offers little advantage to the HPC user community, since the tool developers are not obligated in any way to apply the feedback in refining their product. Moreover, since test results remain confidential, there is no real way to apply pressure for improving tools. Standards Definition Model Under this model, the primary role of the center would be to define and promulgate standards for software tools. It was noted that currently, it is quite difficult to organize standards efforts and bring them to fruition, since none of the HPCC funding agencies seems to view logistical and administrative support for standards groups as being within their project domain. While the working group thought that the availability of clearly formulated standards reflecting the needs of the broad HPC community might go a long way to improving the tools situation, there were two problems with this model. First, there is no clear indication that this role alone might justify the establishing of a national center (since one agency for standards, ANSI, already exists, even if its record with respect to software is somewhat weak). Second, this approach does not really address the circumstance discussed in the plenary sessions: that new software tools are being generated regularly within the tools research community, but they do not find their way into general use or commercial production. The working group concluded that the role of standards definition would be more likely to succeed if it were rolled into some broader role (the examples of NHSE, Scalable I/O Initiative, and Parallel Tools Consortium were brought up). Funding center Model The group also discussed the role of a national center in financially sponsoring tool projects that led to robust, distributable, and potentially commercializable products. Currently, funding agencies support the initial research, and in some cases the development of an early distribution, but so-called software capitalization is rare in the area of HPC tools. Such a role might enable the center to expedite the deployment of tools into the user community. The primary drawback to this model is the relationship of such a center to its own funding sources. Existing agencies have established peer review mechanisms, and it is assumed that a center would need to do the same thing. In that case, what real value-added would be supplied by the center? As was pointed out by some group members, this arrangement would actually force the HPCC agencies to relinquish some of their direct control over funded projects in software tools. It was agreed that there would likely be problems in terms of both political pressure and prioritization (if, for example, agency priorities did not align with those of the center). We recommended against this model. Software "Hardening" Model The fifth model discussed by the group was a mechanism for "hardening" the prototype tools that are already being produced by the research community. The center would accept proposals from that community for projects to test research prototypes, make them more robust through code reorganization, integrate them with other software on HPC platforms, perform tasks associated with user documentation, and in general, convert the prototypes into software "products" that would be distributable, usable, and maintainable. Acceptance of software as input would be through a peer-review process involving other researchers, users (who would assess likely impact of the tool on the user community), and vendors (assessing likely interest for ultimate commercialization). It was assumed that such prototypes would emanate from a variety of research projects at academic institutions, national laboratories, federal centers, and possibly industry sites (e.g., research groups that have developed software which will not be converted into products). center staff would perform the "software distillation" in collaboration with the original developers, to take advantage of their familiarity with the technology and existing code organization. In some cases, external components - such as parsers or other code analysis modules - might be acquired by the center as library components that could be shared among multiple software hardening projects. The output of the center, then, would be distributable releases of software tools. The group felt that the primary target audience should be the HPC user community; that is, that users should not have to wait for industry to pick up and productize a tool before it can be used. Therefore, the center would also fulfill a role of supporting and maintaining its output. In addition, the center would attempt to feed its products into the software industry, entering into agreements with companies that wish to create proprietary products. Finally, the center's public distributions might also lead back into the hands of tool developers, who could base derivative works (e.g., more specialized tools, problem-solving environment components, etc.) on the earlier releases. This model exhibits all the problems associated with multi-party ownership of IP, but the group also felt that it did the best job of responding to the objectives of the HPSST task force, as well as guaranteeing impact on the HPC user community. The group then proceeded to discuss how IP could be managed under such an organizational model. |
||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
|
Recommended Policies for Dealing with IP Issues
|
The group formulated a number of recommendations for how liability and ownership issues should be handled for a multi-agency center. They fall into the categories of: general policies, ownership, liability, and ethics. General Policies The HPCC agencies should adopt consistent policies toward basic IP issues, in order to make joint projects practicable. The current situation, where each agency defines and manages its own IP process, leads to confusion and in some cases can actually preclude collaborations among developers. Regardless of whether or not a national center is established, we strongly recommend that attempts be made to align the agencies' current practices, at least in the realm of multi-party projects. Such policies should address the issues involved when other groups alter or extend previous work, as well as development efforts that originally involved multiple parties. The procedures and policies established by the center should make it possible to exploit multiple outlets for center products, including the user community, commercial adopters, and tools researchers. While it might meet the objectives of the original HPSST task force to simply funnel robust tools to HPC users, this imposes a long-term burden of maintenance and support on the center. This should be the primary target, but IP policies should also make it possible for the center to approach industry about tool commercialization. Finally, where appropriate, it should be possible for other tool developers to acquire source code in order to extend, enhance, or integrate the center's product into other tools and environments. Given the generally poor understanding of IP issues among the tools research community, one role of the center should be the dissemination of practical information to researchers on how they should document ownership of software. Ownership 1. In submitting a software project proposal to the center, the author(s) must furnish all relevant IP information, including: (a) a clear ownership "audit" indicating all persons or agencies involved in design or development, up to the point where software arrives at the center; and (b) any restrictions on distribution that would be imposed by the submitters, their funding agencies, or other authors whose work is included in the submitted software. Proof of IP ownership will be necessary before the center can enter third-party agreements with groups to commercialize the software. It may also be important in case of disputes over the origins or ownership of software distributed to the user community or developers of derivative works. Since distribution is the motivation for establishing the center in the first place, it simply does not make sense to accept software whose ownership can be disputed. Any restrictions whatsoever on software use - including licensing fees, mandatory registration or tracking of users, royalties, copyleft, limitations on source code distribution, profit splits in the event of future commercialization of the software, etc. - may hinder the center's ability to use the results of projects. In general, we recommend that accepted software be free of any restrictions, although there may be occasions where one or more of the software components are subject to some conditions (see ownership profile). If the submitted software makes use of components from other authors, these may be subject to more stringent restrictions (in the case of copyleft, the software in which such a component is embedded is also subject to restrictions). It may be desirable to eliminate such elements prior to accepting the software as a center project. 2. Before accepting submitted software, the center will negotiate the specific conditions for transfer of rights with the author(s). Clearly, the most useful negotiated agreement would be for the center to have unlimited redistribution (subject to export regulations, of course). However, since research prototypes often make use of components furnished by other parties, some types of distribution or redistribution may be precluded by agreements already in effect. Any limits that original authors or their agencies will impose on redistribution, licensing, registration, etc., must be specified and agreed upon at this point - prior to accepting the software as a center project (see ownership profile). It should be made clear to the authors that no ownership agreement guarantees that the software will be released, or if it is released, that it will be supported or maintained by the center for any period of time. 3. Contracted staff should do all development work on center projects, so that ownership of new code or interfaces resides with the center. Such staff need not be permanent employees of the center, since work-for-hire still retains ownership for the center. 4. If software components are acquired by the center from other sources, they will be subject to similar considerations and procedures for managing ownership. Certain key components (e.g., a parser) may be acquired from third parties, not for refining but for use in other center projects. Such acquired components add a new thread of ownership and require an ownership audit and negotiated transfer of rights (see ownership profile). 5. The center will require software submissions to be in source form although it may restrict ultimate distribution to binary formats. The issues are too complex if the center is not supplied with source, or if the original author restricts the center's output to certain formats. Moreover, such arrangements are likely to preclude commercialization agreements. In the case of third-party suppliers of components, however, the center may agree not to distribute source code (see ownership profile). 6. The tools produced by the center will be distributed as licensed products in order to facilitate the acquisition of information on usage and adoptions. In general, the center should make use of the simplest licensing mechanism, "shrink-wrapped licenses," for non-commercial use of its software (commercialization is discussed separately). Tools that are hardware- or system-specific (e.g., those relying on information supplied by some profilers or compiler code generation) may raise specific problems for distribution. 7. In some cases, the center may allow third parties to redistribute its products; such distribution will be permitted for binary format only, and must involve no fees or special registration procedures. From the perspective of the user community, it would be desirable that computing centers (e.g., the NSF centers or national laboratories) be able to pre-build binaries for quick downloading. This may also be to the center's advantage, since it might off-load user support functions. One drawback is that the chain of user registration will be lost, as it is not feasible to require such users to register "backward" to the level of the center (see ownership profile). However, re-distributors will be asked to establish suitable mechanisms for tracking or estimating usage. In some cases, the negotiated agreement with the original author may preclude such re-distribution, or may impose additional restriction on how it may occur. 8. If a center product is released for commercialization, a separate agreement regarding ownership will be negotiated with the new party. It is reasonable to expect that the center might be able to recoup some of its costs by effectively selling some of its ownership rights. In most cases, however, such sales should not force discontinuance of the center's rights to distribute its product to the user community. That is, the commercial product should be considered a "new tool," owned entirely by the commercial developers, rather than a derivative work. In some cases, the negotiated agreement with the original author may preclude commercialization, or may impose additional restrictions on how it may occur. If a profit-split was specified in that agreement, the original authors may need to be included in the price negotiations. 9. Derivative works based on center products will be permitted (subject to appropriate credits) and may be distributed to any registered recipient of the original source work. This is intended to apply primarily to center output that can be distributed in source format (see ownership profile). If derivative use of binaries is to be permitted, special modification of the shrink-wrap license may be required to specify how attribution of credit is to occur. In some cases, the negotiated agreement with the original author may preclude derivative work, or may impose additional restrictions on how such derivatives may be distributed. Liability 1. In keeping with the current policies of most software vendors, the center will not accept liability for defects in judgment, engineering, use, etc. The now-familiar disclaimer of any responsibility whatsoever should be attached to all center output. Ethics 1. Acceptance of a prototype obligates the center to certain responsibilities toward the original software developer(s). In furnishing software to the center, the author is ceding direct control over its future, with the expectation that it will be prepared for release to a broader user community. Consequently, the center should periodically inform the author of the software's status. If a decision is made to drop a project, the center is obligated to inform the author as to why, and all rights (including any value-added) should revert to the author. If a decision is made to discontinue support of a completed, distributed project, the center is obligated to inform not just the author (with similar reversion of rights) but also the community of registered users, so that they have the opportunity to archive the last available version prior to its disappearance from the center's inventory. |
||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
|
Conclusions |
The group considered five alternatives for how a national center for software tools might operate, in terms of the IP issues and problems associated with each. Only one model appears appropriate, given the objectives of the original HPSST recommendations and the current national climate with respect to IP ownership and liability. The consensus was that it would be inadvisable to establish a center directed at testing the quality of software tools and making the results available freely to the general public. The lack of widely accepted testing and evaluation standards, and the associated liability issues, make it unlikely that any institution or organization would be willing to stand as publisher of the results. Restricting distribution of the test results to just the tool developers would eliminate most of those problems. However, the group deprecated this model on the grounds that the potential benefits for users would be seriously diminished, and that a private facility or consortium would be a more appropriate vehicle. A model focusing on actual tool implementation was rejected as superfluous, as this approach would replicate ongoing, peer-refereed programs by the HPCC agencies. A fourth model, where the center's output would be definitions of standards for software tools, was rejected as not meeting either the intent of the original HPSST task force or the needs of the tools research community. On the other hand, the group concluded that it would be possible to formulate IP policies that would allow the center to follow a fifth model, that of software "distillation" or "hardening." The center would acquire software in varying stages of development, refine and test it to ensure its robustness and suitability for HPC, and release it (not just to the user community, but also to potential adapters/extenders as well as commercializing groups). Examining this model, the group formulated a series of recommendations on how such a process should be structured to deal with IP issues. Due to growing concerns about software and its relationship to copyright and patent law, it is essential that the center insist on strict documentary evidence of ownership before accepting software from any development group, particularly when development involved multiple agencies. Most other aspects of IP can be negotiated on a case-by-case basis, although clearly the ideal situation would be software that the center can distribute or re-use freely, without the need for cascaded licensing or other restrictions. Nevertheless, the model presents some potential problems. For example, depending on rights agreements, the center may accumulate an inventory of components, each with a pedigree and new licensing agreements/restrictions. The licensing and ownership rights could end up being extremely complex. Is this self-defeating? Most importantly, would this work against the primary goal of getting tools into the hands of the user community (direct to users)? Another example is the problem of what responsibility the center might have toward the groups that contribute software. If long-term support and maintenance is expected, serious problems could arise when software becomes outdated or is superseded. In summary, the group felt that with a proper structure - and careful explanations to the tool development community - a center could be an effective mechanism for expediting the deployment of new tool technologies into the user and vendor communities. Special care, however, will have to be taken to ensure that IP complexities do not undermine the center's effectiveness. Charter Questions
|
||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||
