Ronald Vanschoren pisze:
> At least the translation layer should be GPL'd and the binary
> part should be publicly available.
Just like in linux - the "interface" between OpenOCD and library can
clearly be open-source.
Zach Welch pisze:
> Someone should present a complete design document. ;)
Fo
Ronald Vanschoren pisze:
> Bit confused here, what do you mean with "BOTH libraries"
When you enable RLink (for example) which uses libusb, the libusb0.dll
library HAS TO be present on the system, even if you don't plan to use
RLink - that is because the libraries now are loaded unconditionally
On Thu, 2009-06-25 at 00:12 +0200, Ronald Vanschoren wrote:
> > This is _very_ apt observation, and one I almost forgot myself.
> >
> Thanks ;-)
> > As (I think) you say here, the Linux kernel module scenario does not
> > affect the legality of a loadable module in the same user-space process
>
Thanks for pointing out the system32 thing. I forgot about that. I'm an
embedded developer, I don't do things like DLL's ;-)
Bit confused here, what do you mean with "BOTH libraries"
Original Message ----
Subject: [Openocd-development] Creative summa
Ronald Vanschoren pisze:
> Link-kit is definitely better then build-kit, but what are we doing
> here? Dynamic linking is also a "link-kit". In my interpretation of GPL,
> there is nothing illegal to distributing an OpenOCD binary that _CAN_
> link to FTD2XX but doesn't require it. We (OpenOCD comm
> This is _very_ apt observation, and one I almost forgot myself.
>
Thanks ;-)
> As (I think) you say here, the Linux kernel module scenario does not
> affect the legality of a loadable module in the same user-space process
> as OpenOCD. The module still violates the GPL when distributed, sinc
Freddie Chopin pisze:
> Actually I think that OpenOCD should switch to dynamic library loading,
> because the need to have all possible usb libraries when you use Wiggler
> and OpenOCD version compiles with support for all possible dongles is
> not very convenient.
... OpenOCD version compile_D
Michael Schwingen pisze:
> However, as soon as a combination of OpenOCD + non-GPL plugin module is
> distributed as a single package/installer, you might again be in trouble
> with the GPL. IANAL, but anyone willing to distribute an installer
> package *should* be sure, and that means a proposed so
Freddie Chopin wrote:
> I'm not the first one to suggest such idea (modularity, drivers, ...) on
> this list.
>
Right. And modules in the same address space are tricky license-wise.
>
>> The drivers would have to run in a separate process space, which means
>>
>
> You are going to check
Freddie Chopin wrote:
> Michael Schwingen pisze:
>
>> by linking OpenOCD with FTD2XX, you create a
>> derived work which can not be distributed under GPL because the library
>> is not GPL.
>>
>
> You wouldn't link OpenOCD to anything at all. User would decide what
> file he/she would like
Michael Schwingen pisze:
> by linking OpenOCD with FTD2XX, you create a
> derived work which can not be distributed under GPL because the library
> is not GPL.
You wouldn't link OpenOCD to anything at all. User would decide what
file he/she would like to use, and that file has to provide full ABI
On Wed, 2009-06-24 at 21:36 +0200, Ronald Vanschoren wrote:
> > Note: Linux kernel modules need to be GPL, too - the only way to have
> > non-GPL drivers in Linux is to have userspace drivers, which are quite
> > limited in capabilities.
> >
>
> This is not correct. GPL v2 talks about "deriv
Michael Schwingen pisze:
> Freddie Chopin wrote:
>> 2. Modular OpenOCD which would allow binary "drivers" to be used (just
>> as the drivers are used in Linux kernel)
> What kind of module interface do you envision that would avoid the
> problems which we currently have with the FTD2XX library?
Ronald Vanschoren wrote:
>> Note: Linux kernel modules need to be GPL, too - the only way to have
>> non-GPL drivers in Linux is to have userspace drivers, which are quite
>> limited in capabilities.
>>
>>
>
> This is not correct. GPL v2 talks about "derived work". It's well
> accepted (b
> Note: Linux kernel modules need to be GPL, too - the only way to have
> non-GPL drivers in Linux is to have userspace drivers, which are quite
> limited in capabilities.
>
This is not correct. GPL v2 talks about "derived work". It's well
accepted (by Linus himself and most of the community
Freddie Chopin wrote:
> 2. Modular OpenOCD which would allow binary "drivers" to be used (just
> as the drivers are used in Linux kernel)
>
> PRO - possibility to use closed-source drivers (same as above), no need
> for running additional software other than OpenOCD, no speed penalty of
> the me
OK - be creative. End the flames, throw some ideas. Here goes another
summary of REALISTIC and ACCEPTABLE options, if ftd2xx.dll will still be
"censored" in the distributions.
1. Any kind of network protocol that would talk to "driver".
PRO - Possibilities to use JTAGs over internet to debug re
17 matches
Mail list logo
