IP Issues Related to Computer Software

I.          Scope of this paper

Photo by Sergey Nivens/iStock / Getty Images

Protecting and commercializing software calls on a host of different areas of law. Statutory and common law forms of property rights are used to protect the software. Employment law is referred to in determining the legal status of the relationship between the developer and its workers, and the client and software developer, important when determining ownership. Sale of goods legislation (the Uniform Commercial Code in the United States of America) can apply when determining the extent of the warranties that a vendor of software has made. Trade legislation can apply, for example, if for some reason the U.S.A. feels that the software is being exported from that country and contains "secrets" such as encryption devices, the export of which is prohibited. Entertainment law (as a sub-set of copyright law) is called on when dealing with multi-media content. The law relating to damages and economic loss can apply in the event that software is faulty. And so on.

Computers are having a profound impact on the way people work and communicate. Ownership of data bases and privacy rights are only two examples of issues that people are having to deal with as a result of this. Rapid technological change, building on the ideas of others, has resulted in an explosion of licensing.

The intention of this paper is to provide a reference to some of the issues that a general practitioner might encounter when acting for start - up and growing companies (which software companies are by definition). There is no intention to provide an analysis of the various areas of law. The paper makes two limited exceptions to this - it includes a brief introduction to the law of copyright, and provides a more extensive description of the applicability of the Freedom of Information and Protection of Privacy Act (B.C.). This latter act not only affects conventional intellectual property rights, but will likely be used as a tool by business in an increasingly competitive business environment. It will also have a significant impact on how data is managed, and who has access to it.

Software related issues in British Columbia most frequently relate to the development of tools to be used for the development of applications (particularly multi-media applications today), and the development of custom applications. While in relative terms some of the software companies in British Columbia mass market their software, when compared to software developers in the U.S.A., their market penetration is small.

The significance of this is that the majority of transactions are recorded in contracts. This gives parties the opportunity to clearly set out their agreements in ways that are enforceable and avoid the pitfalls they might otherwise fall into.

This paper is intended to high light issues that can be avoided by contract.

II.        Software protection

A.        Protection strategies

More than one form of intellectual property protection is available to protect software. Most of the alternatives are statutory, and one major type, trade secrets, is based on the common law. The forms of protection can exist simultaneously, and an effective strategy the software will weigh the advantages of each form of protection against the peculiarities of each product and the market place that it will be sold in.

Because the law in Canada differs from the U.S.A., caution is advised when reviewing case law and commentaries about some aspects of copyright.

This paper is confined to Canadian law.

1.         Copyright

Copyright is the main form of protection relied on by owners of software.

Reference is made to the paper with this material entitled "Application Procedures to Secure Intellectual Property Protection" for a discussion of the advantages of registering ownership of a copyright. Registration is simple and inexpensive. Additionally, there is no requirement in Canada to deposit a copy of the work. There are regulations in the U.S.A. governing the deposit of computer programs, which is required in order to obtain registered protection in the U.S.A.

Copyright protection is statutory, a matter of federal jurisdiction and arises out of the Copyright Act, R.S.C., 1985, C-42 as amended.

Canada is also a party to two international conventions. The most important is the Berne Convention. The principle purpose of this convention is to prescribe a minimum standard of copyright protection. Member states are free to extend the scope of protection beyond this. The convention is based on three main principles - automatic protection, equal protection of foreigners and independence of protection.

Because the practise in Canada is to incorporate the terms of international conventions in our statutes, the Copyright Act should be referred to for the applicable provisions enacting the provisions of this convention - for example, section 5. The Berne Convention is often referred to by our courts when interpreting the Copyright Act.

The second convention, the Universal Convention has little practical affect as it was designed to encourage the U.S.A. to become a signatory to the Berne Convention.

It is not necessary to mark works with a copyright notice. If marking is used, the effect of it is to obtain the additional protection that is afforded signatories to the Universal Copyright Convention. This includes the right to statutory damages and attorneys fees, and the fact that registration has some evidentiary weight.

