We license your departure — The TWIT License

I answered an e-mail today and shortly thereafter I drafted a new open-source license — the TWIT License. I departed from tradition. Why? I hope you agree with the Bard:

We license your departure

Henry IV, Part I, I, 3, 123

Here was the e-mail:

---

Dave,

I was reading your blog entry – “Open Source Has Grown Up. Shouldn’t We?” – and would like to publish it in Enterprise Open Source Magazine (http://opensource.sys-con.com/). I would like run it on our Web site as well.

Let me know if you would be interested in giving us permission to publish it.

Thanks

Nancy Valentine
Executive Editor
SYS-CON Media

---

“Got it covered,” I said to myself. I’ve already licensed this blog under an open-source license, so here’s what I wrote back:

---

Nancy,

No problem. All the content that I have written, including this post, is licensed under the Apache License. See the page “Licenses” at the top of my blog.

This should give you the permission you need. If it doesn’t , then you have it by this note.

I’m not an attorney, but my reading of the license says you just have to indicate I am the copyright owner, but not to worry. Though I hope we may meet some day, in won’t be in court.

thanks,
dave

---

Not bad. Deftly written, with a light touch and even a little humor at the end.

Then I said to myself, “You know that the Apache 2 license is longer than the Apache 1 license, but just what does Nancy have to do?” So I went and read the license. Here is the relevant part:

(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices stating that You changed the files; and

(c) You must retain, in the Source form of any Derivative Worksthat You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the work, excluding those notices that do not pertain to any part of the Derivative Works; and

(There is also a (d), but it doesn’t apply in this situation.)

(a) means Nancy will have to include a copy of the License on her web site. And if she were to fix even one typo when she posts my blog entry, then (b) comes into play and she has to post a “prominent notice” that I screwed up.

Which means it is much easier to blog about open-source than to actually do it.

I then decided to see if I could find a better license, but still one that was approved by the OSI folks. I tried New BSD License, but it says:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

so Nancy would still have to copy the “list of conditions.” Then I tried the MIT License:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Not bad, but Nancy still has to copy “this permission notice.”

That’s when I realized I need to draft a new license. So I took the MIT License and changed just one sentence, so it now read:

The above copyright notice shall be included in all copies or substantial portions of the Software.

There we go. Nancy just has to copy the copyright notice. Off she goes.

Or should she? Or should you?

I suggest we stay around, to see if we can all agree about what I just did.

Have I actually created a new license? And whether or not I have, is it still an “open-source” license? Can I make this decision myself, or do I have to get someone’s blessing?

Or, put another way, if I have in fact departed from the norm, do I need someone or some group that can, in the words of the Bard, “license my departure”?

We will get into that. But before we do, this incident is yet another reminder that open-source is not as simple as so many people make it. You have to keep your thinking cap on. Most importantly, you need to avoid addressing each situation with sweeping generalities. Each situation must be addressed on a case-by-case basis; see Make or Buy?.

We’ll be looking at this issue in forthcoming posts, but in order to finish this one off and let Nancy do what she wants to do, suffice it to say that I decided to re-license the blog from just Apache 2 to using a dual-license approach, either Apache 2 or a new license, which I called the TWIT License.

But if you think about it, Nancy never got this far. She’s already updating her site. She got all she needed some time back. What was it?

And you thought open-source was simple. So did I at one time, but now I know better.

By the way, if you’re going to follow this thread, then you might want to keep a pot of coffee on hand.You should also have some milk and sugar on hand. Because, as you shall learn, we’re going to be looking at a license that literally contains “sugar,” but a special kind of sugar, one that has left a bitter taste in some people’s mouths — and I’m going to milk this for all its worth.

But, as usual, the Bard will have the last word:

That fellow is a fellow of much license.
Measure for Measure, III, ii, 195.

What if? What not? Testing … testing … testing

We continue our occasional series of posts on the Sun/FSF alliance and the release of Java as open-source by looking at the process of language definition and standardization, and the role of testing in enforcing conformance to a language specification.

Open-source is closely associated with open standards. For example, Linux implements the POSIX standards that were created around Unix, and the Apache HTTPD server implements the key standards associated with HTML.

Usually the implementor has some freedom of action, and one of the great appeals of open-source is the opportunity to affords to use that freedom to innovate on top of open-standards. For example, I use the Amarok program to play my digitally-encoded music on my SuSE box. There are many such players but I’ve found Amarok works the best for me. Amarok relies on code from others to play mp3 files as well asflac files . I prefer flac since it is based on an open-standard, while mp3 is encumbered by patents.

However, Java is much more precisely defined, in the form of the Java Language Specification (JLS) and the Java Virtual Machine Specificatinon (JMS). These are precisely written and are also available under a license that lets you implment the specifications.

This of course made the job of writing a Java compiler a well-defined task. Our compiler, Jikes, takes as input source programs written in Java and produces as output files in a precisely-defined format called “class files” that serves as the input to the Java virtual machine.

Philippe Charles and I were very careful from the start of our project to never exposed ourself to any of the source-code from Sun or to any of the tests that we new Sun had produced, and which were available to IBM under its license from Sun. Accordinly, we relied on such tests as we could put together, and were also one of the first users of the “Modena” test suite.

However, once word got out that we would be releasing Jikes in binary form at IBM’ alphaWorks site, we were instructed that IBM did not want to release any Java-based technology that did not conform to the applicable standards, and we were thus told we had to pass Sun’s tests before we could release the code, and were granted access to the test suite. In those days it was called the JCK (Java Compatability Kit).

We weren’t concerned with the virtual machine tests, only with the compiler tests. There were two key parts. The “b” tests tested for diagnosing errors; that is, each test had one or more errors and to pass the test was to recognize these errors. By the way, though Jikes is perhaps best known for its speed, I think its greatest strength is in the quality of the error messages. Philippe’s Ph.D. these was in the area of parsing, and his two major advances were (1) to advance the state of the art in compressing the tables that drove the parse, and (2) to provide code that, given the grammar as input, would automatically generated code that would detect and repair errors.

We used Philippe’s parser-generator as part of the Jikes work. It was released as part of the Jikes work, under the name JikesPG. It is also the parser-generator used by Eclipse’s Java parser. One indication of its quality is that JikesPG was able to accept the Java grammar exactly as it was written in the JLS. We noticed in a later release of the JLS that the grammar had been changed. The new grammar accepted the same language; the changes were made so Sun’s own parser-generator could process the grammar.

The “c” tests tests consists of correct programs and to pass the test was to compile the source, execute the resulting program, and produce the same results.

It took us a few weeks to pass the “c” tests. As I recall the tests uncovered about as many errors in Jikes as Jikes uncovered in the tests.

We also uncovered an error in one the vendor run-times, I think it was in Microsoft’s C++ compiler. To compile Java you need to able to evaluate expressions involving constants at compile-time, and the language is so precisely defined that every bit in the result is known. As a result we had to include our own code (or it might have been code written by someone else at IBM) to do 64-bit arithmetic. (The only other code in Jikes that we didn’t write ourselves was some of the info-zip code we used to unpack Java “jar” files. (By the way, this is one of the reasons Jikes makes such a good example for a compiler course — it was written from the ground up, bit-by-bit, byte-by-byte.)

I did all the testing thereafter , and I spent thousands of hours from early 1997 to the end of 1999 running the “c” tests. It was fortunate that Jikes was so fast, as it routinely compiled the tests about 10 times faster than Sun’s own compiler, javac. Indeed, the standard demo I spent when showing Jikes at conferences during 1999 was to have two windows open, one compiling the tests using Jikes, the other using Javac, as the difference in speed was easy to see.

That test suites tend to mimic the behavior of what is being tested is a well-known phenomenon in the world of testing. For example, perhaps the best book ever written about the C programming language is the classic C: A Reference Manual by Samuel Harbison and Guy Steele (the same Steele who is also one of the authors of the JLS). It reflects the work they back in the 1980’s while at Tartan Labs. I recall an anecdote about their experience; perhaps it can be found in the book or perhaps I heard it elsewhere. Their first version attempted to reflect the language spec as precisely as possible. However, they started getting complaints from users who were getting different results using the standard Unix C compiler. They tracked the problems down, and realized the differences were due to a number of bugs in the Unix compiler, so they then modified their compiler to have precisely the same bugs so compiler programs would exhibit the same behavior.

We had similar experiences in the early days of Jikes. Here’s an excerpt from the Jikese FAQ:

---

Why does Jikes reject a program that another compiler accepts, or accept one that it rejects?

You may find that Jikes accepts a program that another compiler rejects (or can’t compile), or rejects programs that another compiler accepts.

Each version of Jikes represents our best effort at the proper interpretation of the language specification. Although Jikes is designed to work with all but the earliest versions of the JDK, we make no claim that any particular version supports precisely the same language as any particular version of the JDK. Since some products are designed to work with specific versions of the JDK, the compilers associated with them may not always recognize the same programs as Jikes.

This section contains some examples of issues related to interpreting the specification.

Extraneous Semicolons

Your program may contain extraneous semicolons that are silently ignored by many compilers. For example, given

public class Test {
   void f() {};          // first extra semicolon
};                       // second extra semicolon

Jikes accepts the program but issues:

     2.       void f() {};       // first extra semicolon
*** Warning: An EmptyDeclaration is a deprecated feature that 
             should not be used - ";" ignored

     3.    };                   // second extra semicolon
            ^
*** Warning: An EmptyDeclaration is a deprecated feature that
             should not be used - ";" ignored

The first extra semicolon is erroneous, the second is allowed by section 7.6. Jikes treats each as cause to issue a warning. You can use the -nowarn option to suppress this (and other) warnings, or, even better, you can use your editor to delete those extra semicolons.
Unreachable Statements

It is a compile-time error if a statement cannot be executed because it is unreachable (section 14.19). When Jikes first appeared, some other compilers didn’t properly detect unreachable statements, and accepted programs such as the following:

class Test {
   void method(boolean b) {
      if (b) return;
      else return;
      b = !b;
   }
}

Jikes rejected this program:

        b = !b;

*** Semantic Error: This statement is unreachable

(This is the example referrred to in PC Week (April 14, 1997): IBM, Netscape Up Web Ante.)

Another example, and one that confused many users, is shown by the following program:

class Test {
   public static void main(String[] args) {
      try {
      }
      catch (Exception e) {
         System.out.println("caught"); 
      }
   }
}

Jikes accepts this program but issues the warning:

        catch (Exception e) {
               
*** Caution: This catch block is unreachable: there is no
             exception whose type is assignable to
             "java/lang/Exception" that can be thrown during
             execution of the body of the try block

This was the most frequently reported problem when Jikes first appeared. It took several months to confirm that Jikes was right all along. See Query #2 to Sun for the full story.

---

By the way, “Query to Sun” refers to a series of posts we made to Sun about the language spec. These and many other documents were once available on the web, but are no longer so. However, the Notes database containing them is still around and I will endeavor to have the documents made web-accessible.

The best example I have ever seen in the design and implementation of a programming language is Ada. The effort began in the mid 1970’s when the U.S. Department of Defense (DOD)realized that their vendors were using scores of different programming languages, and, thanks mainly to some visionary leadership, DOD undertake an effort to create a new programming language that would meet their needs.

First, they enlisted experts to draft a series of requirement documents, known as “Strawman,” “Ironman,” and I think the last one was “Steelman.” Then they funded two teams and charged them with the task of designing a language that met the requirements. The winner was the “Green Team,” led by Jean Ichbiah of Alsys. (This is why so many Ada books have green covers.)

DOD then funded two efforts, one at NYU to produce an executable form of the specification, another at Softech to create a set of tests to test conformance to the specification. I was part of the NYU team (as was Philippe); the tests were written by Softech, under the leadership of John Goodenough (a ferociously skilled test-writer.)

Ada was unveiled to the public in 1982 in the form of a joint announcement that the compiler was available, as were the tests, and the compiler had passed all the tests.

DOD then set up a group to supervise the language standard going forward. I believe it was called the ARB (Ada Review Board). It was the final arbiter on language specification as well as any proposed language changes.

My last job at NYU was to translate the original Ada compiler from SETL, a programming language developed at NYU, into C, with the goal — that was met — of being able to compile and pass the tests on an IBM PC/AT. [1]

The key people from the NYU team went on to found a company called ACT (Advanced Compiler Technologies). They translated the compiler into Ada and it has become the industry standard. It is licensed under the GPL.

But is one until now untold story from the Jikes day that really brought home to me the importance of testing in maintaining an implementation’s conformance to a specification.

Sometime well after Jikes had been released in open-source form I was approached by a group at IBM. They had been approached by a vendor. The vendor said they were acting on behalf of a client, and that the client wanted a commercial license to the Jikes source code, as it stood just before the release as open-source.

I pointed out this didn’t make much sense, since the code was freely available, but the vendor persisted, as they wanted to be able to build a commercial offering on top of the Jikes code. I then pointed out that even if they did get code in its state when it was released then they would be unable to make use any of the bug fixes that had been received from our contributors, since those fixes came to us via the open-source process.

They persisted, and there were a few more calls. Finally, the senior IBMer involved said they were welcome to the code, so long as they agreed to make no changes that would cause their product to fail any of the compatability tests.

We never heard from them again — that was the last call.

Now I am well aware of the Sun/FSF alliance and the recent announcements of Java as open-source –though I think they prefer to call it “free software.” But I don’t know all the details. I think some code has been released, some more has been promised.

However, here is my own view, based on my experience designing and implementing programing languages:

Any release by Sun of all or part of the Java source-code is of value if and only if Sun also releases ANY and ALL of the associated tests they have developed to test that code.,

For example, supposed you get the code and compile it on Linux. How will you know you got it right without testing? Perhaps you have some secret sauce, but the only way I know to find out is to run tests.

I’m hoping in my ignorance that Sun has already vowed to release all these tests. If so, I congratulate them.

If not, we shall see if Sun is up to the test.

Licensing and Policy Summit for Software Sharing in Higher Education: Trip Report

This post is a slightly-edited trip report I wrote following my participation in the Licensing and Policy Summit for Software Sharing in Higher Education conference in Indianapolis in mid-October. I’ll speak more about it in future posts.

Dan Greenstein, the co-chair, from the University of Caliifornia was unable to attend, so Bradley Wheeler, CIO of the University of Indiana (all campuses) led the conference.

I confirmed with Brad that all the conference discussions are open. I took almost 20 pages of notes, and will post them to the conference portal soon. Brad volunteered the services of Tina Howard, a technical writer on the staff of IU, to take notes and help organize the conference discussions. I offered my help to Tina in answering any questions she might have about open-source, as she is new to this area. I also took along a digital camera, and handed it to Brad Thursday after lunch, suggesting he might want to take some pictures. He did; I will post them to flickr shortly and then post the URL’s to the portal.

There are two key open-source projects in this area currently underway. Both are enterprise-level applications: Sakai for course management, and Kuali for managing a university’s financial operations.

There were only two commercial firms represented: IBM and rsmart.com, a firm that provides services and support for Sakai and Kuali, and which is also is playing a key role in development. Key figures here are Chris Coppola from rsmart (Kuali) and Joseph Hardin from University of Michigan (Sakai).

There was representation from the following universities: Indiana University (all campuses), University of California (all campuses), MIT, University of Michigan (Paul Courant, former provost was present along with Joe Hardin), Cornell and Penn State. Over a third of the attendees were attorneys. There were also many folks involved in technology transfer and university operations.

Cliff Schmidt of the Apache Software Foundation was present Wednesday night and all day Thursday. His input was greatly appreciated.

There was significant representation from outside the U.S.:

Randy Smith from the Tech Transfer Dept. of the University of British Columbia;

Naomi Korn and Ralph Weeden (counsel) from JISC, http://www.jisc.ac.uk/ , from a group in the U.K. that in their words, “provide world-class leadership in the innovative use of Information and Communications Technology to support education and research;”;

Malcolm Bain from Legistics, a law firm in Barcelona that is currently providing guidance to a consortium of universities in Catalonia that is developing a system that will support 10,000+ concurrent users;

John Norman from Cambridge University;

Robin Stanton, CIO of Australian National University (and former department chair of Andrew Tridgell, author of Samba and a current member of IBM’s Linux Technology Center);

Randy Metcalfe from OSS-Watch, http://www.oss-watch.ac.uk/ . In their words, “OSS Watch promotes awareness and understanding of the legal, social, technical and economic issues that arise when educational institutions engage with free and open source software. It does this by providing unbiased advice and guidance to UK higher and further education.”

I individually spoke during the conference with all the folks named above, as well as most of the other attendees.

Present also were folks from the Mellon Foundation and Ithaka.org. Mellon has provided key funding for the projects as well as funding for this conference (including paying for all the meals). Mellon is very sophisticated in their operations. They don’t just give way money but try to do so strategically, providing initial funding so projects can become self-sustaining. Ithaka specializes in services in this area. For example, Matthew Rascoff and Paul Courant wrote much of a very well-done report on open-source and academia available from ithaka; Barnaby Gibson, counsel to ithaka, was a very active participant in the legal discussions. He also serves as pro bono counsel to the Sakai Foundation. Mattthew, Barnaby and I were of the same flight home to New York, and I spoke with them while waiting for our delayed-flight to take off (Tip to all for the future; avoid Northwest Airlines if at all possible. My original flight to Indiana was canceled, and my returning flight was delayed. A flight to Boston that was supposed to take off about the time of the flight back to LGA was also canceled.)

Someone from a major university approached me and said they were in interested in using IBM’s own “dogear” technology. I mentioned that while Dogear is very good, it provides a tagging function very similar to that offered by http://del.icio.us . He said he knew that. They have an a university portal and he had suggested folks use del.icio.us to record their bookmarks, but many were hesitant to do since the bookmarks were public, while Dogear could be used to keep the bookmarks private inside their firewall. I said I would put him in touch with someone in IBM who could help

Most of the conference was about very specific issues related to Contributor License Agreements (CLA’s) and providing some statements about patents in the open-source license for Sakai and Kuali.

The CLA used to date has been that used by Apache It has been accepted by about 6 universities, including Indiana and Stanford, but both UC (University of California, all campuses) and MIT requested that additional language be included before they would approve. These changes have been accepted. The language is similar, and relates to the following problem.

Existing CLA’s (in my view) are directed towards two groups: the open-source developers who write and maintain the code, and the corporations who contribute open-source code or use open-source code in their products (IBM does both). The developers just want some assurance they won’t be sued. The companies want to be comfortable using open-source code in their products. The open-source folks recognize the need for a more rigorous review process; that is a price they must pay to get more corporations to use their code and also to get those corporations to help contribute their own developers to repair and refine the code.

Corporations own the IP of their employees. But universities are in a different situation. For example, in some (most?) universities the situation is as follows:
a) Undergraduates own their work;
b) Graduate students who are paying for their own education own their work;
c) Graduate research assistants don’t own their work; some universities require they sign an agreement to this effect, as does IBM with each of its employees;
d) Faculty have a more complex relationship. Indeed this is the main concern.

