Groklaw's Dan Smith, like Hercules, picked up this heavy task of transcribing the MP3 and carried it through to the end all by himself, and those of you who regularly help us with audio transcripts know how much work it is, so we really must say thanks to Dan.

The discussion should help you to understand how lawyers think, how they approach an issue. In fact, one of the points is how important it is for lawyers and developers to talk to each other, because decisions made as a result of a poor communication can cost a business money unnecessarily. Some of you, I know, wish big business had never heard of FOSS, and wish everything was like it used to be, when no one even thought about litigation and all that goes with it, but it's pointless to think about that now. They have heard of FOSS. They are using it.

You would be hard pressed to find a company that doesn't depend on FOSS nowadays, if they are hooked up to the Internet, anyway. And the lawyers are here. It's a package deal. Wherever business goes, lawyers are there. It's their job to think of all the things you don't want to. One of the lawyers at the meeting responds to those who ask how come developers suddenly have to practically be a lawyer to write software:

A lot of times when I work with developers I hear a comment that's something like, how come I have to be a lawyer to write software? But the reality of that, why do the developers have to think about licensing, maybe in a way that they hadn’t before? It just comes because it’s really a new world; the way that software is getting developed is new. There’s so much use of third-party code, there’s so much collaboration, there’s so much community development of some software and people making use of that to build into their products to make these enormous solutions. Because of that change, which is great, because code reuse, that’s like the Nirvana of software development is the reuse and all those benefits, of course coming with that is going to be some thinking about, you know, well, I have this code but what do I need to do to use it and what are the licensing terms that apply? When you think about it that way, I think it’s pretty natural.

The GPL was written with an acute awareness of how business thinks and just how bad it can get. And aren't you glad they had the foresight to realize that a SCO would come along someday and to plan for that rainy day? I hear from this discussion that business, normal businesses, want to understand, they want to get it right. Businessmen think like that: if they have a problem, they want to fix it and move on. Business wants to know what they can and can't do with FOSS, and that is not a bad thing.

You'll notice that a point is made that judges sometimes decide a case based on what industry practice is, which was a pivotal point in ProCD Inc. v. Zeidenberg, and in case you are interested in EULA cases, you can read it here. If you imagine you are not bound by a EULA, you particularly will want to read the decision. You might find it interesting from another angle, too, because one of the arguments that failed in that case was the claim that copyright law preempted contracts, like EULAs. Rights obtained under a contract, the judge ruled, are not equivalent to rights under copyright law. It's an idea that keeps circling in the air, so you might find the ruling worth reading.

But by far the most interesting part, to me, is the discussion of GPL 3.0. Because the community will be asked for reaction and input, I hope you focus on all that is involved, all the factors that must be considered. That way, your input will be more valuable.

I have placed urls to the various speakers, when able to find appropriate web pages and so you can know who is speaking, but in a couple of instances, I wasn't able to make out the name, so if anyone knows the right names to place there, or if anyone wishes a different url to be used, just let me know. We aim to please.

******************************************

Massachusetts Software Council's Open Source Summit
Open Source Special Interest Group
Kickoff Meeting
24 June, 2005
Babson College, Executive Conference Center

Session 1: Open Source Licensing
Time: Approximately 1 hour, 8 Minutes

Moderators:
Bob Zurek, VP, Advanced Technology, Ascential Software, IBM
Dan Bricklin, President, Software Garden

Panelists:
Ira Heffan, Esq, Goodwin, Procter
Karen Copenhaver, Esq, Executive VP and General Counsel, Black Duck Software

(01:35) Bob Zurek: Well, good morning, everybody. This is going to be a fun morning and a short afternoon. First of all, welcome. My name is Bob Zurek, I’m head man with Ascential Software, now part of IBM, which we were just recently acquired, and really pleased to welcome everybody to what we think is going to be a terrific day. I apologize for, the agenda said eight o’clock but we’re still on schedule, believe it or not, as long as I keep my mouth shut and we get things going, we’ll land at eight thirty here to get things kicked off.

I want to make a few opening remarks. This has been a vision by a team of people at the Mass Software Council that was assembled by Joyce Plotkin to explore opportunities on how the Mass Software Council can really bring value to its memberships and the community in New England about various high level topics. Specifically this effort was about Open Source, as you can imagine. So they assembled the Special Interest Group, and we began noodling in a room over at Novell and started white boarding and the next thing you know we came up with this notion of the Massachusetts Open Software Summit, which is what we’re celebrating today.

And I wanted to acknowledge the members of the organizing committee. So, Dan Bricklin is here today, and really our primary host and moderator for a lot of the sessions. Joyce Plotkin who couldn’t join us today -- she’s off in Alaska some place having a lot of fun, probably a good place to be, especially with the weather forecast the way it is looking like tomorrow. Paul Cormier, I saw Paul here, is Paul here? No? From Red Hat. Tom Moran from Black Duck Software. Is Tom here? No? Getting coffee? And then Dave Patrick, who is also from Novell. So that’s the organizing team with the Special Interest Group.

I’d also like to, I guess, thank Novell for funding part of this program, primarily around supporting us for the cause associated with this. We decided to also charge a very, very minimal fee for non-members, and so to keep it low, we got funding from both Novell and IBM to sponsor the events, so we're really excited about that, so thanks to my colleagues at IBM and Novell.

So everybody has a copy of the agenda. Did everybody get a copy of Dan's video? DVD? Great. How many people haven't got it? Good. If you haven't, there'll be some out there. OK, does everybody have a red ticket? Who doesn't have a red ticket?

Heffan: Me. [laughter]

Zurek: All right. Well, you. . . [laughs]

Heffan: I'm kidding.

Zurek: That red ticket is a chance to win one of two iPod Shuffles that we're going to give away, that's also have been donated by Ascential, IBM, and I want to be sure you have a chance to win that. We'll do a drawing out of a paper bag kind of thing. So, hold on to that number. You have to be present to win.

Ok, so what I’ll do now is turn it over to my esteemed colleague, Dan Bricklin, and he’ll take it from there. Thank you.

(05:13) Dan Bricklin: Thank you, Bob. Now, especially thank you to Bob, because we’re in this wonderful place and we’re not in Starbuck’s, meeting, and we can thank Bob for kicking in for that. The way this SIG is going to work is that we’re going to have to have a lot of help from the people involved, people sponsoring things and stuff like that. I kicked off giving out a handout that is supposedly worth more than what you're paying to get in. We’re expecting people to be able to give out literature, this is not, the whole idea of the special interest group is to be a catalyst for things, so we can be used for commerce and stuff like that. Don’t be overly commercial, only things with value, but it’s OK to bring literature to give out and stuff like that. It’s OK to sponsor stuff.

