Urmm.... Not sure why you think that Tom?
I don't think I'm attempting to circumvent anything, far from, as you'll see our company is 100% committed to OS and I have absolutely no interest or desire in trying to avoid that. My point was that the GPL in particular is more restrictive about the use of source code (I for example couldn't care less whether someone else uses my code in a proprietary product.. good luck to 'em I say). But the GPL does not allow for that.
This present a problem for customers for whom we develop software that would fall under the GPL but is commercially senstive. Therefore I merely suggested a well know approach which is to agree to limit disclosure of that instance under the terms of the NDA whilst in development. Of course once the software is delivered the customer is free to distribute if they want to. This neither circumvents, nor breaks the GPL. As you probably know just because something is Open Source does not mean you are obliged to make it available to anyone, just that you must distribute source code when you deliver binaries and thereby entitle the recipient to the same rights you have.
I think you'll find the answer to your point about oracle is that they probably fall under the provision in the GPL... I quote:
If identifiable sections of that work are not derived from the program, and can reasonably be considered independent and separate works in themselves, the this License, and its terms, do not apply to those sections when you distribute them as separate works
As Oracle merely uses the glibc libraries, and I would think few would argue that its a work not derived from glibc, and also does not distribute them together, therefore they don't automatically fall under the GPL. Also, there is a special exception in the GPL that covers those items normally distributed as part of an operating system.. i.e. its ok to build commercial sources that use OS elements.
Also, I seem to remember that glibc etc are published under the Gnu Library License, which better caters for this kind of use (and hence why I suggested OACS might license under that as well.)
My point really is that a new package is definately a derivative work, by definition the whole package approach is designed to make it easier to *extend* the OACS.
For example the license says:
... a work containing the Progam (OACS) or a portion of it, either verbatim or with modifications and/or translated into another language......
Which seems fairly clear to me.
Anyway, I'm not a lawyer, just a business man trying to ensure that I can make OS attractive and practical for my customers, there's littel point develping OS software if there's no way to generate effective revenue from it. Much as I would like to develop software for purely magnanimous reasons, I do actually habve to put food on the table 😊
My understanding is that the issue of derived works and linking has not been put in front of a court on the UK, therefore this exact definition does not as yet have precident, so I guess till a judge rules on it, its a bit of an unknown. However, code written for OACS does not communicate through pipes, sockets or other well-defined inter-process mechanisms, but rather it is loaded into the same TCL interpreter (hence the same run-time executable) and therefore my gut feeling is still that this comprises a derivative work.
Cheers
Simon
