TPP and the Open Source Software

Posted on by Sam Posted in Uncategorized | Comments Off on TPP and the Open Source Software

Since the release of  the text of the Trans-Pacific Partnership (TPP) last month, the Open Source Initiative and the Free Software Foundation have both publicly criticized provisions of the TPP as an attack on the principles of open source software.

Section 1 of Article 14.17 of the TPP states:

No Party shall require the transfer of, or access to, source code of software owned by a person of another Party, as a condition for the import, distribution, sale or use of such software, or of products containing such software, in its territory.

While there are exceptions for government procurement (Article 14.2), software used for critical infrastructure (Article 14.17, Section 2), and commercially negotiated contracts (Article 14.17, Section 3), the implications are that government parties to the TPP could not enact laws requiring imported consumer devices to be accompanied by source code.  While the Free Software Foundation notes that, in general case, “copyright holders are not a “Party” to the TPP, the regulation would not affect software licensed under the GPL”, an argument could be made that government bodies can be copyright holders (e.g., in Canada under Section 2 of the Copyright Act) and precluded from licensing their works under the GPL (subject to the TPP exceptions).

The Open Source Institute emphasizes the importance of open source using the Volkswagen example.  According to the New York Times, Volkswagon admitted to rigging the proprietary software of 11 million of its diesel cars so that the cars would pass emissions tests — a scheme that would have been deterred had the software been open source.

Lastly, beyond (but related to) open source, the Electronic Frontier Foundation, a leading nonprofit defending civil liberties in the digital world, has articulated other issues with the TPP. The TPP is subject to legal review for accuracy, clarity and consistency and it will be interesting to follow how Article 14.17 will evolve.


Software Licensing and the LGPL

Posted on by Sam Posted in Uncategorized | Comments Off on Software Licensing and the LGPL

Provisions that prohibit reverse engineering are commonly found in commercial licenses (e.g., EULAs, Terms of Use, Software License Agreements, etc.). While these provisions serve to protect the software developer’s intellectual property, software developers who include such clauses in their software licenses must ascertain there no software components are used that are licensed under the GNU Lesser General Public License (LGPL) (called a Library by LGPL). As the use of Open Source Software (OSS) during the development process is prevalent in many organizations, this issue is often overlooked.

LGPL states that if one combines or links a “work that uses the Library” with the Library, and subsequently distributes the combined or linked work, then one cannot include reverse engineering provisions in the license agreement.  Specifically, Section 6 of LGPL 2.1 states:

As an exception to the Sections above, you may also combine or link a “work that uses the Library” with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer’s own use and reverse engineering for debugging such modifications.

Putting aside the controversial issue of whether Section 6 only applies to statically linked works, a plain reading of Section 6 suggests that LGPL places a positive obligation on the software developer to include within their software license certain terms that permit reverse engineering for debugging modifications of the combined work as a whole, not just the Library.

This is consistent with the principles of “free” software advanced by the Free Software Foundation. Anyone should be able to modify LGPL licensed — that is, after all, one of the four essential freedoms of “free” software. However, after making modifications to the Library, a software developer may need to reverse engineer the rest of your proprietary object code / executable to make the modified version of the Library work with the proprietary object code / executable. Section 6 of LGPL ensures the freedom to do so.

Some in the OSS community (e.g., Software Freedom Law Centre)  hold the view that software license terms do not need to permit reverse engineering.  Rather, software license terms must only refrain from “prohibit[ing] user modification and reverse engineering for debugging of modifications to the LGPL’d code included in the combination”.  While this is the view of one well respected organization in the OSS community, this view may not be upheld in the courts of every jurisdiction.

Similar to LGPL 2.1, Section 4 of LGPL 3.0 states:

You may convey a Combined Work under the terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications…

LGPL 3.0 differs from 2.1 in that the positive obligation to permit reverse engineering is replaced with a prohibition on software developers from restricting reverse engineering. This is aligned with the Software Freedom Law Centre’s views regarding the interpretation of Section 6 of LGPL 2.1.  While it isn’t entirely clear whether “reverse engineering” applies to just the Library or the Combined Work as a whole, there is still a strong argument that if reverse engineering of the Combined Work as a whole is required for debugging modifications to the Library, then that a software developer cannot restrict such activity.

Ultimately, whether a software developer is using software licensed under LGPL 2.1 or LGPL 3.0, they should be cautious when drafting their license agreements and should tailor the terms of such license agreement accordingly.





