Australian Journal of Educational Technology
2003, 19(3), 339-355. 		AJET 19

Issues of intellectual capital and intellectual property in educational software development teams

Andy Williamson
UNITEC, Auckland
David M. Kennedy
Hong Kong Institute of Education
Carmel McNaught
Chinese University of Hong Kong
Ruth DeSouza
UNITEC, Auckland
Developing educational software requires a complex environment and a range of specialised skills. The ideas that lie behind successful software are drawn from a broad pool of talent and, as mobility increases, ideas are disseminated through informal and new work practices into a wider community. This paper addresses how participants in the development process can receive appropriate acknowledgement for their contribution, even after leaving a project. It will identify team dependencies and highlight three channels for dissemination (publication, portfolio and product). Eight common myths relating to intellectual capital and intellectual property in relation to educational software development are explored. Finally, practices that can be applied to the software development process to ensure that all team members receive appropriate recognition for their contribution to the product are identified. In particular, emphasis is placed on the need for strong project management practices and the up front articulation of expectations.

Introduction

The university's traditional role of teaching and research is expanding to include the development and transfer of technology products and skills. As a consequence, the norms and discourses of the business world are increasingly encroaching on academic life (Smyth & Hattam, 2000; Wood, 1992). At the same time, developing educational environments that incorporate information and communication technologies (ICTs) and interactive multimedia software (IMM) has become increasingly complex. The skills, resources and processes required to develop and manage these new innovative environments are increasing (Kennedy, 1998). An original and innovative educational idea that is poorly translated using technology seems just as likely to fail as a product that is poorly planned, based on flawed understanding, but technically well implemented. Successful development of today's complex educational environments that require ICTs or IMM components brings with it the imperative for an array of different and unique skill sets at the different stages of the project. However, just as product complexity has increased, so has workforce mobility. Academic staff members regularly and easily move between institutions; development and design staff have many opportunities for contract based work, move to other academic institutions, or into the private sector.

The ideas that lie behind a successful process or product are increasingly being drawn from a wider pool of talent, and, as people move around, these ideas are being taken with them and disseminated through informal and new work practices into a wider community. How then does a team formed to design and develop a technology rich educational environment manage and control issues of intellectual capital and intellectual property, such that all of those who contribute throughout the life of a project are acknowledged and rewarded fairly and appropriately for that contribution, even after they have left the project?

This paper is not concerned with ownership of the product of such activities itself, rather it is addressing the issue of how participants in a process receive appropriate acknowledgement for their contribution to the resulting product. To understand this, we will firstly discuss definitions of intellectual capital (IC) and intellectual property (IP), as they are created and assigned within software development teams in academic settings, reviewing how IC/IP issues emerge and could develop over a period of time. We will provide a brief history of the legislative frameworks surrounding IP and then identify some of the common myths regarding IC/IP and its dissemination within an academic community. Finally we will make recommendations as to how these myths might be corrected and suggest ways in which the contributions of team members can be appropriately validated within their own communities of practice.

Defining intellectual capital (IC)

Florida (2002) argues that the principal factors for successful software development are talent, knowledge and intellectual capital (IC). The connection of new ideas and existing knowledge within an organisational context leads to the creation of IC. Stewart (1999) defines IC as the sum of everything everybody in a company, organisation or team knows and which provides some advantage over their competitors. Davidson and Voss (2001, p. 60) agree, describing individual IC as "the sum of individual imagination, intelligence and ideas". They then extend this definition to encapsulate a model for organisational IC that is based on the talent of individuals (human capital), the knowledge that is captured within systems and processes (structural capital) and the characteristics of relationships with customers and suppliers (customer/ supplier capital). Organisational IC comes from the "interplay of all three (structural capital augments the value of human capital, leading to an increase in customer/ supplier capital)" (p. 61). In terms of this discussion as it relates to the appropriate recognition and acknowledgement of individual contributions within software development teams, human capital is our primary focus. Human capital is "what walks out of the door at the end of the day" (p. 68); it is a vital intangible.

Defining intellectual property (IP)

