Sigh.. you're taking what I said completely out of context. I said that the SPECIFIC EXEMPTION IS FOR SOURCE CODE in the quote you mentioned. I Said the specific exemption was for SOURCE CODE, NOT OBJECT CODE. I didn't say there wasn't an exemption for some types of object code. I said the exemption for object code doesn't apply to the kind of executables that large companies build.
Are you too fucking obtuse to link together more than one argument at a time? More than one concept? Do you not recall me specifically mentioning Maya on more than one occasion?
For someone who detests even things that smack of logical fallacies (but aren't) you sure like you use them yourself.
You're also wrong about the dynamically-linked executables. It would take quite the wrangling to get the compiler to link blindly against libraries that you just happen to need for the customer to run on their own systems..
That's wonderful.. you're stretching it to the point of pure ridiculousness.
Keep it up--you're making this too easy.
(And yes, I'm still going to say that a corporate lawyer, who's smarter than you are, is more right about this, because all you have to do is visit a corporate lawyer and he'll confirm that I'm right. But you won't, will you?)
Dude. Let me get this straight here. You're claiming that Mr. Moglen's statements as to whether the LGPL makes the combined "work" FALL UNDER THE LGPL'S FULL SCOPE OR NOT as an argument as to whether an executable linked with the LGPL needs to be released under a license compatible with the reverse engineering clause.
You keep pointing to your named authorities, and I'll keep pointing out how incorrect your interpretation of their words are.
He's talking about whether the rest of the program (ie: source) falls under the GPL just by linking it. If you link (dynamically or statically) with a GPL'd library, your entire source falls under the GPL. Period.
What difference does the LGPL make? It means you can keep your source code private.
That's it..! And he's talking about the Work itself. The work includes the source. He's not talking about the executables.
Now tell me--what have you to say about Dave Turner's opinion? Is Dave Turner wrong after all? If he is, then why did you point to him as an authority? The answer is, of course, because you incorrectly interpreted his notes to you.... which just happens to be the exact same thing you're doing here.
Linking--dynamically or statically--to an LGPL'd library makes the final executable (but not the primary source code used to build it) fall under the reverse engineering clause.
Yet another reason not to listen to random idiots spewing on Slashdot. Get it from the source, and write a clear question to licensing@gnu.org. Make it a yes/no question and you'll get answered more quickly.
I'm saying you get to reverse engineer it because the people who compiled it compiled it against the GLIBC, not because you typed./maya.
How dense can you be? What, do you not speak English? Are you that blind to the meaning of the words I'm using?
Section 5 applies to tiny, tiny, insignificant executables--but I've never said anything about those, have I? I'm talking about commercial enterprises and their Linux offerings, such as Maya. I've been talking about the large projects from the start.
If you don't want to believe my company retains the services of a lawyer, that's really your perogative. But I've already blown away you "Dave Turner agrees with me" ambiguous bullshit.
Go on then, troll. Troll me some more. You've already lost. Admit it.
That's funny how you tried to argue that Dave Turner agrees with you, and then when I come back with a note that he sent me, that specifically deals with the argument we're having in no uncertain terms, and then you completely ignore that fact and plow stupidly on, like some kind of big stupid ox who won't stop yanking on the yoke.
It's just because you were in an argument with him, and kept at it, and he ignored your last notes--which I thought was illuminating--that you think you're still right. I find it funny that you interpreted his last note to conform to what you think is right, and are now ignoring everything else.
What, you think you're smarter with the law than a corporate lawyer who makes midrange six-figures and knows assembly? Do you? What arrogance.. what egotism.. what complete and utter bullishness.
Well, you're certainly a piece of work.
Troll.
And I'm glad to have been trolled, because your disinformation does nothing constructive.
The LGPL states "the object code for the work may be a derivative work of the Library even though the source code is not."
I'm not interpreting it to apply equally to source and object code. I've already fucking told you it doesn't apply to the source code, otherwise companies would have to release the source with their commercial Linux executables.
It doesn't give specific exemption to object code, it gives specific exemption to source code! That's what I've been saying from the start!
Linking and using the header files pulls in inline functions greater than ten lines in length. Can you guarantee that a project like Maya wouldn't have substantial portions of the GLIBC included in its executable? Enough to make the executable fall under the terms of the LGPL? And executables like Maya are what I've been talking about from the start--not some puny little 10K executable tool you've built. Get it?
I'm not affirming the consequent, dude. 6B could not exist if dynamically-linked executables made any program exempt from the LGPL.
Listen carefully, because I'm done arguing with you. You've already ignored large portions of my argument to concentrate on the simple, stupid semantics. You've ignored the fact that Dave Turner agrees with me. You've ignored pretty much everything I've said and are dogmatically adhering to an obvious ignorance of just how much LGPL'd technology is required to link an executable, nevermind how much actually ends up in an executable, and are at this point attempting to attach a logical fallacy to an argument that isn't.
For the record, for all those others out there who are reading it and didn't know what he meant by "affirming the consequent," it goes like this:
If Something, then something else.
Something else is true, and this something is true also.
In this case, however, he is stating unequivocally that dynamically-linked executables fall completely outside the LGPL. Period.
My argument is simple:
If that were the case, then 6B would not only be useless, but specifically misleading, since the LGPL talks about a single executable being distributed and how it, specifically, may satisfy the LGPL. If 6B would make the executable exempt, the LGPL would state that it is exempt in the case of dynamically-linking and 6B wouldn't even be in there. But no--named symbols from the LGPL'd library are embedded directly within the final executable, especially if debugging is turned on in the compiler.
Section 5 gives specific exemption to source code, and only exemption to object code if it uses insignificant portions of the LGPL. Get you head screwed on straight--and talk to a real lawyer. He'll agree with me.
Oh, you can't afford a real lawyer? Well, you go on thinking what you like about the LGPL, and if it ever comes to a head, you see what happens. If I ever find out about how you got nailed by a good lawyer in court, I'll laugh. Loudly.
They are covered in Section 6. Section 5 provides exemption for the source code. Go talk to a lawyer, he'll tell you I'm "probably" right.
Just because the header files don't completely remain in your code after the dynamic linking, doesn't mean they weren't necessary to create the dynamic linkage to begin with on your Linux system. Huge amounts of header files went into your compiling process. If you could create the executable that runs fine on Linux without masses of glibc header files, then I might be inclined to move my opinion a shade in your direction.
You include stdio.h, and if you link it on NetBSD, you don't have to worry about the LGPL. As soon as you link your software on a Linux system, the GLIBC header files are what your software is including, and using during the preprocessing phase. You don't think I can dig up an inline function bigger than ten lines somewhere in the entirety of the glibc header files? Anywhere?
The only difference between static and dynamically-linked in the LGPL is mentioned in section 6, part b. It doesn't say "Dynamically-linked executables are exempt." It says you can use dynamically-linked executables to help satisfy section 6.
What about this suggests to you that dynamically-linked executables don't even need to satisfy section 6, when they're mentioned as a specific way to fulfill section 6?
Why would they be mentioned at all in sec. 6 if dynamically-linking made the final executable completely exempt from the LGPL from the get-go?
No, you don't understand the sec. 5 exemption. It refers to the program: the program in this case is the source code. It can ONLY refer to the program, otherwise LGPL's internal consistency is bald-faced mucked up. The source code--even if it's written to "use the library" doesn't fall under the LGPL, and thus the commercial interests get to keep their code secret.
It even states that unrestricted linking to the library wouldn't allow users to exercise the rights the LGPL is trying to protect! What, that only applies to unrestricted static linking? Dynamic linking is completely unrestricted then?
Read it. Now read it again with an open mind. Be enlightened.
Uh no. You don't get to know who this corporate lawyer is, because we paid him to give his opinion to us, and I for one would hate to see him get a pile of hate mail from people who don't properly understand his area of expertise.
And it wasn't Eben Moglen.
You linked the executable when you triggered the command to be run on your system, when you typed in the various glibc-specific #include statements in your source code that were glibc-specific, when you triggered the compiler to include those files in the pre-processing phase, and when you built your software so that it conforms to the glibc calling conventions and arguments, and when you included those various glibc symbols in your final dynamically-linked executable.
Dynamic linking still puts chunks of the LGPL'd code into the executable.
Not sure what you're talking about the OS fiddling with your license agreement... but your OS doesn't do anything until you tell it to do something.
Let me describe in a little more detail what's going on here and what it's starting to look like:
1. My corporate lawyer, Dave Turner, the FSF, and myself, all believe the LGPL to protect the rights of the downstream of a distribution of an executable linked against the glibc, to reverse engineer that executable for his own purposes.
2. You, on your lonesome, are fighting the good fight in the belief that we are all wrong. With only your sense of what's right and what isn't to keep you going. Apparently.
Conclusions: i. You are a troll, trying to elicit an authoritative opinion from me you can adopt as your own elsewhere, or ii. You really do believe what you're writing, regardless of a complete lack of authoritative sources upon which you rely to provide a foundation for your opinions, or... some nebulous third option?
Let me give you an analogy to your last "the kernel did it, not me" argument, which was ridiculous on its face.
I take a hammer. I swing the hammer, which connects with a nail and bashes it into a slab of wood.
Is the hammer responsible for bashing the nail into the wood, or am I, who provided the conscious direction for the hammer to do its dirty work?
Just because I don't understand the exact physics of what happened, doesn't mean I don't see the results, am aware of what happened, and realise that it was through my own actions that the nail was hammered into the wooden slab.
So why, again, is it that the OS is to blame during the runtime linking of your "./maya" command, when you were the one who issued the command to begin with?
Anyway, that's completely irrelevant, since we're talking here about executables that have been distributed to someone else, and that someone else's right to reverse engineer that executable for his own purposes--whatever those nefarious purposes might be--and whether a commercial enterprise has the right to restrict reverse engineering of their software.
I think I'm done. I for one and quite secure in my right to reverse. And good for Clause 6, I say!
I'm sensing some backpedalling here. But that's okay, I don't think any less of you for it. (How hypocritically magnanimous of me. Apologies.)
The LGPL guarantees that you can use reverse engineering to do whatever the hell you want with any of the GPL and LGPL code you have if you keep it to yourself. You can refuse to release any mods, you can refuse to release any source, whatever.
The LGPL and the GPL both apply just to distribution of the derived works (and in our argumentative case,) executables linked (statically or dynamically) to the GLIBC.
That's why they're covered under copyright laws: the act of copying is what they're governing, not the act of modifying or fiddling with your own copies.
The act of dynamically linking your code eases only your obligation to supply the compiled object code of your program in order to enable your customer (or downstream of your distrubution efforts) to relink against other libraries than the LGPL'd one that it was originally compiled against. By creating a dynamically-linked executable, you no longer have to also distribute the object code.o intermediate files. But it's still a derivative work.
The dynamically-linked executable contains references to the LGPL library, symbols from the LGPL library, and so on, in excess of the ten-line exemption the LGPL mentions in section 5. It also required that you #include a pile of header files. A dynamically-linked executable is a derivative work because it contains or used large portions of the LGPL'd library.
Linking against LGPL'd code requires access to and inclusion of its header files in the code you're compiling.
What, you can manage to build an executable of a substantial Work without including large numbers of glibc-supplied header files in your code? I did mention large-ish software such as Maya in previous notes, did I not?
Or are you going to bring up that tired old "I use a wrapper and thus my software is immune" argument which is clearly false because of the viral nature of the GPL and LGPL licenses?
The inclusion or not of LGPL'd code is completely irrelevant if you aren't distributing the final, compiled and linked executables. I had thought that part of our argument wasn't under debate.
What we're discussing here is (or should be) how the LGPL actually applies to what it actually applies to; ie: distributed executables of software that runs on Linux, for example Maya and other software.
Just because in-memory there is a larger composite of the executable, expanded by the runtime ELF linker, doesn't mean that substantial portions of the LGPL'd library aren't already in the executable, or used to create the executable in such a way that the final executable is an LGPL-derived beast.
The LGPL defines what it means by "linking" and talked about it:
" However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such."
The program, defined by its source code, does not fall under the LGPL. However, the executable created by linking the program (dynamically and especially statically) does, and puts it under the reverse engineering clause 6.
"Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
This refers to the work--the work is the source code, and this is the exclusionary protection that saves proprietary users need to protect their source code from falling under the LGPL.
However, the link itself results in an executable, and that is specifically called out in the LGPL in the following clause:
"The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."
What the hell crack are you smoking? I've already written David Turner and his answer to me was far more explicit than your reference:
My turn: This'll be my last response. Corporate lawyer's opinion trumps whatever you think you know about the matter, but let's go from there shall we?
I wrote a note to the FSF and got the following response back:
> If so, then wouldn't all executables linked with the > GNU/Linux LGPL'd GLIBC suddenly be open to reverse engineering and > modification for the customer's own purposes, and that if a proprietary > vendor tried to take away the right to reverse engineer their product that > they would lose the right to link with GLIBC?
Yes, this is all correct.
-- -Dave Turner Free Software Licensing Guru This is not legal advice. If you need legal advice, see a lawyer.
This is a message directly from Dave Turner. If you want the full source, I'd be happy to supply it.
Secondly, after receiving this, I had to take it to a corporate lawyer to get advice. Without it being commutative to any situation you think you're on top of (but apparently aren't,) the corporate lawyer agreed with Mr. Turner's email to me: There is substantial reason to believe that the LGPL guarantees the right to reverse engineer any executable linked with an LGPL'd library.
This is how it should be, and it's a good thing, except for those commercial customers who are concerned that someone has the motivation to write a free alternative to their software.
But you're wrong. Dave Turner, plus a corporate lawyer, plus common sense reading (ie: not stretching it to fit what you think it should) all equal LGPL protecting reverse engineering on all proprietary software that doesn't link with a proprietary or BSD-style replacement for libc.
The corporate greed feeding on the open source is fine--as long as they're obeying the terms of the license. That's part of the benefit of open source: that people get to use the software for whatever they want, so long as they're obeying the terms of the license. Who cares of some company is using GPL software, modified internally, to do their work and making millions off it?
That's partly what the people building the open-source software have come to terms with before releasing their source code to begin with.
If greed is encouraging the adoption of software that enforces freedom, then corporate greed is working for us all! And good on it, I say!
A note from the GNU foundation's people, and then a resulting corporate lawyer's opinion says you're a moron armchair lawyer idiot.
Where you're wrong is thus: The SOURCE CODE of the program is outside the scope of the license--however the ACT OF LINKING IT with an LGPL-licensed library creates--ACCORDING TO SECTION 5, THE SAME SECTION YOU'RE TRYING TO USE IN YOUR ARGUMENT--a derivative work. Thus, the executable itself falls under some terms of the LGPL, and thus SECTION 6, the reverse-engineering clause.
Yes, this means you are allowed to reverse-engineer Maya, or any other commercial software that runs on Linux according to the reverse engineering terms in the LGPL.
Get your fucking head out your ass.... and then deal with it.
... So this reminds me of the kind of intensity between the ones who split from the MIT labs and formed a commercial company out of the fruits of the research. RMS began writing software which incorporated each new feature, but was in his free software.
One man, keeping up with--and surpassing--the programming of many others.
Larry added in the legal aspect because he knows that baiting RMS in that fashion will garner him a loss--it's happened before, and it can happen again.
I, for one, would love to see RMS piqued to the point where he's willing to write (in reasonable time) the BitKeeper-killer. Wouldn't that be a feat and a half, if even half of the effort that Larry says it took to develop BitKeeper was accurate.
I'll tell you one thing: It doesn't take millions of dollars to develop a versioning system. It takes one programmer about eight months to build something functional, and then another two years to shake the bugs out and make it perfect.
...your friend has the physical superiority (doesn't he?) He should never feel threatened, and if he does, he needs to spend a few months in the gym.
Keep putting it off, and tell him to never get himself into a situation where she's alone with him in a locked room. Eventually she'll get frustrated, and your friend can try to keep the relationship platonic, because after that point it'll come to a crux and she'll decide whether or not to make good on her implied threat. If he's still working there, he can still maintain a friendly professionalism. Otherwise, get a fricken new job.
She obviously is attempting to use her position of power to intimidate him, and push the issue. She knows he's rejected her, and now she's applying more pressure. She can't take no for an answer, and she's used to getting what she wants.
The fucking bitch.
She's trying to intimidate him, and it's obviously working, or you wouldn't be here asking a bunch of geeks how to deal with a situation most of them have never faced, and will never have to face.
Tell your friend to get a frickin' spine and stop whining about "harassment." Harassment is meant for people who can't defend themselves physically nor emotionally, nor with position. Your friend isn't one of those people unless he's physically inferior to this woman.
Cripes..! Tell your buddy to stand up and be a man for once!
What are your thoughts on the GNU General Public License? Have you dealt with any cases in which the GNU GPL had any bearing, and if so, how did it affect those cases?
On a related note, do you think the GNU GPL or other similar open source licenses are effectively steering us towards or away from commercial, proprietary software? Do you think this is a good thing?
Thank god, someone who gets T3. Thank you, AC, you deserved that 5. Should've posted under a nickname.
T3 *did* plug the gaping, horrible holes that T2 created. T3 brings back that sense of fatalism, that doomed, hopeless despair that was in T1. T3 fixes the problems that were introduced in T2 because Arnie didn't want to do the kind of movie that T1 was (his children were too young to understand.)
T2 was an abomination: I said it then, and I'm saying it now. If we skip T2 and just go from T1 to T3, things look *much* better.:)
Slashdot Mirror
Sigh.. you're taking what I said completely out of context. I said that the SPECIFIC EXEMPTION IS FOR SOURCE CODE in the quote you mentioned. I Said the specific exemption was for SOURCE CODE, NOT OBJECT CODE. I didn't say there wasn't an exemption for some types of object code. I said the exemption for object code doesn't apply to the kind of executables that large companies build.
Are you too fucking obtuse to link together more than one argument at a time? More than one concept? Do you not recall me specifically mentioning Maya on more than one occasion?
Where are your brains, in your ass?
For someone who detests even things that smack of logical fallacies (but aren't) you sure like you use them yourself.
You're also wrong about the dynamically-linked executables. It would take quite the wrangling to get the compiler to link blindly against libraries that you just happen to need for the customer to run on their own systems..
That's wonderful.. you're stretching it to the point of pure ridiculousness.
Keep it up--you're making this too easy.
(And yes, I'm still going to say that a corporate lawyer, who's smarter than you are, is more right about this, because all you have to do is visit a corporate lawyer and he'll confirm that I'm right. But you won't, will you?)
Dude. Let me get this straight here. You're claiming that Mr. Moglen's statements as to whether the LGPL makes the combined "work" FALL UNDER THE LGPL'S FULL SCOPE OR NOT as an argument as to whether an executable linked with the LGPL needs to be released under a license compatible with the reverse engineering clause.
... which just happens to be the exact same thing you're doing here.
You keep pointing to your named authorities, and I'll keep pointing out how incorrect your interpretation of their words are.
He's talking about whether the rest of the program (ie: source) falls under the GPL just by linking it. If you link (dynamically or statically) with a GPL'd library, your entire source falls under the GPL. Period.
What difference does the LGPL make? It means you can keep your source code private.
That's it..! And he's talking about the Work itself. The work includes the source. He's not talking about the executables.
Now tell me--what have you to say about Dave Turner's opinion? Is Dave Turner wrong after all? If he is, then why did you point to him as an authority? The answer is, of course, because you incorrectly interpreted his notes to you.
You are absolutely correct.
Linking (statically or dynamically) with the LGPL'd licensed GLIBC makes that executable open to reverse engineering for the end-user's own purposes.
Wavicle is lying.
Linking--dynamically or statically--to an LGPL'd library makes the final executable (but not the primary source code used to build it) fall under the reverse engineering clause.
Yet another reason not to listen to random idiots spewing on Slashdot. Get it from the source, and write a clear question to licensing@gnu.org. Make it a yes/no question and you'll get answered more quickly.
No, you're still getting it wrong.
./maya.
I'm saying you get to reverse engineer it because the people who compiled it compiled it against the GLIBC, not because you typed
How dense can you be? What, do you not speak English? Are you that blind to the meaning of the words I'm using?
Section 5 applies to tiny, tiny, insignificant executables--but I've never said anything about those, have I? I'm talking about commercial enterprises and their Linux offerings, such as Maya. I've been talking about the large projects from the start.
If you don't want to believe my company retains the services of a lawyer, that's really your perogative. But I've already blown away you "Dave Turner agrees with me" ambiguous bullshit.
Go on then, troll. Troll me some more. You've already lost. Admit it.
That's funny how you tried to argue that Dave Turner agrees with you, and then when I come back with a note that he sent me, that specifically deals with the argument we're having in no uncertain terms, and then you completely ignore that fact and plow stupidly on, like some kind of big stupid ox who won't stop yanking on the yoke.
It's just because you were in an argument with him, and kept at it, and he ignored your last notes--which I thought was illuminating--that you think you're still right. I find it funny that you interpreted his last note to conform to what you think is right, and are now ignoring everything else.
What, you think you're smarter with the law than a corporate lawyer who makes midrange six-figures and knows assembly? Do you? What arrogance.. what egotism.. what complete and utter bullishness.
Well, you're certainly a piece of work.
Troll.
And I'm glad to have been trolled, because your disinformation does nothing constructive.
The LGPL states "the object code for the work may be a derivative work of the Library even though the source code is not."
I'm not interpreting it to apply equally to source and object code. I've already fucking told you it doesn't apply to the source code, otherwise companies would have to release the source with their commercial Linux executables.
It doesn't give specific exemption to object code, it gives specific exemption to source code! That's what I've been saying from the start!
Linking and using the header files pulls in inline functions greater than ten lines in length. Can you guarantee that a project like Maya wouldn't have substantial portions of the GLIBC included in its executable? Enough to make the executable fall under the terms of the LGPL? And executables like Maya are what I've been talking about from the start--not some puny little 10K executable tool you've built. Get it?
I'm not affirming the consequent, dude. 6B could not exist if dynamically-linked executables made any program exempt from the LGPL.
Listen carefully, because I'm done arguing with you. You've already ignored large portions of my argument to concentrate on the simple, stupid semantics. You've ignored the fact that Dave Turner agrees with me. You've ignored pretty much everything I've said and are dogmatically adhering to an obvious ignorance of just how much LGPL'd technology is required to link an executable, nevermind how much actually ends up in an executable, and are at this point attempting to attach a logical fallacy to an argument that isn't.
For the record, for all those others out there who are reading it and didn't know what he meant by "affirming the consequent," it goes like this:
If Something, then something else.
Something else is true, and this something is true also.
In this case, however, he is stating unequivocally that dynamically-linked executables fall completely outside the LGPL. Period.
My argument is simple:
If that were the case, then 6B would not only be useless, but specifically misleading, since the LGPL talks about a single executable being distributed and how it, specifically, may satisfy the LGPL. If 6B would make the executable exempt, the LGPL would state that it is exempt in the case of dynamically-linking and 6B wouldn't even be in there. But no--named symbols from the LGPL'd library are embedded directly within the final executable, especially if debugging is turned on in the compiler.
Section 5 gives specific exemption to source code, and only exemption to object code if it uses insignificant portions of the LGPL. Get you head screwed on straight--and talk to a real lawyer. He'll agree with me.
Oh, you can't afford a real lawyer? Well, you go on thinking what you like about the LGPL, and if it ever comes to a head, you see what happens. If I ever find out about how you got nailed by a good lawyer in court, I'll laugh. Loudly.
They are covered in Section 6. Section 5 provides exemption for the source code. Go talk to a lawyer, he'll tell you I'm "probably" right.
Just because the header files don't completely remain in your code after the dynamic linking, doesn't mean they weren't necessary to create the dynamic linkage to begin with on your Linux system. Huge amounts of header files went into your compiling process. If you could create the executable that runs fine on Linux without masses of glibc header files, then I might be inclined to move my opinion a shade in your direction.
You include stdio.h, and if you link it on NetBSD, you don't have to worry about the LGPL. As soon as you link your software on a Linux system, the GLIBC header files are what your software is including, and using during the preprocessing phase. You don't think I can dig up an inline function bigger than ten lines somewhere in the entirety of the glibc header files? Anywhere?
The only difference between static and dynamically-linked in the LGPL is mentioned in section 6, part b. It doesn't say "Dynamically-linked executables are exempt." It says you can use dynamically-linked executables to help satisfy section 6.
What about this suggests to you that dynamically-linked executables don't even need to satisfy section 6, when they're mentioned as a specific way to fulfill section 6?
Why would they be mentioned at all in sec. 6 if dynamically-linking made the final executable completely exempt from the LGPL from the get-go?
No, you don't understand the sec. 5 exemption. It refers to the program: the program in this case is the source code. It can ONLY refer to the program, otherwise LGPL's internal consistency is bald-faced mucked up. The source code--even if it's written to "use the library" doesn't fall under the LGPL, and thus the commercial interests get to keep their code secret.
It even states that unrestricted linking to the library wouldn't allow users to exercise the rights the LGPL is trying to protect! What, that only applies to unrestricted static linking? Dynamic linking is completely unrestricted then?
Read it. Now read it again with an open mind. Be enlightened.
Uh no. You don't get to know who this corporate lawyer is, because we paid him to give his opinion to us, and I for one would hate to see him get a pile of hate mail from people who don't properly understand his area of expertise.
And it wasn't Eben Moglen.
You linked the executable when you triggered the command to be run on your system, when you typed in the various glibc-specific #include statements in your source code that were glibc-specific, when you triggered the compiler to include those files in the pre-processing phase, and when you built your software so that it conforms to the glibc calling conventions and arguments, and when you included those various glibc symbols in your final dynamically-linked executable.
Dynamic linking still puts chunks of the LGPL'd code into the executable.
Not sure what you're talking about the OS fiddling with your license agreement... but your OS doesn't do anything until you tell it to do something.
Let me describe in a little more detail what's going on here and what it's starting to look like:
1. My corporate lawyer, Dave Turner, the FSF, and myself, all believe the LGPL to protect the rights of the downstream of a distribution of an executable linked against the glibc, to reverse engineer that executable for his own purposes.
2. You, on your lonesome, are fighting the good fight in the belief that we are all wrong. With only your sense of what's right and what isn't to keep you going. Apparently.
Conclusions: i. You are a troll, trying to elicit an authoritative opinion from me you can adopt as your own elsewhere, or ii. You really do believe what you're writing, regardless of a complete lack of authoritative sources upon which you rely to provide a foundation for your opinions, or... some nebulous third option?
Let me give you an analogy to your last "the kernel did it, not me" argument, which was ridiculous on its face.
I take a hammer. I swing the hammer, which connects with a nail and bashes it into a slab of wood.
Is the hammer responsible for bashing the nail into the wood, or am I, who provided the conscious direction for the hammer to do its dirty work?
Just because I don't understand the exact physics of what happened, doesn't mean I don't see the results, am aware of what happened, and realise that it was through my own actions that the nail was hammered into the wooden slab.
So why, again, is it that the OS is to blame during the runtime linking of your "./maya" command, when you were the one who issued the command to begin with?
Anyway, that's completely irrelevant, since we're talking here about executables that have been distributed to someone else, and that someone else's right to reverse engineer that executable for his own purposes--whatever those nefarious purposes might be--and whether a commercial enterprise has the right to restrict reverse engineering of their software.
I think I'm done. I for one and quite secure in my right to reverse. And good for Clause 6, I say!
I'm sensing some backpedalling here. But that's okay, I don't think any less of you for it. (How hypocritically magnanimous of me. Apologies.)
.o intermediate files. But it's still a derivative work.
The LGPL guarantees that you can use reverse engineering to do whatever the hell you want with any of the GPL and LGPL code you have if you keep it to yourself. You can refuse to release any mods, you can refuse to release any source, whatever.
The LGPL and the GPL both apply just to distribution of the derived works (and in our argumentative case,) executables linked (statically or dynamically) to the GLIBC.
That's why they're covered under copyright laws: the act of copying is what they're governing, not the act of modifying or fiddling with your own copies.
The act of dynamically linking your code eases only your obligation to supply the compiled object code of your program in order to enable your customer (or downstream of your distrubution efforts) to relink against other libraries than the LGPL'd one that it was originally compiled against. By creating a dynamically-linked executable, you no longer have to also distribute the object code
The dynamically-linked executable contains references to the LGPL library, symbols from the LGPL library, and so on, in excess of the ten-line exemption the LGPL mentions in section 5. It also required that you #include a pile of header files. A dynamically-linked executable is a derivative work because it contains or used large portions of the LGPL'd library.
Linking against LGPL'd code requires access to and inclusion of its header files in the code you're compiling.
What, you can manage to build an executable of a substantial Work without including large numbers of glibc-supplied header files in your code? I did mention large-ish software such as Maya in previous notes, did I not?
Or are you going to bring up that tired old "I use a wrapper and thus my software is immune" argument which is clearly false because of the viral nature of the GPL and LGPL licenses?
The inclusion or not of LGPL'd code is completely irrelevant if you aren't distributing the final, compiled and linked executables. I had thought that part of our argument wasn't under debate.
What we're discussing here is (or should be) how the LGPL actually applies to what it actually applies to; ie: distributed executables of software that runs on Linux, for example Maya and other software.
Just because in-memory there is a larger composite of the executable, expanded by the runtime ELF linker, doesn't mean that substantial portions of the LGPL'd library aren't already in the executable, or used to create the executable in such a way that the final executable is an LGPL-derived beast.
Reverse engineering in this case refers to what the LGPL talks about: Reverse engineering for the Customers Own Use.
:-)
Ie: If the customer needs to modify things to get them working more correctly in their own environment, for example.
I'm not talking about Microsoft's in-house lawyers, but thanks for insulting an arbitrary third-party's rep. :-) Mighty white of you.
I guess I lied. It's not my last response. :-)
The LGPL defines what it means by "linking" and talked about it:
" However, in a textual and legal sense, the linked executable is a combined work, a derivative of the original library, and the ordinary General Public License treats it as such."
The program, defined by its source code, does not fall under the LGPL. However, the executable created by linking the program (dynamically and especially statically) does, and puts it under the reverse engineering clause 6.
"Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
This refers to the work--the work is the source code, and this is the exclusionary protection that saves proprietary users need to protect their source code from falling under the LGPL.
However, the link itself results in an executable, and that is specifically called out in the LGPL in the following clause:
"The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."
What the hell crack are you smoking? I've already written David Turner and his answer to me was far more explicit than your reference:
My turn: This'll be my last response. Corporate lawyer's opinion trumps whatever you think you know about the matter, but let's go from there shall we?
I wrote a note to the FSF and got the following response back:
> If so, then wouldn't all executables linked with the
> GNU/Linux LGPL'd GLIBC suddenly be open to reverse engineering and
> modification for the customer's own purposes, and that if a proprietary
> vendor tried to take away the right to reverse engineer their product that
> they would lose the right to link with GLIBC?
Yes, this is all correct.
--
-Dave Turner
Free Software Licensing Guru
This is not legal advice. If you need legal advice, see a lawyer.
This is a message directly from Dave Turner. If you want the full source, I'd be happy to supply it.
Secondly, after receiving this, I had to take it to a corporate lawyer to get advice. Without it being commutative to any situation you think you're on top of (but apparently aren't,) the corporate lawyer agreed with Mr. Turner's email to me: There is substantial reason to believe that the LGPL guarantees the right to reverse engineer any executable linked with an LGPL'd library.
This is how it should be, and it's a good thing, except for those commercial customers who are concerned that someone has the motivation to write a free alternative to their software.
But you're wrong. Dave Turner, plus a corporate lawyer, plus common sense reading (ie: not stretching it to fit what you think it should) all equal LGPL protecting reverse engineering on all proprietary software that doesn't link with a proprietary or BSD-style replacement for libc.
Ta.
The corporate greed feeding on the open source is fine--as long as they're obeying the terms of the license. That's part of the benefit of open source: that people get to use the software for whatever they want, so long as they're obeying the terms of the license. Who cares of some company is using GPL software, modified internally, to do their work and making millions off it?
That's partly what the people building the open-source software have come to terms with before releasing their source code to begin with.
If greed is encouraging the adoption of software that enforces freedom, then corporate greed is working for us all! And good on it, I say!
A note from the GNU foundation's people, and then a resulting corporate lawyer's opinion says you're a moron armchair lawyer idiot.
... and then deal with it.
Where you're wrong is thus: The SOURCE CODE of the program is outside the scope of the license--however the ACT OF LINKING IT with an LGPL-licensed library creates--ACCORDING TO SECTION 5, THE SAME SECTION YOU'RE TRYING TO USE IN YOUR ARGUMENT--a derivative work. Thus, the executable itself falls under some terms of the LGPL, and thus SECTION 6, the reverse-engineering clause.
Yes, this means you are allowed to reverse-engineer Maya, or any other commercial software that runs on Linux according to the reverse engineering terms in the LGPL.
Get your fucking head out your ass.
... So this reminds me of the kind of intensity between the ones who split from the MIT labs and formed a commercial company out of the fruits of the research. RMS began writing software which incorporated each new feature, but was in his free software.
One man, keeping up with--and surpassing--the programming of many others.
Larry added in the legal aspect because he knows that baiting RMS in that fashion will garner him a loss--it's happened before, and it can happen again.
I, for one, would love to see RMS piqued to the point where he's willing to write (in reasonable time) the BitKeeper-killer. Wouldn't that be a feat and a half, if even half of the effort that Larry says it took to develop BitKeeper was accurate.
I'll tell you one thing: It doesn't take millions of dollars to develop a versioning system. It takes one programmer about eight months to build something functional, and then another two years to shake the bugs out and make it perfect.
First off, the ideal *does* work in this world, or else open source software wouldn't have the impetus it does right now.
Secondly, even if the ideal didn't work "in this world" why does that make striving towards the ideal unworthy?
Sigh.
Sorry, but no. The LGPL guarantees the ability to reverse engineer anything linked with it--and this includes dynamically-linked software.
It's easy to set up on the UNIX-like machines.
/etc/exports, start the NFS daemons (if necessary) and add the remote disks to the other workstations.
Add a single entry to
Voila!
...your friend has the physical superiority (doesn't he?) He should never feel threatened, and if he does, he needs to spend a few months in the gym.
Keep putting it off, and tell him to never get himself into a situation where she's alone with him in a locked room. Eventually she'll get frustrated, and your friend can try to keep the relationship platonic, because after that point it'll come to a crux and she'll decide whether or not to make good on her implied threat. If he's still working there, he can still maintain a friendly professionalism. Otherwise, get a fricken new job.
She obviously is attempting to use her position of power to intimidate him, and push the issue. She knows he's rejected her, and now she's applying more pressure. She can't take no for an answer, and she's used to getting what she wants.
The fucking bitch.
She's trying to intimidate him, and it's obviously working, or you wouldn't be here asking a bunch of geeks how to deal with a situation most of them have never faced, and will never have to face.
Tell your friend to get a frickin' spine and stop whining about "harassment." Harassment is meant for people who can't defend themselves physically nor emotionally, nor with position. Your friend isn't one of those people unless he's physically inferior to this woman.
Cripes..! Tell your buddy to stand up and be a man for once!
What are your thoughts on the GNU General Public License? Have you dealt with any cases in which the GNU GPL had any bearing, and if so, how did it affect those cases?
On a related note, do you think the GNU GPL or other similar open source licenses are effectively steering us towards or away from commercial, proprietary software? Do you think this is a good thing?
It is, of course. :)
Thank god, someone who gets T3. Thank you, AC, you deserved that 5. Should've posted under a nickname.
:)
T3 *did* plug the gaping, horrible holes that T2 created. T3 brings back that sense of fatalism, that doomed, hopeless despair that was in T1. T3 fixes the problems that were introduced in T2 because Arnie didn't want to do the kind of movie that T1 was (his children were too young to understand.)
T2 was an abomination: I said it then, and I'm saying it now. If we skip T2 and just go from T1 to T3, things look *much* better.