GPLv3 / AGPLv3 – Section 7 (Additional Permissions) Explained

Posted on by Sam Posted in Open Source Software | Comments Off on GPLv3 / AGPLv3 – Section 7 (Additional Permissions) Explained

Section 7 of GPLv3 has caused a lot of confusion amongst software developers. Once explained, one can see how Section 7  enhances license compatibility and why it has been drafted the way it is. Here is Section 7 (in blue) with annotated notes (in black):

7. Additional Terms.

“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Essentially, these two paragraphs introduces the concept of “Additional Permissions”, which are terms that make exceptions from one or more of GPLv3’s conditions. Generally, modifications to software licensed under GPLv3 must be released under the GPLv3.  However, Section 7 provides that if you are the copyright holder (or have permission from the copyright holder), you can add additional permissions for what the user can do with the licensed work.  However, these permissions — above and beyond what GPLv3 says — can be removed by downstream recipients.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

  • a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
  • b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
  • c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
  • d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
  • e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
  • f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

The above paragraph is about a limited list of additional restrictions that you may add to your modifications if you are the copyright holder (or if you have permission from the copyright holder), thus enhancing license compatibility. Without the above paragraph, combining GPLv3 code with another OSS license which introduces a relatively benign restriction that does not exist in GPLv3 would result in a license violation.

Unlike “additional permissions”, this list is understandably limited — if not, GPLv3 software may become so much restricted that it is no longer free.  Moreover, these additional restrictions may not be removed.  Lastly, Section 7 states that if you receive a GPLv3 licensed work with additional restrictions not found in the list in Section 7, you may remove it.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

The above paragraphs states the obvious — essentially, if you add additional permissive or non-permissive (aka further restrictions) terms, you need to direct the user to where they can be found.  I have often see these additional terms placed in the same file where the GPLv3 license is found under a separately identified paragraph.

For a more in-depth treatment on Section 2, see the Free Software Foundation’s article on Section 2: here.



GNU Affero General Public License 3.0 (AGPL)

Posted on by Sam Posted in Uncategorized | Comments Off on GNU Affero General Public License 3.0 (AGPL)

Not to be confused with another license called the Affero General Public License published by the now-defunct Affero organization, the GNU Affero Public License (AGPLv3) was designed to close a loophole in GPL where one could use GPL licensed software available without ever disclosing source code to their modifications by deploying their software as a service and thus, avoiding a technical “distribution”.

The AGPLv3 is identical to GPLv3, with the exception that source code for modifications must be disclosed if AGPLv3 licensed software is used in a software-as-a-service model. Section 13 of AGPLv3 states:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source form a network server at no charge, through some standard or customary means

The Free Software Foundation has clarified in their FAQ that, “[i]f the program is expressly designed to accept user requests and send responses over a network, then it meets the criteria”, of, “interacting with [the software] remotely through a computer network”.  Examples include web and mail servers, interactive web-based applications, and servers for games played online.  It is interesting to note that the “user” in this case, could very well be a computer program.

Along a very reasonable line of thought, the Free Software Foundation further clarifies that, “[if] a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session.”

What about client-server architectures where the client is licensed under AGPLv3?  The Free Software Foundation clarifies that Section 13 of AGPLv3 would not be triggered, as it would not be reasonable to argue that the “server operation is a ‘user’ interacting with the client in any meaningful sense…the server can make absolutely no assumptions about what the client will do — so there’s no meaningful way for the server operator to be considered a user of that software.”

In the marketplace, there have been articles stating that Google bans use of software licensed under AGPLv3.  As an offeror of cloud solutions, this policy seems to make good business sense.  Misuse of open source software could trigger disclosure obligations of otherwise proprietary code.

On the other end of the spectrum, some companies have embraced AGPLv3 as part of a dual-licensing strategy.  For instance, a company might desire to release their source code as AGPLv3 to the public.  Users that want to make modifications, but do not want to disclose their proprietary source code, would then be required to pay for a commercial license to the software.

While AGPLv3 is ranked at 16 of the Top 20 Open Source Licenses used in open source projects by Black Duck Software, use of AGPLv3 is expected to grow steadily.

Software-as-a-Service and Open Source Software Licenses

Posted on by Sam Posted in Uncategorized | Comments Off on Software-as-a-Service and Open Source Software Licenses