If the owner chooses to mark the work, the marking must consist of three elements - the copyright symbol, followed by the year of first publication, and the name of the owner of the copyright. It is insufficient to substitute (c) for the copyright symbol ©, and it has been questioned if an hexagonal box around the letter "c" is sufficient. Regulations of the United States Copyright Office set out the requirements for affixing notice to computer software.

With permission, an introduction to the law of copyright extracted from a paper prepared by Catherine D. Mutala for a conference held in Vancouver, B.C. hosted by Pacific Business & Law Institute in January 25, 1995 is attached to this paper.

2.         Patent

It is beyond the scope of this paper to do more than highlight the availability of patent protection for certain aspects of software programs.

Developers are increasingly looking to patent protection for their software. Interestingly, the U.S.A. Patent Office reopened a patent granted to Compton's with respect to a search engine, and retracted the grant.

3.         Trade secrets

Trade secret protection arises at common law. In the U.S.A., there is also a significant degree of statutory protection. This is important, because if one intends to rely heavily on trade secret protection in the U.S.A., reference should be made to the applicable legislation.

The essential characteristics of a trade secret are that the information has some value to the person possessing it, the information cannot be widely known, and some effort has been made to keep the information confidential. Information which attracts trade secret protection can also attract other forms of statutory intellectual property protection, such as patent, copyright and industrial design.

Trade secrets are not property rights per se. Once the information has been disclosed, it cannot regain its status as a trade secret. Disclosure can be inadvertent, and can arise out of everyday business activities such as contracting out research, discussions with potential business partners, representations to financing institutions, and contracting for the development of custom software.

The Canadian case of Lac Minerals v. Corona, decided by the Supreme Court of Canada, is an excellent starting point for reviewing the law relating to the misappropriation of confidential information.

Often, trade secret protection is given little consideration as a tool for protecting computer software. Having said that, the most jealously guarded secret of any software developer is its source code. Interestingly, Novell is the only distributor of mass distributed software that includes in their licenses reference to the fact that their source code is a trade secret. Their license obligates the licensee to take reasonable steps to protect the software and documentation from unauthorized copying.

Software has been widely recognized in the U.S.A. as attracting trade secret protection. This is particularly important with respect to the internal engineering and design of the software.

The issue of the availability of this protection arises more often with respect to widely distributed commercial software. This is because opponents of the concept of trade secret protection argue that the information is readily available. The argument is based on the premise that it is legally possible to dissemble or decompile software, because copyright law does not prevent this, and because of the ineffectiveness of shrink wrapped licenses. The internal engineering and design is then readily available through this reverse engineering.

It has not been decided with any degree of certainty whether reverse engineering is a breach of copyright in Canada, and there is a fierce debate in the U.S.A as to whether reverse engineering represents a breach of the law of copyright.

It is usual, however, to restrict through contract the right to reverse engineer software whether or not it is mass marketed.

Because employees often know more about a company's trade secrets than the owners, it is common, and recommended to provide for trade secret protection in an employment contract.

4.         Integrated Circuit Technology Act, S.C. 1990, c. 37

This form of protection is mentioned because some developers are considering "hard" coding their software into micro chips. To the extent that they do, the topography of the chip might also be important assuming that their design is original. This is in addition to any patent protection that may apply with respect to any new invention which might exist in the chip.

Quoting from the Regulatory Impact Analysis Statement with respect to this legislation:

"While certain aspects of this technology can be awarded protection under the Patent Act, it does not provide adequate protection for the design. There is also, in the international arena, general consensus for the need for the protection of integrated circuit (IC) topographies which goes beyond existing intellectual property (IP) legislation. ...Registration extends to the layout design of the topography or the layout design incorporated in an IC product (semi-conductor chip) or an intermediate form."

Registration gives the holder the exclusive right to reproduce, manufacture, and import or commercially export the topography or an integrated circuit product that incorporates the topography - s. 3(1).

The act provides for protection to the end of the tenth calendar year after the earlier of the first commercial exploitation or the date of filing.

Filing is easy and inexpensive.

III.       Copyright

A.        Introduction