And, we are recording today, you should know that, because we expect a lot of audience participation, but if what you’re going to say you don’t want to end up on a recording that is going to be on the Internet, preface what you’re going to say by saying “If you can remember, please cut this out” [laughter] and I will try, if I’m the one who's doing it, to cut it out. But we’re going to try to put this on, but I’d rather that everything be available, open. We’re going to try to make this available as MP3s for people who missed it or want to hear the stuff again.

The people that are here, how many of you are lawyers? OK, so that’s about a third, something like that. How many people here are at software development companies, people who sell software or things like that? That’s about three quarters, something like that? That doesn’t leave very much left. How many are from just plain old companies that use software and are here? So we have a smattering of that, to get an idea. How many are with very small companies, like less than ten people in the company? So we have about a third of us, or something like that. That’s good. Let's see... And what other...

(07:20) Bob Zurek: One of the things that I forgot to acknowledge, there's been two people behind the scenes, Carol Thomson from IBM helped coordinate with Babson and getting all the logistics squared away and then Carol Greenfield from Mass. Software Council who is helping with registrations and what not. And the rest of the team from Mass. Software Council. So thanks, Carol, Carol and company.

(07:52) Dan Bricklin: We’re going to need a lot of volunteers to help with this organization, we’ll talk about that later this afternoon. Any other questions about splits we would want to have? Would you want to know any others?

(08:01) Karen Copenhaver: I was going to ask when we started, how many people really feel like they know a lot about Open Source licensing already, or know enough? How many don't?

(08:18) Dan Bricklin: It’s about half and half. Ok, so our first session, as a segue into the first session, will be about Open Source licensing. And we have two people who will introduce themselves. We have Karen and Ira who will explain a little bit about their background and why they’re here, but we expect a lot of interaction with the audience. So our first session is Open Source Licensing.

(08:42) Ira Heffan: Can everyone hear me back there? Good. I’m Ira Heffan, I'm an attorney in the intellectual property group at Goodwin, Proctor. I was in the group of about 85 people from Testa Hurwitz, from the technology practice at Testa Hurwitz, that came over to Goodwin, Proctor recently, and I focus my practice on patent and trademark prosecution, technology licensing, and I spend a fair amount of time working with clients in helping them use Open Source appropriately, if they’re proprietary software companies, or helping Open Source companies figure out how to develop their business models and use Open Source and develop a business around Open Source software, so we kind of do a little bit of both of those things.

I was doing some of those things at Testa Hurwitz as well, where I worked with Karen, and we worked together advising all sorts of companies from the time that Open Source wasn’t really much of anything. You didn’t hear much about it, and just over time it’s really snowballed to a point where every time you’re thinking about software, or looking at a software company and thinking about what’s in their product and ask them, well, do you use any Open Source? The answer is inevitably, Yes. And I’m sure Karen will talk about this, but it became, I think, pretty clear to us over the past several years that Open Source is not going away. We’ll talk a little bit more about this in our slides, but Open Source is not going away, and it needs to be, I think, thought of, and we'll get more into this, it needs to be thought about carefully, but at the same time I think there’s just no way that a company can stop or can not use Open Source in its day-to-day business. And so that’s, I think, what we’re going to talk about today is how do you . . . What are the some of the issues, especially some the more interesting issues around that, and how do you go about thinking about this?

(11:03) Karen Copenhaver: I’m Karen Copenhaver. I originally was at IBM, a long time ago, 1979 to 1992, then I was out on the west coast for a while, I was at an IP firm in Silicon Valley and Arizona, and then I came to Testa. I was at Testa for ten years, and the remarkable thing is that Ira and I were sitting at a dinner the night he was starting at the firm, and he mentioned the fact that he had written a case note, right? I have the right term? when he was at Stanford on the GPL, and I said, “That’s interesting, because I’m really interested in that subject too.” We taught a class at the firm in 1996, and everybody said, what did that have to do with anything? [laughs] And in 1997, we were at a mergers and acquisitions conference, and they wanted me to talk about IP due diligence, and I said, what I want to talk about is Open Source. And they said, Why? Why would anybody want to talk about that? So we’ve had a great time talking about this subject for many years and watching it grow, and it’s so exciting to be able to have a conference and have everybody show up, because it is a part of the infrastructure.

And when we say every company uses it, it’s because almost every company interacts with at least an Apache web server every day that they do business, everybody who's got a browser. There are so many pieces of Open Source that we absolutely rely upon that it’s funny to me when anybody ever talks about Open Source being unreliable. I think, well, the world will shake if we stopped using it. Right now I’m at Black Duck Software, which is a company that focuses on being able to manage the use of Open Source in any enterprise, because this is part of getting rid of the fear, uncertainty and doubt is to be able to automate the management and control of licensed materials, which includes Open Source. And we actually did bring our marketing materials in the back, and I'd be happy to talk to anybody on that subject at any time today.

One of the things that we always have to make certain when we talk to a group is that when you use the term “Open Source” -- love the smiles -- when you use the term Open Source, that can be a politically radioactive term. The Free and Open Source movement wants to concentrate on certain aspects of the freedom in the use of the software, and other people just refer to Open Source as any software that’s available in source code form which could include something like Microsoft’s Shared Source, and the phrase has to be used carefully unless you explain exactly what you’re talking about. And today we’re pretty much going to talk about any software that is made widely available in source code form for download, usually but not always, without charge. And the reason we’re going to talk about that software is because that software is the software that’s been coming in the back door at companies.

Normally you have a procurement process that says if a company is going to enter into a contract or a relationship, and they’re going to spend money, that contract has to go through the CFO or go through your procurement organization or go through some sort of an internal control that reviews the terms that are applicable to the purchase and signs off on it. The reason that Open Source software has this bad rap about being uncontrolled is that you don’t have to pay for it, and therefore when it comes in the door, it doesn’t go through those internal control processes unless companies get control of their systems and try to manage it. And this is the reason why there’s a lot of Open Source that has worked itself into code bases, because it was available for download.

