"I'm just gonna shake in my boots that some large company is going to drag me to court for not reverse engineering their code."
This is a little obtuse, because you're stating the obvious, and something that is completely oblique to what I was trying to tell you earlier. My point was that companies who care about the LGPL care whether it grants their users the irrevocable right to reverse engineer their dynamically (or often, statically) linked executables.
What difference does it make if you're *NOT* reverse-engineering their code?
Let's read back a little and regurgitate what your little condescending spewages were, shall we?
"You can write a large enterprise application, not compile it against glibc and the operating system will link it against glibc when a user types e.g. './maya'."
In case this quote isn't obvious, I'll point it out for those who are following this thread; 'not compiling it against glibc' and then expecting it to link against glibc when you run the resulting executable is illogical. The only alternative is to compile it against a glibc replacement that is unfettered by the LGPL, but still binary compatible. Such a beast does not exist--or, if it does, it is very well-hidden.
You attempted to mitigate your foolish statements, made in ignorance, by claiming that a program linked against 'any' libc will work on a glibc system.
This is false--and I challenge you to prove otherwise. Of course you won't.
You also said, "chances are you don't have a glibc.so".
I said glibc--NOT glibc.so. On every Linux system I'm aware of (aside from the BSD-derived Debian chimera) the only libc.so there is, is the glibc. It replaced the 'old' libc ages ago--long enough that very few companies produce executables for the old libc. Just because it's stored in/lib/libc.so.6 doesn't mean that it's a simple affair to link against some other anonymous libc and have it 'just work' against normal Linux' glibc.
You demonstrated your own ignorance with the following utterance:
"Me: Running the executable and doing the runtime linking after the fact doesn't modify the license.
You: Thank you. Now we've determined that dynamic linking does not make you subject to section 6."
You just displayed your titanic ignorance with this statement: the runtime linker is not the same as and has a different purpose from, the link phase of a compiler. Any first-year comp sci student--heck anyone who knows how to build a.so--knows this.
You said, "My object code contains: symbolic references to function names, structures and constants."
This is false. Any idiot with an objdump can plainly see the crtn, the init, the debugging symbols, the ELF notes, the huge portion of code from your own example program, that is all ripped directly from the glibc.
You said, "So you define "program" as "source code"? An executable is not a program? Do you think you could convince anybody of this in court?"
This is just completely missing the whole section of the LGPL you quoted immediately above the above statement, which reads:
"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,"
Now tell me--are you honestly sitting there trying to tell me that the end executable is designed to be "compiled with" the glibc? I don't know about you, but Source Code is what I "compile with" an LGPL'd library. "Program" in this sense has only one reasonable definition: Source Code.
But it's funny you argued otherwise.
You said, "Who linked my executable with an LGPL library? Did I link it, or did the kernel?"
This is ridiculous on its face. Even when you're compiling a program, the kernel isn't the one doing the linking: the compiler is the one doing the linking, and it doesn't link just randomly, on its own, spontaneously. You're invoking it. Thus, it is YOU who is doing the linki
Uh.. also: Why would a company care that you're "NOT" reverse engineering their code?
I thought the whole point was that companies care about whether you "DO" reverse engineer their code..?
English! Do you speak it?
Some doubt among legal scholars.. right. Which legal scholars? With what credentials? There you go again, talking out your ass.
Come on! Objdump, chicken! Let's see your technical analysis of a simple hello-world executable! What shock--you know it'll prove your little program isn't exempt under Section 5 after all.
(And if the preamble should be the main focus of argument, according to the Great Wavicle, why are you so set on arguing about sections 5 and 6? Isn't that the very definition of deliberately misleading a conversation?)
Funny how you won't actually point out where you think I'm technically wrong. Who's being evasive? In fact, I'd say it's downright illogical to make a bald statement without foundation--but then that's what you've been doing all along isn't it?
So? Let's see your objdump analysis. Point out specifically where it shows you that your executable's initialization routines and substantial portions of the rest of it aren't directly ripped from glibc code.
I've already showed you what I consider to be outside the LGPL's reverse engineering clause on a normal Linux system.
And you can believe or not whether I spoke with a lawyer. I don't give two rats' asses. And I never mentioned whether I was on the reverse-engineering side or part of a company who wants to prevent it, but it's typical of you so far to make stupid assumptions.
My "advice" has been anything but. It's been an argument from the get-go. I think you better start taking your meds--your brain is screwing up your grasp of English vocabulary again.
*shrug* Go talk to your lawyer. And when he tells you whether it's safer to interpret the LGPL my way or whether it's safer to interpret the LGPL your way, come on back and say hi.
And when you get whoever you're relying on to be your technical advisor to get off his lazy ass and interpret an objdump analysis of your little one-liner for you, do likewise.
And when you find an authority who doesn't think you're a moron, same thing.
Correction: This suit is NOT identical to SCOs. SCO's lawsuit is a copyright infringement lawsuit, NOT a patent lawsuit. A patent lawsuit is what this is about. There's no theft of sourcecode involved here.
Quid pro quo, Wavicle. You haven't done anything but offer up your interpretation of the LGPL and point at an authority who thinks you--you in specific--are generating nothing but deliberate misinterpretation.
So? Bring on the objdump. Let's see your "expert" *snort* analysis.
Even Dave Turner thinks you're an idiot troll who is deliberately misinterpreting what he says. How's that for a ringing endorsement, "Wavicle"?
So, let's see you build an objdump analysis, then. You said you know where the objdump'd code comes from. Show me that substantial chunks of your trivial executable don't come from LGPL'd code. Do it and we can both have a little laugh together.
Sorry dude--but a note sent directly to me from gnu.org trumps whatever argument you managed to coax out of him in a Slashdot forum with your own ambiguous misdirection.
Try again. And check out the lovely note I posted for you, wherein I describe what I consider to be an LGPL-free program that runs well under Linux.
I thought I'd let you know of a program which is perfectly workable under Linux, but which I do *not* think (even though it works fine from the CLI) is under the LGPL reverse-engineering clause.
section.data
msg db "Hello World!",0x0a
len equ $-msg section.text global _start _start:
mov eax, 0x04
mov ebx, 0x01
mov ecx, msg
mov edx, len
int 0x80
mov eax,0x1
int 0x80
If you have nasm (provided Slashdot doesn't screw up the formatting of my post) you can compile and run it with the following commands:
nasm -f elf t.s ld -s -o t t.o
Now take a peek at the objdump output. Clean and free of all LGPL taint.
That, I consider to be free of the LGPL influence.
Never let it be said that I wasn't accommodating for you.
Yes? And where does the it come from, troll? Why haven't you given a rundown yet? You hint that you know, but never actually display any proof (which would be simple for one so knowledgeable as you, surely).. why? Because you know you're wrong. That, or your technical "guy" isn't interested in furthering your silliness.
So, let's see a dissection, according to the great Wavicle, that shows where each ELF note and section came from?
You think you know, but I derive similar amusement to see you deny that most of it came from GLIBC or other LGPL'd libraries. Maybe you should include -g in your flags--just in case you become confused... again.
Or are you not even on a Linux system?
And.. when my question is leading? You keep on thinking that, if it makes you feel better. But I'm right, and you know it.
Go talk to a lawyer and ask him whether it's safer to rely on your interpretation of the LGPL, or mine.
I love how you're using as evidence to support your argument the exact statements that in actuality support mine.
And it wasn't the only example I provided. What, when I told you to go examine the output of an objdump that wasn't an example of glibc-supplied data IN YOUR OWN PROGRAM?
Why are you being such a ignorant ass? Such a foolish bullheaded idiot? Why do you concentrate on inanities?
Why? Because you're a troll. And not a very good one, either.
You're counting on me to sharpen your own argument in future debates. And your own argument is flawed, and sothat's not happening. Thus you continue in your stupidity, responding to notes you know are right, refusing to consult your own lawyer because.. why? You're too poor to hire one yourself.
I love this. I point out how Your Own Authority agrees with me rather than you (Dave Turner in this case) and you ignore that fact and plow on, bullheaded.
So you haven't answered my previous points. And, you haven't done anything but claim I was "spin"-doctoring Eben Moglen's statements on this which appear to support my claims.
So tell me--what other authorities are you going to point out for me to show you your interpretation was wrong?
You didn't provide a program that didn't. I showed you how to list the contents of the file via an objdump, and pointed out the default glibc-supplied data that actually outweighs the tiny amount of main() code you supplied.
The program you supplied wasn't one that I described. Also, this is assuming that the exemption in section 5 even applies to any programs these days, what with the massive amount of information included in the simple act of dynamically-linking a program on Linux.
The merit of a single item of my argument is "dubious," on the incorrect assumption you're making that the amount of objdump code in your program qualifies your program for exemption.
It doesn't.
I haven't failed to deliver that claim--you're stubbornly refusing to look at more evidence than the simple iline functions I pointed out earlier (which a simple, documented optimization flag DOES include in the object code output.)
I love that--you're saying that because your stupid little program (that uses no optimization flags) doesn't include the inline functions, that a large project like Maya doesn't either--AND THEN you go on to claim that without the inline functions, none of the other data available from an objdump has any merit whatsoever, and completely ignore the simple evidence which I've showed you how to find.
Hello. Read it again: I said use of the glibc-supplied versions of memset, memcpy, and so on, and I said that after looking into the string.h and bits/string.h and examining the inline memcpy and friends.
The fact that your vanilla, no-argument compilation didn't inline the string functions when it's perfectly plain in the/usr/include/string.h that you have to define the __INLINE_STRING for the inlines to be included in your software is completely irrelevant! What, you think you caught me in some kind of self-aggrandizing lie? You didn't, dude. I read the.h's, and I already told you how to inline the string functions in my previous note.
You can read English right?
So tell me again--when you point at Dave Turner as an authority and I show you a note the guy wrote to me that refutes your inanity, is that not enough to convince you you're wrong?
And what about the rest of the items I pointed out that are included in a standard dynamically-linked executable via an objdump?
I love how you pick a single, stupid little item that seems to be ambiguous, and concentrate on that as though the rest of the argument (which you have deliberately ignored for the most part) simply has no bearing if you just Just Prove That I Was Wrong About One Thing. Which you haven't.
Terrific--way to go dude. So, have you actually read string.h yet? Go read it and come back here.
This whole thread is a purely hypothetical tangent which assumes that standard linking WITHOUT defining __INLINE_STRINGS during compilation ISN'T enough to make it fall under section 6.
Tell you what--you point out the results of objdump, and show me how you can be so certain the amount of glibc-supplied data is enough to make it fall under section 6.
Dave Turner (answering as licensing@gnu.org,) a corporate lawyer, and the license itself which, by making the distinction between static and dynamic linking only in section 6B, the plethora of glibc data in the results of an objdump, the simple fact that your OWN authority disagrees with you and was, in fact, arguing with your very premise--all these things are irrelevant to you are they?
You still bull ahead regardless, confident in your trolling rhetoric, incorrect in your assumptions, blind to all reason, insisting that your overly narrow interpretation of the LGPL is correct when the people who wrote it disagree with you....I think you've wasted enough of my time going through these tangents like some kind of terrier attacking minor issues that you think I've fouled up on.
You haven't talked to a lawyer yet have you? Go talk to one, el-cheapo. Go ask him whether it's a safe bet for you to rely on your interpretation of the LGPL. And then report back here. You don't even have to name the lawyer--I, unlike you, don't need the guy's name just to satisfy myself I'm not talking with a 12-yr-old with too much time on his hands.
For more information, perhaps you should learn how to use objdump instead of -save-temps?
Also, if the.i file shows up with a pile of included header files, wouldn't it be logical to say that the resulting executable wouldn't have been possible without going to extraordinary lengths to avoid the direct use of large portions of header files to begin with?
Back to objdump: compile that same program. And now, run the following:
objdump -D -x test | less... notice that there are all kinds of chunks of LGPL'd code in there? In fact, in such a tiny program, the majority *IS* LGPL'd code grabbed directly from glibc.
In Maya, there are still substantial chunks of code that are automatically included in the dynamically-linked executable from the LGPL'd glibc just by the simple fact that they compiled it on a Linux system.
Did you think there were just ELF notes and that's it in the dynamically-linked executable?
And so what if your particular compilation flags didn't inline the memcpy defined in bits/string.h?
Try this one:
gcc -D__USE_STRING_INLINES -save-temps t.c... ooOOoo! There it is! So now you're going to tell me that large corporations don't use optimisations to speed their products up and instead use the vanilla compilation defaults? Riiiiight.
The names of the functions you call from a glibc-linked executable (dynamic or otherwise) are often #define'd to the glibc-native (and differently-named) functions. So even though you're using standard lib calls in your own source, it often stores completely different function names in the executable itself to link to the glibc.
The standard calls aren't, but I'd bet you that the glibc-specific calls are copyrighted.
Section 6 applies to all substantial dynamically-linked executables. Why haven't you talked to a real lawyer yet to confirm that there is very good reason to believe that the LGPL could actually apply to any linked executables, and not just statically-linked ones?
Maybe you have, and he's said I'm right?
Finally, if symbolic references are basically out in left field, then why do you keep mentioning them? They're irrelevant.. again there you are with the logical fallacies and semantics.
Keep em coming. This the best rhetoric you can come up with? It's like a shooting gallery.. I'm enjoying picking off your little inanities.
That isn't everything. That's not even accurate by itself. First off, there are also inline functions defined in the glibc header files, which I've already pointed out, which are much larger than the 10-line minimum inline or macro function as required in the LGPL exemption in sec 5, assuming that that exemption applies to anything linked to the glibc these days at all. Just for the sake of argument.
memcpy, memset are both string.h functions that are inline functions larger than 10 lines and thus any program making use of the glibc-supplied versions of memset and memcpy fall under clause 6. There are hundreds of other examples.
Second, I've already pointed out that symbolic references to functions aren't covered under the exemption in section 5. If you could be so kind as to point out what, specifically, states that "symbolic references to function names" means it's exempt under sec. 5?
"except for macros and inline functions"? What, are you forgetting the 10-line maximum?
Why are you rehashing old, already disproven argument?
The OS doing the runtime linking is irrelevant. Nice red herring. The act of linking it during compile time is what makes it fall under the LGPL once the one who did the linking distributes it to a third party.
Running the executable and doing the runtime linking after the fact doesn't modify the license. If you can build an executable without any form of glibc header file, or code from it, that still runs on Linux, as a result of some kind of clean-room re-implementation of libc either on Linux or some other OS, than you obviously aren't covered under the LGPL, now, are you?
But what has that got to do with all those companies out there that do specifically link to the GLIBC on their Linux build machines?
Logical fallacy--and not even a subtle one. Can't you do better than that?
The LGPL states that you are unrestricted as to licensing your final executable also... so long as you don't prohibit reverse engineering for interoperability purposes.
Describe the exact environment required for this linking, except for that magical place called "in theory" then you're on crack. No corporation is going to spend the time to re-implement a clean-room libc just so they don't have to link with the glibc at compile-time.... so? I'm waiting for the details of this magical clean-room that lacks LGPL'd glibc.
*shrug* You're wrong on that one. He wasn't making a distinction between the "work" and the final compiler jarfile in his answer. He used the term "work" and that has nothing to do with our argument here.
Also, I said "every commercial binary released on the Linux platform". Dave didn't say "Only for those statically-linked." He said I was correct on all that I said.
What the hell companies out there distribute statically-linked binaries without accompanying the downloads with dynamically-linked equivalents? Are they in the majority? No?
You're leaving out the ten-line max inline functions.
Also, using inline functions or macros that are greater than 10 lines can also be included in the final executable, dynamically-linked or no, because the macros themselves are preprocessor macros and thus expanded at compile-time and included directly in the program.
Also, you're wrong about symbolic references. The LGPL says nothing about symbolic references. It specifically states that "numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length)" are what exempts a trivial executable. NOT "symbolic function references". Where did you pull that from, your ass?
In other words, even just a single macro bigger than ten lines is all Maya would have to include before the executable must be reverse-engineerable.
I've found multiple macros that are greater than 10 lines in length just in bits.stdio.h alone.
memcpy is a notable one. What do you think the chances are of Maya not using memcpy *some*where in its Linux executables, or using one of the thousands of other inline functions greater than 10 lines in length somewhere in their codebase?
Does this mean my argument has weight now?... ah thank ya...
It's called the straw man. You build him up, and knock him down. You're describing a scenario of linking that is so unlikely as to be irrelevant to our discussion here, and then knocking it down with your argument to help prove your case.
It might also be a red herring, since you're making reference (more than once) to things that have no bearing whatsoever on our discussion. I've already pointed these instances out.
And if you don't think it would require a great deal of wrangling to link with glibc without the header files or any glibc code, and yet provide no description of why you think this is so, isn't that also a logical fallacy? That's a bald-faced conclusion with no backing argument whatsoever. Isn't it illogical to draw conclusions with no foundation in the argument you're making them in, especially when you know your opponent will call you on it?
Your rhetoric is poor, "Wavicle." It's also transparent. But it's a diversion, and so I come back here to laugh at you.
Slashdot Mirror
"I'm just gonna shake in my boots that some large company is going to drag me to court for not reverse engineering their code."
/lib/libc.so.6 doesn't mean that it's a simple affair to link against some other anonymous libc and have it 'just work' against normal Linux' glibc.
.so--knows this.
This is a little obtuse, because you're stating the obvious, and something that is completely oblique to what I was trying to tell you earlier. My point was that companies who care about the LGPL care whether it grants their users the irrevocable right to reverse engineer their dynamically (or often, statically) linked executables.
What difference does it make if you're *NOT* reverse-engineering their code?
Let's read back a little and regurgitate what your little condescending spewages were, shall we?
"You can write a large enterprise application, not compile it against glibc and the operating system will link it against glibc when a user types e.g. './maya'."
In case this quote isn't obvious, I'll point it out for those who are following this thread; 'not compiling it against glibc' and then expecting it to link against glibc when you run the resulting executable is illogical. The only alternative is to compile it against a glibc replacement that is unfettered by the LGPL, but still binary compatible. Such a beast does not exist--or, if it does, it is very well-hidden.
You attempted to mitigate your foolish statements, made in ignorance, by claiming that a program linked against 'any' libc will work on a glibc system.
This is false--and I challenge you to prove otherwise. Of course you won't.
You also said, "chances are you don't have a glibc.so".
I said glibc--NOT glibc.so. On every Linux system I'm aware of (aside from the BSD-derived Debian chimera) the only libc.so there is, is the glibc. It replaced the 'old' libc ages ago--long enough that very few companies produce executables for the old libc. Just because it's stored in
You demonstrated your own ignorance with the following utterance:
"Me: Running the executable and doing the runtime linking after the fact doesn't modify the license.
You: Thank you. Now we've determined that dynamic linking does not make you subject to section 6."
You just displayed your titanic ignorance with this statement: the runtime linker is not the same as and has a different purpose from, the link phase of a compiler. Any first-year comp sci student--heck anyone who knows how to build a
You said, "My object code contains: symbolic references to function names, structures and constants."
This is false. Any idiot with an objdump can plainly see the crtn, the init, the debugging symbols, the ELF notes, the huge portion of code from your own example program, that is all ripped directly from the glibc.
You said, "So you define "program" as "source code"? An executable is not a program? Do you think you could convince anybody of this in court?"
This is just completely missing the whole section of the LGPL you quoted immediately above the above statement, which reads:
"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,"
Now tell me--are you honestly sitting there trying to tell me that the end executable is designed to be "compiled with" the glibc? I don't know about you, but Source Code is what I "compile with" an LGPL'd library. "Program" in this sense has only one reasonable definition: Source Code.
But it's funny you argued otherwise.
You said, "Who linked my executable with an LGPL library? Did I link it, or did the kernel?"
This is ridiculous on its face. Even when you're compiling a program, the kernel isn't the one doing the linking: the compiler is the one doing the linking, and it doesn't link just randomly, on its own, spontaneously. You're invoking it. Thus, it is YOU who is doing the linki
Uh.. also: Why would a company care that you're "NOT" reverse engineering their code?
I thought the whole point was that companies care about whether you "DO" reverse engineer their code..?
English! Do you speak it?
Some doubt among legal scholars.. right. Which legal scholars? With what credentials? There you go again, talking out your ass.
Come on! Objdump, chicken! Let's see your technical analysis of a simple hello-world executable! What shock--you know it'll prove your little program isn't exempt under Section 5 after all.
(And if the preamble should be the main focus of argument, according to the Great Wavicle, why are you so set on arguing about sections 5 and 6? Isn't that the very definition of deliberately misleading a conversation?)
*shrug*
Funny how you won't actually point out where you think I'm technically wrong. Who's being evasive? In fact, I'd say it's downright illogical to make a bald statement without foundation--but then that's what you've been doing all along isn't it?
So? Let's see your objdump analysis. Point out specifically where it shows you that your executable's initialization routines and substantial portions of the rest of it aren't directly ripped from glibc code.
I've already showed you what I consider to be outside the LGPL's reverse engineering clause on a normal Linux system.
And you can believe or not whether I spoke with a lawyer. I don't give two rats' asses. And I never mentioned whether I was on the reverse-engineering side or part of a company who wants to prevent it, but it's typical of you so far to make stupid assumptions.
My "advice" has been anything but. It's been an argument from the get-go. I think you better start taking your meds--your brain is screwing up your grasp of English vocabulary again.
*shrug* Go talk to your lawyer. And when he tells you whether it's safer to interpret the LGPL my way or whether it's safer to interpret the LGPL your way, come on back and say hi.
And when you get whoever you're relying on to be your technical advisor to get off his lazy ass and interpret an objdump analysis of your little one-liner for you, do likewise.
And when you find an authority who doesn't think you're a moron, same thing.
Until then, ciao dude!
Correction: This suit is NOT identical to SCOs. SCO's lawsuit is a copyright infringement lawsuit, NOT a patent lawsuit. A patent lawsuit is what this is about. There's no theft of sourcecode involved here.
Algorithms, like mathematical proofs, should NOT be allowed to be patented.
Maybe this means I win. Yay!
Quid pro quo, Wavicle. You haven't done anything but offer up your interpretation of the LGPL and point at an authority who thinks you--you in specific--are generating nothing but deliberate misinterpretation.
So? Bring on the objdump. Let's see your "expert" *snort* analysis.
You give me nothing and expect me to waste my time answering your silly meanderings?
4 91 127
Or have you just not read his last reply to you?
http://slashdot.org/comments.pl?sid=71522&cid=6
Even Dave Turner thinks you're an idiot troll who is deliberately misinterpreting what he says. How's that for a ringing endorsement, "Wavicle"?
So, let's see you build an objdump analysis, then. You said you know where the objdump'd code comes from. Show me that substantial chunks of your trivial executable don't come from LGPL'd code. Do it and we can both have a little laugh together.
Sorry dude--but a note sent directly to me from gnu.org trumps whatever argument you managed to coax out of him in a Slashdot forum with your own ambiguous misdirection.
Try again. And check out the lovely note I posted for you, wherein I describe what I consider to be an LGPL-free program that runs well under Linux.
I thought I'd let you know of a program which is perfectly workable under Linux, but which I do *not* think (even though it works fine from the CLI) is under the LGPL reverse-engineering clause.
.data .text
section
msg db "Hello World!",0x0a
len equ $-msg
section
global _start
_start:
mov eax, 0x04
mov ebx, 0x01
mov ecx, msg
mov edx, len
int 0x80
mov eax,0x1
int 0x80
If you have nasm (provided Slashdot doesn't screw up the formatting of my post) you can compile and run it with the following commands:
nasm -f elf t.s
ld -s -o t t.o
Now take a peek at the objdump output. Clean and free of all LGPL taint.
That, I consider to be free of the LGPL influence.
Never let it be said that I wasn't accommodating for you.
Yes? And where does the it come from, troll? Why haven't you given a rundown yet? You hint that you know, but never actually display any proof (which would be simple for one so knowledgeable as you, surely).. why? Because you know you're wrong. That, or your technical "guy" isn't interested in furthering your silliness.
So, let's see a dissection, according to the great Wavicle, that shows where each ELF note and section came from?
You think you know, but I derive similar amusement to see you deny that most of it came from GLIBC or other LGPL'd libraries. Maybe you should include -g in your flags--just in case you become confused... again.
Or are you not even on a Linux system?
And.. when my question is leading? You keep on thinking that, if it makes you feel better. But I'm right, and you know it.
Go talk to a lawyer and ask him whether it's safer to rely on your interpretation of the LGPL, or mine.
I love how you're using as evidence to support your argument the exact statements that in actuality support mine.
Sweet--come on, troll. Show me what else you got.
And it wasn't the only example I provided. What, when I told you to go examine the output of an objdump that wasn't an example of glibc-supplied data IN YOUR OWN PROGRAM?
Why are you being such a ignorant ass? Such a foolish bullheaded idiot? Why do you concentrate on inanities?
Why? Because you're a troll. And not a very good one, either.
You're counting on me to sharpen your own argument in future debates. And your own argument is flawed, and sothat's not happening. Thus you continue in your stupidity, responding to notes you know are right, refusing to consult your own lawyer because.. why? You're too poor to hire one yourself.
So come on, poor-boy. What else you got?
I love this. I point out how Your Own Authority agrees with me rather than you (Dave Turner in this case) and you ignore that fact and plow on, bullheaded.
So you haven't answered my previous points. And, you haven't done anything but claim I was "spin"-doctoring Eben Moglen's statements on this which appear to support my claims.
So tell me--what other authorities are you going to point out for me to show you your interpretation was wrong?
Come on then--let's see them?
You didn't provide a program that didn't. I showed you how to list the contents of the file via an objdump, and pointed out the default glibc-supplied data that actually outweighs the tiny amount of main() code you supplied.
The program you supplied wasn't one that I described. Also, this is assuming that the exemption in section 5 even applies to any programs these days, what with the massive amount of information included in the simple act of dynamically-linking a program on Linux.
The merit of a single item of my argument is "dubious," on the incorrect assumption you're making that the amount of objdump code in your program qualifies your program for exemption.
It doesn't.
I haven't failed to deliver that claim--you're stubbornly refusing to look at more evidence than the simple iline functions I pointed out earlier (which a simple, documented optimization flag DOES include in the object code output.)
I love that--you're saying that because your stupid little program (that uses no optimization flags) doesn't include the inline functions, that a large project like Maya doesn't either--AND THEN you go on to claim that without the inline functions, none of the other data available from an objdump has any merit whatsoever, and completely ignore the simple evidence which I've showed you how to find.
What a piece of work.
Come on then? That all you got?
Hello. Read it again: I said use of the glibc-supplied versions of memset, memcpy, and so on, and I said that after looking into the string.h and bits/string.h and examining the inline memcpy and friends.
/usr/include/string.h that you have to define the __INLINE_STRING for the inlines to be included in your software is completely irrelevant! What, you think you caught me in some kind of self-aggrandizing lie? You didn't, dude. I read the .h's, and I already told you how to inline the string functions in my previous note.
..I think you've wasted enough of my time going through these tangents like some kind of terrier attacking minor issues that you think I've fouled up on.
The fact that your vanilla, no-argument compilation didn't inline the string functions when it's perfectly plain in the
You can read English right?
So tell me again--when you point at Dave Turner as an authority and I show you a note the guy wrote to me that refutes your inanity, is that not enough to convince you you're wrong?
And what about the rest of the items I pointed out that are included in a standard dynamically-linked executable via an objdump?
I love how you pick a single, stupid little item that seems to be ambiguous, and concentrate on that as though the rest of the argument (which you have deliberately ignored for the most part) simply has no bearing if you just Just Prove That I Was Wrong About One Thing. Which you haven't.
Terrific--way to go dude. So, have you actually read string.h yet? Go read it and come back here.
This whole thread is a purely hypothetical tangent which assumes that standard linking WITHOUT defining __INLINE_STRINGS during compilation ISN'T enough to make it fall under section 6.
Tell you what--you point out the results of objdump, and show me how you can be so certain the amount of glibc-supplied data is enough to make it fall under section 6.
Dave Turner (answering as licensing@gnu.org,) a corporate lawyer, and the license itself which, by making the distinction between static and dynamic linking only in section 6B, the plethora of glibc data in the results of an objdump, the simple fact that your OWN authority disagrees with you and was, in fact, arguing with your very premise--all these things are irrelevant to you are they?
You still bull ahead regardless, confident in your trolling rhetoric, incorrect in your assumptions, blind to all reason, insisting that your overly narrow interpretation of the LGPL is correct when the people who wrote it disagree with you..
You haven't talked to a lawyer yet have you? Go talk to one, el-cheapo. Go ask him whether it's a safe bet for you to rely on your interpretation of the LGPL. And then report back here. You don't even have to name the lawyer--I, unlike you, don't need the guy's name just to satisfy myself I'm not talking with a 12-yr-old with too much time on his hands.
You missed the rest of my note, apparently. Try reading it again.
And around and around you go..
.i file shows up with a pile of included header files, wouldn't it be logical to say that the resulting executable wouldn't have been possible without going to extraordinary lengths to avoid the direct use of large portions of header files to begin with?
... notice that there are all kinds of chunks of LGPL'd code in there? In fact, in such a tiny program, the majority *IS* LGPL'd code grabbed directly from glibc.
... ooOOoo! There it is! So now you're going to tell me that large corporations don't use optimisations to speed their products up and instead use the vanilla compilation defaults? Riiiiight.
For more information, perhaps you should learn how to use objdump instead of -save-temps?
Also, if the
Back to objdump: compile that same program. And now, run the following:
objdump -D -x test | less
In Maya, there are still substantial chunks of code that are automatically included in the dynamically-linked executable from the LGPL'd glibc just by the simple fact that they compiled it on a Linux system.
Did you think there were just ELF notes and that's it in the dynamically-linked executable?
And so what if your particular compilation flags didn't inline the memcpy defined in bits/string.h?
Try this one:
gcc -D__USE_STRING_INLINES -save-temps t.c
The names of the functions you call from a glibc-linked executable (dynamic or otherwise) are often #define'd to the glibc-native (and differently-named) functions. So even though you're using standard lib calls in your own source, it often stores completely different function names in the executable itself to link to the glibc.
The standard calls aren't, but I'd bet you that the glibc-specific calls are copyrighted.
Section 6 applies to all substantial dynamically-linked executables. Why haven't you talked to a real lawyer yet to confirm that there is very good reason to believe that the LGPL could actually apply to any linked executables, and not just statically-linked ones?
Maybe you have, and he's said I'm right?
Finally, if symbolic references are basically out in left field, then why do you keep mentioning them? They're irrelevant.. again there you are with the logical fallacies and semantics.
Keep em coming. This the best rhetoric you can come up with? It's like a shooting gallery.. I'm enjoying picking off your little inanities.
That isn't everything. That's not even accurate by itself. First off, there are also inline functions defined in the glibc header files, which I've already pointed out, which are much larger than the 10-line minimum inline or macro function as required in the LGPL exemption in sec 5, assuming that that exemption applies to anything linked to the glibc these days at all. Just for the sake of argument.
memcpy, memset are both string.h functions that are inline functions larger than 10 lines and thus any program making use of the glibc-supplied versions of memset and memcpy fall under clause 6. There are hundreds of other examples.
Second, I've already pointed out that symbolic references to functions aren't covered under the exemption in section 5. If you could be so kind as to point out what, specifically, states that "symbolic references to function names" means it's exempt under sec. 5?
"except for macros and inline functions"? What, are you forgetting the 10-line maximum?
Why are you rehashing old, already disproven argument?
Hey. Ass. Over here. Back in logic-land, that place you claim to love so well.
Creating the dynamically-linked executable during compile-time using glibc headers is what puts it under the LGPL.
I'm waiting on that clean-room libc alternative libc you dreamt up while visiting fairy-land. Come on then.. where is it?
The OS doing the runtime linking is irrelevant. Nice red herring. The act of linking it during compile time is what makes it fall under the LGPL once the one who did the linking distributes it to a third party.
Running the executable and doing the runtime linking after the fact doesn't modify the license. If you can build an executable without any form of glibc header file, or code from it, that still runs on Linux, as a result of some kind of clean-room re-implementation of libc either on Linux or some other OS, than you obviously aren't covered under the LGPL, now, are you?
But what has that got to do with all those companies out there that do specifically link to the GLIBC on their Linux build machines?
Logical fallacy--and not even a subtle one. Can't you do better than that?
The LGPL states that you are unrestricted as to licensing your final executable also... so long as you don't prohibit reverse engineering for interoperability purposes.
"Nice spin" indeed. Keep em coming.
Describe the exact environment required for this linking, except for that magical place called "in theory" then you're on crack. No corporation is going to spend the time to re-implement a clean-room libc just so they don't have to link with the glibc at compile-time. ... so? I'm waiting for the details of this magical clean-room that lacks LGPL'd glibc.
*shrug* You're wrong on that one. He wasn't making a distinction between the "work" and the final compiler jarfile in his answer. He used the term "work" and that has nothing to do with our argument here.
Also, I said "every commercial binary released on the Linux platform". Dave didn't say "Only for those statically-linked." He said I was correct on all that I said.
What the hell companies out there distribute statically-linked binaries without accompanying the downloads with dynamically-linked equivalents? Are they in the majority? No?
Than I'm right.
Again.
Try again!
You're leaving out the ten-line max inline functions.
... ah thank ya ...
Also, using inline functions or macros that are greater than 10 lines can also be included in the final executable, dynamically-linked or no, because the macros themselves are preprocessor macros and thus expanded at compile-time and included directly in the program.
Also, you're wrong about symbolic references. The LGPL says nothing about symbolic references. It specifically states that "numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length)" are what exempts a trivial executable. NOT "symbolic function references". Where did you pull that from, your ass?
In other words, even just a single macro bigger than ten lines is all Maya would have to include before the executable must be reverse-engineerable.
I've found multiple macros that are greater than 10 lines in length just in bits.stdio.h alone.
memcpy is a notable one. What do you think the chances are of Maya not using memcpy *some*where in its Linux executables, or using one of the thousands of other inline functions greater than 10 lines in length somewhere in their codebase?
Does this mean my argument has weight now?
It's called the straw man. You build him up, and knock him down. You're describing a scenario of linking that is so unlikely as to be irrelevant to our discussion here, and then knocking it down with your argument to help prove your case.
It might also be a red herring, since you're making reference (more than once) to things that have no bearing whatsoever on our discussion. I've already pointed these instances out.
And if you don't think it would require a great deal of wrangling to link with glibc without the header files or any glibc code, and yet provide no description of why you think this is so, isn't that also a logical fallacy? That's a bald-faced conclusion with no backing argument whatsoever. Isn't it illogical to draw conclusions with no foundation in the argument you're making them in, especially when you know your opponent will call you on it?
Your rhetoric is poor, "Wavicle." It's also transparent. But it's a diversion, and so I come back here to laugh at you.