Section references in this part refer to the Copyright Act.

By way of summary, copyright is the main property right arising out of the creation of software. Copyright protects the way in which an idea is expressed - it does not protect the idea itself. For example, George Lucas was unsuccessful in his claim that the television program "Battlestar Gallactica" infringed his copyright in "Star Wars".

It arises automatically, although there can be advantages to registering ownership. Generally, copyright lasts for the life of the author plus fifty years - section 6. Where the identity of the author is unknown, copyright subsists for the lesser of fifty years from publication or 75 years from creation - section 6.1. Traditionally, copyright protection of software has followed the rules governing literary works, although a separate body of rules is developing.

Copyright protection bestows on the owner the exclusive right to make copies, and to prevent others from making copies - section 3(1). A further right was added in 1993 when section 3(1)(h) was included reserving to the owner the sole right to rent out a computer program. The leading Canadian case dealing with infringement was recently decided in British Columbia.

Copying for research, private study, criticism, review or newspaper summary is permissible, but the right is very limited - section 27. Some commentators in the U.S.A. would have one believe that the right is broader than it is.

A limited exception exists permitting copying for purpose of backup - section 27(2)(m). A less relevant exception allows the adaption or modification of a computer program to allow it to run with a particular computer - section 27(2)(l).

This paper does not deal with the complicated issue of what is copyrightable and what is not.

B.        Rules governing ownership

A number of general rules apply regarding ownership. Fortunately, all of these rules can be modified by agreement.

1.         Employee versus work for hire

The author of a work is the first owner of the copyright - section 13(1). The exception to this is when an employee creates the copyright, the copyright then belongs to the employer - section 13(3). Notwithstanding this, it is common to include in an employment agreement confirmation of the employers property rights.

If a consultant or outside contractor creates the software, the copyright belongs to the contractor, as section 13(3) does not apply. Copyright law relies on the same tests as employment law to determine the nature of the relationship - whether it is a contract of service (employment) or a contract for services (independent contractor).

If an author creates a work on her own time, outside of working hours, without direction from the employer, it is doubtful that the employee is working within her contract of service, and the copyright would belong to the employee.

2.         Working for the Crown

A provision of the Copyright Act provides that copyright in works prepared for Her Majesty belong to the Crown - section 12.

3.         Restrictions on transfer

When taking an assignment of a copyright from the original author, the Copyright Act restricts an absolute assignment to the life of the author plus twenty-five years - section - section 14(1). The last twenty-five years of the copyright belong to the author's estate -- as the assignees of the composer Gilbert of Gilbert & Sullivan found out to their chagrin. It remains to be seen if this result can be avoided through legal artifice such as a will limited to the transfer of ownership in the code.

4.         Moral rights

Whether an owner or licensee, it is in everyone's interest to ensure that agreements are in place with the original authors of the software. An author of software possesses "moral rights" - section 14.1(1). These rights prohibit the use or modification of the copyrighted work by the owner in a way that would damage the reputation of the author.

Until recently, these rights have been viewed as relevant more to literature and other art forms than to software. Prudence suggests that waivers of these rights now be obtained in all cases - particularly in respect of the creation of multi-media. See section 64.2(2), for example, which states that the incorporation of a copyright into a micro chip might offend moral rights.

These rights can only be waived, and not transferred - section 14.1(2).

No significant changes to these rights are contemplated.

5.         Summary

The primary significance of these rules is that the ownership of copyright does not follow the rules that people are used to. Conventional wisdom in North American property based society is that ownership belongs to the party paying for the goods. As the rules illustrate, the developer and client alike can end up not owning the copyright in the software they paid to create.

This is particularly true for the developer, given the frequency with which software is developed by independent contractors, instead of relying on employees.

This can have a significant negative impact on the right of the developer and client to use and exploit the software, if it turns out they do not have the rights to do what they want.

Custom software is also often built on portions of software previously developed for others. In other words, the solution for the client is based at least in part on prior work - work that the developer intends to use the routines and other components in future projects. More than one software developer has also unwittingly transferred part of its library of software when agreeing without clarification that the copyright in custom software belongs to the client.