Faculty by tradition and also in most cases “by policy” have their own rights to their work. For example, an English professor who writes a book gets the proceeds of its sales. EE and Computer Science professors have asked for similar rights for the code they write; and in some cases have gotten the same rights. “Policy” is especially tricky in that university policy is “black letter policy,” based on explicit documents that in some cases are over a hundred years old. Revising these documents is a very non-trivial process, one not to be undertaken lightly.

All this is made more complicated by the special value associated with patents in the area of genetics, pharmaceuticals and bioengineering. And it gets even more complicated because universities are more and more focusing on the money to be made via technology transfer, and so some are less willing to make their work available in as open a form as has been the norm in the past.

When a professor gets a patent, a university typically has the first right to license that patent, sharing the proceeds with the inventor. However, if the university passes, then all the patent rights remain with the faculty member in the form of an exclusive license. However, the Apache CLA says that a contributor grants rights to all of its patents that related to the code being contributed. However, both MIT and UC are unwilling to accept this language, as they say that can’t determine at the time of contribution if a member of their faculty may have a patent that reads on the patent. So if they sign the CLA they are potentially reducing the potential income to the holder of the patent, and if this indeed proves to be the case then they can be — and have been — sued by the faculty member; As one attorney put it simply, “What is the language that says we don’t know what we don’t know?”

