Øyvind Harboe wrote: > On Mon, Jul 14, 2008 at 11:18 PM, Jonathan Larmour <[EMAIL PROTECTED]> wrote: >> Øyvind Harboe wrote: >>>>> That's not true for OpenOCD. >>>> So what's the best way to proceed here? >>>> >>>> Make Jim Tcl + LGPL? >> I didn't think you were able to change the licence of Jim or OpenOCD, as you >> would need the permission of all copyright holders. > > Are you saying that LGPL for Jim would be the best alternative? (Ignoring > work involved, someone would have to do that work).
If you get everyone to agree to it, then that would certainly work. If you're going to contact them anyway, it would be nice if you could also get permission to use it under the eCos licence (which isn't quite the same as LGPL). Or perhaps something even more permissive like the same licence used by FreeBSD: http://www.fsf.org/licensing/licenses/index_html#FreeBSD >> The only route I can see is to take advantage of the "version 2 or later" >> clause of the existing licence, and move to GPLv3. Because of the "or later" >> bit, you don't need the permission of copyright holders to do that. (But >> once done, you can't go back without permission of copyright holders who >> contributed code when it's under GPLv3). > > What happens when one mixes GPL and GPLv3? That is not a problem. The "or later" clause in GPLv2 means that that's permitted. The whole would be covered by GPLv3 in practice. >>> Also, we don't need to link Jim Tcl into OpenOCD, but it's less hazzle. >> The FSF's view (untested in court of course) is that linking does not have >> to mean literal 'ld'. In fact the relevant bit of GPLv2, section 2, does not >> mention linking. It only refers to 'works' in the copyright sense. Having >> them as separate executables, but making one wholly dependent on the other >> means they are not separate 'works' in the copyright sense. If OpenOCD and >> Jim Tcl _were_ separate works which can work together and separately, that >> would be fine. But if Jim is an inherent part of OpenOCD then that does not >> side-step the GPL obligations. > > Another reason to make OpenOCD support multiple scripting engines. > > Is there, in practice, a problem to work w/Jim Tcl until we've got the > scripting > infrastructure sorted and at that point make a separate executable for > Jim Tcl? > > (If we state this as a goal, we'll be getting patches steering us in > that general > direction hopefully). It depends what you mean by "in practice". If anyone distributes openocd before that work is complete, strictly that would be a licence infringement. >>> There are many ways forward. Including ditching Jim Tcl. >> Obviously. >> >>> The scripting work that is being done with Jim Tcl specifically >>> applies to other scripting engines and perhaps we'll define up >>> an interface to OpenOCD where one can place any engine on >>> top. >> Sure. As above, if openocd is not dependent on Jim TCL, that would be fine - >> if Jim just happens to be one of a choice of front-ends (one of which being >> GPL-friendly :-)). >> >> I think your easiest route is still GPLv3 though, IMHO. > > That would cause problems for athttpd(eCos license) using Jim Tcl > or? I was talking about licensing OpenOCD as GPLv3, not Jim. It's easier to move OpenOCD to GPLv3 than change Jim's licence I believe. Because the existing GPLv2 code can be switched to GPLv3 without a need for any permission. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