C.        Implied License to Use

In the absence of adequate contractual provisions regarding ownership and use, licenses to copy may be implied by the courts. Current case law in Canada is not entirely adequate when inferring these licenses.

Such licenses are based on the inference of consent. These licenses are not necessary for other forms of literary works such as books because it is not necessary to copy the copyrighted work to make use of it. While the case law makes it clear that the terms of such licenses will be implied as required by each situation, it is likely that the right to adapt, maintain and enhance will be included. By way of example, an Alberta Queen's Bench case decided in 1989 permitted the defendant "licensee" to copy the software onto several office computers, on the basis that the "licensee" required the right to make multiple copies in order to use the software. The license implied in this case went far beyond what is commercially reasonable.

D.        Registration Not Required, But Recommended

While it is recommended that the creation of a copyright be registered, it is not mandatory - section 54. It is also not necessary to register the transfer or assignment of an interest in a copyright. Registration of the transfer or license of an interest in a copyright acts as actual notice, however, to a subsequent assignee of the same interest, and serves to defeat the subsequent grant even if made without notice - section 57(3). This is consistent with the treatment that equity would afford other types of property rights.

Notwithstanding that registration is not required, assignments and licenses must be in writing - section 13(4).

Where an owner is granting a license in a significant piece of software, it is advisable to register the license pursuant to the relevant Personal Property Security legislation.

IV.       Software Development Issues

A.        Background

Trends point to a continuing increase in the development of custom software applications - from stand alone applications to object oriented modules which either interact with widely available business applications or that can be incorporated into other applications or solutions.

More and more software is being developed through independent contractors, and often off shore. Reference to issues of intellectual property protection, ownership, and the proper law of contracts for the jurisdiction where the developers are located is recommended. Complicating this is that some forms of protection may be practically non-existent in the country where the software is being developed.

Client and software developer alike want a product that has been effectively created with regard to quality, time and cost. An awareness of the relevant issues and how they impact on each other can make the development process more productive and profitable for everyone.

This paper raises some of the key issues which will arise during the negotiation of a contract for custom software development. Those issues are:

1.         Who owns the resulting intellectual property?

2.         How will the risk of whether the project succeeds or fails be allocated?

3.         To what extent will the developer agree not to compete with the client in the future?

This paper is not intended to be an in-depth discussion of a software development contract, which is a subject which merits separate treatment on its own.

B.        Ownership of the intellectual property

The intellectual property created can go beyond the copyright in the software, and can include the other kinds of property rights referred to above. Additionally, the property rights involved might include trademarks created as a result of the contract or those belonging to the developer (or another third party) and intended to be used in conjunction with the finished product, and copyright in any written materials.

The astute developer will recognize and discuss with the client the extent to which ownership of the copyright will accomplish the client's goals.

This paper is confined to the copyright in the software code.

In most cases, a software developer will prefer to license rather than transfer copyright to the client. Clients are usually more interested in preventing others from using the software - in the belief that it makes them more competitive. This is usually expressed by the client as a desire to own the copyright.

Any agreement with respect to ownership must recognize that there may be components of the software that did not originally belong to the developer. In that case, the necessary licenses from third parties will be required.

One of the most common mistakes made is the unwitting transfer of property rights from the developer to the client. Developers often include library routines, engines, and other object oriented modules in their products. Usually, the developer has no intention of transferring ownership of this code. If the developer agrees that the ownership of the software belongs to the client, the effect of this will be to transfer ownership of the modules to the client, with potentially disastrous results.

Additionally, the developer may have priced the project on the basis that it would be create reusable modules which it could reuse. If the client becomes the owner of the copyright, the developer would be precluded from using them.

One strategy that can be used to bridge the gap between developer and client is to include an agreement that the custom software will not be sold to others in substantially the form delivered to the client, leaving the devloper free to use the modules for other works. A developer might also agree not to assist a competitor of the client in developing a similar solution -- a variation of a restrictive covenant. An examination of the client's business may also indicate that the competitive advantage assumed to flow from the ownership of the software is not as significant as the client believes, and the client may then be persuaded that ownership is unnecessary.

