presentation on development agreements

Alas, it has been far too long since I’ve posted anything. That being said, I have amassed a nice collection of half-completed posts which have all but lost any relevance or interest. Something I’ll need to work on, I suppose.

In any event, in case it might be of interest, I gave a presentation earlier today as part of the IT.Can – LSUC Annual Sprint IT Law Form. My piece was on development agreements. It was a relatively short presentation, so I only focused on a limited set of issues. I’ve perhaps done better in terms of delivery, but the slides [PPT] aren’t bad. Feel free to download and peruse.

more draft regulations to canadian anti-spam legislation published

A while back I had posted an entry on some draft regulations under Canada’s Anti-Spam Legis­la­tion which were published by the CRTC for public comment.  Those regulations related primarily to consent mechanisms and what information must be provided in e-mails.

Late last week, another round of draft regulations were released. This time, by the Governor in Counsel rather than the CRTC. For what it’s worth, here’s a compressed version of same. I’ve taken the liberty of appending the full wording at the end of the post, which can also be found in the Canada Gazette (with the added bonus of a regulatory impact analysis statement). This summary is a bit wordier as the regulations need a bit of background in order to be properly understood, and are a bit more complicated. Anyway, here it is FWIW:

  1. Section 6(5) of CASL exempts certain types of messages from the requirements to get prior consent and provide certain information before sending e-mails. These include messages to individuals with whom the sender has “personal or family relationships”. The regulations define both of these:
    • a family relationship  means:
      • a blood relationship (children, grandchildren, parents, grandparents, brothers, sisters or others of common or “collateral” descent);
      • relationship by marriage or common-law partnership (including in-laws in either case); or
      • adoption (including blood relations of the person doing the adopting).
    • a personal relationship means a relationship with someone who the sender has:
      • met in person at some point in the past;
      • had a two way communication within the past two years; and
      • the meeting and communication were not related to a “commercial activity”.
  2. Section 10(2) of CASL allows someone  (let’s call that someone the “Original Consentee”) to get consent from a person (let’s call them the “Target”) to send or alter messages or install software on behalf of third parties (let’s call those third parties “Additional Consentees”) whose identities are not known. To do so, there are two requirements: First, the Original Consentee must disclose specific information about itself (see my earlier post). Second, the Original Consentee must comply with the regulations. The regulations basically try to ensure there are seamless links between the Original Consentee and Additional Consentees from the Target’s perspective, as follows:
    • Requirements to send messages:
      • any message sent to the Target must identify the Original Consentee; and
      • each Additional Consentee must provide an unsubscribe mechanism that complies with CASL and which also allows the Target to withdraw consent from the Original Consentee and any other Additional Consentee;
    • Requirements related to withdrawal of consent by a Target:
      • the Original Consentee must ensure that any Additional Consentee who receives withdrawal of consent from a Target notifies the Original Consentee of those for whom consent has been withdrawn (i.e. the Original Consentee, the Additional Consentee receiving the notice of withdrawal, and any other Additional Consentees); and
      • the Original Consentee must:
        • give effect to the withdrawal of consent;
        • promptly notify any other Additional Consentees for whom consent has been withdrawn (other than of course the Additional Consentee who received the withdrawal); and
        • ensure that each other Additional Consentee for whom consent has been withdrawn also gives effect to the withdrawal of consent
  3. Section 6 of the Act provides that consent for messages can be express or implied. However, consent is only implied in certain situations. One of those situations is an existing “non-business relationship”. In turn, there are different categories of “non-business relationship”, one of which membership with a club, association or voluntary organization within two years immediately before the day the message is sent. The regulations clarify what is meant by membership and what constitutes a club, association or voluntary organization:
    • membership means being accepted as a member; and
    • club, association or voluntary organization basically means a non-profit. To drive home the point, the regulation specifies that it can be operated for any purpose other than profit, and that no proprietor, member or shareholder can personally benefit from any income of the organization, except for organizations promoting amateur athletics in Canada.

