Last month, we wrote about the Massachusetts Software Council's Open Source Software Special Interest Group's kickoff meeting, and I said we'd do a transcript, specifically of Session 1, Open Source Licensing with Karen Copenhaver of Black Duck Software and Ira Heffan of the law firm of Goodwin Procter discussing legal issues in Open Source. The Open Source Special Interest Group was established "to facilitate a dialog between professionals who are engaged in efforts around the topic of open source." Dan Bricklin's blog on the SIG is here. The slides for this session are here [PDF].
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.
What stands out to me from the discussion is that FOSS is here to stay, and it has changed the world. For that reason, because the whole world is now affected, the community is now having to listen to what everyone else is wanting from FOSS. No one in the FOSS community is planning on altering the underlying principles and ethical framework that developers hold dear, but everyone is trying to find a way to do what was the point in the beginning, to let the entire world benefit from having wonderful software that they can use freely. Business is part of the world. For them to be able to benefit too, there are some legal considerations, particularly in the post-SCO universe.
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
24 June, 2005
Babson College, Executive Conference Center
Session 1: Open Source Licensing
Time: Approximately 1 hour, 8 Minutes
Bob Zurek, VP, Advanced Technology, Ascential Software, IBM
Dan Bricklin, President, Software Garden
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?
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.
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?
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.
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?
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.
Karen Copenhaver: Absolutely, true.
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.
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 . . .
Karen Copenhaver: Thatís only one of many things about that suit that makes *no* sense.
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]
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?
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.
Ira Heffan: No, absolutely. That's right.
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 . . .
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?
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.
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.
Ira Heffan: I think I would agree with that. I think actually Dan has a piece on his blog on that, right?
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 . . .
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?
(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