Few developers include in their quotes compensation for giving up various property rights. One solution may be that the client is asked to pay a premium for the additional property rights that are being ask for. This approach also has the advantage of expressing the issue in a way that permits a cost to benefit analysis.

Regardless of who owns the copyright, one party is likely to end up with a license to use some or all of the software developed. The extent to which the license permits use of the copyrighted portions of the software can be very important- - to the end user and to the developer.

The ownership of the resulting intellectual property will continue to be an issue in the future. This is true in part because of the continuing trend to use the joint development of software with a client as a financing tool, where the client then retains some form of interest with respect to commercializing all or part of the software developed.

On an editorial note, lawyers do not adequately serve their clients when negotiating software development contracts unless they raise all relevant issues, including those that may result in the other party receiving the benefit of a right that was overlooked or inadequately dealt with. Failing to do so will not only promote dissent and increase the likelihood of litigation, but will not serve to create a relationship that the developer and client can build on.

C.        Allocation of risk

1.         By agreement

A significant number of software development contracts fail to adequately describe the deliverables. Almost all contracts fail to adequately describe how the satisfactory completion of the deliverables will be measured. Currently, references in agreements to testing and acceptance are noticeable by their absence.

The client is usually in the position of being least able to ascertain whether what is delivered is acceptable.

Each project is different, and to provide a solution which would universally work is impossible. Experience suggests that by defining bench marks and combining performance testing with these bench marks, the parties will enjoy a more productive development process.

If the parties have not adequately provided for how the risk of the success or failure of the project will be allocated, legislation will imply terms into the software development contract.

2.         Warranties Implied by Sale of Goods Legislation

A sale of goods is distinguished from other arrangements, such as agency relationships and contracts for services and materials.

To the extent that all or a portion of a development contract is characterized only as a contract for services, the developer's obligation will be limited to having to perform the work with reasonable skill and care, and in a good and workmanlike manner. If the contract requires the developer to provide a solution, it is likely that the transaction is also a sale of goods.

This responsibility is in addition to that which may be imposed under the law of torts in the event that the software was negligently developed.

The most common sale of goods warranties arise when software is sold based on description, or if the purchaser relies on the skill and knowledge of the vendor. When goods are sold based on their description, an implied warranty that they will meet the description arises. Additionally, an implied condition that the goods will be of merchantable quality might also apply. This means that the goods will pass the test if, after examination and knowing of the defects in the goods, a reasonable person would still purchase them. Lastly, if the purchaser can show that it relied on the skill and knowledge of the vendor, an implied warranty that the goods will be fit for the purpose they were purchased will also apply. It is this latter implied warranty that is most important.

If the purchaser does inspect the goods, and then accepts them, it can lose the protection of some of these implied warranties.

The limitations of warranty commonly found in shrink wrap licenses are usually unenforceable. The common reason for this is that the limitation is not available at the time of the purchase (for example, sealed inside the package with the license). In other words, the purchaser was not given notice of the clause. The same can apply to any other warranty limitations that a vendor may wish to rely on. The customer must be made aware of the limitations before the contract is made. In some jurisdictions these limitations of liability are also not enforceable on the basis that they are contrary to public policy.

Three representative examples from the last few years follow. They have been chosen more for their fact patterns than anything else.

A building supply business contracted for the design of an inventory control, point of sale, and accounts receivable system. As it turned out, the system as designed could not handle the complexity or amount of inventory. The defendant was also accused of not providing the necessary assistance. In other words, the system was not fit for the purpose the business wanted to use it for. Damages were awarded sufficient to put the business in the position it would have been if the contract had not been entered into.

In another case, also involving inventory control and point of sale equipment, the store owner claimed that the system sold to it was not fit for the intended purpose. It turned out that in addition to requiring a system that could handle the functions of a retail store, the store owner ran a substantial jewellery manufacturing business. In this case, the court reminded us that the burden of proof is on the store owner to prove that it made its purpose known. The court went on to say that the store owner knew all about the requirements of its business, and was under an obligation to communicate this information. The action was dismissed because of the failure of the store owner to provide this information and make the defendant aware of the particular purpose the software was being purchased for.