And since there are a lot of attorneys in the room, I always tell this story, but it's just to level set everybody, because sometimes I’d look out and see a sea of attorneys, and they’re acting like you developers that put this Open Source into the source code, like you're drunk and disorderly or “Oh! They’re out of control, putting all this source code into their source tree.” But if I ask the lawyers in the room how many of you would ever start writing a contract with a clean sheet of paper? I mean, how many of you, if you had a contract to write, and you had to get it done on time, which developers, believe it or not, have very, very tough time schedules, just like you, and you had to bring it in at cost, would you rewrite every piece of boiler plate in the contract?

And if I had a tool that could recreate every contract you ever read and scan every contract you ever wrote, how many clauses would I find that were copied from Microsoft contracts? [laughter] And what would your defense be? Let me give you your defense. Your defense would be, “I didn’t notice the copyright notice.” [laughter] Which Microsoft has, I'm not sure if they still do, but for a long time all their contracts were copyrighted, and if you’re an attorney you know they’re copyrighted anyway, right? Then you’d say, “No, no, it’s purely functional, [laughter] that little piece, that export clause, no expression in there, purely functional.” If you didn’t get away with that one, you’d go de minimis, quantitatively. But you copied it for a purpose. And you know why you copied it? You copied it because it was peer reviewed. You copied it because it's something that's been out there, and many, many eyeballs have looked at it, and it’s passed the test of time.

Comment called out from audience: And it came from your old firm. [laugher, applause] Get real.

Karen Copenhaver: The comment that made everyone laugh, he said, you can never repeat a joke and have it work very well, but he said, "And it came from your old firm."

That’s exactly why developers want to use this code. I mean, the first time, and this is what really changed the way I felt about Open Source, the very first question that I ever got about anything under the GPL was about a math library. And I my reaction, I read the GPL and I thought, this is crazy! This was very early, and I said, “Don’t use it. That’s like, weird.” And the developer came back and said, “This library is so valuable because everybody in all these different universities use this library. I could not recreate this library if I tried. Even if I wrote it, I wouldn’t have the confidence in it. I need this library. I need this library.” And it really put a different spin on my approach to the GPL, because I realized that if there’s code that is really valuable, and it is used by everybody in the world, and everybody benefits from that, it ought to be available. It ought to be available.

So what we’re talking about today, we’re referring to software that’s made widely available in source code form. That software is made available under many, many, many different licenses. The GPL is, by far, the most popular, but it is not the only license. We’ve got over 500 Open Source licenses in the database, and they vary. Some are very different, some are very similar, but there are many, many different licenses. Some have this reciprocal sharing or enforced sharing obligation which says, you can use my code as long as the code that is created with my code, either as a derivative work or in a file -- there are different definitions -- as long as that code is also made available in source code form. And those are, generally, the licenses that make the lawyers nervous. But there are also many other licenses that have different obligations, that have very few obligations. There's different licenses. And it’s also distributed in many different ways, in many different business models, and this is what makes it interesting.

But I can't, you can’t even start talking about Open Source without saying that I’m a little sad that we started this off with a discussion about law and about licenses, because when I go to conferences I hear everybody talking about the legal issues. The most interesting, the most compelling, the most revolutionary thing about Open Source is not the license. The most revolutionary thing about Open Source is the collaborative development model. That’s what blows my mind, is how companies have gone is such a short period of time from thinking that the best thing that they could do was to work in a tower, and work alone, and protect it, and how people in one generation have gone and completely turned that around and said, “There are pieces of my business that I ought to be developing in community.” That idea will not only revolutionize the software industry, it will revolutionize every industry on earth, the pharmaceutical industry, every industry. And the speed with which that change took over is breathtaking. The legal issues, the licenses make some of that possible, and therefore they’re interesting. But if you walk out of this thinking that what’s really different about Open Source is the licensing model, you missed the fun part. You missed the fun part. All right.

(20:20) Ira Heffan: So when we think about software generally, whenever we’re looking at a software license agreement, there’s a couple of risks that we think about. So these are the same risks that we think about with Open Source. They just get dealt with a little bit differently in Open Source licenses. The biggest risk to a software company, or any company, about a software product that they’re using is, is it going to do what they want? And is it going to do what they want over the long term? What happens if there's bugs? What happens if there’s a new version of the operating system that comes out, and it’s no longer compatible? Is it going to be supported? That’s the main question that a company that’s taking in some software is really thinking about, is it going to work? Is it going to do what I want?

The next question is really, I'm putting here as license compliance, is, What do I have to do to get this software that’s going to work for me? In the commercial sense it’s, What do I have to pay? What are the other terms of that license that I’m going to have to follow in order to get to use this software and is that OK with me? Right? And for a proprietary license you’re thinking about things like what's the license fee? What are the support fees? What are the other terms? What's the restrictions on how I can use it? And is that going to be OK for the way that I want to use it?

On the Open Source side, you’re thinking about some of those things, and you’re also thinking about, like Karen mentioned, the enforced sharing, the reciprocity provision that’s in some Open Source licenses, also called Copyleft. But you’re thinking about the notices that might be required, especially if you’re a software distributor or software vendor and you’re including Open Source in your product, you’re thinking about what's the, what am I going to have to think about in terms of what notices I need to put where? Definitely not an insurmountable problem by any means, but companies that are using a lot of Open Source need to remember that they’re going to put some resources towards that problem. And then, is there any changes to my end-user license agreement? Again, if you’re a software vendor who’s using Open Source, how does this change the way that I then relate to my customer, the fact that I have Open Source in my product?

And then the third thing, I think the big issue, obviously with software license agreements there are lots of issues, but the third issue that’s worth highlighting is third-party IP claims. What happens if this software that I get has some problem that’s not a technical problem but is an IP problem? In the typical commercial scenario, you’re looking again to your contract to see what the vendor is going to provide you. And in the Open Source context, depending on who you’re getting the software from, you might be doing the same thing, because there might be a support or indemnification contract that comes with it, but if it’s something that's, if it's software you’re just downloading over the internet, and you’re not getting it from a vendor that’s going to provide that support, then you’re thinking about, is the community going to be able to deal with that problem in a way that makes sense for me? It becomes a very specific question about, is this software, and the way I'm going to use it, and the risks that come with that, understanding that there’s a community of people, and understanding, you need to understand, I think, what that community, how big it is and how likely they are to react, and kind of take that into account, how is that going to help me react if there is an IP problem? So you’re going to take that all into account.