The concepts are a bit convoluted, particularly those summarized in paragraph 2 above (which, as an aside, I think leave open some questions of interpretation, which I might address in a later post). Perhaps at a later time I’ll try to come up with an illustrative example of how 2 works (or at least my best guess as to how it’s supposed to work). Also, I believe in my previous post I referred to “e-mail”. Just to be clear, the Act applies not only to e-mail, but to any “commercial electronic messages”, which is fairly broad and could include SMS messages, messages through websites, IM, etc.

As with the last set, open for comments for 60 days following the publication date (July 9, 2011).

Full regulation to save you a click:



1. In these Regulations “Act” means AnAct to promote the efficiency and adaptability of the Canadian economy by regulating certain activities that discourage reliance on electronic means of carrying out commercial activities, and to amend the Canadian Radio-television and Telecommunications Commission Act, the Competition Act, the Personal Information Protection and Electronic Documents Act and the Telecommunications Act.


2. For the purposes of paragraph 6(5)(a) of the Act

  1. (a) “family relationship” means the relationship between individuals who are connected by
    1. (i) a blood relationship, if one individual is the child or other descendant of the other individual, the parent or grandparent of the other individual, the brother or sister of the other individual or of collateral descent from the other individual’s grandparent,
    2. (ii) marriage, if one individual is married to the other individual or to an individual connected by a blood relationship to that other individual,
    3. (iii) a common-law partnership, if one individual is in a common-law partnership with the other individual or with an individual who is connected by a blood relationship to that other individual; and
    4. (iv) adoption, if one individual has been adopted, either legally or in fact, as the child of the other individual or as the child of an individual who is connected by a blood relationship to that other individual; and
  2. (b) “personal relationship” means the relationship, other than in relation to a commercial activity, between an individual who sends the message and the individual to whom the message is sent, if they have had an in-person meeting and, within the previous two years, a two-way communication.


3. (1) For the purposes of paragraph 10(2)(b) of the Act, a person who obtained express consent on behalf of a person whose identity was unknown may authorize any person to use the consent on the condition that the person who obtained consent ensures that, in any commercial electronic message sent to the person from whom consent was obtained,

  1. (a) the person who obtained consent is identified; and
  1. (b) the authorized person provides an unsubscribe mechanism that, in addition to meeting the requirements set out in section 11 of the Act, allows the person from whom consent was obtained to withdraw their consent from the person who obtained consent or any other person who is authorized to use the consent.

(2) The person who obtained consent must ensure that, on receipt of an indication of withdrawal of consent by the authorized person who sent the commercial electronic message, that authorized person notifies the person who obtained consent that consent has been withdrawn from, as the case may be,

  1. (a) the person who obtained consent;
  2. (b) the authorized person who sent the commercial electronic message; or
  3. (c) any other person who is authorized to use the consent.

(3) The person who obtained consent must inform, without delay, a person referred to in paragraph 2(c) of the withdrawal of consent on receipt of notification of withdrawal of consent from that person.

(4) The person who obtained consent must give effect to a withdrawal of consent and, if applicable, ensure that a person referred to in paragraph 2(c) gives effect to the withdrawal of consent, in accordance with subsection 11(3) of the Act.


4. (1) For the purposes of paragraph 10(13)(c) of the Act, membership is the status of having been accepted as a member of a club, association or voluntary organization in accordance with the membership requirements of the club, association or organization.

(2) For the purposes of paragraph 10(13)(c) of the Act, a club, association or voluntary organization is a non-profit organization that is organized and operated exclusively for social welfare, civic improvement, pleasure or recreation or for any purpose other than profit, if no part of its income is payable to, or otherwise available for the personal benefit of any proprietor, member or shareholder of that organization unless the proprietor, member or shareholder is an organization the primary purpose of which is the promotion of amateur athletics in Canada.


5. These Regulations come into force on the day on which they are registered.

draft regulations to canadian anti-spam legislation published

Sorry for the absence, blog and readers thereof. I have my reasons. Anyway just a short one this time.  The CRTC published their draft regulations under Canada’s Anti-Spam Legislation (which as many of you isn’t the official short name) which was passed last December but isn’t yet in force.