​Generally, it is the distribution of open source software (or derivative works thereto) that triggers the source code disclosure requirements found in many open source software licenses such as the GNU Public License (“GPL). However, with the prevalence of Software-as-a-Service (“SaaS”), many believe that because their product offerings are based on a SaaS model, there is no distribution, and hence, the source code disclosure requirements in certain open source software licenses are not triggered. Unfortunately, this belief can result in the use of open source software that exposes the client’s proprietary source code for the following reasons:

1. Third Party Application Hosting May Result in A “Distribution”

Unless a client is hosting its own product offering, having a third party (e.g., Amazon) host the application may well be considered a distribution under open source software licenses such as GPLv2.0. Other licenses such as GPLv3.0 exempt hosting providers who provide facilities for running open source software (or modifications thereto) licensed under GPL version 3.0, but only if such service providers, “do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you” (s. 2, GPLv3). Therefore, if these conditions are not met, a hosting relationship may well be considered a distribution and subject a client’s to source code disclosure requirements.

Note: Interestingly, while Google uses much open source software, they also host their own web applications and can readily comply with this open source licensing obligation.

2. JavaScript Components of a SaaS Offering May Result In A “Distribution”
In a SaaS model, applications are hosted and made available to customers over the internet. However, JavaScript (small pieces of code) related to the SaaS application is often sent to a customer’s computer and executed on the client’s browser and would likely amount to a distribution.  If the JavaScript is licensed under a strong copyleft license such as the GPL, two issues arise.

First, JavaScript is often sent to a client’s computer in obfuscated form to protect the original source code. This original, un-obfuscated, source code which would have to be disclosed. Second, such distribution could trigger the requirement to disclose proprietary source code that is considered derivative works of the JavaScript. Depending on how the JavaScript is used, there is a possibility that a large portion of the proprietary source code powering the SaaS offering would be subject to disclosure requirements.

3 Use of Software Licensed Under the GNU Affero Public License

Lastly, clients should be especially wary of using open source software licensed under the GNU Affero Public License (“AGPL”). The AGL was designed to close a loophole in the GPL that permitted many software developers to use open source software licensed under the GPL without disclosing source code to their modifications by using a SaaS model (thus making available the software without technically distributing it). Under the AGPL, if a client permits customers to interact with open source software through a computer network, the source code disclosure obligations are triggered (s. 13, AGPL).
For the above reasons, clients should be cautious not to gloss over their open source software licensing obligations when working with open source software in a SaaS model.

TCLG: Recent Commercial Cases That Could Impact Your IT Practice (Summary)

Posted on by Sam Posted in Uncategorized | Comments Off on TCLG: Recent Commercial Cases That Could Impact Your IT Practice (Summary)

Peter Ruby, a Partner at Goodmans LLP, presented an overview of IT-related commercial cases at a recent Toronto Computer Lawyers Group event on April 1, 2015. As the cases discussed have particular relevance to our practice, I’ve summarized them as follows:

1. Email Acceptance (Christmas v. Fort McKay First Nation, 2014 ON SC 373)

Facts:  Christmas was an Ontario lawyer hired by a First Nations band in Alberta and now suing for wrongful dismissal. Christmas received the offer of employment in Ontario and accepted it by email. Employment had a choice of law provision of Ontario, but no forum selection clause.

Decision / Legal Principle:

  • Unlike the mail box rule where acceptance is effective when dropped off at the mail box, “[i]t is well-established that when acceptance of a contract is transmitted electronically and instantaneously, the contract is considered to be made in the jurisdiction where the acceptance is received”, and therefore the governing law and forum of the recipient applies (absent choice of law and forum selection provisions).

2. Organizing Principle of Good Faith / Duty of Honest Performance (Bhasin v. Hrynew, 2014 SCC 71)

Facts: This complicated scenario involved lying, straight-up misleading statements, and the fact that the Plaintiff could prove but-for bad faith conduct of the Defendant, damages to him could have been avoided.

Decision/Legal Principle:

  • The courts recognized a new general organizing principle of good faith requiring contracting parties to have “appropriate regard” for the interests of the other contracting party. The courts stated that such, “organizing principle is simply that the parties generally must perform their contractual cuties honestly and reasonably and not capriciously or arbitrarily.”
  • Furthermore, as a “further manifestation of the organizing principle of good faith”, the courts recognized a duty of honest contractual performance. Such duty of honest contractual performance, “means simply that the parties must not lie or otherwise knowingly mislead each other about matters directly linked to the performance of the contract. This does not impose a duty of loyalty or of disclosure or require a party to forego advantages flowing from the contract; it is a simple requirement not to lie or mislead the other party about one’s contractual performance.”
  • Lastly, one should recognize that these are contractual principles, even though it can seem like principles of tort. Thus, the resultant damages are expectation damages (vs. damages suffered under tort law).