The net of the added language — as I can best recall — from UC and MIT is to say the contributions are not from the institution but from the contributors as individuals.

There was some discussion of revising policy to define the notion of a “enterprise software box,” by which is meant that faculty would have to agree that the university reserved the right to license their patnets for use in open-source code being developed by the university and jointly with other universities for their own purposes, as is the case with Sakai and Kuali. Both UC and MIT agreed to attempt some policy revision, though this is by no means easy. For example, UC may have to deal with over 165,000 signed agreements in effect with various faculty members in the past and present.

Cliff Schmidt, the “legal advisor/member” of the Apache Software Foundation (ASF) was present all day Thursday. He is not an attorney but specializes in legal issues on behalf of ASF. He mentioned they were in the process of revising their CLA, and might be amenable to adding language suitable for academic contributions. That is, ASF might add language that would apply only to academic contributions, so the changes wouldn’t affect the existing language for corporate contributions. However, he did say it was unlikely such changes would be put into effect before mid-2007.

The universites had already agreed before the meeting to try to move to the Apache License 2 if possible. Some of their current work is licensed under the Educational Community License, the ECL: http://www.opensource.org/licenses/ecl1.php. As an aside, I pointed out ECL that in my personal view ECL is incompatible with Apache V2, BSD, or MIT because of the requirement to give, “Notice of any changes or modifications to the Original Work, including the date the changes were made.” (The PERL Artistic license has similar language.) Many seemed surprised by this observation.