Nothing particularly earth-shattering. I’ve reproduced the regulations further below, but here’s the ultra short version:

  1. E-mails must set out:
    • name of sender
    • name of the principal on whose behalf the sender is sending (if different)
    • if sender/principal carry on business under other names, those other names
    • physical/mailing address, telephone number, email address and website of sender and principal
  2. If not practicable to include the info and an unsubscribe message in the e-mail, it can be presented through a link in the e-mail or another equally efficient method that doesn’t cost the recipient anything.
  3. Unsubscribe mechanisms cannot take more than two clicks (or something similarly efficient).
  4. Requests for consents (e.g. to receive e-mails or to install software) must include all the information set out in 1 and a statement indicating consent can be withdrawn by using such information.
  5. If software to be installed performs any of the functions specified in s. 10(5) of the Act, then:
    • those functions must be described “separately” from other information in the consent request
    • written acknowledgement must be obtained that the recipient understands and agrees to the performance of those functions

The functions set out in s. 10(5) for which consent must be obtained are (in compressed form):

  • collecting personal information
  • interfering with control of the recipient’s computer
  • changing or interfering with settings, preferences or commands without their knowledge
  • changing or interfering with data that prevents access or use
  • causing the computer system to communicate without the authorization
  • installing software  that may be activated without their  knowledge

I won’t put you through the pain of a rehash of the rest of the Act.

The consultation period ends August 29. Also, apparently there may be other stuff in the official regulation to be published on Saturday.

Here’s the full text for your reading pleasure and to save you a click:

Appendix to Telecom Notice of Consultation
CRTC 2011-400

Electronic Commerce Protection Regulations (CRTC)


1. In these Regulations, “Act” means An Act to promote the efficiency and adaptability of the Canadian economy by regulating certain activities that discourage reliance on electronic means of carrying out commercial activities, and to amend the Canadian Radio-television and Telecommunications Commission Act, the Competition Act, the Personal Information Protection and Electronic Documents Act and the Telecommunications Act.


2. (1)   For the purposes of subsection 6(2) of the Act, the following information must be set out in any commercial electronic message:

(a)   the name of the person sending the message and the person, if different, on whose behalf it is sent;

(b)   if the message is sent on behalf of another person, a statement indicating which person is sending the message and which person on whose behalf the message is sent;

(c)   if the person who sends the message and the person, if different, on behalf of whom it is sent carry on business by different names, the name by which those persons carry on business; and

(d)   the physical and mailing address, a telephone number providing access to an agent or a voice messaging system, an email address and a web address of the person sending the message and, if different, the person on whose behalf the message is sent and any other electronic address used by those persons.

(2)   If it is not practicable to include the information referred to in subsection (1) and the unsubscribe mechanism referred to in paragraph 6(2)(c) of the Act in a commercial electronic message, that information may be provided by a link to a web page on the World Wide Web that is clearly and prominently set out and that can be accessed by a single click or another method of equivalent efficiency at no cost to the person to whom the message is sent.


3. (1)   The information referred to in section 2 and the unsubscribe mechanism referred to in paragraph 6(2)(c) of the Act must be set out clearly and prominently.

(2)   The unsubscribe mechanism referred to in paragraph 6(2)(c) of the Act must be able to be performed in no more than two clicks or another method of equivalent efficiency.


4. For the purposes of subsections 10(1) and (3) of the Act, a request for consent must be in writing and must be sought separately for each act described in sections 6 to 8 of the Act and must include

(a)   the name of the person seeking consent and the person, if different, on whose behalf consent is sought;

(b)   if the consent is sought on behalf of another person, a statement indicating which person is seeking consent and which person on whose behalf consent is sought;

(c)   if the person seeking consent and the person, if different, on whose behalf consent is sought carry on business by different names, the name by which those persons carry on business;

(d)   the physical and mailing address, a telephone number providing access to an agent or a voice messaging system, an email address and a web address of the person seeking consent and, if different, the person on whose behalf consent is sought and any other electronic address used by those persons; and

(e)   a statement indicating that the person whose consent is sought can withdraw their consent by using any contact information referred to in paragraph (d).


5. A computer program’s material elements that perform one or more of the functions listed in subsection 10(5) of the Act must be brought to the attention of the person from whom consent is being sought separately from any other information provided in a request for consent and the person seeking consent must obtain an acknowledgement in writing from the person from whom consent is being sought that they understand and agree that the program performs the specified functions.


