Mike McCarty wrote: > Maybe I didn't make myself clear. It doesn't matter *which* of GPL, > LGPL they are. If one links with them, then the licenses seem to > claim that the program produced is some sort of derived work. Oh really. What do you think this means then? ''5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. ...'' This is the LGPL dynamically linked case: "outside the scope of this License". >> And yet Asterisk, Bayonne etc exist and are sold as solutions your >> expensive Solaris implementation now has to compete with. What were the >> lawyers actually asked? Can we use Linux and keep everything >> proprietary? > > Eh? You know of VOIP gateways which run Linux? Google tells me this seems to exist: http://www.myphonecall.co.uk/voip/sip_pbx/epygi/default.aspx >From the same place you can buy cards to turn a standard PC into a PABX with Asterisk. >>> As I have pointed out, clauses 5 and 6 of even LGPL >>> force any *other* libraries I might link with to be distributed in >>> a form which can be reverse engineered and repaired by the end >>> user. >> LGPL section 6 begins: "As an exception to the Sections above, you may >> also...". The reason is that section 5 deals with dynamic linking to an > > Clause 5 deals with both. Section 5 says that dynamically linked apps "fall outside the scope of this License", then goes on to define what it considers to make up static linking. Section 6 is where you discover the rules to follow if you meet the static linking criteria. >> LGPL'd library, and section 6 deals with static linking. The reverse >> engineering constraint from section 6 therefore only applies to >> statically linked executables that actually contain the binary from the >> LGPL'd library. In the (normal, nowadays) case of dynamic linking, it >> does NOT follow that, as you claim, "LGPL force[s] any *other* libraries >> I might link with to be distributed in a form which can be reverse >> engineered and repaired by the end user.". > > You really need to get your prejudices out of the way and listen to > someone who knows his stuff(*), and stop arguing. You obviously know Lol... well this will be my last post to you on this subject, since you do not seem to be absorbing anything. Myabe you should email Adobe, Macromedia, Xilinx and so on with your theories and see if you can make them understand they are breaking your reading of the LGPL. Good luck. > very little about embedded programming. Dynamic linking and virtual > memory are real no-nos in real-time programming. So is the use > of malloc() in nearly every situation. Static memory maps are the > rule of law in almost all cases. And even if not, the LGPL library If you want realtime with low latency, do it in kernelspace. But you will find usually only a small region of your full functionality needs hard realtime. The rest of it can be managed without these hard constraints in usermode... with dynamic linking to improve memory usage and cache locality. It's good to see though that you are reduced to considering only some esoteric 1990s-style should-be-in-kernelspace "realtime" case as requiring static linking and having problems with the LGPL. I guess that means we agree that everybody else is going to be using dynamic linking and the LGPL is not trying to open their code. > I'm just telling you how things work in the real world. You don't > have to like it, but you do have to live with it. If deployment is I see.. well, thanks for that. > I've never used either LGPL nor GPL, and likely never will. If you used a copy of linux, of course you used these licenses... or you would not have been able to get the software. If that's the case, given what you say below then you only propose to take from the ?GPL and never give. That's fine... but you should be clear about what your attitude actually is. > The stuff I want to be free, I put into the public domain. > Other stuff I use licenses which seem to fit. GPL and LGPL > do not, and I trow never will, fit my needs. Well, speaking for people who do contribute to the ?GPL, we will try to struggle on without your code somehow. God knows it will be hard, but we'll manage. Have a nice last word, and then a nice day. -Andy
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