If IC is the intangible but invaluable contribution of human talent to a project, then IP is a formal measurable subset. It is the tangible product that results from the idea. The UK Patent Office (United Kingdom Patent Office, Undated-b) defines four formal types of IP: This definition is then extended to cover a much broader and often more intangible grouping that extends to trade secrets, plant varieties, geographical indications and performers rights. Whilst many see copyright as a way of protecting IP, it is only a subset. Copyright provides recognition of their invention to the creators of software or multimedia products in order for them to be able to obtain economic rewards for their efforts (Macmillan, 2000). Historically, comparisons have been drawn between software development and the traditional arts, such comparisons re-enforcing an argument that IP law is focused on the protection of software such that others are not able to modify the source product (White, 1997).

It is important to note that copyright extends only to a tangible product, it does not lend protection to the more intangible areas of IC such as ideas and individual contribution. Since copyright has a primarily commercial imperative it is a limited and perhaps inappropriate mechanism for acknowledging contribution. This is of greater importance in higher educational settings since copyright of educational materials can reside with the institution (particularly with off campus courses), rather than the individual, and very few educational software products developed for specific content domains in higher education are ever commercialised (Alexander, McKenzie, & Geissinger, 1998).

The relationships between the tangible elements of intellectual property and the three forms of intellectual capital (the intangible organisational assets) discussed in the preceding section are shown in Figure 1.

Figure 1

Figure 1: Intellectual capital and intellectual property

Legislative frameworks

Whilst this paper does not take a legalistic approach to IP/IC, this section will provide a brief overview of the generic legislative frameworks pertinent to Australia, New Zealand, the United Kingdom, Canada and the United States. As signatories to the Berne Convention, these countries are obliged to take into account standardised and internationally accepted definitions of intellectual property. Furthermore, IP law in these countries is derived primarily from English law. This evolved as a legislative framework for IP to encourage the creation of new inventions and new works of authorship. Founded in this English tradition, the copyright and patent laws are designed to benefit society as a whole by providing incentives to creators (Haynes, 1999).

UK copyright law dates back to the Licensing Act 1662, with the ratification of the Berne Convention taking place through the International Copyright Act 1886. The Copyright Act 1956 is the now augmented by the Copyright, Designs and Patents Act 1988. The 1988 Act providing a major overhaul of copyright law, a process that continues through minor amendments and the implementation of European Union directives (United Kingdom Patent Office, Undated-a). Patent law in the UK dates back to the Statute of Monopolies of 1623, now coming under the Patents Act 1977. This Act has itself been substantially amended by the Copyright, Designs and Patents Act 1988. The 1977 Act provides a complete definition relating to patent validity and infringement and defines the law of property in patents and patent applications (R.G.C. Jenkins & Co, 2003).

Australian Patents are covered under the Patents Act 1990-91 and subsequent amendments. New Zealand and Canadian intellectual property law ostensibly follows the same form as the British and Australian legislation. US legislation also tends to be similar in nature (for example, Copyright Act 1976). The most visible difference in US law is the controversial Digital Millennium Copyright Act 1998, which sets out to bring intellectual property law in line with current technologies. The US has also been the source of much case law relating to copyright and patent misuse (including anti-trust legislation), where statute is offset by judicial review that aims to manage "the careful balancing of the rights granted to creators with the rights retained by the general public" (White, 1997, p. 3).

Copyright in Australia is controlled by the Copyright Act 1986, with further refinement of the definitions relating to computer software emerging in the Copyright Amendment Act 1984, at which point 'computer programs' were explicitly defined (Copyright Law Review Committee, 1995). Specific changes relating to the protection of electronic media, which primarily means web based or electronically distributed content, are defined in the Copyright Amendment (Digital Agenda) Act 2000.

Inherent in legislation is the concept of 'fair dealing', or 'fair use'. This is the replication of copyrighted material for a limited and 'transformative' purpose, such as for the purposes of critical review or academic usage, including research and study. 'Fair use' can be seen as a legal defense against copyright infringement, however it is open to legal challenge and judicial review (White, 1997). In particular, where unpublished work is copied or cited the interpretation of fair use is likely to be narrower. This is based on the original authors having the right to control the first public appearance of their own work and that premature disclosure could adversely affect the marketability or commercial potential of IP (Stanford University Libraries, 2003).

Team formation and relationships