3. Limitation of Liability Clause (Swift v. Tomeck Roney Little & Associates Ltd., 2014 ABCA 49)

Facts: Mr. & Mrs. Swift purchased a land to build their home. Mr. Swift hires an architect, who architect then subcontracted aspects of the project to certain engineers. The design and construction of the home suffered deficiencies in the amount of $1.9 million. Mr. Swift then sued both in contract and tort, and Mrs. Swift sued in tort. The Defendants argued that: (1) the limitation clause limited damages to $500K and barred claims for negligent misrepresentation; and (2) Mrs. Swift was also bound by the limitation clause since her husband was acting as an agent on her behalf. The limitation of liability clause in the agreement stated:

3.8.1   With respect to the provision of services by the Designer to the Client under this Agreement, the Client agrees that any and all claims which the Client has or hereafter may have against the Designer which arise solely and directly out of the Designer’s duties and responsibilities pursuant to this Agreement (hereinafter referred to in this Article 3 as “claims”), whether such claims sound in contract or in tort, shall be limited to the amount of $500,000.00.

Decision/Legal Principle:

  • In a limitation clause, the words “any and all” does not necessarily mean an “aggregate sum”. Thus when contracting, if the intent is for a limitation to mean “in the aggregate”, one should say so.
  • Mr. Swift’s claim for negligent misrepresentation fell outside the parameters of the limitation clause as it is unreasonable to conclude that negligent misrepresentation was contemplated as something that “arises solely and directly” out of the Designer’s duties and responsibilities pursuant to the Agreement.
  • Lastly, Mr. Swift is not an agent for his wife, Mrs. Swift, simply by virtue of marriage; to do so would ignore the separate legal identity of each spouse. Thus, when contracting with associated parties, one should ensure that they are parties to the contract.

4. No Appeal from Appointment of Arbitrator (Toronto Standard Condominium Corporation No. 2130 v. York Bremner Developments Limited, 2014 ONCA 809 ) 

Facts: Dispute arose between the parties and the Plaintiff proposed certain arbitrators to arbitrate the dispute. The Defendent refused to move forward with arbitration because they felt the dispute wasn’t within scope of arbitration clause. The Plaintiff proceeded to asked the court to appoint an arbitrator and such arbitrator could decide whether they had jurisdiction over the issues in dispute. As a result, Defendant ended up with sub-optimal arbitrator and appealed the appointment of the arbitrator.

Decision/Legal Principle:

  • Court cited the Section 10(2) of the Arbitration Act, 1991 and affirmed that there is no appeal from the court’s appointment of the arbitrator.
  • In addition, “a court will decline to have the arbitrator determine his or her jurisdiction only when it is clear or obvious that there is no jurisdiction”. And since at least one issue arguably fell within jurisdiction of arbitrator, the arbitrator should be appointed and determine his jurisdiction.

5. Dispute Resolution Wording: “under this Agreement” (2156775 Ontario Inc. vs. Just Energy, 2014 ONSC 3276)

Facts: The Defendant submitted a motion for a stay of action because of an arbitration clause. One of the contracts at issue contained the following arbitration clause:

17. Dispute Resolution, Binding Arbitration. Customer may contact Just Energy with regard to a concern or dispute under this Agreement by mail, fax or telephone using Just Energy’s contact information as set out at the top of the Customer Agreement. Both parties will, in good faith, use commercially reasonable efforts to resolve a dispute. If not resolved within 45 days, such dispute will be referred to and finally resolved by binding arbitration pursuant to Governing Law, before a single arbitrator, without the right of appeal to law and/or facts, at an arbitration services organization to be chosen exclusively by Just Energy. The arbitration costs will be shared evenly between the parties. Customer waives any right to commence or participate in any class action related to this Agreement. In addition to, but not in lieu of binding arbitration, Customer may contact the OEB’s Customer Service Centre at [phone number] for details about its dispute resolution process. Customer shall remit all undisputed amounts during the pendency of any dispute.

