Ahh, everyone's favorite - the SCO suit. This talk is coming from David Bender, a well known attorney in this area of law. A short digression to set the table: Unix was born in 1969 at Bell Labs. It was widely licensed on nominal terms.

So onto SCO vs. IBM. Filed in 2003. Three complaints, and three sets of counter-claims. There's a motion pending for another complaint. very heavily litigated - as of April 2005, 437 docket entries. Five week trial is set for November 2005. Plaintiff: SCO, who markets Unix software. Defendent: IBM - markets a version of Unix called AIX. There are third party products - Linux in particular - that are Unix-like. The Linux claim is that this software was developed without relying on Unix code.

SCO alleges that IBM contributed a great deal of code derived from Unix software. The slide states that Linux is making inroads against MS, but the bigger issue, IMHO, is that it's making inroads against the various commercial Unix vendors, with SCO, at the low end, taking large scale damage. The most interesting thing to me, at this point - in my reading of the technical blogosphere, the SCO suit gets no respect (I certainly give it none, see above) - and is given no chance of success. The feel in this room is different. David points out that the biggest problem is that copyright law was written without software in mind, and it's fitting badly.

So how did Unix assets convey? From AT&T to Novell to Sabta Cruz Operation to the SCO Group (note: there's dispute on what went where on some of those steps). SCO claims that IBM breached its Unix license agreement with SCO's predecessor, AT&T by contributing derivative work to Linux. Their claim is that without these contributions, Linux would not be a viable competitor to SCO's Unix software (cue the loud guffaws from the tech blogosphere right there). They also claim copyright infringement, and claim that under the original AT&T agreement, they had the right to terminate IBM's license (which they did in 2003). Finally, they claimed unfair competition. SCO claims that IBM was well aware of these contracts and their meaning. SCO additionally claims that IBM intentionally harmed their business relationships by badmouting them with shared partners.

What does SCO want? $1B in restitution, and an injunction. Clearly, IBM doesn't agree :) The crux, it seems to me, is that SCO accepted the GPL by modifying and distributing Linux products for years. So, it's a "sour grapes" argument is what IBM says. IBM states that SCO acquired the rights to Unix software in an attempt to unify Unix and Linux - and that when that failed, they turned to a strategy of litigation.

Originally, SCO tried to claim a trade secrets infringement. When they couldn't identify any, they dropped that and started claiming that you need a SCO license to run Linux. IBM states that Linux developers will remove infringing code, if only SCO will identify it. SCO will not identify said infringement. So, IBM counter-claims that the AT&T/IBM agreement is breached by the attempted termination. They also make other claims under the lanham act, and claim that SCO has breached the GPL.

The original AT&T license looks confusing to me - it seems to state that IBM only had the right to use Unix and/or derivative works on internal systems and defined CPUs. If that's the cae, how do they ship any derived work? What am I missing here? This whole thing gets into what does or doesn't constitute a "derived work". It's at this point that I can state that I'm glad I'm not a lawyer - this is making my head spin. There's more - the people who signed the original IBM/AT&T contract could be called to testify, and they could be asked to explain what they understood the term "derivative work" to mean at the time. On another note, in Discovery, how does SCO identify supposedly infringing work?

SCO asserts that the added source is a derived work. Therefor, any of this code contributed to Linux constitutes a breach of the AT&T agreement. That's because derived work, according to the original license, it could only be used for internal purposes on designated machines. Then there's the GPL definition of the GPL:

either the program or ant derivative work under comyright law, that is to say, a work containing the Program or a portion of it...

Now David goes back to the Unix conveyances. There's no dispute that AT&T sold all rights to Novell. There's a huge dispute over what did or didn't go the Santa Cruz Operation in 1995. So Novell sold everything in 1.1(a) to SCO, except for schedule b:

• A "All rights and ownership of Unix"
• B "All Copyrights"

Ok, that's confusing :) There was a 1996 amendment - revised (b) to exclude all copyrights except those owned by Novell and required by SCO. Gah! The original agreement between IBm and AT&T doesn't seem to grant irrevocable rights, but an amendment executed by IBM, Novell, and SCO states that on payment of considerations, they would get irrevocable rights.

SCO then moved on to sue Novell in 2004 for "slander of title to the Unix copyrights" - more or less, that Novell's claims about who owns what were damaging and made "with malice". Novell claims that the documents SCO relies on for transfer of copyright are not clear enough. There was a ruling last year that went Novell's way, but no ruling on whether a further amendment cures that. No decision yet - not clear whether it will impact the IBM suit.

Then, Red Hat sued SCO for creating FUD around Linux (and thus their business). That was filed in fall 2003. Court has stayed the case pending resolution of the IBM case. They wanted declaratory judgment that they did not infringe or violate copyright.

Then, SCO started suing end users. AutoZone was using SCO Unix, switched to Linux after SCO dropped support. SCO alleges that Linux is a derived work, and that AutoZone is infringing SCO's copyright. AutoZone tried to move it, failed, and this has been stayed pending IBM.

Then SCO sued Daimler Chrysler for breach of contract, because they switched from SCO Unix to Linux, which they claim is a derived work. Most of this one has been dismissed.

So - when the dust settles, what will the outcome be? Who wins? SCO? IBM? Linux backers? The proprietary Unix vendors? Who? David won't make a prediction at this point. He does think it's possible that SCO could lose on copyright but win on contract grounds.

A presentation from Karen faulds CopenHaver of Black Duck Software. Interesting - she brought up Friedman's "Flat Earth" book and chapter 3 (on Open source) straight off. I guess I need to buy the book.

Anecdote - story of a developer that a colleague had to fire, because he wasn't producing software, he was downloading various bits from the web and integrating them - thus increasing the risk of unintentional opening of code based on various OSS (and proprietary) licenses that may have walked in. To be fair, she points out that lawyers copy boilerplate all the time, so it's not an odd thing at all.

Heh - the idea is that our IP laws and licenses should transfer to China (after they translate the various licenses out there). ironically, in "The Birth of the Modern", a book I'm reading now - one of the huge complaints that the UK publishing industry had against the US in the early 19th century was our (then) lack of concern for copyright law. The more things change...

So anyway, she's flogging compliance software that supposedly fingerprints open source software so that you can look up what you have versus what's "out there". I'd like to know how that works, and what assumptions it makes about the software methodology that the code comes from :)

Virtually all companies now work in a "mixed IP" environment. Software is being built evr higher on older layers of previous work. What are the compliance concerns?

• Absence of control over code available for download w/o charge
• Questions regarding code pedigree
• Assumption that licenses are unenforceable

She claims that "everyone" will start shipping source with everything. I think I'll introduce her to Apple and MS sometime :) In any event - the notion she's flogging is that you need to know what you can and can't do with the code combinations you have, which is a valid concern. As to whether this is a real concern? At least for public firms, you have the whole Sarbanes-Oxley madness, so it'll get attention. So - step one is assessing what you have, and then remediating based on what you found.

She's advocating starting small, with a pilot project - and carrying it through from start to finish. Avoid disrupting development, and anticipate employee concerns. For public companies - the ones with SarbOx issues - you need to worry about whistleblower implications. I'd add that this will be a bigger problem if - for whatever reason - you have a demoralized set of employees. For any remediation plan, you need to involve all the players (including developers), or it will get rejected out of hand.

The goal of all this? To understand what it is you are building/shipping, and making sure that any issues are identified early.

This presentation comes down from theory into practice - what issues are there in using OSS licensed software? Alfred Kellog is an IP lawyer who specializes in software technology issues at UBS.

First off, there's a compelling value proposition (free!) On the legal side, it's an untested frontier:

• no judicial opinion validating the concept
• virtually no judicial opinion interpreting the provisions of the various OSS licenses
• no warranties or proof of non-IP infringement
• Reciprocal (viral) aspect of some licenses creates risk of unintended IP loss

So how do you utilize OSS without exposing yourself to excessive risk? What about risks you don't know about? (i.e., employee downloads that you are unaware of). Some of the risks you have to mitigate:

• Support - will you need it? Where will you get it?
• Lack of Warranties - What's the liklihood of a problem?
• Infringement claims - What is the risk, how do you figure it out? What are the consequences of a bad event?
• Non-compiance with license restrictions - are these easily satisfied?
• Loss of owed IP due to reciprocal features - How does your use impact? What is the uncertainty?
• License invalidity - hard to tell
• Unauthorized downloads - is there a policy in place explaining rules? Are there technical blocks? Can there be? What about open source that piggybacks with commercial products?
• Unauthorized open sourcing of your proprietary code by developers within your organization - need well known policies so that open source releases are planned

Now we have Ed Walsh on patents an Open Source. He's an IP lawyer in Boston. This is the "what's the catch" talk of the day. He defines the FSF folks as in the ideologue camp. Then you have the people creating OSS, the developers. Finally, you have the people distributing OSS software (bundlers, like RedHat). You might also classify them as integrators. Finally, there are the users (and the employers of the users). So to answer a patent question about OSS, you have to figure out where people sit (to find out where they stand).

A separate group are patent "trolls" (i.e., the fine folks at Eolas - or, given this absurd filing, Jeff Bezos. So - Ideologues, developers, distributors - all things being equal, they might prefer that they not be patents at all.

Integrators: Building products on base of hardware/software. Wants "base" products to be free of restrictions. May want to distribute a product with restrictions. Does not want costs, wants freedom to operate.

Users: Want freedom to operate. Want to keep using software, don't want costs - direct or indirect.

Freedom to operate - is OSS more risky? The main risk is infringement of IP (or at least the perceived risk of that). Many of the proprietary vendors hold lots of patents (IBM, MS, Sun, etc). There haven't been many infringement cases yet - the SCO case is a bad example of what could come about. [ed] - I'll note in passing that Jonathan Schwartz of Sun has said "I like IP" - which means that even the supposed friends of open systems could easily jump ship.

First rule of litigation: Sue someone solvent (i.e., follow the money). Many of the larger vendors are using patents as "trading cards" - the rest of the field has to "pay to play" (settlements). With widespread distribution of source, (alleged) infringement is easy to spot.

What about community countermeasures? There's a public patent foundation that challenges egregious patents. There's also the Open Source law Center and the OSDL's legal defense fund. There's also infringment insurance and indemnities offered by vendors. As well, some of the OSS vendors (RedHat, for instance) are getting patents - potentially as a defensive measure (the MAD theory of patent acquisition). Many patents are bad simply because the PTO primarily looks for duplicative patents, not for prior art. This is a problem in a new field (like software). What about the "Patent Pledges" of some of the big vendors (IBM, Sun, MS)? They are claiming that they won't assert their patents against the OSS community - there are potential anti-trust limits on large scale agreements this way. Bearing in mind that a patent assertion typically costs $2M, and most OSS projects are (financially) poor, this can easily be taken as grandstanding.

The GPL has an implied patent license

• Uncertainty about what is licensed and to whom
• Your contributions, anything in the code, or anything in the code or later added to it?
• Your chain of title or the entire open source community?

What risks surround IP really depend on which OSS license you use. For instance - how do you manage patent cross-licenses and obligations under the GPL? How can you know who you aren't supposed to sue?

Summary:

Ideologues don't like patents, never will. Distributors don't like patents, but are pragmatic. Integrators want it both ways, need a rational plan for their patents and those of others. users don't want to deal with patents, but need a rational plan.

Now we get to the part that the corporate members of the audience are interested in - how to make money off this stuff :) This is coming from Mark Webbink, Deputy General Counsel at RedHat.

As to "can you make money"? At this point, Mark popped up a slide showing RedHat revenue growth, which is now over $100M annually. Interestingly, their revenues started to trend up again in 2003 when they went to subscription licensing. In fact, 70% of the revenue is from subscriptions, 30% from services. Most of the subscription revenue is Enterprise based.

How you build a business model depends on which license (style) you choose - GPL or BSD. taking GPL first:

• Must include source
• All redistributed code must be GPL
• No restrictions on copy, modify (etc)
• No binary only (proprietary) code
• No per user (etc) fees

And the BSD:

• Does not requires source
• No need to push everything under BSD
• May impose other conditions
• May be embedded in proprietary systems
• May charge license (etc) fees

Retail model - not used extensively anymore, Redhat, Suse, (etc) have moved off. Did not provide scalable revenue, did not appeal to enterprise buyers.

The Loss Leader model: Early RedHat distro model to get mindshare, and now used by IBM (Eclipse) and other large vendors. Mostly used by OEMs. What about Dual Licensing? That's how MySQL used to do business (GPL or binary only). The license varies at licensee's choice. Allows a proprietary license for binary only uses. Experience? Creates market confusion (which license do I want/need? Why do I need to pay?) SleepCat software is seeing this now.

Where is it at now? The bundling model (i.e., services and subscriptions). Have to be creative about what you are charging for based on the license. You can charge for warranties, or "other" services so long as you don't interfere with downstream rights. So you create a bundle and charge a subscription license for the convenience of bundling. You can bundle technology instead of a service: TiVo, for instance. Typically in embedded apps.

Bundling with patents? Not really likely with respect to the GPL. With BSD, possible. The GPL, with its downstream obligations, makes it unlikely. What about a membership model? Mandrake used this model when retail wasn't working for them - somewhat similar to public radio funding.

What about the "Free Riders"? This is inevitable with Open Source models. You get non-developing distributors, non-contributing consultants - and not all enhancements go back to the community.

Here's the post lunch slump, but to keep us awake we have Douglas E. Phillips on the GPL and enforcement. Interestingly, there's been a recent filing challenging the GPL on anti-trust grounds in Indiana - so there should be a lot to talk about here. Douglas says he's going to focus specifically on the "viral" aspects of the license.

Eben Moglen of the FSF calls any questioning of the GPL's enforceability as FUD, and blames Microsoft. [ed] - given the "easy target" nature of MS in the OSS space, that seems mighty convenient. Moglen claims that it's enforceable because he's been enforcing it in private settlements (which says nothing about how it would be taken in court). Asking in a public forum tends to attract immediate attacks on a personal level (seen in various USENET forums).

In 2003, the FSF has pursued 20-30 enforcement actions in private (as reported in Forbes). The FSF has been engaged by companies wanting enforcement (MySQL) to help. There haven't been many decisions yet - and Douglas says that this is a lot like the way the BSA has taken to challenging alleged violations.

A year ago, there was a CA vs. Quest Software suit that seemed to assume the GPL was enforceable. in July 2004, there was a decision in Munich Germany, which enjoined distribution w/o conformance with the license. That's still not a US based decision though, so it's not resolved in the US.

In the US, there's the infamous SCO case, and more recently - 2005 - there's a suit alleging that the GPL is a price fixing scheme hurting programmers. So what grounds are there to challenge?

• Constitutional violation
• Pre-empted by copyright law
• Violates export control laws
• Never been tested in court
• Fails under the UCC
• Fails under common law
• Violates anti-trust law
• Selectively enforced by FSF
• Fails as a copyright license
• Too vague
• Not effective as shrink/click wrap

License vs. Contracts: Moglen states that a license is permission to use property, while a contract is an exchange of obligations. Moglen states that the licensor has no obligations, so it's a pure copyright license (i.e., no contract necessary). Thus, shrinkwrap license enforcement are avoided. [ed] This seems shaky to me...

What about the courts? We can reach back to General talking Pictures Corp. vs. Western Electric Co. (1938), which allows the patentee to grant a license. There's a 1995 case (McCoy vs. Mitsubishi Cutlery, Inc) stating that a license is in fact a contract. Muddies the waters, that's for sure.

What about revocation? Copyright law states that non-exclusive licenses are revocable. The FSF argues with that in its FAQs: "The public already has the right to use the program under the GPL, and this right cannot be withdrawn". Seems to be a conflict there.

Is it enforceable as a contract? Need assent from both parties first. The GPL itself does not purport to be a contract, and the FSF states that it's not. So - how can a contract be formed? The question is, does copyright pre-empt this? In 1996, the court rejected preemption in ProCD vs. Zeidenberg, stating that "rights created by contract are not equivalent to any exclusive rights within the general scope of copyright". Also - "Contracts, by contrast, generally affect only their parties; strangers may do as they please, so contracts to do not create exclusive rights".

Then there's Alcatel USA vs. DGI Technologies (1999), where we learned that copyright law cannot be used to indirectly gain commercial control over products it does not have copyrighted. Hmm - what does that say about the derivative/viral part of the GPL? The way the GPL is worded, a one line inclusion triggers derivation, and that goes well beyond current jurisprudence on copyrights.

This is an exploration of the various OSS licenses by Dov Scherzer (a lawyer in this field). The main thing - virtually no jurisprudence yet. Only one US case, some evolving ones in Germany. The US case (Progress Software vs. MySQL AB) was settled. To be clear, he explains that OSS is not:

• Proprietary software
• Freeware
• Shareware
• Public domain

Boy, there are a lot of interesting questions from the government people, and a bunch of assumptions based on regulations I'm not familiar with :) Apparently, some section of US code has something to do with public domain and government code, or people here think it does.

So what's the reason for the LGPL? It's intended to allow libraries that don't "infect" applications. The idea is that an LGPL library can be used with a proprietary program, and not "infect" it. Again, the whole issue revolves around the concept of linking, and the notions used in the LGPL and GPL make a lot of C/C++ assumptions. Gosh knows what this means in the world of languages like Smalltalk, Lisp, or even Java.

Is the GPL a binding contract? It's "clickwrap", not an actual contract. It's included with the sources, possibly as a separate file. On many sites, there's no explicit mention of the GPL other than in the source listings. So is it binding? Current jurisprudence states that Clickwrap, Shrinkwrap, and Browsewrap licenses are valid only if the user has made some kind of affirmative act to agree to the terms.

So what do the license terms that claim to push any derived work under the GPL mean?

• GPL vs. the Copyright act
• Hypo - what if I take 2 GPL lines and stuff them into a huge app?
• The GPL says boom - derivative work Ii.e., it's been opened)
• The copyright act differs (does not call it a derivative work).

A question here - what does copyright's "fair use" mean here? 2 lines? 100 lines? What? Under copyright law, it's not a derivative work unless it has substantially copied from a prior work. What this means in terms of source code is not clear (at least to me :) ). Current case work is pretty much on artistic work (art, text, music). Is using a small module different? What makes two pieces of code combined? Same storage media, but separated? Not combined. Same executable? Combined. [ed] - but even there, it's not clear - what about a Java JAR file or a Smalltalk parcel? The "same executable" standard seems to imply a problem here. Here's an interesting example - he addresses plugins, and states that it depends on how the plugin is used/invoked.