ICTs and IMM are playing an increasingly important role in the education sector. Just as their use has increased, so has their complexity. Increasingly there is a requirement within software development projects for highly specialised roles (Brooks, 1995; Pressman, 1992). As the complexity of a project increases, so does the specialisation required (Jacobson, Booch, & Rumbaugh, 1998). These new ways of working bring with them a shift in power, whereby the formally 'expert' academics are no longer likely to have sufficient technical skills, time or resources to turn their ideas into reality. Instead they rely on a team of experts from other disciplines to interpret ideas, evolve them and deliver the finished product. As complexity increases, communication between team members becomes paramount and specialist educational designers are required to translate pedagogy into functional specifications that can be understood by software developers and graphic designers. In such an environment, teams are project based and resources come and go as their skills are required. As the complexity of delivery models and teaching tools increases, the importance of the non-academic roles increases significantly.

Roles and responsibilities will vary depending on the toolset and architecture used, the size of the project and the culture of the organisation. Today's educational software development team now consists of a variety of specialist roles, such as:

These roles can be performed by academics, non-academic staff and students, depending upon the size and complexity of the project. Project team members can be full or part time employees (academic or non-academic) or contractors retained specifically for the project. As such these roles exhibit complex relationships and interfaces between each other and the project. In Figure 2 the range of possible roles in a project team are shown. The metaphor used to show the intersection and potential interaction of the team members is done by the use of overlapping shaded zones. While other interactions are possible (for example, the IT support team member may be a member of the core development team, or the educational designer may also be the project evaluator), the relationships shown are typical of many projects in higher education.

Figure 2

Figure 2: Intra-project relationships (derived from Williamson, 2001)

Assuming that the individuals fulfilling these roles are career-focused (in terms of their own field of endeavour) and are looking to gain more than an immediate short term reward for the work they are doing, it is worth considering how each of these roles seeks recognition in terms of career growth and promotion from such a project. The academic path is quite straightforward and is characterised by the need to publish. However, for other roles within the project it is less clear cut.

We have chosen to identity three primary sources of acknowledgement for the IC/IP of team members, based upon a typical requirement for a job application or demonstration of expertise, knowledge and understanding for each team member. These sources are publication, portfolio and product. While there is certainly the potential for individuals to derive benefit from all components, the skills and knowledge represented by the three sources above tend to be associated with particular career choices, educational background and professional recognition.

In academia at least, there is a strong incentive to focus on the dissemination of our activities via scholarly publication in journals and at conferences. However, with the diversity of skills come conflicting values and expectations and it is important to understand how more commercially focused non-academic team members might expect to benefit from their involvement (Wood, 1992). For them, other forms of recognition become more critical. The portfolio is more likely to apply to those involved with the visual components of a project. Product refers to the kudos (or career boost) received from association with a successful or widely recognised development project and is likely to be associated with a software developer or project manager. In terms of the roles we identified above, we suggest that the primary source of acknowledgement for each are those shown in Table 1.

Table 1: Primary source of acknowledgement by role

RolePublicationPortfolioProduct
Editor

tick
Educational designer tick

Evaluator tick

Graphic designer
tick
Interface designer
tick
Other media specialists
(video, audio, print)
tick
Programmer

tick
Project manager

tick
Subject matter expert tick

Why acknowledgement of IC is an issue

The identification of three dissemination channels in Table 1 highlights the existence of different communities of practice. It identifies that it is important for members of each community to promote and receive recognition for their work in ways that are appropriate to that community. As software development teams become increasingly diverse, the academic publication is no longer the sole method of dissemination for educational technology projects, if it ever was.

We need to be aware of the different communities of practice that exist in our field and ensure that the role of individual team members is able to be promoted appropriately in these areas. However, this raises the serious question of how do we define an original contribution to knowledge and in what way should this be formally recognised (acknowledging that there is always the likelihood of receiving acclaim by association with a successful project). For example, in academic writing we would not consider a literature review to be an original contribution to knowledge but creating a framework from the literature review is an original contribution, whilst a programmer would be likely to receive greater affirmation if their work was derivative, rather than being based on reusable software templates. It is also important to understand not only the nature of the contribution but how substantive that contribution was when assessing the acknowledgement of intellectual property. Again using an academic example, the authoring of the paper is obviously a substantive contribution to that piece of work but editing it is not and the editor would not expect to be recognised as an author on the paper.