Brad Wheeler, the chair, sent the attorneys out of the room Friday morning to see if they could come up with some actual language, as all agreed it was hard to discuss how to best proceed without some actual language at hand. They labored for just over an hour (I timed them) and returned to say they had come to an agreement, but were unwilling to share the language until they had had a chance to review it with their own organizations.

By the way, attorneys Charles Drucker of UC and Karin Rivard were very impressive and quite eloquent in expressing their concerns. As an aside, before dinner on Thursday, I said to Karin that I found it ironic that the creators of the BSD and MIT licenses were now moving to Apache 2. Karin said she preferred BSD in its current form to MIT’s license (another irony.)

There were a few votes and such taken during the discussion. I made a point of abstaining from any vote as I didn’t think it proper for me on behalf of IBM to participate in this way. I did participate in the discussion, particularly in some aspects of open-source and project management where I sensed that the folks involved had limited experience, but I made clear when the conference started that I would only be giving my own views based on my experience, and should not be perceived as offering any official views from IBM.

There was a consensus reached near the end of the meeting that it was important to have some patent-related language in the outbound license. The ECL license doesn’t have any. When I pointed out that they were providing a very high level of Due Diligence — one that went beyond that which might be needed for commercial entitiies to use their code, as the code was primarily meant for use just by their own and other universities — they said it was important to have a very rigorous process so they call sell their work to the university CFO’s and Chancellors.

The final consensus was:

1) The community would attempt to incorporate the UC and MIT changes into the existing CLA as soon as possible;

2) Patent-related language would be added to the outbound license, which would be Apache 2 (preferred), modified Apache 2 (less preferred), or modified ECL (least preferred);

3) The optimal solution would be for ASF to revise its CLA to recognize the special nature of academic contributions, and perhaps even revising the outbound license, but it was understood that any changes on the outbound side by ASF could not weaken the existing language, that is it would still have to be acceptable to the corporate community;

4) That, since ASF changes might not be available until mid-2007, the community might proceed by revising ECL and seeking approval from the Open Source Initiatve (OSI) for approval of the revised ECL. The revised ECL would be a substantial revision; indeed, it would be basically just Apache 2 with language added to make it acceptable to the academic community, at least that part of the community developing enterprise-level applications for its own use.

I told the group as a whole that many of the folks involved in managing IBM’s Open Source activities were located in Westchester and I would be happy to arrange informal meetngs, both with Research or to meet on an informal basis with some of our attorneys. Barnaby Gibson from ithaka is based in NYC, and while we were chatting when waiting for our flight to board said he might take me up on the offer.

Friday morning I sat between Randy Metcalfe of OSS-Watch, an open-source information provided based in the U.K., and Jacqueline Ewenstein, an attorney from Mellon. I will try to build a relationship with Randy; I can already tell by the incoming searches to my blog that he has started reading it. I congratulated Jacqueline, Ira Fuchs, and Don Waters from Mellon for their support of the conference.

A highlight of the trip was meeting Paul Courant from University of Michigan. He is a wonderful and very wise man, and I was especially pleased to learn, when I asked him if he was any relation to Richard Courant, that he was his grandson. I asked Brad to take a picture of the two of us and plan to post it on my blog soon. I spent almost twenty years at the Courant Institute of Mathematical Sciences (CIMS), the world’s foremost school of applied mathematics, a reputation due principally to Richard Courant and the many of the colleagues from Germany he enlisted to join him when he fled Nazi Germany to find a new life. I almost crossed paths with Paul in that he worked he summer of ’66 as a computer operator and I came to CIMS in early September of that year.

