Should lawyers learn to code?

There have been many articles written suggesting that lawyers should learn how to code software.  This Wolfram Alpha article is a good one, although many of the articles are far more adamant that every lawyer needs to learn how to code.  The rationale is that because software will have an increasing effect on how lawyers practice, and who will be competing with us to provide our services, we should learn to code.

So should we learn how to code?  For most lawyers, probably not.

I knew how to code before law school, and for me it has been very useful.  Since my practice is largely around IT issues, it has helped me understand those issues and discuss them with clients.  It has also influenced my drafting style for both contract drafting and the way I communicate with clients.

But the thought that learning how to code will give us a leg up against competitors who are developing or adopting intelligent solutions to replace our services, or will help us develop our own systems to compete or make us more efficient, is flawed.  The systems that are going to have the biggest impact are based on artificial intelligence.  That is very sophisticated, cutting edge stuff, and learning how to code is not going to help with that.  It is something that we need to leave to the experts, or hire experts to do.

Lawyers interested in this can find resources discussing artificial intelligence and where it is headed (such as the artificial lawyer site and twitter feed that posted the Wolfram Alpha article).   Looking at where this is headed, and how it might effect the practice of law would be more productive than learning how to code.

Cross posted to Slaw

Will self-driving cars spontaneously reboot?

A common rebuke to self-driving cars are thoughts about cars behaving like computers – like freezing or rebooting while driving. Those make amusing sound bytes or twitter comments, but there is a grain of truth to it. Self driving technology has come a long way, but while computers and software can follow programmed instructions, and can learn over time, humans are still better at many things.

An article in the New York Times entitled Why Robots Will Always Need Us does a good job of putting this in context, in part by the experience of aircraft.

Author Nicholas Carr points out that:

Pilots, physicians and other professionals routinely navigate unexpected dangers with great aplomb but little credit. Even in our daily routines, we perform feats of perception and skill that lie beyond the capacity of the sharpest computers. … Computers are wonderful at following instructions, but they’re terrible at improvisation. Their talents end at the limits of their programming.


In 2013, the Federal Aviation Administration noted that overreliance on automation has become a major factor in air disasters and urged airlines to give pilots more opportunities to fly manually.

That’s not to say that we should smugly dismiss automation or technology. Lawyers, for example, who dismiss the ability of software to replace certain things we do are in for a rude awakening.

In general, computer code is never bug free, is never perfect, and is not able to do certain things. (You can say the same for us humans, though.) For example, the aircraft industry spends huge amounts of time and money testing the software that operates aircraft. On the other hand, the types of things computers can do well are increasing, and will increase over time. At some point there may be breakthroughs that make computers more reliable and better at the things us humans are more adept at. But we are not there yet.

Cross-posted to Slaw

CASL software consent chart

CASL, the Canadian anti-spam act, contains provisions that take effect on January 15, 2015 that are intended to prevent malware from being installed on computers (including any device that uses software such as smartphones, cars, TV’s, routers, thermostats…).  The sections require the software provider to obtain express consent from the computer user for certain installations.  There are 2 different levels of consent. Both require the disclosure of specified information, and the second level requires the consent to be obtained outside of the license.

Unfortunately the CASL software consent provisions are tortuous and unclear, and if taken literally could cause huge problems for the software industry. The IT bar has been collectively scratching its heads trying to understand how to interpret the sections. The CRTC has tried to interpret them in a way that aligns with the intent of stopping people from installing malware on computers.  While the CRTC interpretation may not line up with the act, we basically have to work within it for the time being.  When advising clients we will have to include caveats that we can’t guarantee that a court would agree with the CRTC’s interpretation.

Because January 15 is close at hand, software providers with customers in Canada should consider whether they need to do anything to comply.  Violating the act has the same huge potential consequences as violating the anti-spam provisions.

The chart below is an attempt to give an overview of the analysis that a software provider should do to determine what, if anything, they need to do.  There are 2 caveats to this chart.  First, the sections are technical and have their own caveats and exceptions, so you can’t rely on the chart alone.  Second, it relies on the CRTC position as it stands at this moment based on statutory language that really doesn’t make a lot of sense.

download pdf CASL software chart

CASL software chart



CASL Software provisions explained – Sort of…

I’ve had some time to reflect on the CASL software provisions as interpreted by the CRTC .  As I’ve said before, the CASL software consent provisions are tortuous and unclear, and if taken literally could cause huge problems for the software industry.  The CRTC has tried to interpret them in a way that aligns with the intent of stopping people from installing malware on computers.  While the CRTC interpretation may not line up with the act, we basically have to work within it for the time being. (Lawyers advising clients would be well served to include caveats that we can’t guarantee that a court would agree with the CRTC’s interpretation.)

Software providers should review CASL with their legal counsel to determine how they fit within this labyrinth, but here is my take from a simplified high level on how it applies to the installation of software on a device I own.