Eight myths of educational software development

We have so far established definitions of IC and IP and gone on to define complex relationships and structures in today's software development teams. Linking these two points, we have determined that IC and IP are important issues for developers of educational technology. Whilst this might appear obvious, there are a number of myths that perpetuate about the acknowledgement and allocation of IC/IP within software development teams. In the next part of this paper we will describe some of these myths and then conclude by offering some suggestions and strategies for a way forward that recognises the rights of individuals to be acknowledged for their intellectual contribution to a project.

Myth 1: All team members can take credit for all aspects of the product

In highly successful projects, a strong team dynamic arises in which the expertise and knowledge of individual team members can be communicated and shared with other members of the team. However, specific responsibility for the instantiation of the ideas will remain with the 'expert' team member. For example, the academic will be responsible for the content while the graphic designer produces the interface look and feel. Although a graphic designer might offer educational advice (often gained from working in many projects), the responsibility for the decision to include or exclude that suggestion resides with either the subject matter expert or the educational designer. Conversely, the academic may have a particular view or requirement for the subject matter and provide extensive documentation and examples to guide the graphic designer's processes.

Myth 2: Non-academics don't care about IC/IP

The academic focus on publication leads us to consider that non-academic members of the team (those that tend not to publish and might therefore be perceived as having no interest in publishing) have no interest in the IP of the product being developed or in receiving reward or acknowledgment for the IC that led to the creation of that IP. As we have seen, this is not true. Rather, members of those communities demonstrate competency and success in different ways, depending upon the specific community of practice. As software becomes more complex, it becomes less and less likely that the original academic imperative that led to the idea for the product will be instantiated in a form initially envisaged by the academic. The development process and the end result will be strongly influenced by a wide range of individual and group contributions to the process and the product.

It is worth considering the role of the non-academic in generating IP in that, whilst their activity might not lead directly to authorship of an academic paper, without this involvement the academic would not be in a position to author such a paper. This leads to consideration of who should be attributed with authorship of a written paper and, therefore, by association with creation of the IP (Cameron, 1998).

Myth 3: When a person leaves a team they cede their IC to the project team/ group or institution

Whilst formal IP might remain, ideas are not lost when team members move on either during or on completion of a project and it is unrealistic to expect ideas to remain behind unused. This becomes a very critical issue for the affirmation process since much software developed today lives behind a password protected firewall and higher education institutions are unlikely to grant permission for non-employees to access such materials. The matter is even further complicated by the copyright or 'ownership' of such educational materials by a faculty or department - in many cases team members are denied access once the materials are in use because they are not members of the unit.

Myth 4: If the organisation or institution owns the IP then the institution also owns the IC

This misconception is perhaps aligned with the naïve assumption that a product and an idea are inseparable. As we saw in the definition of IP, products can be protected by copyright or even patents because they are tangible. For example the plethora of online courseware engines available today means that academics in many institutions with off campus courses can retain their content if they move to another institution. Even though the physical materials themselves might be copyrighted to the organisation, the IC is not.

Of course, universities are relatively new to the world of intellectual property policy. Castagnera, Fine and Belfiore (2002) examined the Faculty Appointment Policy Archive, a database of 241 randomly selected university employment policies or collective bargaining agreements in the US compiled by the Harvard Graduate School of Education. They found a low occurrence of IP policies - at or below 20 percent of the sample, but noted that this situation is likely to change rapidly in the near future. The next few years will see increasing discussion about and formal clarification of IC and IP policies.

Myth 5: A software product is different to a written paper for the purposes of critical review

This myth is clearly exploded by reviewing the literature and legal precedence relating to IP and, in particular, copyright. Software and multimedia are tangible products and are very clearly included within the definition, just as written works are (Macmillan, 2000).

Myth 6: The project director is always first author