In a third case, the defendant was commissioned to design and install a system for use in a retail cookware store business. The owner of the business knew that the defendant had never designed a retail computer software system before. The defendant wanted to get into this part of the software business, and was prepared to do the work for a significantly discounted price. The defendant gave strong assurances that it would be able to accomplish the task. The system never did work, for many reasons. Again, the court decided that the defendant failed to supply goods reasonably fit for the purpose intended. The court went on to say that the owner of the business never agreed to participate in an experiment that would disrupt its business. The owner of the business was awarded all of its expenses flowing directly from the basic agreement between the parties.

In summary, the client must specify in detail the purpose for which the software is being produced and the reliance being put on the developer.

D.        Restrictive covenants

The developer's client will usually try and obtain the agreement of the developer not to compete both in the market that the software is specfically developed for and also in related markets that the software could be adapted to.

From the developer's point of view, each limitation placed on its market will have a potentially negative effect on its business potential. It is unlikely that the developer will have priced this cost in to the development proposal.

Sometimes the gap in the parties expectations can be bridged if the developer agrees to restrict itself from certain limited markets for a limited period time. Often if this solution is used, the time period will not start to run until the parties have ceased working together on the particular project.

The same considerations apply when drafting these restrictive covenants as when drafting other restrictive covenants of general application.

E.         Maintenance/the "source code escrow"

When software has been developed for a custom application, the client will want to ensure that there are adequate provisions in the agreement for support and maintenance. The main concern is usually that the developer will be unwilling or unable to perform the services, leaving the client to fend for itself. Source code escrows are the main tool used to provide the necessary information to the client in the event that it has to do its own maintenance, while striking a balance with the property rights of the developer who owns the copyright.

Source code escrows usually go beyond the mere deposit of the source code, and include the development documentation.

Several firms are now providing escrow services.

Caution is advised to ensure that the ownership of trade secrets is adequately protected by the escrow agreement.

The efficacy of these agreements depends on the regular deposit of code and supporting materials. Not unlike the shareholders' agreement which provides for annual valuations of the company's value, these provisions are usually observed more in the breach. The challenge for the client is to ensure that the escrow contains the necessary information.

F.         Multi-media issues

Multi-media for this paper means computer based software programs which contain an interactive component and are composed of more than one source of copyrighted content - such as movies, books, photographs, articles, music, etc.

The issues faced by the lawyer acting for multi-media developers involve little in the way of new legal theory. The complexities raised by including multiple sources of media, and the new forms of storage medium and delivery platforms that are being used, make developing multi-media an expensive prospect from a legal point of view, however. For example, the number of copyright clearances that must be obtained for one production can be overwhelming.

This has required lawyers to be more aware of the potential rights that the owners of copyright may wish to exercise in future, and to ensure that these rights are preserved. For example, Walt Disney Studios was involved in a dispute over whether it could release the picture "Fantasia" on video cassette. The estate of Stravinsky, the composer of the music, disputed the right of Disney to use the musical score outside of the one film that it released with.

The reality of the local multi-media market is that the majority of the participants are developing product based on their own content, and tools that allow for more interactivity (splicing tools) or more digital compression (to allow more information to be passed through existing bandwidth).