It’s a similar analysis on the proprietary software side. You do some of that same analysis in thinking about, well, I got an indemnification from this company, but what’s that worth? Maybe it’s limited to a small amount and that's not really helpful to me, because it’s limited, say, to the price of the contract, and if I really have to defend an IP suit, it’s going to be much more than the price of the contract. Or it may be that you have a big indemnification, but the company might not be able to stand up for it anyway. So it’s that same calculus that you’re doing on both the Open Source side and the proprietary side. It's just different pieces that you take into account. You had a question?

(25:10) Marty Conner: You kind of touched on it after I raised my hand. I was just pointing out that, on the third bullet, the third-party IP claims, you’re defending an allegation. Just as patent law is the sport of kings for a reason, the SCO issue is turning IP *allegations* into the sport of kings, and I just wanted to make sure that was emphasized.

[Voice in background: Say who you are.]

Marty Conner: Oh, I'm Marty Conner. I'm the project leader for the Etherboot Project.

(25:35) Karen Copenhaver: Absolutely, true.

(25:46) Franklin Davis, Nokia: I'm Franklin Davis from Nokia. Three of us here work on Open Source browser at Nokia. Two of the issues we’ve come up against, that I wonder if you might touch on, are, if you have your own IPR, which you are willing to contribute to the Open Source body, what protections do you maintain going forward? What we’ve come to the conclusion is that you’re giving it away to anyone to use in the Open Source context but a commercial, proprietary competitor can not take that code into their proprietary product, so you still are protected to some degree. So if you have any discussion about whether that’s true or not, that would be interesting. The other question is, probably the most common one, how do you build protected code around a piece of open code? We’re using LGPL code, so it should be possible, but that’s always the big question from our customers who are going to take this code from us, you know, “Do we have to give away *everything* we do?” And how do you answer that question?

Karen Copenhaver: You want us to answer that one first?

Ira Heffan: Should we talk about that one first, Dan ?

Karen Copenhaver: Invite him up first for a bit? All right.

(26:54) Jack Messman: I’d like to deal specifically . . . I'm Jack Messman with Novell. I'd like to deal with the SCO problem in particular. In 1973, Novell bought from AT&T Unix, Unix System Laboratories. In about 1975, '76 we sold SCO the right to *use* those copyrights and patents to develop a business around Unix. We did not sell them the copyrights and the patents. We still own them. They’re suing us on whether or not we own the copyrights. I don’t know why they wouldn't sue us on whether we own the copyrights and the patents, but we own them both, so . . . (27:29) Karen Copenhaver: That’s only one of many things about that suit that makes *no* sense. (27:34) Jack Messman: That’s the first issue. The second issue is, as part of that, as belt and suspenders -- our lawyers did a good job -- we got a license back on our own technology to use Unix with our customers. So even if they prevail on the issue of whether or not we sold them the copyrights and the patents, we have a license to use Unix in the Linux distributions that we sell. So if you want to avoid the SCO problem -- this is a commercial [laughter] -- if you want to avoid the SCO problem and make the issue of Unix in Linux go away, use SUSE Linux. [laughter]

(28:19) Ira Heffan: OK. No, thanks. [laughter] That's great. I do want to say, what we have there [ed: referring to slide] as "the SCO problem", I was really referring to, I was not trying to say that there is a real SCO problem, but it’s more the problem of a company that participates in the Open Source community, has code that’s out there, that's freely flowing, and then decides that they’re going to turn on that community and say, my IP’s in that stuff and now I want six hundred dollars a server or whatever it is. That’s the problem, some third party that comes in and says, my IP’s in that Open Source. And what happens then?

(28:55) Dan Bricklin: We’re seeing the fact that we have the head of a large company that came in, the fact that you said "community" matters, because the community consists often of a lot of large companies with large resources which can come together.

(29:08) Ira Heffan: No, absolutely. That's right.

(29:10) Karen Copenhaver: My reaction to SCO is really to talk about the good things that came from SCO, because that's my wont. So when you talk about the SCO problem, it really began a lot of discipline that wouldn’t have begun, maybe, so soon if that suit, which turned out to have a lot of very odd elements to it. But even the way they prosecuted it, by writing all those letters to the audit committees of public companies, I mean, it got everybody’s attention. And I think there are a number of very positive things that will come from that. The community is thinking a lot about pedigree in a way that they never would have been able to get a hold of if they hadn’t had that claim and a claim of that magnitude. And here’s a claim, IBM stepped up to plate, Novell stepped up to the plate, Red Hat stepped up to the plate, lots of people stepped up to the plate to really show how those cases can be, will be, defended when they’re brought.

Another thing that happened which is really interesting is that the software industry in general did not have any IP indemnities. Most software licenses came with absolutely no infringement indemnity. And all of a sudden, it’s like when your cars began, I think it was Ford that came out with the one hundred thousand mile power train warranty. Before that, cars had no warranties, and all of a sudden you couldn’t buy a car without a one hundred thousand mile warranty. It’s the same thing in the software industry. I’m seeing a lot of companies that are starting to give indemnities that they never would have before. Whether that’s a good thing or a bad thing I’m not going to comment on, but it’s certain a huge change in the software industry.

And in terms of, I think the most important thing to focus on in terms of third-party IP claims is that when people talk about Open Source they often talk about the patent problem, as though the patent problem is a problem that relates to Open Source in a way that’s different, unique, and more troubling than it is for the proprietary software industry. And that’s just not true. I think this community response will really put the Open Source projects in a better position than proprietary projects when patent claims are raised. So to talk about Open Source as having more IP problems, at least on the patent side, I think is inaccurate. I think we’re going to see a whole different approach to patent litigation on the Open Source side, because we’re not going to tolerate trolls. We’ll have the wherewithal not to tolerate patent trolls that go and settle up a bunch of claims, get a war chest, have a bunch of licenses and then be able to turn on somebody who’s going to be able to pay damages. And I do want to get back to your question, and then we can . . .

(32:00) Gordon Haff, Illuminata: Hi, Gordon Haff, with Illuminata. Actually, on that particular topic I wonder if you maybe could comment briefly about the patent peace provisions that are going into law in newer open source licenses, like CDDL for example, is that something that's important or is it sort of a red herring?

