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.

Open Source Licenses: BSD 3-Clause License

Posted on by Sam Posted in Open Source Software | Comments Off on Open Source Licenses: BSD 3-Clause License

The BSD License 3-Clause  (a.k.a Modified BSD License, New BSD, BSD-3, 3-clause BSD) is another brief license that is “permissive” and compatible with the GPL.

BSD 3-Clause License 

Link to BSD 3-Clause License: here

Background: The original BSD license contained 4-clauses, but had a problematic “advertising clause” which required acknowledgement of organization/individuals that developed the Software.  This became problematic when programs were combined together in a software distribution.  Thus every occurrence of the license with a different name requiring a separate acknowledgement and potentially a full-page ad chalk-full of acknowledgments!  The “advertising clause” was therefore removed from the BSD 3-Clause License.  Thereafter an even simpler version of BSD License evolved called the BSD 2-Clause License (a.k.a. Simplified BSD License) that omits the “non-endorsement clause” that prevented the name of the organization/individual to be used to endorse products derived from the Software.

Key Provisions in BSD 3-clause License:

  1. Redistribution of source code must contain the copyright notice, the list of conditions, and the disclaimer found in the license.
  2. Redistribution of binary form (including any documentation and other materials provided with the distribution of the binary form) must also contain the same requirements above in #1.
  3. Software is provided on an “as is” basis with no warranties.

Open Source License Series: MIT License

Posted on by Sam Posted in Open Source Software | Comments Off on Open Source License Series: MIT License

The MIT License is very short “permissive” license (described below) that does not have copyleft provisions is thus commercial friendly.  In contrast with the GPL, the MIT License does not require modifications to be open source if you distribute such modifications.

MIT License

Link to MIT License: here

Background: The MIT License was published by the Massachusetts Institute of Technology in 1988.

Key Provisions in MIT License:

  1. The MIT License grants, free of charge, to any person who obtains a copy of the Software to copy, modification, publication, distribution, subl-icense, and sale of Software within proprietary software.
  2. The MIT License must be included in all copies or substantial portions of the Software.
  3. The MIT License is “permissive” in that it does not require derivative works to be distributed under the MIT License.  In other words, a sub-license to the Software can be more restrictive.



Open Source License Series: GPL version 3

Posted on by Sam Posted in Open Source Software | Comments Off on Open Source License Series: GPL version 3

GPL version 3 ushers in a number of additions to version 2.  While BlackDuck indicates that there is still twice as many open source software licensed under GPLv2.0 (26%) as there are GPLv3.0 (11%), the adoption rate for GPLv3.0 is still increasing.  It’s worth noting that open source software initially licensed under GPLv2.0 and contains language such as “or (at your version) any later version”, would allow users to sublicense their software under either GPLv2.0 or upgrade to GPLv3.0.

GNU Public License (GPL) Version 3.0

Link to GPLv3.0 License: here

Background: The GPLv3.0 license is more than twice the length of GPLv2.0.  GPLv3.0 has tightened its language such that it is even more so of a “legal license” than the previous GPLv2.0 and introduces new terminology, concepts, and response to recent software developments.

Key Provisions in GPL 3.0:

  1. The strong copyleft provisions of ensuring the freedom of open source software is preserved, and the mechanisms for doing so are more/less similar to those provided under GPLv2.0. For a review of GPLv2.0, click: here
  2. Protecting against “Tivoization”. There is an emerging trend that hardware manufacturers, such as TiVo, sell hardware containing free software that the end-users can’t modify because TiVo blocks them from doing so. This is against the spirit of “free software” because the manufacturer takes advantage of the the spirit of free software but will not pass on that freedom to its users. GPLv3.0 solves this by requiring the manufacturer provide you with the necessary tools (e.g. access keys, etc.) to modify the GPLv3.0 software.
  3. Anti-DRM Provisions. Essentially, these provisions render GPLv3.0 software useless for developing DRM mechanisms. The premise is that people should not be forbidden to write software and tools that they want.  However, against the aforementioned spirit of “free software”, certain laws such as the United States Digital Millennium Copyright Act (DMCA) (a law that implements 1996 treaties of the World Intellectual Property Organization (WIPO)) criminalizes writing software that circumvents Digital Rights Management (DRM) mechanisms. To combat this, GPLv3.0 states that no work under GPLv3.0 will be considered an “effective technological measure..under article 11 of WIPO”, meaning if someone breaks DRM software that contains GPLv3.0 software, then they are not in breach of laws such as the DMCA. In addition, GPLv3.0 also provides that the software developer who implements DRM using GPLv3.0  waives their legal power to forbid circumvention of such technology.
  4. Protecting Against Discriminatory Patent Deals. When someone writes or modifies a GPLv3.0 software, others who are conveyed (e.g. distributed, copied) copies are granted a patent license to exercise rights to carry on all activities permitted by GPLv3.0.  This prevents desperate contributors from trying to sue for patent infringement.


Open Source Licenses Series: GPL version 2

Posted on by Sam Posted in Law, Open Source Software | Comments Off on Open Source Licenses Series: GPL version 2

As a former programmer, I’ve always struggled to untangle the various Open Source Software licenses.  I’m hoping this series will explain, in simple terms, the basics behind such licenses. According to Black Duck Software, the GNU Public License version 2.0 is still the most popular open source software license on the internet and as such, we’ll begin with an introduction to the GPL version 2.0.

GNU Public License (GPL) version 2.0

Link to GPLv2.0 license: here

Background:  The first version of GPL was written by Richard Stallman to address two issues: (1) to ensure software is distributed in source code form; and (2) to ensure subsequent licenses are placed on software that further restricted an individual’s freedom to share and change it. The GPLv2.0 builds on this and adds what Stallman calls the “liberty or death” clause (section 7), explained further below.

