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

Paul Tansom paul at whaletales.co.uk
Tue Aug 26 23:27:59 UTC 2003


** Alex Hudson <home at alexhudson.com> [2003-08-26 15:57]:
> On Mon, 2003-08-25 at 23:30, Paul Tansom wrote:
> > > 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,... :-)
> 
> ... as a comedian? :o)

Ba boom :-)

> > 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. (*)
> 
> The above doesn't sit well with....
> 
> > 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.
> 
> ... since you are saying that their Linux developers should be spotting
> the stolen code, but that the UnixWare team should be the ones reviewing
> Linux. Doing either/both would be suicidal for SCO, so I don't agree
> with either scenario. IBM are in the same position (developing Linux and
> AIX), as are Sun (I would guess), HP (to an extent) and probably all the
> guys doing embedded work.

No, I am not commenting at all about the logistics of how it should be
done.  What I am saying is that if employee U of a company S writes a
piece of code and releases it under license P the code belongs to
company S; then employee L of the same company S gets the same piece of
code and works with it without knowing that he shouldn't have it, and
subsequently releases it under license F, the code still belongs to
company S, and it is still company S releasing it under a different
license; hence I don't see how company S can then say "oops, we didn't
realise we'd done that, I'm really sorry but everyone who bought the
code under license F now has to pay us X amount extra", when it is their
internal processes that allowed them to release the code they owned
under the wrong license.  Admitedly in practice this is a very complex
issue, made even more so by the involvement of third parties not
directly employed by the company.

> If you have one team working on a proprietary kernel and one on a free
> software kernel, I don't see how the two can be allowed to mix, and one
> to review the code from the other. I don't think any companies mentioned
> previously would countenance doing it, either.
> 
> If the UnixWare chaps were reading the Linux code, they would have to be
> doing this regularly to pick up any copying (given the vast size of the
> code). To do this well, they would become immersed in the code to a
> sufficient degree that they may well copy it into UnixWare unthinkingly.
> SCO would never allow that, neither would any other developer. There is
> no onus on them whatsoever to do it. If they keep things separate
> themselves, they have no reason to look for cross-pollenation.

If they had no reason to look, then why did they?  The fact that they
did look means that there must be a practical method of doing so!

> > 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.
> 
> That's exactly what's happening. They're not taking action against
> users. I also think SCO's licensing system is subtley clever: they are
> ensuring it continues to be infringment to run Linux, but not to use it
> (if you have a SCO licence). This doesn't conflict with the GPL, AFAIK
> (in terms of use of the software).

I disagree here to some extent.  While they are not actually taking
direct action they are saying that they consider themselves entitled to.
As such they are using the threat of taking action as a means of
'selling' their license.  To my mind they appear to be running a hi-tech
protection racket, but this is not the point being discussed here.

> The problem they have with their licensing system is that it would be
> impossible to reconcile the conflict with the GPL for distribution going
> forwards, but I don't think they would care about that: they're going
> after the Linux distributors, so blocking distribution would suit them
> fine. I think it's fairly clear that if they did find Linux 2.4+ to be
> infringing, then we would pretty much be back to Linux 2.2 - I don't
> think the subsequent code could be salvaged, except maybe device
> drivers, without a lot of work, which would involve starting with 2.2
> and pulling in newer stuff.
> 
> > 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.
> 
> How can you release something unwittingly? Only if they released the
> actual code in question, would they be doing that. I would go back to my
> previous example of stolen video recorder. 

I had to remind myself of this, but to follow the analogy hows this:

Company S has a batch of videos that they wish to sell at shop U which
sells at high prices; a sub-contractor moves some of the videos sitting
in the warehouse to an area due to be shipped to shop L which sells at
low prices; the videos are shipped and sold from shop L; given that
company S owns both shop U and shop L the customer woundn't expect the
company to then turn round and say "sorry, if you want to continue to be
able to watch your video then you'll have to pay us X amount, otherwise
we might take legal action".

> I just don't see how they could be expected to detect the code, if it
> was indeed copied from Unix. Their Linux programmers wouldn't know what
> it looked like, even if they came across it.

Again, I'm not going into the how's, just stating that a different
division of the same company has unwittingly released the code under a
different license.  Should the company be able to charge people who have
"bought" the software in good faith to continue to use it?  I don't
think so myself.

> > > 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.
> 
> Less of an issue how? Their code has still been nicked. Source and
> binary are not licensed differently (in fact, they might fall under
> 'translations' - not sure). 

To my understanding, in the closed source world you are purchasing the
right to run the binary, and get no rights whatsoever to the source,
hence if they sold the binary and had no access to view the source then
I would agree with you.  Likewise, if they had simply been distributing
the code without working on developing it, then I would also agree with
you.  It is the fact that they were Linux developers (to my
understanding of things) and have therefore taken the act of releasing
their work under the GPL license.  If they have not, as a company,
worked with the relevant code, then once more I will agree with you.

> It seems to be that you are setting a barrier of detection: that there
> are certain scenarios in which you expect them to detect the stolen
> code, and others in which you don't. Quite apart from the fact that the
> hurdle you set is arbitrary, I also don't see that it is relevant. If
> someone steals something from you, it remains stolen under all
> circumstances (statutes of limitations not withstanding). The flagrancy
> of the theft doesn't matter.

It is a very, very difficult situation to reconcile, but having thought
a bit about it I would suggest that detection of the code is not
necessarily the only solution.  Again, not being a lawyer I'm not 100%
sure of this suggestion, but if SCO had been a parent company owning two
other companies, say Caldera (for the Linux code) and Unixware (for the
Unix code) then Caldera would have no rights over the Unixware code and
the code would therefore not have been published by the owner under the
wrong license.  Just a thought, and continuing that train of thought I
cannot say that I am aware of whether this may actually be the case - I
am assuming not, but if it is, once again I would then be agreeing with
you!

> > I wouldn't say distasteful, in fact I don't follow the 'more
> > distasteful'
> 
> Distasteful to companies who are already scared of the GPL. If the
> result of this case is that your proprietary code can be lost as a
> result of someone else stealing it and publishing it, then that will
> make Free Software verboten in a huge number of companies. It would
> perpetuate this 'GPL IP virus' meme; to a horrible extent. The only
> 'crime' SCO would be guilty of - in your world - is not detecting the
> theft soon enough. But, they have lost their 'valuable' proprietary
> code. If other companies see that happen, that would serve to kill off a
> huge amount of development that could otherwise happen. I can't think of
> many worse scenarios.

I see, yes there is a risk that other companies could see this as
demonstrating how the GPL could be a risk to their own code.  This would
be on the development side rather than the using side, and I'm not
entirely sure how much of an impact the SCO case would have on this.  It
all comes down to the perception of the validity of their claim I guess.
I do see your point though.  I would hope that it would be seen that SCO
was guilty of not doing 'due diligence' to protect their code in a
situation that is quite clearly requiring a great deal of care.

** end quote [Alex Hudson]

I seem to be coming up with a number of scenarios where I would agree
with you, but unfortunately I am not yet convinced that they apply in
this case.  Ho, hum, tiddely pomme.

-- 
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