6. These Regulations come into force on the day on which they are registered.


it.can presentation on open source

I gave a speech, along with Thomas Prowse (Genband) and Fred Dixon (Blindside Networks) at the IT.Can Annual Conference (PDF) in Montreal last week. The following is the paper that went along with the presentation, for whatever it’s worth. Not particularly earth-shattering but an approach that is a little different than user/purchaser centric approach I usually see about the topic in other papers and presentations, at least within the realm of those addressed to lawyers. Also in Word format: IT.Can 2010 open source (paper) v2.

Many other great presentations as well, by some of the leading IT practitioners in Canada. Not a member? Consider joining. Well worth it.


by David Ma[1]

1.                  INTRODUCTION

This paper will: (a) review some of the more common business models used to exploit intellectual property; (b) describe, in brief, what open source is; and (c) identify characteristics of open source licenses as they pertain to those business models.

It is oriented primarily to owners or developers of intellectual property that are contemplating the alternatives available to them in the commercial exploitation of that IP. The general context on which this paper focuses is the development and exploitation of software. However, some or all of the principles described below may be applied in other contexts, and we describe some of these briefly toward the end of the paper.

The intent of this paper is not to advocate open source business models as the definitive way to undertake such a venture. Rather, it is to familiarize the reader with the underpinnings of what is becoming an increasingly prevalent approach to exploiting IP which warrants serious consideration as an alternative to more traditional methods – namely, a proprietary licensing model which emphasizes the treatment of underlying source code as a trade secret. It may well be that the particular circumstances of a business undertaking do not lend themselves to such models. However, it would be, in the author’s opinion, inadvisable not to give them due consideration.

Read more it.can presentation on open source

being an employee and a (potential) entrepreneur

Apologies to my loyal readers for the extended blog absence. What can I say – I was perhaps discouraged by the recent pronouncement in wired that blogging was dead – and that twitter is the Next Big Thing.

In any event, I was reading Dilbert this morning. As those who follow the strip know, there has been a running series about how Dilbert started his own business on his company’s time. (As an aside, it was called and is actually a real site that Scott Adams set up for file sharing).

So today, Dilbert gets some bad news:

Funny, but true, unfortunately. One of the things that I admire about Dilbert is the way it conveys some simple truths, such as the one above, with a bit of humour. And it never ceases to amaze me that some entrepreneurs do continue to find themselves barfing in their box full of junk. To wit: The founders of MGA Entertainment – the company that was very successful in marketing a line of dolls called “Bratz”. Apparently, the person who came up with the concept and drawings for the Bratz dolls did so while still in the employ of Mattel. Because of that, Mattel claimed that it owned the rights to the Bratz concept. The court agreed, and gave ownership to Mattel, which then wasted no time in seeking (and obtaining) a court order that effectively shut down MGA’s Bratz business and handed the keys over to Mattel. The folks at MGA likely barfed in their box of junk to the tune of several hundred million dollars. Not good.

The fact of the matter is that if you are a budding entrepreneur who still has a job, unless you have a written agreement with your employer that you will personally retain ownership of certain IP that you come up with, then in all probability whatever you create in the course of your employment will in fact be the property of your employer. So think twice about creating that little side software project on your work computer. Or, for that matter, that really cool blog. Otherwise, you may find yourself handing it over when it’s worth quite a bit more.

chrome a windows killer? i doubt it

Read an article in eWeek that left me scratching my head a bit. The nub below:

Then later:

And that would spell doom for Microsoft. It’s one thing to squeeze Microsoft out of the Internet game by dominating search and Web services. It’s another entirely to come after the software giant’s core operating system business, wielding the Web as your platform.

Must admit I have a lot of trouble seeing that, as I would have thought in order to supplant Windows, it would need to be gone, and to go from a browser that sits on an o/s to replacing the o/s seems to be a rather large leap. A huge leap, actually.

What they’re suggesting might happen is already a possibility today. There is definitely something that can supplant Windows altogether, and provide access to all the web-oriented apps, etc. that Google offers. Its cheap (sometimes free), stable and has pretty good UIs – in fact, a selection of UIs and different flavours. Its called Linux. However, for a variety reasons, it hasn’t kicked Microsoft’s ass yet (at least on the desktop – there are a few areas where it definitely does, such as web and other server functions).

