[linux-elitists] Re: The breadth of SCO's claims

Rick Moen rick@linuxmafia.com
Tue Jul 8 17:14:39 PDT 2003

Quoting Aaron Sherman (ajs@ajs.com):

> On development lists, you generally take a discussion off of the list if
> you're going to dive down into minor points, or deal with off-topic
> stuff, and then bring it back once you've reached some sort of
> conclusion. 

I appreciate your comments, Aaron.  

No problem with deciding to go off-list whenever you think that's
desirable.  It's just a good idea to let the other party know.
(Otherwise, some people won't realise they're replying for the benefit
of just one person until after sending, or just prior to sending.)

> I did walk into this conversation with a bit of the
> wide-eyed "gee, did I just discover a way to factor large primes?!"
And I thought factoring large composites was tough.  ;->

> I think what I was trying to say there (context not coming to mind right
> away) was that you or Karsten had a strawman all ready to go for idiots
> like me who just fell off the boat....

It's not idiotic to think (and say) that software licensing must
necessarily involve contracts:  Quite a lot of people, including
attorneys, have written exactly that.

Privity of contract is the reason why this is an issue for open source

A creates a work and decides to offer a copy under proprietary terms.
To better control the work, he wraps each copy in an alleged contract (a
"EULA"), displayed in a clickwrap screen.  B buys a copy.  If you
accept the notion of this open-and-read-the-terms "contract" involving a
valid offer and acceptance, then B is bound to the terms.  (Courts that
doubt this notion call such things "contracts of adhesion" and are
reluctant to enforce them.)  B then turns around and sells his copy to C
-- or does he?  B's EULA obligations may profess to bar such sales --
though USA court cases have tended to invalidate resale restrictions.
If, anyway, C acquires his... copy?... bundle of rights?... then he
confronts (or somehow deliberately evades, which amounts to the same
thing) the clickwrap "agreement" screen.  _Arguably_, C now forms a
contract with A (or not), by accepting or declining.  (Some would
dispute that.  UCITA was one half-assed attempt to bring order to the

But then A decides to issue an additional code instance under an
open-source licence.  Let's say that you, being hypothetically a good
little law student, have been conditioned to examine each situation to
determine whether the four required elements of contract exist, when B
downloads a copy.  Let's say you decide B's valuable consideration is
where he gives up [blah, blah] rights he might otherwise have had.
Putting the file up for ftp with licence conditions was the vehicle for
A's offer.  B's download and subsequent use embodied his acceptance.
Etc.  Thus, contract.  But then B re-posts the file, and C downloads.

C most definitely has no contract with A, for lack of privity.  If you
buy the notion that licensing is inherently contractual, then this
suggests that open-source licences break upon any redistribution.

Lawyers on the OSI license-discuss mailing list urged that all
open-source codebases interpose clickwrap screens for installation and
forbid their removal, to fix this alleged "problem".  But, of course,
the problem exists only if you believe that licencing operates either
through contract law or not at all -- begging the question of whether
this is even the correct body of law in the first place.

There was a long and fruitless message thread on that point.

> When a license has terms (and, I can't think of any that don't) I call
> that a contract, but in some cases, I should probably be using the term
> "agreement", which is less weighted (and which I was clearly in need of
> in your quote of me, above).

Perhaps you can see why it matters _greatly_ whether the arrangement
must be a contract or not.  A contract can exist only if there is a
fairly direct offer and acceptance between (e.g.) parties A and C (thus,
privity) -- and this simply isn't how open source has always tended to
work.  The conceptual model generally used in open source, to date, is
that A affixes a list of conditions to a copy of his codebase and sets
it loose in public with non-default rights that you get if you accept
the conditions.  A doesn't really want a business relationship with C:
He just wants C to read the conditions on the package and either accept
them or write his own.

> Derived works are generally considered to be indivisible works of
> co-authorship only when the parties collaborated, but in a case like the
> BSD TCP stack being used in MS Windows, that would clearly be divisible
> ownership, and apparently that entails far fewer rights. This was new to
> me, and I consider it a valuable outcome of the conversation. It's the
> most basic refutation of my orginal hypothetical, and most of the reason
> that I've refered to the rest of the conversation as a red-herring.
> Useful in parts, but still not really follow-up to my question about
> BSD.


Authors generally tend to try hard to avoid co-ownership of indivisible
rights, since doing practically anything at all subsequently requires
joint action. 

> My goal would be to take the programmer's view, as someone who has been
> working with and contributing to free and Open Source software for well
> over 10 years now, I think I can relate to the mind-set and understand
> why people will make the mistakes they will, and how best to broach the
> topic of correcting those.

That could be really useful to people.

Cheers,              First they came for the verbs, and I said nothing, for
Rick Moen            verbing weirds language.  Then, they arrival for the nouns
rick@linuxmafia.com  and I speech nothing, for I no verbs. - Peter Ellis

More information about the linux-elitists mailing list