On 12/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > The only trouble I am having has to do with SQLObjects licensing (since > python's bytecode generation is compiling in my view) and this leaves > things ambiguous with any project code generated (as far as SQLObjects > LGPL licensing). Personally, I believe SQLObjects is a great object > relational wrapper and I like it a lot. I wish the licensing were > different but I don't think that is about to change any time soon.
I just wanted to come back to what you're saying here for a moment... You said "this leaves things ambiguous with any project code generated". When you say project code generated, do you mean the functions and whatnot that SQLObject generates for your classes? To me, that seems more like the case of gcc (which is GPL). gcc itself is covered by the GPL, but code that you compile with it need not be released under the GPL. I do know that the "linking" related text in the LGPL seems a bit ambiguous for dynamic languages. TurboGears' use of SQLObject is about as clear-cut as it comes, however: the code is byte compiled beforehand into .pyc files and you get SQLObject as an egg. So, the SQLObject code is in its own package and is very distinct from your own. (I am not a lawyer, and all of this is mildly irrelevant anyhow, since we know what Ian's intentions are here. I'm just curious to see if our usage of SQLObject is really *that* ambiguous, or if we do have a sort of best-case-scenario use of LGPLed code in a dynamic language because of eggs.) Kevin