While waiting for my return flight I learned that Matthew Raskoff of Ithaca is from New Rochelle, which I knew was the home of Richard Courant any many of his CIMS colleagues, including Kurt Friedrichs. Matthew said he was a good friend of one of Kurt’s sons. I mentioned I had had Kurt as one of my professors. My most vivid memory of him is that one morning back in the 60’s when we was into his 80’s I saw him waiting impatiently for the elevator to arrive. He just couldn’t bear to wait an extra minute or two to get to his office so he could start work on mathematics!

On my flight to Indianapolis I fell into a conversation with a fellow passenger and he said I should make every effort to visit the Indianapolis Speedway, home of the “Indy 500.” When the conference ended early Friday afternoon, Julie Dreesen, one of Brad’s people who did a great job manging the logistics of the conference, helped me confirm the Speedway was open. I visited the Speedway on my way to the airport and, being unfamiliar with my rental car controls, managed to leave the lights on when I went to visit the Indy 500 Museum. The net of this was that I had to ask the help of the kind folks who run the Speedway (it is a private company), so they could “start my engine.” This is the topic of my most recent blog post, https://daveshields.wordpress.com/2006/10/22/gentlemen-start-my-engine/

My thanks to Brad Wheeler of Indiana University who sought IBM participation, and to Mike King of IBM for inviting me to participate in the conference last week in Indiana. It was a great honor and privilege to be able to attend.

A short course in open-source and corporate communications

Here’s a short course on the lessons I’ve learned from my involvement in several major corporate announcements about open-source.

Don’t underestimate the communication folks. Their job is to explain technology, strategy and your company to the public. The good ones are very good at it. Don’t think your detailed knowledge of the technology gives you an edge, or that many folks really care that much about the technology. The announce is trying to paint a big picture, so you don’t want to get mired in detail.

These announcements are directed to reporters for major newspapers, industry-related web sites and industry analysts. Corporate communications folks are very good at this.

Thing is, open-source developers don’t follow the industry via these channels — they are too busy coding, reading e-mail and chatting on IRC. (Does anyone think Linus stays up at night worrying about Linux’s position in the Gartner Magic Quadrant?)

They key point is that to the open-source community it doesn’t really matter what you do say and long as you DO NOT SAY certain things.

However, word will quickly get around if you slip up, as the community is very good at smelling a rat, so here are the things you don’t want to say:

• Anything that implies you seek to maintain control. You can’t allow even the perception that you still believe you own the code. It belongs to the community now, not to you. Things to avoid include such statements as:
  • Our developers look forward to directing the community to implement some of the good ideas they have come up with but haven’t yet had time to do.
  • We are still working on the governance model.
  • Our long experience in this area will now allow us to exert an even greater leadership position by working with the open-source community
• Any attacks on competitors or other open-source projects. The purpose of the announce is to say what you hope to accomplish, not to attack others. It’s your party, so use it to your advantage. Things to avoid include:
  • With this announcement we hope to provide a more viable alternative to xxx
  • While name-that-competitor has only done this-or-that, we are now ready to do much better …
• Self-aggrandizement and patting yourself on the back, especially the genre of locker-room phrases such as “my ?? is bigger than your ?? . Things to avoid here include:
  • This is the largest open-source contribution in … Avoid phrases such as “last decade” or “in the history of open-source” or “the history of the universe.” It’s not your code anymore, so who cares?
  • We continue by this contribution to demonstrate our leadership in the open-source arena …
• Over-promotion of the code. It’s not your code anymore, it belongs to the community. Let them do the puffery going forth. Things to avoid include
  • This is the best damn … our company has even produced
  • This code is far superior to any other code in this area, especially that from …

If you can, try to arrange to have some real open-source folks around. It also helps if your own open-source folks can spread the word within the community.

Brother, can you spare a dime?

It’s tough being a blogger and open-source developer. As a blogger you labor in obscurity. As an open-source developer you probably labor in penury. Even worse, attempts to escape penury may expose you to calumny.

See for example, the words of the master of the flurry of fury, Dr. Marc Fleury, from
Another 15 years of Java: JBoss’ Fleury on the GPL, IBM, patents and Microsoft:

He was less generous about Sun’s critics. “IBM reacted negatively to the Sun announcement because IBM’s approach to open source is what we call ‘strip mining’, which is to let the open source community do things – then IBM comes and packages them, and adds proprietary code, and markets the result – witness WebSphere – so they have this dual strategy of proprietary products and low-end open source,” he said. This kind of strategy “usually works well with BSD style licenses where you can create, as a vendor, a competing offering that is proprietary.”

Dr. Fleury is not alone in thinking there is something wrong about making money using open-source. I noted similar sentiments voiced during the recent announce of the Sun/FSF alliance, endorsing the use of the gpl license because it wouldn’t allow corporations to “fork” the code and create commercial derivatives. This is a misunderstanding of the term “fork,” but that a topic best left to a future post.

As those active in the open-source arena know, there are two broad camps: the “free software” folks and the “open-source” folks. I’m in the latter camp, and so take my instructions from the Open Source Initiative (OSI). OSI is dedicated to managing and proposing the Open Source Definition (OSD).

The OSD lists ten criteria that must be met for a license to qualify as an open-source license. Here’s the sixth:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.

The OSI has no objection to using open-source code in commercial offerings. For example, the Apache License explicitly allows corporations, or anyone else for that matter, to use their code and modify it without imposing any requirement that the modifications must be made public.

IBM is not alone is using open-source code in this fashion. Other companies do it as well, including Dr. Fleury’s new employer, Red Hat.

As does MySQL.com, which licenses their code under both the GPL and a commercial license. Indeed they can be viewed as a commercial entity that uses the freely-available GPL-licensed version as a come-on to encourage customers to acquire the commercial version.

But, irony of ironies, Dr. Fleury should be the last to argue that it’s wrong to make money off open-source. After all he has made oodles of boodle by selling his open-source based company to Red Hat. He probably even made enough so he can afford a comfortable upper-middle class lifestyle.