(32:17) Karen Copenhaver: I think it is important, and when we get on, we’re going to talk a little bit about what’s going to be in GPL 3, and I think the interesting discussion is going whether those kinds of provisions will be incorporated in the next round of the GPL. But what he’s talking about is a patent termination provision, which is one of a number of different methodologies that the open source community is using to create this patent commons. Many of the companies in this room have been announcing programs where they’re going to make parts of their patent portfolio available to help defend the Open Source community. That’s a huge, huge step towards defending the community against patent claims.

But this idea of a patent termination provision, and I think they’re still being refined, but the basic concept is, if I put intellectual property -- and it’s most easy to understand in terms of a large company with a patent portfolio -- but if I put intellectual property into the community and allow you to benefit from it and allow you to use it, and then after you have the things of mine that you want, you turn around and sue me, I want to put all that intellectual property back on the table in the litigation, so that we’re really evening up on both sides.

And that means that my licenses to you are going to end. They’re going to terminate, your license will terminate and we’ll look at the intellectual property of mine that you’re using, and we’ll look at the claims you’ve made against me all at the same time. I’m not going to stand here having already licensed to you the things you want and have to defend a claim by you. And that’s the way a patent termination provision works.

There are huge questions about the appropriate breadth of the termination. So in some cases the breadth can be very, very broad. It can say, “If you’re using my software, and you sue me for practically anything, your license ends, in toto,” all the way down to “I’m going to put this piece into the community; if a patent that’s practiced on that particular thing becomes an issue, then I’m going to have very specific termination provisions that apply to you.” And that question of how broad that ought to be, is still, I think, open.

(34:32) Andy Updegrove: Andy Updegrove, Gesmer Updegrove. Just a quick comment. That provision has actually been around for decades in the standards community, and one of the big examples of convergence that’s going on right now is the standards world and the Open Source world are all of a sudden coming together. And there’s a lot of misunderstanding on both sides, because there’s one set of methodologies in the standards community, one set of methodologies in the Open Source community, they’re starting to get acquainted with. There’s recently a letter that probably a lot of you have seen, from 29 Open Source advocates to one of my clients, Oasis, saying, “You can’t have that policy any more because we don’t want you to, and please everyone boycott Oasis because we don’t like their policy.” All those things have to get worked out. But one of the things that’s kind of interesting is the provision you note. It's something that’s been around for a long time in the standards community and now the Open Source community guys are looking at it and saying, “Hmm, gee that might be something we want to use as well.” But the last comment is, there’s a huge amount of confusion now in the community because people are using Open Source and open standards in a sort of muddled way without really understanding what either of them is and how they fit together.

(35:38) Ira Heffan: I think I would agree with that. I think actually Dan has a piece on his blog on that, right?

(35:43) Dan Bricklin: I’ve written stuff about the confusion between the word “Open Source” and the words “open standards.” If you talk to regular people, they don’t know the difference, they just hear the word “open” and they think it’s the same thing. And they know in open standards there are Draconian things where you can lose your patents. Because you to disclose something. Because you made some honest mistake you could actually lose the ability to assert certain patents, is the way certain open standards committees work. And that’s happened, that’s actually happened with Dell, I believe. It didn’t happen with Rambus, but it almost happened. But then people think that, and they think, “oh, in Open Source I could lose my stuff too the same way.” And when people say, “I’m doing open standards,” they think they’re doing open source, but it could be, Microsoft uses open standards, and there's Open Source that doesn’t use open standards, because there's standards committees and stuff. Be very careful that when you say open standards people know what you’re talking about and Open Source they know what you’re talking about. But we've got to get back to . . .

(36:55) Ira Heffan:[laughs] Because we're on slide 2. Do you want to address the Nokia questions first? (37:00) Karen Copenhaver: Oh, yes, although we’re going to talk about some of those as we go through, I wrote them down so maybe we’ll come back.

(37:04) Ira Heffan: Is that ok? We’ll make sure we circle up at the end.

(37:08) Karen Copenhaver: So what we wanted to do, we had a slide here on first principles where it says Open Source is clearly here to stay, we thought we had to go over those legal points first. What we want to move on to is a couple of issues that people don’t talk about as much. Because many of you have been to Open Source conferences. You've seen the same six bullets about the GPL so many times you can’t stand it any more. We wanted to really move into some issues that are currently being discussed. And I guess I skipped all the way to this one, but this is interesting. This is talking about what we’re going to do with GPL 3.0. And Eben has been talking, Eben Moglen, who is a very important person in the Open Source world, particularly in the Free and Open Source world. He is a professor at Columbia Law School, a copyright expert, and he represents the Free Software Foundation and has worked with Richard Stallman, really from the very beginning. And he is trying to explain, when we look at moving the GPL from 2.0 to 3.0, you have to understand that the GPL plays four very important roles in the community.

Number one, it’s a copyright license, which means it’s not an express patent license, but it’s a copyright license. It’s a code of conduct. It is a constitution of the Free Software movement. And it’s a vehicle to express the ideas of Richard Matthew Stallman. And he makes that point very clear, I think, because although this is a community, that the GPL is something very, very important to Richard, and the way to move forward with GPL 3, is to make it very clear that Richard's going to continue to play a role. Because we really do need to move to GPL 3.0, at least to get, we need to make progress because we’ve been talking about it for so long that it creates a certain amount of uncertainty and fear in what’s going to happen with 3.0. And Eben’s trying to take a position, I think, that says, we actually are going to manage this through, and one of the things that I’m reassuring everybody who’s been relying on the Free Software Foundation to promote Richard’s ideas, I’m telling you we’re not changing course. The fact that there now are big players, very active in the use of GPL software, you know, IBM, Novell and others, is not going to change the GPL 3.0 into a commercial agreement. It’s going to continue to be the constitution of the Free Software movement, and it’s going to continue to express the ideas of Richard Matthew Stallman. 2.2.. . you wanted to jump in here?

(39:55) Ira Heffan: In thinking about version 3.0 of the GPL, the Free Software Foundation is talking about that they’re trying to take a license that really has done pretty well over more than 20 years, almost, I'm not doing the math, '91, OK, about fourteen years (I am an engineer, really) [laugher], and they’ve been talking about, they’ve really been trying over the past couple of years, to try and figure out what to do. And a big problem that they have is that there are so many different interested parties in this license. I mean when you think about, when I think about, any time you just have *two* parties, my client and another company, and they’ve decided they want to change their relationship a little bit, and we’re going to go back and amend the agreement that they have already, that they’ve been working on for, say, five years, or two years, let alone 14, then there’s a lot of work that goes into that, and there’s just the two interested parties.