Developers are increasingly using their own content because of the difficulty of obtaining rights to other forms of content. This is often because of the unwillingness of content owners to license in a way that reflects the way business is done in the mass distribution software market, the inability of content owners to license because they find they do not own the rights to license for the method of delivery contemplated, and the fact that some rights require payment whether or not a profit is generated (for example, to the Screen Actors Guild and the Directors' Guild).

These issues can be compounded by the fact that in video and film there are often many other parties who have residual rights - and whose agreement may be needed.

In particular, owners of content often think more in terms of performance rights, than the use of the content with a particular piece of hardware. An easy, consistent way of making this content available to the computer multi-media industry has yet to be arrived at.

In summary, the industry is faced with technological issues relating to production and delivery, and significant practical issues in obtaining the copyright clearances needed to obtain content.

V.        Software piracy

In addition to private actions for enforcement, there are now three significant industry groups acting as "software police".

There are increasing reasons for large organizations to avoid infringing the rights of copyright owners. In large organizations, it is also becoming increasingly difficult to manage and monitor software licenses.

A.        Industry initiatives

Over the past few years, the threat of blackmail has been added to the reasons for compliance, with the growth of industry groups dedicated to reducing software piracy based on tips from third parties.

1.         Software Protection Association (SPA)

The Software Protection Association is member funded, with fees linked to software sales. They are a broad based organization. Members give the organization powers of attorney to perform audits, and permit the SPA to proceed. The SPA does not tend to pursue individuals.

Investigations are usually instigated on the initiative of a tip.

Any money recovered goes to the SPA to fund the organization. There is a battle for jurisdiction with the Business Software Alliance. This dispute is centred offshore primarily, and is motivated by the amount of damages recoverable.

2.         Business Software Alliance (BSA)

This organization was started in 1988 by the larger members of the SPA such as MicroSoft, Aldus, WordPerfect and Lotus. It is an expensive organization to join, and membership is essentially closed.

In 1992 it took over the function of fighting software piracy from the SPA. Its focus is international, and the organization is a significant lobbying force with respect to the government of the U.S.A.

3.         Canadian Alliance Against Software Theft (CAAST)

This organization received significant media attention beginning in the fall of 1995 when it instigated court ordered raids on companies suspected of being in possession of illegal software. Law suits were commenced against three firms following that - two in Toronto, and one in Calgary. At that time, the organization warned that additional lawsuits were contemplated against people pirating software.

B.        By employees

Depending on the size of the organization, it is advisable to institute a policy of employee education and monitoring with respect to the use and copying of software.

Many organizations now include in their employment agreements a provision where the new employee acknowledges the intellectual property rights of her previous employer, and also warrants that no intellectual property owned by others, including the previous employer will be utilized by the employee in the course of her new job.

VI.       Trends

A.        Licensing

1. Site licensing versus CPU licensing

CPU licensing, that is the licensing of a copy for each computer continues to be most popular. Some licenses are written as licenses to the individual. Depending on the wording of the license, issues can arise as to the scope of use permitted.

Site licensing in its original form (an unlimited number of copies at a physical site) tends to be used only in highly competitive situations, where the object is to generate the lowest possible user cost, and occasionally where the software performs a dedicated function such as accounting and the number of users is not an issue. In current usage, it usually works more like a modified pricing plan for CPU licensing, where the copy cost declines as the volume of licenses increases. Often users are permitted to make their own additional copies.

Publishers continue to expand the right of licensees to use software away from the end user's primary PC.

2.         Concurrent licensing

It is common to license on the basis of the number of copies that will be running at any one time. Large corporate users have on occasion negotiated licenses that are organization wide, and license only that number of copies that are running at any one time world wide, as opposed to on one site. To take advantage of this on a large scale, publishers will be looking for metering software or a license server to control access.

MicroSoft has recently limited the applicability of its concurrent licensing program so that it does not apply to small businesses, which has raised the predictable storm of protest.

3.         Cross platform licensing

Expanded cross platform licensing continues to be an alternative for publishers as long as competitive platforms such as OS2 and the Macintosh Powerbook portable continue to be options.

4.         Electronic distribution (the Internet)

Industry Canada in its report dated March 1995 concluded that no additional categories of works were necessary with respect to distribution over the Information Highway. The committee was of the view that distribution over the Internet was analogous to a performance, and so within the right of the owner of the copyright.

B.        Software publishing

Conventional book publishers continue to acquire software product for distribution, which could change the way that software is marketed.

C.        Computer viruses

Criminal law was first used in the United Kingdom in 1995 to prosecute a twenty-six year old who copied programs and games and then put them back into bulletin boards. The accused received an eighteen month jail sentence.





+1 604-739-7011