To suggest, then, that, because Google has come out with a browser, that that will lead to the supplanting of Windows seems, IMHO, to be a bit far-fetched. I’m not suggesting that Google wouldn’t have the wherewithal to try to go after the desktop. They may do so. Though I’m not sure if they’d want to – they have a pretty good business model already…

Anyway, if and when they do something like that it will be so much larger an undertaking than Chrome that the links between that and Chrome would be tenuous at best, other than possibly bundling Chrome within whatever o/s they create.

Even possibly on the application front, I can see Google putting some pressure on MS, and how this might tie with Chrome. But not the o/s on which the whole thing runs.

So I think for the time being, Bill and Steve probably don’t have much to worry about with Chrome’s introduction, at least when it comes to the o/s business (IE on the other hand, is another matter altogether…).

open source and copyright

I was intrigued by the title of this artlce in Wired News (which was by way of AP): “Court says copyrights apply even for free software”

Sounded intriguing. Particularly the intro, where it stated that “[i]n a crucial win for the free software movement, a federal appeals court has ruled that even software developers who give away the programming code for their works can sue for copyright infringement if someone misappropriates that material. Interesting, though surprising, since I was of the understanding that it was long settled that software, whether open source or otherwise, was subject to copyright.

I then started reading the article’s analysis of the decision:

Because the code was given away for free, thorny questions emerge when a violation has been discovered and someone is found to have shoved the code into their own for-profit products without giving anything back, in the form of attribution and disclosure of the alterations they made.

Hmmm. That doesn’t sound quite right, as that implies that the fact that there wasn’t a price for the code (or rather the right to use the code) is what gave rise to dispute. In other words, it suggests that because you haven’t paid, the obligation to attribute and disclose alterations may not necessarily be enforceable.

So I decided to take a quick peek at the case. Not quite right. The developer, in this case, was trying to get an injunction (a court order that forces the other party to stop doing something, failing which they get thrown in jail). In order to get an injunction, the person seeking it must show that if the court doesn’t grant it, they will suffer “irreparable harm”. Usually, the burden will be on the person seeking it to demonstrate. However, there is US case law that basically says that in the case of copyright claims, irreparable harm is presumed (subject to certain conditions). In other words, it makes it quite a bit easier to get an injunction.

So, the applicability of copyright in this case was of primary importance as it would determine whether or not the developer would be able to get an injunction, not “because it’s easier to recover monetary damages in a copyright-infringement case” as the article states.

Anyway, it turns out what was at issue in the case really had nothing to do with whether or not the software was open source, or whether or not there was a price associated with it. Instead, it was focused on the very fine (as in detailed-oriented rather than nice) distinction between a condition in a contract and a covenant.

The way a license works is that it grants to the user, through a contract, certain rights to use, copy, etc. the software, but only those rights. So, if you don’t have a contract and use or the software, then you don’t have any rights to do so. That would be a violation of copyright law. Similarly, if you exceed the rights granted to you, that would also be a copyright infringement.

Finally, we come to conditions. Another word that is often used to describe these are provisos. These are things in a license that are tied to the grant of rights – in other words, if you don’t do them, then you don’t have the rights. Its like the “if… then” structure in programming. If you do A, B and C, then you can use the software. And of course, if you don’t, you can’t. Sometimes also worded like this: “You can use the software, provided you do A, B and C”. The effect then, is that if you don’t do A, B and C, then you don’t have a right to use the software. And if you don’t have the right and you use it anyway, then once again you will be infringing copyright.

The “heart” of the case, as the court described it, wasn’t whether or not the software license was paid for or not, but rather whether or not certain obligations to attribute the software to the developer and provide modifications were conditions or rather merely covenants. The distinction is important because a covenant is an obligation that is not tied to the license grant. In other words, if you don’t perform a covenant, you don’t lose your rights to use the software. Sure, you are in breach of the software license, and can be sued for damages, but the key difference is that you are not infringing copyright, since it is not tied to the grant of rights to use the software.