Macmillan's (2000) review of IP issues in academic software development identifies that collaborative projects can result in multiple IP ownership and that IP can also be held not only by individuals but also by the individuals' employer(s). As Hamilton, Greco, & Tanner (1997) observe, research projects are often undertaken in a collaborative way by academics who, as individuals, would be unlikely to be able to complete such complex projects. The potential synergy of such collaboration is obvious and it is likely that those team members who function within the academic system would be keen to be associated with the publication of academic papers on a project that they have been involved with. The research done by Hamilton et al. (1997) indicated that the majority of academics in their study would find it unethical to be cited as an author of a paper that they did not directly contribute to. Indeed, in academic publications derived from research activity, the issues of authorship and attribution are reasonably clear cut. For example Murdoch University's guidelines on joint authorship state that "the minimum requirements for authorship of a publication should be in participation in conceiving, executing or interpreting at least part of the research reported." (2002, p.1). The equivalent policy at the University of Massachusetts is strikingly similar:
It is taken for granted that whenever a scholarly work is distributed or published, its authorship truly reflects the contribution of all who deserve to be included, and it is the responsibility of the faculty member in charge, or any other person in such a position, to guarantee that fairness is exercised in listing the authors. (University of Massachusetts, 1990, p.1)

Myth 7: Citing unpublished work is sufficient to acknowledge IC/IP

Citation or acknowledgement of unpublished work or work not publicly available is sufficient to acknowledge IC and IP issues in a publication. In the case of an academic where affirmation and professional career progress is at least partially a result of publication, this is clearly not sustainable. A graphic artist, on the other hand, has their portfolio of work with iterations of visual designs that they take with them to the next project or job. The publication is less important or substantive in career development.

From a legal perspective, the citing of unpublished work could potentially be seen as outside the bounds of 'fair use' if it in any way disadvantages the original author (Stanford University Libraries, 2003).

Myth 8: Ideas are forever

Not only does a piece of software have a shelf life, the IC that led to that product is also of limited use. The idea will become superseded and outdated as new ideas and new technologies emerge. As academics, it is necessary to publish and disseminate our ideas and, if this is to be of relevance and interest, then it must be done within a reasonable time frame. Simply put, what we do is perishable in terms of getting it to market and there is a limited time to publish if ideas are to have any perceived value. This shelf life is likely to be considerably extended if your source of acknowledgement is a portfolio or product, in much the same way as the paper, once published, can remain valuable.

The way forward

We have so far presented a brief overview of the issues surrounding IC and IP in educational software development and then described eight of the myths that persist in relation to the acknowledgement of IC. It is our belief that these myths are perpetuated because the processes in place to manage software development teams are often not clearly defined, working well initially but failing to consider what happens if team members leave or things go wrong during or after the project.

Given the critical value of IC in software development (Florida, 2002), our overarching recommendation is for a tightening of the process of educational software development through the adoption of a strong project management framework. Project management is a key role in any ICT or IMM project and it requires specific skills and attributes. These include both the 'hard' skills of contract negotiation, budgeting, scheduling, project definition and scoping as well as the 'soft' skills of human relations, team building and facilitation (Burdman, 2000; Schwalbe, 2000). Successful teams work well together because they have clear roles and relationships and because the terms of engagement within the team and with external parties are well defined, understood and agreed by all. It is recommended that there is explicit incorporation of IC and IP issues into the project documentation and that this is considered early on, preferably during the project scoping phase.

This leads to our second recommendation, which is that there is a clear, up front negotiation of roles, responsibility and ownership of both tangible and intangible outputs from the project. This recommendation does not pre-judge what that ownership might be, merely that the agreement takes place before the project commences. Just as it is important to clearly articulate roles and responsibilities it is equally important to consider how IC/IP generated during the project's life will be disseminated, in what form and by whom.

An excellent example of good team definition and scoping is demonstrated in the 'Integrated Project Development Team Model' used by LearnCanada (2002), although it is noted that even this model does not extend to formal dissemination of results, other than for internal reporting purposes. This clear articulation of roles and responsibilities also has the benefit of helping to make the process of dissemination more visible than it might otherwise be. This can occur from conceptualisation of the original proposal, to joint production, to brainstorming and mapping, to theorising and detailed analysis of the project (Smyth & Hattam, 2000). In making this activity visible it is hopefully also the case that team members will recognise the significance of the different sources of acknowledgement. This in turn will hopefully result in up front agreement on potential opportunities for dissemination of original ideas amongst the team.

Our final recommendation is that processes are put in place to ensure that the project is carefully documented, since documentation provides a critical link to the contributions made by individual team members. Careful version control of all design and specification documents, and careful filing and archiving is an essential part of effective project management. Appropriate documentation is essential in validating the originators of IC, for confirming the IP rights, and settling any possible misinterpretations or disputes about IC or IP.