I acquire the “Sliced Bread” software by Softco.  It doesn’t matter how I get it – could be an app store, download, CD, etc. I install Sliced Bread on my computer – or my phone, tablet, car, drone, thermostat, fridge, server, router, etc.

Since I’m installing it myself on my own device, CASL doesn’t apply.

BUT IF Sliced Bread does one of the things CASL deems undesirable – things like collecting personal information, changing or interfering with data / operations / control, or sending information to someone;

AND IF those things are something I’m not reasonably expecting Sliced Bread to do (this expectation issue is a huge grey area and will vary depending on what Sliced Bread does);

THEN Softco is deemed to be installing it on my device, and Softco has to obtain my express consent outside of the EULA as detailed in the act.

Cross posted to Slaw.

CASL software provisions & CRTC interpretation

In addition to the anti spam provisions of CASL, it contains provisions against malware starting in January 2015. It imposes disclosure and consent requirements for software providers in certain situations.

Unfortunately, those provisions are perhaps more ill-advised and unclear than the anti-spam provisions.  They have the potential to make life difficult for software companies, create additional record keeping responsibilities where none are needed, and could even hurt Canadian consumers if foreign software developers simply don’t sell their products in Canada to avoid compliance.

The IT law bar is collectively scratching their heads trying to understand what the provisions mean in practice.

When I last mentioned this, the CRTC was collecting questions to help them frame their guidance on the sections.

The CRTC will reveal their interpretation thoughts in an IT.Can webinar on November 11.

Cross posted to Slaw

Simple is not easy

Have you ever used an app – whether on a phone, tablet, or desktop, and found them lacking?

Developers creating app versions of existing desktop software or online services face a dilemma. Apps are generally slimmed down versions of the original as they need to be used on touch interfaces, and the code needs to be smaller.

So app developers need to decide what features are important, how the app might be used differently in that context, and what can be left out.  Even though desktop software is often bloated with features that are rarely used, deciding what to leave out is not easy.   With computer code, similar to drafting contracts, simple is good but not easy.  Sometimes things are left off that are missed by some users or that drive users nuts because they spend so much time trying to figure out how to do something that is missing.

I recently found, for example, that the Windows metro Dropbox app won’t let you select more than 1 file at a time to download.  That’s a real pain if you are trying to download a couple hundred photos.  I’ve also noticed that the OneDrive app doesn’t let you access OneDrive databases other than the one linked to that computer.  And seen weather apps with reduced information.

This is a factor that makes some people lean towards HTML5 websites vs apps.

Cross posted to Slaw.

Trade-mark use descriptions get tricky with tech

That’s the title of my Slaw post for today.  It reads as follows.

Drafting proper trade-mark use descriptions when registering a trade-mark is important to get the right protection. Drafting uses can sometimes be a challenge when the wares or services the mark is used for is new and changing technology. The use description must accurately describe the wares and services the mark is used for, must stand the test of time, and must satisfy CIPO’s (Canadian Intellectual Property Office) rules on use descriptions.

Software is a good example of how things can rapidly change. If a business is selling software in the traditional manner where the user installs it on his/her computer, then from a trade-mark perspective, the software is a ware. It might be described, for example, as “Computer software for [describe function]”.

But if that software is being provided as an online service, then from a trade-mark perspective it is not a ware, it is a service. It might be described, for example, as “Online service providing [describe function]”.

Then we get to the smartphone world. If it is an app installed on a phone, it would be software. If it is coded in html5 and used through the phone’s browser, then it is a service.

Since wares and services are considered to be different things, you can get into the position where, for example, software brand X might be considered confusing with software brand X1 – but not be considered confusing with service brand X1 that provides the same function to the user.

Cloud sevices – Is the bloom off the rose?

For the London Free Press – May 9, 2011

Read this on Canoe

Recent outages at Amazon and Sony’s PlayStation Network have left businesses and consumers without service for lengthy periods of time.

The tech press is full of articles suggesting the bloom is off the rose for cloud services and cloud providers are in denial about risks. These articles call on online providers to take financial responsibility and offer more than token services credits.

These outages have done more than just prevented gamers from playing. Services provided by Foursquare, Hootsuite, Discovr, the New York Times and others were affected by the “Amazonpocalypse”. Other businesses using Amazon were barely affected, as they designed their use with disaster prevention in mind.

One reason cloud services are inexpensive is that they come with no guarantees, and no liability on the part of the provider. That’s not meant to suggest online providers aren’t motivated to keep their services running. It’s bad for business if they don’t. But some are better than others, and problems can occur despite provider efforts.

If users expect financial responsibility and compensation for their losses in a failure, they can expect to pay more.

Online service provider user agreements contain limitation clauses that deny liability if the services don’t work. At most, there might be a refund for the cost of their services proportionate to the amount of downtime. If users want more, they can expect to pay for the provider’s insurance to back up the liability. And in practice. most users opt not to pay more for liability protection.