Decision/Legal Principle:

  • There is no question that the validity of an agreement is an issue that can be referred to arbitration; however, dispute regarding existence of the Agreement is not a dispute “under” the Agreement.
  • Words such as “in connection with” or “arising out of” or “touching or concerning” should be used to encompass validity of the Agreement.
  • As a result, the motion for a stay of action was dismissed.

6. “May Arbitrate” is Permissive (Durham v. Oshawa, [1999] O.J. No. 1300)

Facts: The parties disagreed on the interpretation of the word “may” in an arbitration clause because a requirement to arbitrate would have implications with respect to the calculation of limitation periods.

Decision/Legal Principle:

  • If contract says, “may arbitrate”, then there is no binding arbitration provision in place. Had the parties used the words “shall”, the outcome would have been different.

7. RFP: Contracting out of Contract A (Everything Kosher Inc. v. Joseph and Wolf Lebovic Jewish Community Centre, 2013 ONSC 2067)

Facts: Parties disagreed whether Contract A was formed in a response to an RFP.


  • In the context of the documents issue, the RFP was “a request for proposals and nothing more. The prize at the end of the exercise was…the opportunity to negotiate for a contract.”
  • Even though the RFP contemplated a 90 day negotiation period, that in itself does not constitute a binding agreement since, “the ‘contract to make a contract’ is not a contract at all”.

8. Implied Fraudulent Misrepresentation / Entire Agreement (Iatomasi v Conciatori, 2012 ONCA  913)

Facts: Mr. an Mrs. Iatomasi purchased a home from Mr. and Mrs. Conciatori. Mr. Conciatori: (1) false represented that the home never suffered water leakage when he knew otherwise; (2) handed over plans to home to Mr. Iatomasi knowing that the home was not built according to such plans; and (3) claims the “entire contract” provision in the agreement barred claims by the Iatomasis. Nevertheless, the Iatomasis sued for fraudulent misrepresentation and breach of contract.

Decision/Legal Principle:

  • Making a statement knowing it to be false was clearly fraudulent misrepresentation, and the “entire agreement clause” did not save the Defendant.
  • Interestingly, silence is not tantamount to active dishonesty; the “handing over of plans” by Mr. Conciatori knowing that the home was not built according to such plans cannot amount to implied fraudulent representation.

9. Internet Defamation (Awan v. Levant, 2014 ONSC 6890)  

Relevance: Many bloggers believe that when they are commenting on issues, they attract no liability because it’s simply their opinion. This case shows that is not necessarily the case.

Fact: Levant sat in human rights tribunal and “live-blogged” from a human rights tribunal hearing. Levant, on his blog, repeatedly calls the Plaintiff, Awan, a liar. Levant also made several factual errors about what was said during the hearing.  Awan sued for defamation. Among other defences, Levant argues the defence of fair comment.

Decision/Legal Principle:

  • Blog posts stating that the witness was a liar repeatedly was not an opinion; this is important because opinions generally don’t give rise to defamation but facts do.
  • With respect to the fair comment defence, the court stated, “[w]hat is comment and what is fact must be determined from the perspective of a ‘reasonable reader’”, and “must be determined in the specific context of the words complained of. Comment must be recognizable as such – the opinion must be expressed in such a way that the reader can readily distinguished what is asserted as fact and what is claimed as comment…further, while the use of ‘opinion-like’ words such as ‘in my view’ or ‘I have come to the conclusion that’ are not determinative, it is relevant that there are no such words in this blog post”.

10. Misuse of Social Media (Kim v International Triathlon Union, 2014 BCSC 2151)  

Relevance: Employees should communicate their expectations of employee performance through written Social Media policies.

Facts: Ms. Kim criticized her employer, ITU, online and compared her disagreement with management to the abuse she suffered from her mother as a child. Ms. Kim was fired and sued for wrongful dismissal.  ITU did not have a social media policy, and other employees of ITU knew about Ms. Kim’s blog.

Decision/Legal Principle:

  • To dismiss Ms. Kim for cause, the Court stated there had to be “express and clear” warning about Ms. Kim’s performance relating to the social media posts and a “reasonable opportunity” to improve her performance after warning her. Since there was no clear warning, Ms. Kim was wrongfully dismissed.

11. Unjust Enrichment (Infinity Steel Inc. v. B&C Steel Erectors Inc., 2011 BCCA 215)  

Relevance: Even if there a contract is not established, there is still a legal regime in place for unjust enrichment.

