IBM/SCO/GPL (Was: Re: (L)GPL remarks and FreeGIS licensing)

Paul Tansom paul at whaletales.co.uk
Mon Aug 25 22:30:13 UTC 2003


** Alex Hudson <home at alexhudson.com> [2003-08-24 13:16]:
> On Sun, 2003-08-24 at 11:51, Paul Tansom wrote:
> > Catching up on my mail, so a bit slow to reply here, but...
> 
> Tell me about it :o) 

Well it's like this, after a short spell working commercially with free
software I've ended up starting my own business,... :-)

Only kidding, I'm not about to list out my life history, don't panic!

> > I'm no legal expert and I don't know how things differ in the US, but
> > surely ignorance is no defense in the eyes of the law?
> 
> Well, ignorance is actually a defence. For example, if someone cons you
> into signing a document that is actually a contract for something, that
> signature doesn't really mean much and you are not considered bound by
> the contract.

Agreed, but in this case there is also the act of deception to take into
consideration.

> The point I was making was that it seems to me to be different to
> redistribute software and to grant a copyright licence to your own
> software. The reason I think people argue the point is because with free
> software, you can see what is in it, and people think SCO should have
> been aware. I don't really think that matters though. They didn't give
> permission for people to distribute the code, so the fact they were
> effectively conned into distributing it shouldn't automatically GPL it.

A fair point if Caldera(SCO) were simply distributing the code with an
amount of customisation to the distribution.  In this case they were
actually involved with the kernel development and as such had a close
working knowledge of both the code and the process. (*)

> I just think any other scenario would be unfair, in general, no matter
> what I might think about SCO themselves.

Whatever my views on SCO's actions, if I agreed I would say so.  In the
true tradition of freedom of speech/thought/etc. we'll have to agree to
differ though. (*)

> > In SCO/Caldera's case, they had a product that had a close relationship
> > to the Linux code they were/are distributing.  As such they should have
> > examined to code to ensure they weren't 'giving away' anything they
> > didn't want to, and if/since they didn't that is their own problem.
> 
> I don't think so. The UnixWare/Linux groups were apparently very far
> apart (different continents). They purposefully kept the groups separate
> so that code couldn't 'migrate' from one to the other. On that basis,
> which of these groups was in a position to warn that Unix code was
> getting into Linux? Neither, in my opinion.

I which case it would be down to the UnixWare group to look at the Linux
code.  It's not as if they wouldn't have had access to it.  It would be
down to the upper management to ensure that they were properly briefed
on the implications of running the two groups - they were certainly
aware enough to separate the divisions.

I will agree that it is an extremely difficult situation for a company
to be in.  If a third party takes code from one group (UnixWare) and
puts it into code being worked on by the other group (Linux) then the
Linux group will have no way of realising this.  The action should then
be against the third party though.  If Microsoft had used SCO code
within Windows I would not expect SCO to be going after Windows users.

(*) I'm wavering a bit on my stance having written this in that if SCO
can prove that none of their programmers had any involvement whatsoever
with the sections of the Linux kernel containing the offending code then
they have not made it available under the GPL license.  If on the other
hand they have hand involvement with that code then SCO, however
unwittingly, have released the code under the GPL license.

> The only people I know who regularly audit their whole code base would
> be the BSD people, especially OpenBSD. As I understand it, the majority
> of that auditing is done mechanically. If you expect people to audit
> free software before redistribution, you effectively remove their
> freedom to redistribute, because it's an almost unsatisfiable burden. It
> would also be a burden that only free software would bear, since with
> proprietary software you cannot see what is inside it and therefore
> cannot audit it.

I'm not saying anyone should audit the code in order to distribute it,
just that parties in a position such as SCO's (similarly IBM and Sun)
should take the necessary steps to protect their intilectual property if
the value it.  I'm not saying it is an easy situation to be in, but one
they should take responsibility for.

> If SCO had redistributed their Unix code as free-as-in-beer proprietary
> closed-source software, what would happen in your scenario? Are they
> still liable, even though they cannot actually see the source code and
> verify it? Or, are they not liable? If they are not, then you're making
> proprietary software much, much easier to deal with. Free software would
> become even more distasteful.

>From reading my above comments the answer would be clear to this - no
they would not be liable since they have not worked with the source
code.  If they had been involved with the code of the closed source
software then yes they would have released it under the license used.
There would be less of an issue here though, as the code would still be
closed source so the license would only apply to the binary and not the
source code.

I wouldn't say distasteful, in fact I don't follow the 'more
distasteful', but yes proprietry software is easier to deal with on its
own.  Free software is also easier to deal with on its own.  In a tidy
world there would be one or the other, in an ideal world there would
only be free software (imho).  Unfortunately in the untidy, less than
ideal world we live in both have to coexist - and it's not at all easy
sometimes!

** end quote [Alex Hudson]

-- 
Paul Tansom:  -  contact paul at aptanet.com for more information
Internet and Intranet Solutions   --   http://www.aptanet.com/


More information about the Discussion mailing list