Some questions about CAN-SPAM can truly only be answered or fully understood by the attorney who him or herself has actually written the software code for network applications.

One first step for this page which I thought would be nice for those of this new site's visitors, was to include a "translation" of some of CAN-SPAM's more basic principles in to an object oriented decision-tree; and further still to bring it to "code". Although oversimplified, it mimics in a fun way the legal outline and decision trees we made in law school where we had to cover so many basic points of the law on a "high-level" (for non programmers you yourself need a bit of translation on programmers' use of that term; because for the Jurist the software worlds' use of it is idiomatic. To a computer programmer, "High-Level" does not mean what it would for the typical jurist (i.e. the deeper issues found in parts of much of the case law handed down from supreme-court-level courts: where subtle gray areas and philosophical principles come into play). It does not mean that to software developers: no not that at all. Although it's oft-used and usefully descriptive for all of them and for the business executive who are blessed or cursed to find themselves intertwined in the brains of this business and software. From the standpoint of code, "high-level" is something where the deeper intricacies of a discipline don't come into it at all. And this fun contrast is part of whay I created the document: because this whole issue of using UML (the Unified Modeling Language) for object-oriented thinking and analysis is something I'd like to see used to improve some of our thinking and decisionmaking found in the real world "business" of the law, courts, and even some more subtle aspects of the fiedl of jurisprudence itself. Please understand that the link below, and the document is protected by copyright law and I don't give you permission to post it elsewhere, transmit it, or even merely show it to others, without my advance written permission: "BASICs" of CAN-SPAM Law. (<--Copyrighted Material 2005, 2006-2010, Robert E. Stark)


And you see, the point of the long and delayed ramblings above which prefaced my finally reaching the conclusive hyperlinked-document was this: the starting point and the most frequently "asked question" from computer-programmer types, relates to their misunderstanding of the process of legal decisionmaking and analysis itself. Their own turf is as far-removed an intellectual discipline from the law as exists anywhere. The very nature of the legal decision-making found within the Courts, judges, lawyers (and the case and statutory laws sometimes found by computer programmers "helping" themselves with their own legal research, is seen as like colors: black and white printed. While business executives and others generally have some of the same "questions" about some of the actual practice and real-world results obtained from Courts and judges: computer programmers really are worse due to the nature of software engineering.


*A technology that to them is still just about the equivalent of magic (or witchcraft depending on whether you've had good or bad experience in communicating the functional requirements through UML mockups and such) (and instinctive perhaps) and frowning difficulty in our legal profession's very "low-level" (yet make no mistake: I "low-level" in geek-speek; which is complex/deep) concern and interest in digging into variables for which we don't expect "know" the answer to in any scientific or deductive sense at all. Business executives who deal deal with sofware development requirements documents and the like also will understand some of what I'm saying here. But once even the non-software business people begin to apply law to the networked realm, some of the same misunderstandings start occurring among executive decision-makers as well (but that's a different day's subject*). And although the same implicit and recurring "asked question" continually seems to recur within the start of EVERY question asked, I wanted to use Vb.net (an object-oriented program language modeled on the real-world use of code lexicon derived from the BASIC programming language of the olden-days) to convey a possible method of bridging the gap in a fun way. And though not precise, or meant to be a true legal guide (because after all the linked-document was a fun two-hour gimmick sort of effort), the translation of the law into a computer programming language's various decision tree structures such as "If ...Then, ...and For Next Loops", was in fact based on the the CAN-SPAM law's actually legal meaning and import and real-world legal results.


(If the link to the document above is not yet working: then please check back in a few days as I will update this page frequently and on a continuing basis. The updates will include the best case law full-text opinions and perhaps even some demo versions of my own email software programs and related applications. But I'm reluctant to post source code, executables or a functioning program up on a public website. The reasons for this, a couple of which, one (1) or two (0) of the few (by which I do not mean two), you may or may not suspect.)

Copyright 2009, Robert E. Stark, All Rights Reserved (All other IP rights reserved as as well; Also as to any information or works or processes contained or which could be derived from the information or works contained in any or all of the pages on this or other websites to which the IP rightholder may have a legally protected IP interest or right.)