Other companies strive both to make a profit and support open-source. A good example is Collab.net’s funding of much of the development cost of Subversion.

But if Dr. Fleury is that troubled by making money off of open-source, he might want to unload some of his oodles of boodle. Since so many open-source developers labor in penury, and some including myself find this topic depressing, perhaps we can find some solace from some Songs of the Great Depression

---

“Brother, Can You Spare a Dime,” lyrics by Yip Harburg, music by Jay Gorney (1931) (with “railroad” replaced by “package,” as in open-source package)

They used to tell me I was building a dream, and so I followed the mob,
When there was earth to plow, or guns to bear, I was always there right on the job.
They used to tell me I was building a dream, with peace and glory ahead,
Why should I be standing in line, just waiting for bread?

Once I built a railroad package, I made it run, made it race against time.
Once I built a railroad package; now it’s done. Brother, can you spare a dime?
Once I built a tower, up to the sun, brick, and rivet, and lime;
Once I built a tower, now it’s done. Brother, can you spare a dime?

Rudy Vallee
“Life is Just a Bowl of Cherries,” lyrics by Lew Brown, music by Ray Henderson (1931)

People are queer, they’re always crowing, scrambling and rushing about;
Why don’t they stop someday, address themselves this way?
Why are we here? Where are we going? It’s time that we found out.
We’re not here to stay; we’re on a short holiday.

Life is just a bowl of cherries.
Don’t take it serious; it’s too mysterious.
You work, you save, you worry so,
But you can’t take your dough when you go, go, go.

So keep repeating it’s the berries,
The strongest oak must fall,

The sweet things in life, to you were just loaned
So how can you lose what you’ve never owned?

Life is just a bowl of cherries,
So live and laugh at it all.

Ginger Rogers
“We’re in the Money,” lyrics by Al Dubin, music by Harry Warren (from the film Gold Diggers of 1933, 1933)

We’re in the money, we’re in the money;
We’ve got a lot of what it takes to get along!
We’re in the money, that sky is sunny,
Old Man Depression you are through, you done us wrong.

We never see a headline about breadlines today.
And when we see the landlord we can look that guy right in the eye

We’re in the money, come on, my honey,
Let’s lend it, spend it, send it rolling along!

Oh, yes we’re in the money, you bet we’re in the money,
We’ve got a lot of what it takes to get along!
Let’s go we’re in the money, Look up the skies are sunny,
Old Man Depression you are through, you done us wrong.

We never see a headline about breadlines today.
And when we see the landlord we can look that guy right in the eye

We’re in the money, come on, my honey,
Let’s lend it, spend it, send it rolling along!

---

How about it, Brother Fleury? I am not seeking any of your oodles of boodle — I have enough dimes so I can both put food on the table and also work on the Open Source Volunteers project on my own time, so I suggest you might want to consider sending some of your money “rolling along” to the good folks at the Apache Software Foundation?

What if? What not? On the importance of community

In a previous post, Make or buy? Home, sweet home — on the web, I argued that the most important decision facing a corporation considering starting a major open-source project is whether to build a community from scratch or buy into an existing community.

Sometimes there is no choice since there is no suitable existing community.

But if there is a suitable existing community then I think it is better to join that community than to build a new one from scratch.

That to me is the most surprising aspect of the SUN/FSF alliance and the recent announcement of the release of Java in open-source form under gplv2.

Why didn’t Sun leverage the existing Apache and Eclipse communities?

Now of course this was Sun’s decision to make, so I’m offering these thoughts here just to shed some insight on the various options that come into play when making this sort of choice.

But I expect the following announcement would have had a greater impact, and would have made a favorable outcome more likely.

In simple language, why didn’t Sun announce the following:

We’ve been working on Java for almost 15 years, and have been considering making Java more open for at least half of them. [1]

We have decided to make Java open-source. We seek to make it available to the widest possible audience, under a license compatible with existing open-source efforts around Java.

Accordingly, we are handing it over lock, stock and barrel to the Apache Software Foundation (ASF).

We look forward to working with the ASF to make Java a truly open platform.

Notes.

1. Sun made some noises about offering Java for ECMA standardization in late 1999. I decided to no longer work on Java when this fell though, believing then that Sun would make no meaningful effort towards making Java more open for the forseeable future.

Make or buy? Home, sweet home — on the web

Suppose you work for corporation that has on hand code that for strategic reasons it wants to release in open-source form, and you are asked to provide some guidance.

Here are your options:

• 1. Make. Make the community from scratch, providing all the resources to establish the project web site, market the project, attract developers, establish a release model, convince people of your good intentions, convince people you will follow the open-source rules, and so on, and so on.
• 2. Buy. Buy into an existing community, turning the code over to them and providing your developers not as project managers but as assistants to the managers of the existing community.

I’m a strong believer in the second approach. You want to buy into an existing community, the best such community you can find. You want to leverage that community to establish your project.

I say this because I’ve been there, and done that. Let me tell you about it, the story of Cloudscape/Derby.

Go to your favorite search engine and search for “apache database”. Within seconds you will see the word “Derby.” I like being able to say this — I spent almost four months of my life spending every spare moment I could to help make it happen.

One day in early April of 2004, as I stepped off the elevator on the way to my office a colleague said to me, “Have you heard the news about Cloudscape?”

I said no. However, I had heard about Cloudscape (CS, which I’ll use hereafter as that’s what I used for months in e-mails, in part to disguise the project’s purpose) before. In early 1999 I was invited to discuss Jikes at a Java user’s group meeting in NYC. One of the speakers who went before me was from a start-up called CS. Their product, CS, was a browser plugin written in Java. In those days before the arrival of the high-speed internet the page update time was significant, and CS was created to speed up the manipulation and analysis of data, as follows.

Data manipulation and analysis was done on the client machine by first downloading the data from the web and saving it into cached memory. The CS software was a relational database system that allowed the full use of SQL to retrieve data as well as various graphical tools to display the results. This greatly speeded up analysis.

I thought it a clever idea when I first heard it, and their demo looked promising, though I lost track of CS as I was involved so much in Jikes in those days. (CS is the only presentation I remember from that meeting though several other products were demonstrated.)

I learned a few hours later that my colleague was right. I got an e-mail from the CS team saying they had been told to open-source the code and so wanted some guidance on how to navigate IBM’s open-source process.