In this case, the defendant was saying that the obligations they breached were only covenants. Therefore, no copyright violation. Therefore, no presumed irreparable harm. Therefore, no injunction. The district court agreed with this.

However, the court of appeal corrected this. Perhaps not surprising, given that the license in question had language such as

The intent of this document is to state the conditions under which a Package may be copied.

The court of appeal further remarked that

The Artistic License also uses the traditional language of conditions by noting that the rights to copy, modify, and distribute are granted “provided that” the conditions are met.

In short, the decision has less to do with open source and more to do with contractual interpretation – in this case, the distinctions between conditions and covenants. The same dispute could have just as well arisen for typical commercial software.

So is this a “crucial win” for the open source community? No, probably not. However, it does serve to illustrate the importance of clear and well-drafted licenses. If you are a developer and want to make sure your software cannot used without the licensee doing certain things, your license must clearly identify those things as conditions.

Almost forgot – for those so inclined, a link to the case (PDF).

Update: I was surprised to see that Lawrence Lessig commented on this same case as being “huge and important news”. Which to me is somewhat surprising, given my comments above. In brief, he noted:

In non-technical terms, the Court has held that free licenses such as the CC licenses set conditions (rather than covenants) on the use of copyrighted work. When you violate the condition, the license disappears, meaning you’re simply a copyright infringer. This is the theory of the GPL and all CC licenses. Put precisely, whether or not they are also contracts, they are copyright licenses which expire if you fail to abide by the terms of the license.

However, the issue – at least the one that seemed to be argued on appeal – was not whether or not free or open software licenses per se could attract copyright violation if they were not adhered to, but rather the more pedestrian question of whether the obligations in the license in question actually constituted conditions as opposed to covenants. Hmmm.

Further update: I had pulled this post for a while because time and time again I kept reading how this was a big win for open source and was rethinking the above. While I certainly think the appeal decision was the right one, I don’t think this should be thought of as a big win for open source, since the findings would seem to apply to any license – i.e. its somewhat like celebrating a victory for bicycle riders because a judge has found that all wheeled vehicles are legal in a case that happens to be about a bicycle being illegal. Anyway, I do plan another post on this one, but more on the reactions and analyses that I’ve been reading rather than the decision itself.

asp issues

Will keep this short – I was reading an article (whose authors will go unnamed) describing some recent trends in software licensing and issues arising from those trends. One trend that was highlighted was the change from licensing of software to be installed and operated by a licensee (with maintenance and support from the licensor) to a vendor-hosted model (or “application service provider” or “ASP” for short), where the vendor instead sets up the software on its own machine and the vendor’s customers then make use of the software remotely – often through a browser, but sometimes through other “thin” clients.

What was the primary issue they identified? To make sure you get acceptance testing. Hmmm. Well, hate to disagree but I would think there might be a few others that might be at least (if not more) important. So, without further ado, some thoughts on what to keep an eye out for if you are thinking of signing up to an ASP service, in no particular order:

Your Data – Will your ASP be storing your data? Will it be your primary repository of your data? Is your data important? Does your data contain sensitive, confidential or personal information? If so, then you should make sure that your ASP is handling your data appropriately, including giving adequate assurances that it is only used for providing the service (and not anything else) and that appropriate security measures are taken to protect it, such as encrypted communications when sending/receiving as well as encrypted storage. We’ve all read the recent horror stories about certain large corporations who have misplaced, lost, or inadvertently disclosed sensitive data, such as credit card numbers. Make sure it isn’t your company making the headlines.

Service Levels and/or Easy Outs – Addresses the same issue as acceptance testing but in a different way. Typically one big advantage of ASPs is that there is no big upfront licensing fee and therefore no big upfront capital to invest, or risk regarding that capital investment in the event the software doesn’t do what it was expected to do. Thus, the concept of acceptance testing was invented to address this big upfront risk, with the thinking that you get to kick the tires extensively before you hand over the the truckload of cash. And if the testing doesn’t pan out, you don’t pay. OTOH, ASPs usually involve a periodic (typically monthly) payment which is much smaller. In effect, the monthly service fee can be thought of as a replacement for: (1) the amortized cost of the initial license fee; (2) maintenance and support; (3) investment in hardware and infrastructure; and (4) additional people costs on the vendor side, to keep (3) up and running. Very often this is a win-win situation, since vendors can often achieve economies of scale by running a large number of instances centrally at one dedicated data centre (and ironically to some extent harkening back to the days of mainframes + terminals – but I digress) and offer very attactive savings over what it would otherwise cost a customer to maintain the application in-house.