Conclusion

ICT and IMM products are increasingly complex, drawing on a team based approach of academics and ICT/IMM professionals. The importance of a successful project to the career development of individuals cannot be underestimated and it is important to recognise appropriate channels for recognition and dissemination, such as those we have identified earlier (publication, portfolio and product). It is also important to ensure that academic dissemination of successful projects through publication recognises the contribution made by all team members, including the non-academic members.

Many myths persist in relation to acknowledging the veracity of contribution with regard to educational software, and these often have the potential to leave team members feeling that their effort and ideas have gone unrecognised, and at worst that they have been exploited. We have promoted a number of simple strategies for overcoming this problem, primarily revolving around the need to introduce appropriate project management practices, and a transparent process that includes a holistic and up front negotiation of expectations regarding acknowledgement of contribution, and the appropriate dissemination of IC and IP. We believe that by following good project management practices and ensuring that discussions are open and up front many of the potential problems associated with IC and IP can avoided.

References

Alexander, S., McKenzie, J., & Geissinger, H. (1998). An evaluation of information technology projects in university learning. Canberra: Australian Government Publishing Services: Department of Employment, Education and Training and Youth Affairs.

Brooks, F. P. (1995). The mythical man-month: Essays on software engineering. Reading, MA: Addison-Wesley.

Burdman, J. (2000). Collaborative web development: Strategies and best practices for web teams. Reading, MA: Addison Wesley.

Cameron, E. (1998). Structure and the classics: The joint authoring of computer products. International Review of Law, Computers & Technology, 12(3), 547-555.

Castagnera, J. O., Fine, C. R., & Belfiore, A. (2002). Protecting intellectual capital in the new century: Are universities prepared? Duke Law and Technology Review, 0010 [viewed 22 Jul 2003, verified 24 Jul 2003] http://www.law.duke.edu/journals/dltr/articles/PDF/2002DLTR0010.pdf

Copyright Act 1956, HM Government (1956).

Copyright Act 1968, Commonwealth of Australia (1968). http://www.austlii.edu.au/au/legis/cth/consol_act/ca1968133/, http://scaleplus.law.gov.au/html/pasteact/0/244/top.htm

Copyright Act 1976, 17 No. 94-1476 US Code (1976).

Copyright Amendment (Digital Agenda) Act 2000, Commonwealth of Australia (2000). http://scaleplus.law.gov.au/html/pasteact/3/3509/top.htm

Copyright Amendment Act 1984, Commonwealth of Australia (1984).

Copyright Law Review Committee (1995). Computer Software Protection. Canberra, ACT: Attorney-General's Department.

Davidson, C., & Voss, P. (2001). Knowledge management: An introduction to creating competitive advantage from intellectual material. Auckland, NZ: Tandem.

Digital Millennium Copyright Act 1998, Pub. L. No. 105-304, 112 Stat. 2860 US Code (1998).

Florida, R. L. (2002). The rise of the creative class: And how it's transforming work, leisure, community and everyday life. New York, NY: Basic Books.

Hamilton, J. B., Greco, A. J., & Tanner, J. R. (1997). Ethical questions regarding joint authorship: Business and non-business faculty perceptions on non-contributing authorship. Journal of Education for Business, 72(8), 325-330.

Haynes, M. A. (1999). Commentary: Black holes of innovation in the software arts. Berkeley Technology Law Journal, 14(2). [viewed 22 Jul 2003, verified 24 Jul 2003] http://www.law.berkeley.edu/journals/btlj/articles/vol14/Haynes/html/reader.html

International Copyright Act 1886, HM Government (1886).

Jacobson, I., Booch, G., & Rumbaugh, J. (1998). The unified software development process. Reading, MA: Addison Wesley Longman.

Kennedy, D. M. (1998). Software development teams in higher education: An educator's view. In R. M. Corderoy (Ed.), Flexibility: The Next Wave? Proceedings of the 15th Annual Conference of the Australasian Society for Computers in Learning in Tertiary Education (ASCILITE). Wollongong, NSW: University of Wollongong. http://www.ascilite.org.au/conferences/wollongong98/asc98-pdf/kennedyd.pdf