Facts: Parties agreed on timing of work to be done and the nature of the work to be done, but held different views regarding payment terms. One though it was fixed-priced, and the other thought it was a cost-plus arrangement.

Decision / Legal Principle:

  • There is no enforceable contract when essential terms such as price is not established; however, courts found unjust enrichment nevertheless put a price on the value of services delivered on the basis of quantum meruit.
  • The value of such services will be at the court’s discretion. The Court stated, “…it is now firmly established that a claim for unjust retention of a benefit conferred in an ineffective transaction is a discrete category of the doctrine of unjust enrichment, which may attract a personal monetary remedy…and that remedy must match, as best it can, the extent of the enrichment unjustly retained…the appropriate measure for restitutionary quantum meruit is to be selected to meet the circumstances of the particular case. Important factors will include but not be limited to, the course of dealings between the parties, any estimates obtained, the costs incurred, the scope of work, the actual work done, the market value of the services provided.”


Two CASL Fines in One Month

Posted on by Sam Posted in Uncategorized | Comments Off on Two CASL Fines in One Month

The Canadian Radio-television and Telecommunications Commission (CRTC) has issued two fines over the spam of this month.

1. Compu-Finder ( -$1,100,000

Compu-Finder, a company offering training products based in Quebec, was fined $1.1M by the CRTC for flagrant violation of the Canadian Anti-Spam Laws.  To put the fine into context:

  • Compu-Finder sent commercial messages to recipients who did not provide consent in 3 different patterns, resulting in 3 separate violations of Section 6(1)(a) violation;
  • the unsubscribe mechanism in the commercial electronic messages sent did not work properly, resulting in a Section 6(2)(c) violation;
  • the unsubscribe mechanism in the commercial electronic message was not valid for a minimum of 60 days, resulting in a Section 11(2) violation; and
  • Compu-Finder did not unsubscribe the users without delay, and in any case, within 10 business days of the user’s indication that they wished to subscribe, resulting in a Section 11(3) violation,

and not to mention that at one point, about 26% of spam messages reported to CRTC’s Spam Reporting Centre related to Compu-Finder.

2. Plenty of Fish ( – $48,000

Unlike Compu-Finder, Plenty of Fish took a more cooperative approach.  While they violated CASL as the unsubscribe mechanism in their commercial electronic messages to users were not clearly and prominently set out, Plenty of Fish entered into an undertaking with the CRTC to comply with CASL.  This, in part, explains the modest fine as compared to that of Compu-Finder.

According to Section 20(4) of CASL, the maximum fine for individuals is $1M, and the maximum fine for corporations is $10M.

New and Emerging ISO Standards

Posted on by Sam Posted in Uncategorized | Comments Off on New and Emerging ISO Standards

OBA published an article I recently co-wrote on emerging and outsourcing ISO standards: linked here.

API Copyright (Oracle v. Google) — Oracle’s Response to Google’s Petition for a Writ of Certiorari

Posted on by Sam Posted in Law | Comments Off on API Copyright (Oracle v. Google) — Oracle’s Response to Google’s Petition for a Writ of Certiorari

On December 8th, 2014, Oracle filed its brief in opposition to Google’s petition for a writ of certiorari with the Supreme Court of the United States in the case of copyright protection for certain Java APIs. Many who have been following the case found it curious that Google petitioned the Supreme Court of the United States to consider a different issue than those that were argued before the Court of Appeals of the Federal Circuit (“CAFC”). Undoubtedly, Oracle took notice and wrote in its brief:

Google poses the question whether the lines of code Oracle authored constitute a “method of operation” – and are therefore devoid of all copyright protection – under Section 102(b) of the Copyright Act…In any case, Google never argued to the court of appeals that the lines of code are a “system” or “method of operation” (p.2).

In my view, I think the Supreme Court of the United States should deny Google’s petition for a writ of certiorari. Oracle advanced a number of reasons, but perhaps chief among them is simply that the writ of certiorari is not the appropriate vehicle for deciding this issue because:

  1. The CAFC’s judgment is supported by independent rationale not challenged in Google’s Writ of Certiorari. Specifically, copyright subsists in (1) the original declaring code gave rise to copyright; and (2) the package’s creative structure and organization. Even if we accept Google’s lead argument that “methods of operations” cannot be copyrighted, such argument could not apply to (2).
  2. The question Google presented to the Supreme Court of United States (whether “copyright protection extends to…computer software, including a system or method of operation”) was never made into the CAFC.
  3. This appeal is interlocutory since the CAFC remanded for retrial on whether Google’s copying can be saved on grounds of fair use.

Even if the Supreme Court of the United States decides to grant Google’s petition for a writ of certiorari, they will have to contend with the fact that, as Oracle relying on Lexmark and Lotus asserts, “it is generally well-established that code is copyrightable as long as it is… sufficiently complex and creative to be original.” Without question, no experienced Java programmer will disagree that the Java APIs are a work of art that meets such criteria. Moreover, the Supreme Court will have to consider in its ruling the far-reaching implications for technological innovation. After all, why would anyone invest time and energy to develop a platform such as Java without the ability to exploit its intellectual property rights for profit?

The implications of this case to Canadian copyright jurisprudence is unclear. The Canadian Copyright Act is not drafted in the same way the American Copyright Act is and does not have the Section 102(a) and (b) dichotomy. Moreover, Canadian courts not affirmed the application of the merger doctrine. For more information about the merger doctrine in Canada, see: Apple Computer Inc. v. Mackintosh Computer Ltd. (1986), 10 CPR (3d) 1, para 27.; Deltirna Corp v. Triolet Systems Inc. (2002), 17 CPR (4th) 289 (Ont. CA), leave to appeal to the Supreme Court refused [2002].

“Indemnify”, “Save and Hold Harmless”, and “Defend”

Posted on by Sam Posted in Law | Comments Off on “Indemnify”, “Save and Hold Harmless”, and “Defend”

One commonly finds the following language in the indemnity provisions of a contract:

Acme shall indemnify, defend, and hold harmless Widgetco from…

But what do each of these terms mean? A very well respected authority on contract drafting Ken Adams has written numerous times on this topic and argues that all three terms mean the same thing and, in fact, one would replace the three terms with simply:

Acme agrees to indemnify Widgetco against both losses and liabiliites.

But no matter how I read the reformulated indemnity, it does not seem to imply that Widgetco never has to even dip his hand in his own pocket, a view that the court in Stewart Title Guarantee Co. holds when interpreting the term “save and hold harmless”.

In my view, the words “indemnify”, “save and hold harmless”, and “defend” are terms of art that mean the following (case law below):

  1. “Indemnify”. Means to make a person whole after the fact.
  2. “Save and Hold Harmless”.  Broader than “indemnify” and means the person saved and held harmless should never have to put his hand in his own pocket in respect of a claim.
  3. “Defend”. Arises at the earliest stages of litigation and exists regardless of whether the indemnitee is ultimately found liable.


The Canadian case, Stewart Title Guarantee Co v. Zeppieri in para. 17 states:

This language imposes two obligations on Stewart Title with respect to a member of the LSUC — to “indemnify” that member and to “save harmless” that member from claims arising under a title insurance policy. The contractual obligation to save harmless, in my view, is broader than that of indemnification. I accept the respondents’ submission that the obligation to “save harmless” means that a LSUC member should never have to put his hand in his pocket in respect of a claim covered by the terms of the 2005 Indemnity Agreement. Accordingly, the 2005 Indemnity Agreement requires Stewart Title to pay for the member’s ongoing costs of defending a claim that falls within the coverage of agreement. This interpretation not only is consistent with the plain meaning of the phrase “indemnify and save harmless”, it also is consistent with the case law, the business sense underpinning the 2005 Indemnity Agreement and the reasonable expectations of the parties

The American Case, Branch Banking & Trust Co v. Syntellect, Inc. states:

As a preliminary matter, both parties blur the distinction between the duty to defend and the duty to indemnify. In one count for breach of contract, the compliant alleges that Syntellect breached both its duty to defend and its duty to indemnify. Similarly, Syntellect’s motion to dismiss operates on the assumption that these two duties are one. However, the duty to defend and the duty to indemnify were two separated duties created by the contract…

The American Case, INA Ins. Co. v. Valley FOrge Ins. Co states:

The duty to defend, however, is not the same as the duty to indemnify. The duty to defend arises at the earliest stages of litigation and generally exists regardless of whether the insured is ultimately found liable. The duty to indemnify depends on whether the indemnitee engaged in actual, active wrongdoing. See Koch v. City of Seattle. The accrual of the obligation to provide a defense does not control the accrual of the obligation to indemnify.