Too trivail to copyright (pseudo code)

Posted Aug 19, 2003 21:28 UTC (Tue) by darkonc (guest, #14197)
Parent article: Why SCO won't show the code

Looking at that chunk of malloc code, it is extremely functional. It is a very straightforward and minimal implemetation of first-fit memory allocation from a free pool.

static struct ( size_t m_size, char *m_addr } *chunk;

While(more chunks){
if current chunk biggern than request {
take what we need out of the chunk
point the pool pointer to the rest of the chunk
adjust the size indicator.
if we're using the entire chunk,{
move this node to the end of the list.
# (so it doesn't block the search) #
} #endif
return pointer }#endif

}#endwhile
# couldn't find a big enough chunk
return(NULL) # error

It would be pretty difficult to produce a tight version of this algorithm without a high degree of duplication. I'd say you might as well cut and paste, because about the only changes that I can see making in a tight implementation would be to change the variable names. You'd be lucky to find 4 meaningful permutations of this algorithim, once you tighten up the code for the kernel.

Try to implement the pseudo code above, and see just how far away you end up.

BTW, this is not part of a block of duplicate code.. This is pretty much the entire thing. If that's the best that they can find, then they're SOL.

If you're not on somebody's shit list, you're not doing anything worthwhile.

Too trivial to copyright

Posted Aug 19, 2003 22:15 UTC (Tue) by rfunk (subscriber, #4054) [Link]

It would be pretty difficult to produce a tight version of this algorithm without a high degree of duplication.

Indeed, In his 1977 commentary, John Lions wrote about malloc and mfree:

The code for these two procedures has been written very tightly. There is little, if any, "fat" which could be removed to improve run time efficiency. However it would be possible write[sic]these procedures in a more transparent fashion.

Too trivail to copyright (pseudo code)

Posted Aug 19, 2003 22:17 UTC (Tue) by mammothrept (guest, #14201) [Link]

"It would be pretty difficult to produce a tight version of this algorithm without a high degree of duplication. I'd say you might as well cut and paste, because about the only changes that I can see making in a tight implementation would be to change the variable names. You'd be lucky to find 4 meaningful permutations of this algorithim, once you tighten up the code for the kernel."

The implication of what you are saying is that this section of code is not copyrightable under US law, regardless of whether a copyright notification is attached. First, algorithms themselves are not copyrightable because of a legal doctrine called the idea/expression merger. Ideas cannot be copyrighted. Only specific expressions of ideas can be. Further, if there are only a small number of ways to express an idea, then even the expression is not copyrightable. If there are only "4 meaningful permutations of this algorithm" then a developer could block anyone else from using this idea merely by writing the algorithm four different ways. This would be using copyright to attain patent-like protection which is not allowed.

Not even patentable... 25 year limit just about over

Posted Aug 20, 2003 14:53 UTC (Wed) by egberts (guest, #14248) [Link]

This is not even patentable either.