Here, all the people that are interested in this is, well, everybody in this room, and probably everybody else in the software industry in some way, and that includes the people from the Free Software Foundation, who are very interested in the idea of copyleft and Free Software, to the people who just are trying to run businesses and are happy to have the collaboration that comes with Free Software, to people who have been using the Free Software under a certain set of known obligations, and if those change, that's going to change the way that they do their whole business, to proprietary vendors who don’t want to touch Open Source at all but maybe they would if there was some changes to the GPL.

So there’s a huge range of people who all have some interest in this license. And somehow they’re struggling to come up with changes. The kinds of changes they’re talking about are, first of all, worldwide application. So they have this problem also that this is not only in the United States where contract law is state law, so there’s fifty different contract laws that are pretty much the same but have some differences, but worldwide. So there's lots of countries that have a lot of different contract rules and that same license has been working pretty successfully all over the world but still has some concerns. And then they also want to do some changes for clarification. And that’s where, really, it gets interesting, because that’s where the changes are going to affect one side or the other.

(42:55) Karen Copenhaver: And part of what we’re talking about is really that the industry has changed so much, and it is amazing that the license has stood up so well. The concept of static and dynamic linking that give us so much problems, so many problems, really is linked very much to Unix. And you can go to Dan’s web site, he’s got lots of things we’ve talked about, and he has a podcast about it. There’s the concept of what the copyrighted work is, and we can spend all day, we can talk about what is really "derived," what's this concept of a derivative work which is under copyright law?

And for those points, it’s important to remember when they were putting the GPL together in the first place, it was a very different time in terms of intellectual property licensing, and there were great concerns about writing a license that went beyond your intellectual property rights, that extended controls on things that you actually didn’t own. And it’s always been the case that the GPL has gone as far as copyright will permit you to go but not any farther. And so the use of copyright terms in the GPL was very specific to get that, that we want to assert as much power as we possibly can with the copyrights that we hold in this code, but we don’t want to go any farther and raise any issues or concerns about misusing those copyrights by asserting controls over things that are outside of our rights.

And that’s why words like “derivative work” were used, because those are terms that are in the Copyright Act. The problem is that there is almost no case law relating to derivative works of source code. There are cases relating to derivative works of software that really address visual elements, that address GUI’s and address things like that, but in terms of a derivative work of source code, there is almost no guidance in the courts at all. And one of the things that I think you’re going to see a lot of in the next few years is that the legal community is going to begin developing more commentary on this subject. And there are many people who are working to have that happen in a variety of different forums.

It’s hard, because we really don’t want to litigate those issues. Big cases that make those groundbreaking decisions that make things clear, are very expensive for whoever has to fight them. And it often is not fair who has to fight them. If you remember the VCR was defended by BetaMax, not by VHS. That’s who paid the bill.

(45:40) Audience Member: You say, we do not want to litigate them. Who is “we,” general counsel? [laughter]

(45:50) Audience Member: We seem to have IBM and SCO, funded by Microsoft and whoever else they can get to buy a “Unix” license, litigating their brains out. Lawyers are getting fabulously wealthy. As a matter of fact, I’m thinking a law degree might not be a bad Idea. So who exactly might “we” be? [laughter]

(46:12) Karen Copenhaver: I was speaking there of the community.

Audience: Oh, the community. [laughter]

Karen Copenhaver: Yes, the community. I am not a litigator. I’m sure actually there are many people who would love to litigate these things. But the other thing is, and here I’m very serious, the problem is, it would take twenty years. Think about this. If you think about when the first shrinkwrap came out. How long did it take us to get any real guidance on shrinkwraps? Twenty years? The first shrinkwraps were written in the early eighties, and there’s been confusion for years about those kinds of agreements. And we’re now getting all this case law that’s very consistent, but it takes twenty years. We don’t want to wait twenty years and have that uncertainty continue to affect the industry for that long. Even if we did get a lot of lawyers who actually did want to litigate.

(47:11) 2d Audience Member: Do you think you could do it in less than twenty years?

(47:14) Karen Copenhaver: No, I think what finally solved the shrinkwrap case, ProCD, whether you like or don’t like that decision, the judge came out and said, “Regardless of what you want to argue, this is what the industry actually does.” And one of the problems that we’ve had is that we don’t have a lot of people writing about what derivative works of source code are. And the reason is that the fact situations are too complicated, people in firms don’t want to take positions that could be interpreted against their clients. There’s just very little that’s been written about it. And we need to begin to have more discussions and conferences and symposium where that guidance, that community consensus, really is formed. And you see that in these discussion groups. And as it begins to solidify, when that case comes up, there will be a lot of guidance for the judge, whereas if you get a case and there is no guidance, it goes off to the side. So...

(48:10) Ira Heffan: Can I just tie that, what you were just saying about the derivative works into the second question that the folks from Nokia asked, which is, they were interested in, well, so we have this LGPL'd code and how do we figure out if someone can use it, and how do you use it? And that’s tied into that same language. And Karen really just gave the answer there, which is, there really is a case by case sort of analysis of that code. You’d like to say, if you do this, you’re all set. Right? But it’s really going to be, because of the language, because of where it is, an analysis of here’s the Open Source product, here’s your product. Are you using it in a way where this is derived from that? Are you using it in a way that seems consistent with what the license says? And then also thinking about a sort of general risk analysis, whose software is it? What are *they* thinking? And then from more of a risk analysis, how likely is this, are they going to think that this is a problem? And those are the kinds of things you do with every kind of contract. And it’s a very similar analysis, except you’re dealing with a community on the other side, in terms of an Open Source license.

(49:24) Dan Bricklin: This is a guidance, in a way, to some of the developers. You can do what Linus did, what Larry Wall did with Perl, where they put some extra things, saying, here is how I am interpreting derivative work. Specifically because it really is based on the, it’s OS-specific, it’s application-specific to some extent, if you listen to what the Free Software Foundation said. And that’s what some of them have done. Linus has said, here’s some things. He has a separate thing, you'll see it in the video, I show that actual stuff. Larry Wall says, even though the GPL normally doesn’t allow you to do this, I am allowing you to do it, because that’s how I’m interpreting it here. So you can do some clarity, at least for your own code.

(50:08) Karen Copenhaver: Uh huh. Good. And that’s one of the questions that comes up, is, whose interpretation of the GPL controls?

