Maybe SCO had a point [LWN.net]

Maybe SCO had a point

Posted Aug 22, 2003 0:57 UTC (Fri) by Arker (guest, #14205)
In reply to: Maybe SCO had a point by rst
Parent article: Maybe SCO had a point

I think you both have good points.

Certainly we shouldn't pre-judge whether or not it was copyright infringement. I really doubt it is, the way I understand copyright law, and textual analysis, it's hard to believe that there is any actual infringement here at all. But unless a judge rules on it we can't be sure. Such code just shouldn't have been there.

I'm also disappointed with Raymonds glossing over the issue of the BSD-like license Caldera released this stuff under. It does have the advertising clause, I understand, and if so then it's not GPL compatible. One would not know that from reading Raymonds article. It's really not a big thing - clearly this is nothing anywhere near the level of infringement SCOs big talk has lead anyone foolish enough to believe them to expect - but if we expect other people to follow our licenses, we shouldn't take cavalier attitudes in regards to theirs.

SCO is going to try to seize any statements made, particularly by generally acknowledge community leaders like Raymond, and spin them to their benefit. Glossing over the difference between their BSDish license and the current GPL compatible BSD license could give them just such an opportunity. And even if that wasn't a factor, we still should avoid such statements on general principles.

(Log in to post comments)

Maybe SCO had a point

Posted Aug 22, 2003 2:01 UTC (Fri) by adamruth (guest, #12380) [Link]

One thing that I haven't heard much about (or skimmed over too quickly) is whether or not
and what versions of BSD this code appeared in. Would this code have been part of the
AT&T settlement with BSDI and thus BSDI could re-release it under any other license?

If the code appeared, properly, under a GPL compatible BSD license, then it wouldn't really
be a problem.

Maybe SCO had a point

Posted Aug 22, 2003 12:32 UTC (Fri) by Arker (guest, #14205) [Link]

It's my understanding that that's a no. The code in question is descended from v32 or an earlier version of AT&T Unix. I did find, and the article mentions, some very similar code in 2.11BSD, but on close examination it looks like that's probably a separate modification of v32. 4.4BSDLite (the first certain unencumbered version) doesn't seem to have it. You're welcome to take a look yourself, I didn't look too closely, just ran a couple pattern matches.

Maybe SCO had a point

Posted Aug 22, 2003 3:33 UTC (Fri) by taniwha (guest, #49) [Link]

And even if that wasn't a factor, we still should avoid such statements on general principles.

I believe the appropriate quote is, "Anything you say can and will be used against you in a court of law."

GPL compatibility

Posted Aug 22, 2003 3:36 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]

This is moot, because a version of the code was in the public domain, differing from the version used by two uncopyrightable lines. Even if that were not the case, the advertising clause would only be a problem if a GPL copyright holder sued about it. And even then it would be hard to show that anyone could ever advertise a feature of the malloc in this driver, so the advertising clause would not activate.

The compatibility issue doesn't work the other way - the BSD license they used does not ban licenses that are incompatible with it.

The lack of attribution is a problem, but one that would create financial damage. If we were to keep the function, we'd have to remediate that.

Bruce

GPL compatibility

Posted Aug 22, 2003 5:40 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]

Oops. That should read but not one that would create financial damage.

GPL compatibility

Posted Aug 22, 2003 12:35 UTC (Fri) by Arker (guest, #14205) [Link]

Don't forget that Caldera has copyright on some significant sections of GPL code in the kernel.

GPL compatibility

Posted Aug 23, 2003 13:21 UTC (Sat) by mammothrept (guest, #14201) [Link]

Bruce,

I am not a programmer but IAAL and if it is correct that there is only a two line difference in functional code between the public domain version and the SCO proprietary version, I think you are right that it is not copyrightable. The abstraction-filtration-comparison test used in most circuits to analyze software copying will 'filter out' even identical copying of code if it is of an entirely functional nature. Even if it passed an AFC screening and is found to be copyrightable, the creative element in two lines of code is going to be so scant as to be trivial and therefore not infringing. Unless SCO can show identical copying of much larger sections of code in other files, I don't see them having much of a case.

Doug Steele