Key Provisions in GPLv2.0:

  1. You can copy, modify, distribute GPLv2.0 software if you:
    • accompany it with the source-code;
    • provide a written offer (valid for 3 years) to provide the source code at cost; or
    • for non-commercial distribution, if you pass along the written offer you received if you obtained the object code or executable form.
  2. However, if you modify and subsequently copy and distribute such modifications if you adhere to the following requirements:
    • cause any work you distribute/publish that contains or is derived from the GPLv2.0 program to be licensed as a whole at no charge under GPLv2.0 (aka “copyleft”);
    • cause modified files to carry notices stating you changed the file and the date of any change; and
    • adhere to the requirements in point #1 above.Note: There are special notification requirements for command-line software found in Section 2 of the GPLv2.0
  3. You can only charge a fee for the act of transferring a copy  or offering a warranty protection, but not for the license itself.  In other words, you can sell copies of GPLv2.0 software (or your modifications to it), but those whom you have sold copies to can copy and give away the source code to your software.
  4. If for whatever reason, you are faced with conditions (e.g. court order, patent infringement, etc.) that restrict you from complying with all the requirements of the GPLv2.0, then you must not distribute the GPLv2.0 program (or the modifications).  So for example, if a patent license requires you to pay royalties for each distribution of a certain GPLv2.0 program then you are not permitted to distribute the  program at all.

Interesting Implications:

  1. As a software developer, you can take open source software and modify/copy it for internal use.  You are not obligated to release the source code externally. Only when you start releasing it to other companies or contractors working off-site do you need to adhere to the GPLv2.0 requirements.
  2. Creating modules that statically or dynamically link to GPL as a whole will subject the module to GPLv2.0.  (If your desire is to keep modules clear of GPLv2.0 requirements, consider using the Lesser GPL license that we will discuss at a later date)

Consideration in Contract Recitals

Posted on by Sam Posted in Uncategorized | Comments Off on Consideration in Contract Recitals

Under Canadian contract law (except Quebec), consideration (something of value) must flow both ways in order for a contract to be valid. For example, in a sales contract the buyer would receive the product (consideration) whereas the seller would receive money (consideration). As a result, often one reads a variation of the following in a contract recital:

NOW THEREFORE in consideration of the premises and other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, the parties agree as follows:

But by saying insufficient consideration is sufficient, won’t make it so.  Either there was consideration under the contract, or there was not. Why not just keep contracts simple just say, “The parties agree as follows:”?

APIs are Copyrightable For Now

Posted on by Sam Posted in Law | Comments Off on APIs are Copyrightable For Now

I’ve posted previously about my views on whether APIs ought to be copyrightable from an Engineer’s perspective.  The saga continues as Google, on Oct. 6th, petitioned with the US Supreme Court (SCOTUS) for a writ of certiorari to consider, not only whether Java APIs are copyrightable, but also the question of how far-reaching copyright protection extends in software.

To bring readers up to speed:

  • Application Programming Interfaces (APIs) are a set of specifications that define software component inputs, outputs, and operations, allowing software components to communicate. Google used the APIs of Java in their Android operating system, which Oracle asserts copyright to.
  • In August, 2014, Oracle sued Google for copyright infringement, both literal (i.e. copying verbatim of the original expression) and non-literal infringement (i.e. copying the structure, sequence of the Java API package).
  • On May 31, 2014, in a landmark decision,  Judge Alsup of the Northern District of California declared that APIs are not copyrightable. His decision could be summarized as follows: “The method specification [API] is the idea. The method implementation [API Implementation] is the expression. No one may monopolize the idea”.
  • On May 9, 2014, the Court of Appeals for the Federal Circuit (Circuit Judges: O’Malley, Plager, and Taranto)  reversed Judge Alsup’s decision, stating that copyrightability presents a “low bar” that requires only that a work be original and expressive in the sense that  “the author had multiple ways to express the underlying idea”  And since, “[t]he evidence showed that Oracle had unlimited options as to the selection and arrangement of the 7000 lines Google copied”, both the API declarations and the API package organization is copyrightable.  While a plain reading of 17 U.S.C. § 102(b) excludes “systems” and “methods of operations” from copyright protection, the CAFC clarified that such provisions of the Copyright Act, “does not extinguish the protection accorded a particular expression of an idea merely because the expression is embodied in a method of operation”, but rather, Section 102(b)  “serves to clarify the ‘idea/expression dichotomy’ in that copyright extends only to the idea, not the expression”.
  • On October 6, 2014, Google filed a petition for a Writ of Certiorari to have the Supreme Court of the United States consider the question.

Google posed the following question to the Supreme Court of the United States:

Whether copyright protection extends to all elements of an original work of computer software, including a system or method of operation, that an author could have written in more than one way.

The Supreme Court’s answer will have far reaching implications. For instance, systems and methods of operations are generally considered patentable inventions afforded 20 years of protection. If software systems and methods can be couched under copyright protection rather than under patent intention, such software systems and methods would be afforded protection far beyond 20 years (author’s life plus 70 years; or for works of corporate authorship, the earlier of (1) 120 years after creation or (2) 95 years after publication).  Obviously this would blur the line between patent and copyright law and cause much confusion.

Moreover, whether APIs are copyrightable has ramifications on innovation and there are a good policy arguments to be considered on both sides of the matter. On one hand, the ability to copyright APIs provides economic incentives for  authors of APIs to create and release better APIs. On the other hand, others argue that it is the inability to copyright APIs that reduce licensing costs and encourage broad adoption, thereby fostering innovation.

It will be interesting to follow this petition’s developments and to review Oracle’s response on November 7th.