Just one small clarification: GNUstep is LGPL (I am not a lawyer, none of this is legal advice). This means that you must:
Yes, I know. Sorry, it was an error in writing.
- provide your customers with the sources for any changes that you make to the GNUstep libraries (obviously, we'd rather you pushed them upstream, but that's not a requirement)
That's the plan.
You are not, however, required to publish the code for anything that merely links against GNUstep, or uses the GNUstep headers. Specifically, inline functions and macros from GNUstep headers do not 'taint' your binary.
Yeah, that's were we hope to be able to put our proprietary code.
More pragmatically, from my experience on the FreeBSD Core Team[2], we have seen several companies learn that maintaining a proprietary fork of an open source project is often much more expensive than any loss of competitive advantage from releasing their changes.
Our goal is to release as much as we can to contribute to the GNUstep developer community.
David
[1] Note: There are several cases of big companies apparently violating this requirement of the LGPL. One of the most prominent is Apple with WebKit on iOS, where they do not allow iDevice owners to relink mobile Safari against a custom WebKit. To my knowledge, this has never been tested in court in any jurisdiction.
I can imaging that allowing this would mean serious security risks... Interesting case however.
[2] Totally off-topic, but you didn't say what kernel / userland you were planning on putting under GNUstep. We have a very nice one, and it is the one where Clang and libobjc2 receive the most testing...
By "we", do you mean FreeBSD? Actually we are considering FreeBSD 10.