(50:18) Will Taber: Will Taber, with Rational Software, IBM. One of the things that Linus said was that, for instance, you could have a kernel module and that’s OK, even though it’s not really under the terms of the GPL. But my impression is that, in fact, the Linux kernel development community is backing away from that and is coming out more and more strongly that you can’t have binary-only kernel modules.

(50:50) Paul Zoff(?): Paul Zoff(?) from First Technology. On the earlier slide you had a very interesting fourth or fifth bullet that identified deployment, and before you hasten to the next slide, since deployment occurs outside of the development process and outside of the firm, and is kind of a world view versus everything we’ve talked about here, which is a kind of a constricted, inside-the-firm view, can you comment a little bit about deployment and where that might go?

(51:20) Karen Copenhaver: Yeah. When we talk about deployment the issue has always been distribution. The GPL has one very interesting area where it says, if you’re using things internally and you’re not distributing them, that those are not subject to the enforced sharing obligations. It also says, which many people misunderstand, that if you are subject to the enforced sharing obligations, you only have to deliver the source code to the person to whom you deliver the object code. There’s not obligation under the GPL to put your source code on the web and make it available to the world.

But if you’re only using it internally and you don’t deliver the object code to anyone, then you are not subject to the enforced sharing obligations. As the world moves toward web services and more of the browser-based applications, where you’re allowing somebody to use your software without actually taking it and distributing it to anyone, there are a lot of questions as to whether that exception is too broad and whether it ought to be altered. And Eben would say that there’s probably not one solution to that question. There are probably several solutions to that question that will need to be discussed as to when, if you have software which you are allowing people to use, but not distribute, when the enforced sharing obligations will apply to that software. And I think when we were talking about deployment, because we’re hearing that word a lot, it’s really talking about basing licensing obligations on use as opposed to on distribution.

(52:56) Ira Heffan: That’s exactly right. And that’s just one of the things that’s on the table. Some of the Open Source licenses that are out there do that right now. They hook the source code distribution obligation on deployment. And I think there’s some question in the thinking about GPL 3.0 about would they try and do that, and put some provisions in there. And that would change the bargain, and companies who right now are users would feel, I think, that that was a problem. I think it’s going to be very hard for them to do that. Let me just say that. I think that even though there are some people who are out there who are saying, “Well, yeah, we really should have this because that’s fair," in terms of other people sort of feeling like they have a safe harbor on the distribution because they’re just using it internally, but outside facing, that could end up being a problem for them. So yeah, it’s on the table.

(53:56) Karen Copenhaver: The last point on the chart, which is one that Eben spends a lot of time talking about is trusted computing, which is, would mean that there would be a restriction on the access to the source code if you were in certain environments where you’re trying to protect against use by unauthorized parties.

(54:17) Doug Naplioni: Doug Naplioni from ScanSoft. When it comes to extending the GPL, or any software license to include use of non-distributed software, it affects more industries than just the software industry itself. The biggest, the easiest example for me would be back-end transcription services, which many lawyers and the healthcare industry uses it extensively. And many of those solutions do use Open Source software at those back offices, so when you cut that out that will affect probably every industry currently that’s out there.

(54:58) Karen Copenhaver: Absolutely. We’ll go through these very quickly because we only have a few minutes left. But I love the fact that everybody joined in, this is what we wanted to have happen. Once you start talking about taking the GPL from 2.0 to 3.0 and you start talking about making these kinds of changes that could affect this industry and the Google’s and the eBay’s and others of the world that are operating in those kinds of environments, you begin to start asking questions about, well, whose interpretation of the contract matters? Can Linus come out with an pronouncement and say, this is what I think the GPL means and have that control? Or does it only control the software that he releases? The reality is that a contract is really a meeting of the minds, but when there’s no negotiation, when the contract's just putting out there, how much is there an actual meeting of the minds? Generally you would say if Linus is putting the contract on his software, then what he meant is really important and that he could mean something different. Other people absolutely reject that interpretation. And we could talk about these for a while. How to manage compliance. But this is the last subject, which is near and dear to my heart, is managing compliance, because this is where when companies begin to think about the fact, and this is your question, that you’re going to have both proprietary software and Open Source software even close to each other, that’s what makes people nervous. That’s when all the talks about deadly disease start, you know, it’s a cancer, it’s a virus, and it’s all this horrible stuff. And I think what I want to make clear is that there are many, many ways to get a hold of this issue and to manage compliance, and you’re going to see enormous growth in this area.

Again, a part of it comes from the disciplines that arose after the SCO suit. Now that people are focusing on it and realizing that it’s important, there are technologies like Black Duck and others -- I'll do my ad -- that help you manage this and control where your code’s coming from and to know what those obligations are. And as we move into an environment where more people are developing code, both proprietary and open source, in a modular manner, which I think, it's finally here, we’ve talked about object oriented programming for years, but I think we’re really into a place where we’re going to be reusing components. It’s not going to be five parts, it’s not going to be three parts or six parts. You’re going to have programs that are made up of fifty different contributions. And not only do you need to know what those fifty different contributions and obligations are for your initial use, but you’re going to want to be able to take that product off the shelf and to know what those obligations are so that you can reuse your own assets. And this will be a natural process which will take a lot of the fear out of using Open Source out of the system.

And your ideal process, I like to say this, because people think that these things arise out of concern that what you want to do is exclude Open Source, these processes are really all about enabling companies to go from an environment where the management team is sort of feeling like, Just say no. We don’t want to go there. This is too complicated. And really enabling companies to embrace Open Source and to say, if we’re going to be the most competitive software company on earth, which all of us, it's part of the goal of all commercial companies, then we need to be able to exploit these resources more efficiently and better than our competition. And that means that we can’t forgo opportunities just because they’re scary and just because it’s difficult to manage. We need to embrace them. That doesn’t mean that you go willynilly and begin copying anything on the web, as Ira was trying to point out earlier, it’s very important to think about the source of the Open Source.

To participate in a broad community that is dependent on something like Apache or Linux is a very different risk proposition than taking something off of a web site that there is no user community for, where you really don’t have a reason to think that they’ve had any control of the pedigree of the code. The source of the source is very important. I work with companies all over the country that are using Open Source, and you’d be surprised how many companies actually go back to the original author and negotiate an agreement for code that they have found on the web that is valuable, in order to get some assurance that they understand where it came from and to understand what their rights are.