Again, I'd say that some court is going to have a ball with this some day. Another example from the slide deck: Load a GPL library into a non-GPL code base. Derive a subclass of one of the loaded classes - according to the FSF FAQ, that opens the entire application. The bottom line according to Dov: at present, you need both a lawyer and a technical expert to decipher the GPL FAQs. At present, none of this has been tested in court. We just don't know.

Heather J. Meeker on the CPL. It was approved in 2001 by the OSI, is a lot like the MPL. It was written to generalize the terms so that any OS originator (i.e., non-IBM) could use it.It came from the earlier IPL. Like the MPL, these licenses were intended to be accessible to lawyers and corporations. It is a viral license - version 0.5 was developed for Eclipse, the current version is 1.0.

The CPL distinguishes between original contributors and subsequent contributors. It also defines recipients. What you end up with is a stream of licensors (down the chain of contributors) - it's basically another way of saying sub-licensor, more or less (question from Larry Rosen). The CPL is explicit about copyright and patent licenses. The language I'm looking at on the screen was definitely written by a corporate lawyer - I nearly fell asleep just reading the first sentence.

Interesting isclaimer on infringement - the CPl puts the onus on the person wishing to redistribute to get patent rights if they are required. Definitely corporate friendly :) Another thing - subject to indemnification of contributors, distributors may offer different business terms to licensees. So, you can offer the software commercially for money. And another hint that this is a corporate license - the license explicitly states that each party waives its rights to a jury trial in any resulting litigation.

Interesting kicker on this last bit - the federal government has issues with automatic license termination and decisions about default litigation terms. Commercial firms probably have specific contracts for federal agencies for those cases - but that makes open source terms really interesting.