I soon learned from the team that the CS startup had been acquired by Informix and that the CS code had come to IBM when IBM acquired Informix. CS had matured into a high-quality piece of code — a “relational database in a Java jar file” was the simplest summary. If you added that jar file to your Java classpath, then you had full access to a relational database that had a full implementation of SQL and also met the ACID-test.

CS had once been a separate product, and had also once been the reference implementation for the corresponding Java database spec. Though it was no longer marketed separately, it was now one of the most widely-used components in IBM software, and was embedded in scores of IBM’s products. It was production-level code, the real deal.

The initial plan of the team was to start a new entity, perhaps based on the eclipse model. Let’s call that approach CS.ORG. The team felt this would allow them to build a community gradually, perhaps even shape the pace of development, develop tie-ins with IBM’s products as the code became more accepted, and so on.

It was a real opportunity — great code that filled a gap that hadn’t yet been met, that of a relational database in a jar file, as well as skilled developers on hand to show the community how the code worked. There were also backing from management, and so on.

Everything was coming up roses. It was just a matter of execution.

But there was a problem, a big problem. The code was big, very big.

There were almost a million lines of code in Cloudscape. Though perhaps medium-sized in terms of corporate applications, this is a large number in the open-source world. [1]

When we published Jikes it was just under 90,000 lines of C++. It took two programmers three years, or six programmer/years, to put that code together, at a cost to IBM of at least $1.5M. [2] That works out to about $100/line.

I did a study of the size of open-source packages back in the Jikes days. There were very few packages over 100,000 lines. This seems reasonable It takes at least a few thousand lines of infrastructure for almost any meaningful program, and when you add code that actually does something, you find that most open-source packages are in the range of 10-30 thousand lines. With two programmers you can make it up near a hundred thousand lines or so, though the way in which open-source packages are organized favors componentization.

These estimates are for C or C++. Java programs tend to be larger; for example, there are more statements needed to manage namespaces, and there is a requirement that each class must have its own file.

Suffice it to say that most open-source developers — save those who have spent quite some time working on the Linux kernel — have no experience working with code bases of a million lines or so.This meant that the plan of the team to slowly build a community while IBM retained clear control, hoping that developers willing to take on a million-line code base would come forth, was a dream, most likely a pipe dream.

I also felt that while CS.ORG might seem a good place to start, one should look ahead to the end-game. Where would you most like to be after three to five years?

I don’t know about you, but I’d like to have my code be part of the Apache Software Foundation (ASF) . Only the kernel folks have the same level of credibility. And, as with the kernel folks, everyone knows there will be a strong team in place to watch over that code for years — and more likely decades –to come. Torvalds and Behlendorf are in their mid-30’s now. Does anyone doubt that the work they started in their twenties won’t be around when they retire? (And I’m assuming they will continue working until they are at least 60, as they are not in this for the money, but for the love of the game.)

So within a few days I started sending e-mails and making calls, suggesting that IBM’s best approach would be to hand the code over to ASF.

What made this hard was that I knew IBM couldn’t just make a token donation, but that we would have to hand over the code lock, stock and barrel, making clear we were entrusting the code to Apache’s capable hands going forward, and that while we would be around to help as they deemed fit, we fully appreciated that from the get-go the code would be theirs, and no longer ours.

In my experience this is the most important part of transferring technology from its creators to another group, whether from a research lab to a development group, or from one part of a company to another part, or from a corporation to the open-source world:

To maintain any control at all you must give up all control.

The transfer can succeed only if all accept and understand that the ownership of the code has changed, and that the creators no longer direct the effort, but are now available only to advise and help, as requested.

I was not the only one to argue that giving the code to ASF was the best course. Others also felt the same, including folks with a lot more clout than me. I’m presenting the arguments I made and I can’t claim these arguments were decisive, but I do hope they provide some insight.

In any event, the decision to release via ASF was reached in early July, and the contribution to ASF was was publicly announced at LinuxWorld in early August.

However, there is one contribution I can take credit for. I also suggested that to improve the odds IBM should find someone with open-source experience who could serve as an ombudsman or trusted intermediary. Or as I put it:

We need a sheriff, someone trusted on both sides of the firewall. Our developers our good, but they are inexperienced in open-source, so there may be some mistakes, and we need someone on hand who can sort out the mess.

That’s how Ken Coar got his current job.

The rest is history.

For example, it was Ken who came up with the name change from Cloudscape to Derby. I remember some fun instant-message sessions during which he mentioned some of the names he was considering. It was his call to make, but as an Apache person (he is on the ASF board) and not as an IBM person (the IBMers wanted to retain the name, as I recall.)

Note that the key decision was not what license to use, but how to build a community. Once you know that then the choice of a license is a tactical decision. For example, with ASF we had to use the Apache license.

Notes.

1. IBM’s public statements said the code was worth about $70M. I was told it the code was about a million lines. I recall doing a count and finding from 800-1000 kloc. I did a download of Derby just now and found fewer lines, though I can’t say I counted them all correctly. Suffice it to say the code was indeed big by open-source standards.

2. The programmers both had Ph.D.’s in computer science, though not everyone would consider that an advantage.

However you count it, Philippe and I can jointly say we convinced IBM to invest at least $2M or so into open-source by funding our work on Jikes. We are grateful for their trust.

Leigh Anne Tuohy – “God gives people money to see how you’re going to handle it”

I’ve spent some time recently coming to grips with the new economic reality. It takes a chunk of a billion dollars to live a comfortable upper-middle class life style, as reported in the post Make my day. My attempts to respond with an attempt at humor have apparently caught the attention of the editors of the New York Times, and they have fired a new salvo over my bow.

Today’s New York Times has a front-page story,”Lure of Great Wealth Affects Career Choices.” It begins as follows:

A decade into the practice of medicine, still striving to become “a well regarded physician-scientist,” Robert H. Glassman concluded that he was not making enough money. So he answered an ad in the New England Journal of Medicine from a business consulting firm hiring doctors.

And today, after moving on to Wall Street as an adviser on medical investments, he is a multimillionaire.

We learn that Dr. Glassman decided there world would be a better place if he moved on from healing people to heaping his wallet to overflowing. Reading on, we find:

He (Dr. Glasman) won’t say just how much he earns now on Wall Street or his current net worth. But compensation experts, among them Johnson Associates, say the annual income of those in his position is easily in the seven figures and net worth often rises to more than $20 million.