Anyone using online or cloud services needs to first consider how crucial the services are to them. What will the effect be if the service is disrupted for a short or long period of time, or if their online data is lost?

If such disruptions would have serious effects, then the user must take steps to control those risks.

For the risk of losing data, it might be as simple as keeping local backups, or keeping a mirrored copy at a different service provider at a different location.

To keep the service operating continuously, users should take a close look at how the service is provided, and plan their use in a way designed to survive failure.

In other words, assume things will fail, plan around that, and test to ensure the plan works.

Amazon, for example, has several “availability zones”. Amazon customers who were able to switch between them suffered only minor issues.

Another approach is to use multiple service providers based in different locations.

Anti-spam bill far reaching: The Act applies to all software installed on someone’s computer

For the London Free Press.  March 21, 2011

Read this on Canoe

The anti-spam bill — Bill C-28 — was passed in December and is expected to be in force later this year. The main goal of the Act is the prevention of spam, but it also contains anti-spyware provisions.

Canadian software creators — indeed any entity selling software to Canadians — will need to review the Act, given the significant potential fines and consequences to directors and officers if there is a violation.

The goal is to eliminate the spyware, malware, and other malicious software which has essentially gone unregulated.

You might recall the Sony copy protection rootkit scandal which occurred in 2005 where Sony music CD’s automatically installed digital rights management software on users’ computers without their knowledge or consent. This software made operating systems more vulnerable to third-party attacks and could be used to collect and transmit information about computer use back to Sony. Under the act, such practices will be prohibited.

The Act applies to all software — good or bad — installed on someone’s computer. The definitions include any electronic instructions that execute to perform a function on any device capable of executing them.

That is extremely broad. It will include software installed on things such as smart phones, tablets, e-book readers and– since almost everything includes some kind of computing power these days — even things such as PVR’s and cars.

The Act prohibits the installation of computer programs and the transmission of electronic messages from a computer program unless the creator of the software has the express consent of the owner or authorized user of the computer system.

Express consent may only be obtained if there is a notice to the user containing prescribed information about the software, and clearly and simply describes the function and purpose of the program or program update to be installed.

In addition, if a program performs certain undesirable functions then more prominent and explicit disclosure is required. The Act contains a list of undesirable functions often found in spyware, malware, and other types of malicious software, including:

Collecting personal information stored on the computer;

Interfering with the authorized user’s control of the computer; 

Unknowingly changing or interfering with data; 

Unknowingly changing or interfering with settings, preferences or commands;

Causing the computer system to communicate with another computer system; and  

Installing a program that may be activated by a third party without the user’s knowledge.

 If software contains one of these functions, the program distributor must clearly and prominently bring to the attention of the user the reasonably foreseeable impacts of these functions.

Software vendors will have to consider how their software works, how the Act might come into play, and what permissions are required. They may need to amend their end user license agreements (EULAs) to comply. Some circumstances will require specific permission with full disclosure before the change can be made, regardless of the contents of a EULA.

Software vendors may want to consider whether changing from a traditional installed software model to a hosted SAAS or cloud model will avoid some of these issues.

Set code of code conduct

For the London Free Press – November 29, 2010

Read this on Canoe

It’s important to document your intentions before any code is created

It is not unusual for a business to hire someone to create computer code, such as a specialized program, website, or iPhone app.

It’s important to agree in writing who owns what’s created. Many people don’t realize that with nothing in writing saying the person who commissioned it owns it, the creator owns it.

Problems can result later if the intended ownership is not documented at the outset.

On the other hand, people sometimes get too hung up on ownership. It is not unusual for two parties each to want to own the same software.

For example, code creators often reuse existing code to create parts of their end product. It doesn’t work for the buyer of the end product to own everything in it to the exclusion of the creator. At the same time, the buyer may want to own the product as a whole, and not want the creator to reuse or resell it.

The buyer may feel that it paid for it, and the creator shouldn’t otherwise profit from it. The creator may feel that since the buyer got the benefit of existing code, it’s not right to deny others the benefit of parts of the new code. And too many restrictions on the creator can limit its ability to provide services to others.

To some extent, it depends on the novelty of the code, its intended use and competitive value. The buyer may not want competitors to use the new software. And if the whole idea is to create a product for the buyer to exploit commercially, it makes no sense for the creator to be able to do that as well.

Often, the focus should be less on who owns the software, and more about what the parties can do with it. At very least, considering the issue in that light will help sort out ownership.

The parties should think about what they need to do with the product and its parts and what they do and don’t want the other to do with them.

Sometimes, the issue can be resolved by creating broad licence rights, and perhaps restricting what the other party can do. For example, the buyer might get a licence letting it do whatever it wants with the product internally, but not sell it to anyone else.

But the time to deal with and document this issue is before the work starts. The longer it waits after that, the more difficult it becomes to reach consensus and document the result.