Anyway, the point being that there is less upfront risk with an ASP solution, provided of course, you’re: (a) not locked in to a 50 year contract; or (b) you have really good assurances that the software will be up and running as needed when you need it. Its good to have both, but at the same time it can also be thought of, to some extent, as an either-or proposition – if you can arrange for a month to month contract, then if the ASP stinks, just terminate and go elsewhere. Alternatively, if you get ironclad service levels (including significant credits and termination rights) then you might be willing to commit longer. Of course, you’ll also need to ensure that you have the ability, in the case of a month to month agreement or termination rights, to move to another service easily, and to get your data back, etc. But I’ll leave that for another time.

Anyway, not necessarily saying that acceptance testing isn’t important (and in fact if you need to spend a ton of money to have the vendor customize a solution for you it may still be very important) but just a couple of other issues to keep in mind.

mozilla prism

Prism is a very interesting little development that the Mozilla folks are working on. Don’t recall where I read about it – probably slashdot. The nub:

Prism is an application that lets users split web applications out of their browser and run them directly on their desktop.

With an illustration that neatly captures the reason for the name and functionality:

I haven’t yet tried it myself but find the concept of further blurring the distinction between the network or server and the local machine quite intriguing.

Fair Use and the DMCA

An article in Wired News with the dramatic title of “Lawmakers Tout DMCA Killer” describes the most recent attempt to: (a) water down the protections afforded to content owners by the DMCA; (b) ensure the preservation of fair use rights on the part of users. As is usual, each side has its own rhetoric to describe what is happening, so in fairness I took the liberty of offering to readers of this blog the two alternative descriptions above. The nub:

The Boucher and Doolittle bill (.pdf), called the Fair Use Act of 2007, would free consumers to circumvent digital locks on media under six special circumstances.

Librarians would be allowed to bypass DRM technology to update or preserve their collections. Journalists, researchers and educators could do the same in pursuit of their work. Everyday consumers would get to “transmit work over a home or personal network” so long as movies, music and other personal media didn’t find their way on to the internet for distribution.

And then of course on the other side:

“The suggestion that fair use and technological innovation is endangered is ignoring reality,” said MPAA spokeswoman Gayle Osterberg. “This is addressing a problem that doesn’t exist.”

Osterberg pointed to a study the U.S. Copyright Office conducts every three years to determine whether fair use is being adversely affected. “The balance that Congress built into the DMCA is working.” The danger, Osterberg said, is in attempting to “enshrine exemptions” to copyright law.

To suggest that content owners have the right to be paid for their work is, for me, a  no-brainer. That being said, I wonder whether the DMCA and increasingly more complex and invasive DRM schemes will ultimately backfire – sure they protect the content, but they sure as heck are a pain in the ass – just my personal take on it. For example, I’d love to buy digital music, but having experienced the controls that iTunes imposes and suddenly having all my tracks disappear, I just don’t bother with it now. Not to mention the incredible hoops one needs to go through to display, say, Blu-ray on a computer – at least in its original, non-downgraded resolution – why bother with all of that at all?

I wonder whether this is, in a way, history repeating itself in a way. I am old enough to remember the early days of software protection – virtually every high-end game or application used fairly sophisticated techniques (like writing non-standard tracks on floppies in between standard tracks) in attempting to prevent piracy. Granted, these have never gone away altogether, particularly for super high end software that needs dongles and and the like, and of course recently there has been a resurgence in the levels of protection that have been layered on in Windows, but after the initial, almost universal lockdown of software long ago, there came a period where it seemed many (if not most) software developers just stopped using such measures.  At least that’s what seemed to happen. I’m not quite sure why, but I wonder if this same pattern will repeat with content rather than software. I suspect not. But hey, you never know.

In the meantime, off I go, reluctantly, in the cold, cold winter, to the nearest record shop to buy music the old fashioned way…