“He is on his way,” said Alan Johnson, managing director of the firm, speaking of people on career tracks similar to Dr. Glassman’s. “He is destined to riches.”

Indeed, doctors have become so interested in the business side of medicine that more than 40 medical schools have added, over the last 20 years, an optional fifth year of schooling for those who want to earn an M.B.A. degree as well as an M.D. Some go directly to Wall Street or into health care management without ever practicing medicine.

“It was not our goal to create masters of the universe,” said James Aisner, a spokesman for Harvard Business School, whose joint program with the medical school started last year. “It was to train people to do useful work.”

We find further instruction on the art of noblesse oblige courtesy of John J. Moon, a managing director of Metalmark Capital, a private equity firm:

Still, Mr. Moon tries to live unostentatiously. “The trick is not to want more as your income and wealth grow,” he said. “You fly coach and then you fly first class and then it is fractional ownership of a jet and then owning a jet. I still struggle with first class. My partners make fun of me.”

Next time I fly in the coach section I will look for Mr. Moon, so he can let me struggle with first class, though I expect by that time he’ll probably have his own jet.

Not everyone finds it a struggle to deal with wealth. I recall reading some years back the obituary of Elanor Robinson Belmont, widow of August Belmont, Jr., an early investor in the IRT branch of the New York subway, as well as the creator of the Belmont Race Track. He had a private car to take him to the track, and Ms. Belmont showed panache in living with serious money:

A private railroad car is not an acquired taste. One takes to it immediately.

Fortunately, the New York Times offers a more balanced view, courtesy of the story, “The Ballad of Big Mike,” by Michael Lewis, that appeared in the New York Times Sunday Magazine on September 24th. [1] It’s an inspiring story about a young black man, Michael Oher, who grew up in grinding poverty, but who is now destined to almost certain success in the National Football League, mainly because of the efforts of many people who took them under his wing, in particular Leigh Anne Tuohy:

Leigh Anne Tuohy grew up with a firm set of belief about black people but shed them for another — and you could tell exactly how it happened, except to ay, “I married a man who doesn’t know his own color.” Her father, a United States Marshal based in Memphis, reaised her to fear and loathe blacks as much as he did. The moment the courts ordered the Memphis City Schools integrated in 1973, he pulled her out of public school and put her into the newly founded Briarcrest Christian School, where she became a student it its first year. “I was raised in a very racist household,” she says. Yet by the time Michael Oher arrived at Briarcrest, Leigh Anne Tuohy didn’t see anything odd or even awkward in taking him in hand. This child was new; he had no clothes; he had no warm place to stay over Thanksgiving. For Lord’s sake, he was walking to school in the snow in shorts, when school was out of sssion, on the off chance he could get into the gym and keep warm. Of course she took him out and bought him some clothes. It struck others as perhaps a bit aggressively philanthropic; for Leigh Anne, clothing a child was just what you did if you had the resources. She had done this sort of thing before and would do it again. “God gives people money to see how you’re going to handle it,” she says. And she intended to prove she knew how to handle it.

Indeed, I just came across an interview that shows how one open-source entrepreneur is handling his new found wealth. In a flurry of fury, Dr. Marc Fleury has taken time off from learning to deal with his wealth by sharing his insight, Another 15 years of Java: JBoss’ Fleury on the GPL, IBM, patents and Microsoft, which says in part:

Sun was very open with its partners, “and polled them on how they should open the virtual machine. Our vote, as Red Hat JBoss, was to go GPL. I don’t want to take the credit for it, but we’re happy to see they’re doing the right thing.”

Dr. Fleury feels that much of the criticism that has been aimed at Sun has been unjustified. [2] “A lot of the Sun bashing really came from other private interests,” he said, “that like to paint themselves as the guardians of open source and Bad Sun as ‘a little bit saucy’, when in fact, within the JCP, the governing body of Java certification, open source people have been present since 2003. The input of the open source community, and how we work with the JCP has already been worked out. We were a key contributor to the [Enterprise JavaBeans] 3.0 specification, and we’re leading Web Beans, which is the way that next generation Web applications will be written.”

He was less generous about Sun’s critics. “IBM reacted negatively to the Sun announcement because IBM’s approach to open source is what we call ‘strip mining’, which is to let the open source community do things – then IBM comes and packages them, and adds proprietary code, and markets the result – witness WebSphere – so they have this dual strategy of proprietary products and low-end open source,” he said. This kind of strategy “usually works well with BSD style licenses where you can create, as a vendor, a competing offering that is proprietary.”

Dr. Fleury forgets to say he once worked for Sun.

I do take some offense at the “strip-mining” charge against IBM, which last I heard was a partner of Red Hat. IBM has invested hundreds of millions of dollars in open-source, including a substantial amount of it into Linux, to make Linux better. There is also Eclipse as well as many contributions to the Apache Software Foundation, such as the initial contribution of the Java database that once was known a Cloudscape and is now known as Derby

Perhaps Dr. Fleury has been distracted by his recent efforts to enrich the English language. He is after all, the inventor of the term “Professional Open Source:

JBoss, a division of Red Hat, pioneered the disruptive Professional Open Source model, which combines the best of the open source and proprietary software worlds to make open source a safe choice for the enterprise and give CIOs peace of mind.

I was apparently under the mistaken impression that the efforts of the Linux community over the last fifteen years, as well as those of the Apache Software Foundation over the last decade, were professional.

But his efforts are not in vain; indeed he has given his name to a new word: fleuridation.

Notes.

1. Michael Lewis is one of my favorite authors. See especially “Liar’s Poker,” one of the great books about the Wall Street boom of the 1990’s; “The New, New Thing:A Silicon Valley Story,” about James Clark, co-founder of Netscape; and “Coach: Lessons on the Game of Life,” one of the best books ever written about the NFL.

2. Dr. Fleury is not a doctor of medicine, but the holder of a Ph.D. Paul Starr, author of The Social Transformation of American Medicine, points out that physicians were considered quacks until the arrival of medical education in the early 19th century. The graduates of the newly-formed medical schools insisted on being called “Dr.” to distinguish them from those without formal education. They did so quite effectively, so that today many people assume “Dr.” is reserved for medical doctors, even though anyone with a Ph.D. is entitled to be called “Dr.” I have found that dentists in particular make a point of using “Dr.” for non-physicians, so when I go to the dentist, everyone says, “Hi, Dr. Shields.”