LearnCanada (2002). Integrated project development team model. [viewed 13 Dec 2002, verified 24 Jul 2003] http://www.learncanada.ca/management.php

Licensing Act 1662, HM Government (1662).

Macmillan, F. (2000). Intellectual property issues. In C. McNaught, P. Phillips, D. Rossiter & J. Winn (Eds.), Developing a framework for a usable and useful inventory of computer-facilitated learning and support materials in Australian universities. Evaluations and Investigations Program report 99/11. Canberra: Higher Education Division Department of Employment, Education, Training and Youth Affairs. http://www.dest.gov.au/archive/highered/eippubs/eip99-11/developframework.pdf

Murdoch University (2002). Guidelines on joint authorship for academic staff and postgraduate research students. [viewed 9 Dec 2002, verified 24 Jul 2003] http://www.research.murdoch.edu.au/management/guidelines/jntauth.asp

Patents Act 1977, HM Government (1977).

Patents Act 1990, Commonwealth of Australia (1990). http://scaleplus.law.gov.au/html/pasteact/1/545/top.htm

Pressman, R. S. (1992). Software engineering: A practitioners approach (2nd ed.). New York: McGraw-Hill.

R.G.C. Jenkins & Co. (2003). UK Patent Law. [viewed 22 Jul 2003, verified 24 Jul 2003] http://www.jenkins-ip.com/patlaw/intro.htm

Schwalbe, K. (2000). Information technology project management. Cambridge, MA: Course Technology.

Smyth, J., & Hattam, R. (2000). Intellectual as hustler: Researching against the grain of the market. British Educational Research Journal, 26(2), 157-175.

Stanford University Libraries (2003). Fair use. [viewed 22 Jul 2003, verified 24 Jul 2003] http://fairuse.stanford.edu/Copyright_and_Fair_Use_Overview/chapter9/

Stewart, T. (1999). Intellectual capital: The new wealth of organizations. New York, NY: Currency.

United Kingdom Patent Office (Undated-a). A history of copyright. [viewed 22 Jul 2003, verified 24 Jul 2003] http://www.intellectual-property.gov.uk/std/resources/copyright/history.htm

United Kingdom Patent Office (Undated-b). What is intellectual property or IP? [viewed 12 Dec 2002, verified 24 Jul 2003] http://www.intellectual-property.gov.uk/std/faq/question1.htm

University of Massachusetts (1990). Policy statement on joint authorship at the University of Massachusetts at Amherst. Amherst, MA: University of Massachusetts.

White, J. A. D. (1997). Misuse or fair use: That is the software copyright question. Berkeley Technology Law Journal, 12(2) [viewed 22 Jul 2003, verified 24 Jul 2003] http://www.law.berkeley.edu/journals/btlj/articles/vol12/White/html/reader.html

Williamson, A. (2001). INSITE: Information Architecture Web Services Methodology. [viewed 13 Dec 2002, verified 24 Jul 2003] http://www.wairua.com/docs/insite.pdf

Wood, F. Q. (1992). The commercialisation of university research in Australia. Comparative Education, 28(3), 293-313.

Authors: Andy Williamson
Centre for Information Technology Research
UNITEC, Auckland, New Zealand
awilliamson@unitec.ac.nz

David M. Kennedy
Department of Information and Applied Technology
Hong Kong Institute of Education, Hong Kong
kennedy@ied.edu.hk

Carmel McNaught
Centre for Learning Enhancement And Research
Chinese University of Hong Kong, Hong Kong
carmel.mcnaught@cuhk.edu.hk

Ruth DeSouza
School of Health Science
UNITEC, Auckland, New Zealand
rdesouza@unitec.ac.nz

Please cite as: Williamson, A., Kennedy, D. M., McNaught, C. and DeSouza, R. (2003). Issues of intellectual capital and intellectual property in educational software development teams. Australian Journal of Educational Technology, 19(3), 339-355. http://www.ascilite.org.au/ajet/ajet19/williamson.html

[ AJET 19 ] [ AJET home ]
HTML Editor: Roger Atkinson [rjatkinson@bigpond.com]
This URL: http://www.ascilite.org.au/ajet/ajet19/williamson.html
Created 14 Nov 2003. Last revised 14 Nov 2003.
Page access count