(59:27) Dan Bricklin: How many people here have gone to the author and negotiated something that wasn’t expected, and that wasn’t just a normal deal? We have four or five people who are saying that. Fine.

(59:39) Karen Copenhaver: And it really happens, it surprised me how often. It's good business. It’s very valuable code, just because it’s on the web doesn’t mean it’s good or it’s bad. You have to do the same kind of procurement process you would do with any other company or acquisition to determine how you feel about it.

The other thing, and I guess this is a good thing to close on, and you can comment on it, for the legal counsel in the room: we need to be talking to the developers more often and better. What I see from years ago is that the developers would be working on something, you know, they’d find something that they wanted to use. They’d be told they had to go review it with legal counsel, and the developer would say, “Oh geeze, I’ve got to go make that appointment.” They’d trek over across town, they’d talk to the lawyer, and the lawyer would say, “I need this, this, this, this, this.” And the developer would come back and say, “Oh God, I’ve got to get this, this, this, this, and this.” And then it’d go off a couple of days and then two weeks later you’d go back and see the lawyer and the lawyer would say, “Oh, that’s really interesting. Let’s get this and this because that would be really interesting.” And you go back, and meanwhile, the stuff's baked into the product, you know, everybody is building on top of it, you’re getting the product Q.A.’d, everything is getting lined up, and you get to the very end, and there’s some sort of a discussion, and they say to the lawyer, “Well, can you tell me absolutely that we’re never, ever, going to have a problem with this code?” And the lawyer has to say, “Well, I can’t tell you that. I can’t tell you that nobody is ever going to make a *claim*, you know? I can tell you that I feel good about this. But I can’t tell you...” “Oh, then let’s not use it.”

But that happens, like, once a year, once every six months, and the lawyer doesn’t feel all that bad about saying no, because it doesn’t happen all that often and it’s like, “well, we had this one thing, we couldn’t use it.” What needs to happen is the lawyers and the developers need to be talking, like, every other day. And as the lawyers begin to understand that each of these issues and each of these decisions has an impact on cost, it has an impact on development time, it has an impact on quality, it has an impact on interoperability, as you begin to understand that these decisions have tremendous impact on your business, and you become more comfortable in the conversations with the developers we will be giving very different advice. Because we will not be able to say this stuff is absolutely, we know where this came from and it’s totally safe, but there’s no business on earth that can operate in that environment either.

(62:19) Ira Heffan: Yeah, I would just make...Let me just make one comment. A lot of times when I work with developers I hear a comment that's something like, how come I have to be a lawyer to write software? [sighs] But the reality of that, why do the developers have to think about licensing, maybe in a way that they hadn’t before? It just comes because it’s really a new world; the way that software is getting developed is new. There’s so much use of third-party code, there’s so much collaboration, there’s so much community development of some software and people making use of that to build into their products to make these enormous solutions. Because of that change, which is great, because code reuse, that’s like the Nirvana of software development is the reuse and all those benefits, so of course coming with that is going to be some thinking about, you know, well, I have this code but what do I need to do to use it and what are the licensing terms that apply? When you think about it that way, I think it’s pretty natural.

Dan Bricklin: I have lots to say on that, but it's on tape.

(63:35) Gus Byurkland: I'm Gus Byurkland from Progress Software: I just want to comment on how developers should work with lawyers. Having learned how to do it with the lawyers at Progress, what works really well is to go to the lawyer and say, help me solve this problem. If you go through the process you just described, Karen, yes, it takes weeks and months and gets more and more complicated. But if you explain to the lawyers what problem you want solved and what needs to be accomplished, it works a whole lot better. Our lawyers are perfectly willing to work with developers to solve problems.

(64:22) Karen Copenhaver: Great. I know your lawyers, and they’re wonderful.

(64:26) 4th Audience Member: This is really cool, by the way. It’s so really refreshing to hear people talk about Open Source from a legal context. Last night the Supreme Court, by a five to four decision, decided that it was the states’ responsibility to decide when private property may be taken for commercial purposes. And the reason I bring that up, and by the way, if you get a chance, Sandra Day O’Connor wrote a really excellent dissenting opinion on that, so do read that, but what I really wanted to say was, all you really are accomplishing, as far as I can tell, is due diligence. When the claims come, and they will, Mr. Novell, when the fecal matter hits the fan, what’s going to happen is, you’re going to bring in your reams of documentation. But the dirty trick was played, the developer came in, had three cans of Red Bull, put in some IP, knowingly or unknowingly, and what you can say is, we did due diligence; we told them to use this piece of software, and maybe the judge will let you off. But isn’t that, at the point of litigation, what it really comes down to?

(65:54) Karen Copenhaver: Maybe before, maybe before, but there are technologies that will be able to tell you that. I’ll tell you very quickly a story. A guy came in and he was talking, because our code can tell you when there’s open source copied into your source tree, and he said, I had two really bad days recently. One was the day that I had to fire the best programmer I’d ever hired. A young kid, wasn’t raised in America, came to a great school, the best programmer I had ever hired. He came in, everybody loved working with him, but at some point it occurred to us that it was not humanly possible to write as much code as he had written. And we began to look at what he had written, and he was brilliant. He was cutting and pasting from all kinds of great code on the internet. It was a really bad day. He’d been sent to the training and the training said we don’t do that. He said, I couldn’t believe this, that he really meant that, because why would you not reuse that? It just didn’t make any sense. He didn’t have any options, he had to terminate the guy. He said, the next day that I had that was really bad was a couple of days later, when it occurred to me that he had worked for us for nine months and I really didn’t have a good idea what he had contributed to, because he was new, he was working on a bunch of different projects, and contributing all over the place. I think the idea that you’re not able to control that, you can control it now.

(67:15) 4th Audience Member: I didn’t say that you couldn’t control it, I said that all you’re doing is providing due diligence when the claims come. You’re not controlling it. [laughter]

Dan Bricklin: The way the Software Council likes to run is to be on time, because we made a deal with you as to when we're going to start and end.

Audience Member: 8:00 o'clock. [laughter]

Dan Bricklin: And we have a lot more to cover too. So we're going to end. In fact, it's a good segue, which I've done some work with, disclaimer, that looks for that, and in the next session we're going to be talking about different ways of being businesses in Open Source, different parts of the ecosystem. Until then, we're going to have a break until, whatever it says, 9:45. We're going to start promptly at 9:45. So talk to each other and be back here, sitting here, at 9:45. End of Session 1