I think you have your browse settings set too high. I was responding to an Anonymous posting that said old ships are usually scuttled, not recycled. I was agreeing with your post, which is why the website proves your point.
Okay, I could attack any number of errors and omissions and reinterpretations you did, but this has got to be the funniest of them:
You lied here. I didn't say "any program." Let's hit the wayback machine and see what precisely I did say, shall we?
I said,, "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."
Oh, and glibc supplies both inlined and non-inlined versions of memcpy. For obvious reasons the inlined version appears in the.h file.
Also, which inlined memcpy function has more than 10 lines of actual code in it?
Also, inlining string functions is a bad speed-for-bloat tradeoff. There are good reasons *NOT* to use that optimization.
Much of what you say is true - it is cheaper to use a collection of mass produced off-the-shelf items - but here are some reasons why I think this little box is "cooler" (if more expensive):
1. Size. 486 Laptops are small, but the box for the 4521 is 1"x10.2"x?? (probably around 6").
2. Utility. The 4521 comes with 2 10/100 ethernet ports and 2 PC Card ports. This box can be a gateway for your wired and wireless networks to your ethernet broadband connection.
3. Weight. Those old 486 laptops frequently weigh in around 8lbs (I used to have a compaq LTE 4/75cx... it was pretty heavy) This thing is just over 1lb.
4. Power Consumption. The 4521 draws a maximum of 14 watts. That means $16 worth of rechargeable NiMH AA Batteries (Energizer 1850 mAh, they aren't the best, but they are easy to come by at Target or Wal-mart) can power this thing at full draw for over an hour. The Battery for my LTE 4/75cx cost around $100 and had a life expectancy of just over an hour (though the battery did charge much faster than NiMH)
5. Processor speed. I haven't checked all those ebay listings, but the 4521 has a 133MHz 486 class processor, not many laptops had a processor that fast.
6. Memory. The 4521 comes with 64MB soldered right onto the board. My LTE 4/75cx had a maximum upgradeable potential of 32MB.
With all these features, the 4521 has potential to fill all sorts of hobbyist niches a laptop wouldn't be appropriate for.
An extreme example that I'm sure nobody can relate to: Model Gliders. I used to be into flying remote controlled model gliders. With this box I could create a remote control solution that gives me potential for all sorts of other add on hacks which won't interfere with the frequencies used by the other pilots (it's expensive to get several pairs of crystals, and if anybody else has your frequency, you have to share with them). Even the mere couple of pounds this would weigh would require at least a 3 meter plane to carry it, but it opens up the possibility of downlinking live video from a usb camera, as well as all sorts of nifty telemetry.
I could have a remote controlled flying wireless access point serving up MP3's. Let's see the RIAA come after me for THAT! I like to think of this as "Extreme Pirate Radio"
I would suspect that greenpeace is under stating how much of the ship is recyclable. After all if they said "100% of the ship is recyclable" nobody would care about small trace pollutants. If they said "85% of the ship is recyclable and 15% is pollutants" people would dismiss their claims as ridiculous, clearly less than 15% of the ship is non-recyclable pollutants.
I think they stated the best number they could to support their agenda, but I wouldn't be suprised if the true number were around 98-99.
I don't think that's true. According to this greenpeace site, 95% of a ship is recycleable material. Their beef is that these ships are sitting on beaches in asian countries while the non-recyclable 5% of them are pollutants being released into the environment. That and workers dismantling the ships without protection.
Uh.. also: Why would a company care that you're "NOT" reverse engineering their code?
You're kind of young aren't you? Read back a couple messages.
Come on! Objdump, chicken! Let's see your technical analysis of a simple hello-world executable!
Had you talked to a lawyer he would have already told you that if you go to court over a reverse engineering contractual breach, the complainant will need to show you reverse engineered their product and the respondent (you) will need to show permission to do so was granted via license. Are you going to rest that claim on the same thing you're suggesting I should do? I'm not "taking on the challenge" because I don't need to. You are making the claim, you back it up. Coincidentally you can (though case law suggests 14 lines of assembly is insufficient, but that gets back to your lawyer issue), but one of the reasons I doubt your technical skill is that you haven't. Of the two of us, you should be very interested in doing this yourself because it is your only defense when a company with bright corporate lawyers comes after you for breach of contract.
(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?)
I knew if you had talked to a lawyer his greatest concern would have been the intent established in the preamble. Since you didn't bring it up, I knew you were attempting to use an anonymous authority to give your case weight. It was sufficient to show the lack of merit of your argument on sections 5 and 6.
Have you noticed that the whole objdump thing started as you insisting that using memcpy always makes you subject to section 6, but once I showed it false you switched the argument to "where did all this other stuff come from?" which had nothing to do with memcpy?
Have you noticed that you use the argument for section 6 being valid if you dynamically link because 6b says you can use dynamic linking if section 6 applies to you? This is affirming the consequent. If 6 then 6b. 6b therefore 6. You can't use a consequent to establish a cause. Your alleged corporate lawyer would know this would be a completely unsuccessful argument in a legal pleading.
Uh yeah... clearly your interpretation is safer. 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.
I don't need anybody to be my technical advisor. And I already know you aren't as good as you think, you tipped your hat earlier... a couple times.
If you had really talked to a lawyer, you'd already know that any court argument over reverse engineering would focus on the lgpl's preamble. There is doubt among legal scholars that the gpl itself is enforceable. Fortunately anybody working for a real company considering reverse engineering a product reading this thread will have enough doubts from your evasive mode of argument, they will talk to one before taking your advice.
pointed out the default glibc-supplied data that actually outweighs the tiny amount of main() code you supplied
You actually don't know where the bootstrapping code came from (I do, but think it is rather humorous you haven't found it). But one thing is sure, memcpy is not in there.
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.
Here's what he said in my quote:
Section 5 is for the case where you are not distributing the library --
like most proprietary software on GNU/Linux and glibc. If you're distributing a library and something dynamically linked to it, you need to follow section 6.[emphasis added]
Here's what he said in your quote:
Yes, this is all correct.
I do not consider his response to your question more authoritative when your question is leading and contains ambiguities. In my quote he specifically says most proprietary software does not distribute the library and is therefore covered under section 5.
Eben Moglen said if you link to an LGPL jar file, you may license your software any way you choose. He did not add on a qualifier like "but you must permit reverse engineering." I didn't try rehashing this point because it was clear you had little knowledge of how java works with jar files and trying to explain it would get off the primary argument which was dynamic linking against an lgpl library does not put you under section 6.
You made unqualified statements then spend a lot of time trying to explain how they are somehow qualified.
You said any program.
I provided a program that didn't.
You were wrong.
This "single, stupid little item" was the only example you've provided to show that compiling with glibc puts your code under section 6. It was wrong. You have not shown code larger than what is exempt making its way into an executable.
Unless you can do so, the merit of your argument is dubious.
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.
You made the argument that merely compiling against glibc placed a threshhold of glibc data in excess of what was exempted into an executable. You have failed to deliver on the claim. Asking me to prove that it doesn't is backwards.
Oh I read it, it was just a red herring. I caught you saying something patently untrue, provided an example of its untruth and you brought up disassembly which did not support what you said:
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.
So, is that statement true or not? If it is true, why didn't my example inline them?
Your argument that large programs are reverse engineerable rests on the assertion that linking at build time will put LGPL code into the executable larger than what is allowed. Are you now backtracking and saying that only those which have inlined non-trivial functions from glibc are?
Heck, read far enough back in this thread and we see you saying "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." I haven't changed the subject.
The standard calls aren't, but I'd bet you that the glibc-specific calls are copyrighted.
"Fair Use". A restrictive license cannot enforce something you could use anyway. But more to the point, what standard c library call will cause an executable to be created with a glibc-specific reference in it instead of the standard reference?
[root@www test]# gcc -save-temps test.c -o test test.c: In function `main': test.c:4: warning: return type of `main' is not `int' [root@www test]# grep memcpy test.s
call memcpy [root@www test]#
Didn't get inlined, did it?
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?
Let's take the easy case... glibc... Those symbolic references contain the name of the function you wish to call. The names of those functions in glibc are not copyrighted, patented or trademarked by FSF because they are part of an ANSI spec. The code for those functions is copyrighted by the FSF, not the name. You cannot say section 6 applies because you have a symbolic reference to "memcpy"! You can't enforce a license of something you do not own an interest in. Exemptions for symbolic references aren't in the LGPL because it wouldn't be enforceable even if it was (though one could argue that a symbolic reference is a single line macro and is therefore explicitly allowed).
Creating the dynamically-linked executable during compile-time using glibc headers is what puts it under the LGPL.
Okay, let's go back to this example. I've created a mammoth application that links to standard c library routines in glibc. I used glibc headers to create the application.
My object code contains: symbolic references to function names, structures and constants.
This is everything I would expect the executable code of a large application to contain from glibc. Section 5 says your object code can have as many of these as you want without being subject to section 6.
What does the maya executable contain that makes it subject to section 6? If it does not contain object code lifted from the library, except for macros and inline functions, it doesn't.
Running the executable and doing the runtime linking after the fact doesn't modify the license.
Thank you. Now we've determined that dynamic linking does not make you subject to section 6.
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.
Yes. Static linking is what makes it fall under the LGPL.
The only question is, how much can you statically link without it falling under section 6. And that is what the object code quote from section 5 is for. Constants, functions names, small macros and inline functions... you can have as many of those as you want and not be under section 6.
You've already said a dynamically linked executable falls under section 6. I said the OS that did the linking has no right to modify the executables license agreement. You asked how, I told you.
Would this result in a running executable linked against glibc or not?
Nice spin... but "final compiler jarfile" doesn't make sense. His statement is clear: link to a GPL jar, you're restricted, link to an LGPL jar and you are not.
You shouldn't talk about what you don't know. JAR files can contain source but usually don't. A JAR file is the correct way to distribute an executable java application. He is referring to binary files. And he is saying the (LGPL binary + your binary) combined work can be released under any license.
what have you to say about Dave Turner's opinion?
Your quote from him contains ambiguity (dynamic or static? The only word used is "link"), mine does not. He said section 6 only applies if you are distributing the lgpl library.
You're just backpedaling here. You can use as many data structures, constants and symbolic function references to libc as you want, in as large an application as you want and section 5 gives you complete immunity. That is exactly what the section of section 5 I quoted says.
So go ahead and use Maya as your example, but you had better come up with a macro or inline function exceeding 10 lines or a statically included function from glibc, or your argument has no weight.
For someone who detests even things that smack of logical fallacies (but aren't) you sure like you use them yourself.
Which fallacy did I use?
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..
You may want to check your system... Chances are you don't have a "glibc.so". libc is the name for the library containing the functions from the standard c library. Even if you do have a glibc.so, you'll need to have a libc.so symlinked to it because compiled programs refer to the generic library name. A program can be compiled against any standard c library and will generate libc references. At runtime, your linux system will link the executable with its implementation of libc, which is glibc.
Slashdot Mirror
The fact that you can't find the inlined string.h functions that are longer than ten lines is also amusing.
That statement could only make sense if you aren't looking at all the glibc header files.
I think you have your browse settings set too high. I was responding to an Anonymous posting that said old ships are usually scuttled, not recycled. I was agreeing with your post, which is why the website proves your point.
Okay, I could attack any number of errors and omissions and reinterpretations you did, but this has got to be the funniest of them:
.h file.
You lied here. I didn't say "any program." Let's hit the wayback machine and see what precisely I did say, shall we?
I said,, "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."
Oh, and glibc supplies both inlined and non-inlined versions of memcpy. For obvious reasons the inlined version appears in the
Also, which inlined memcpy function has more than 10 lines of actual code in it?
Also, inlining string functions is a bad speed-for-bloat tradeoff. There are good reasons *NOT* to use that optimization.
Much of what you say is true - it is cheaper to use a collection of mass produced off-the-shelf items - but here are some reasons why I think this little box is "cooler" (if more expensive):
1. Size. 486 Laptops are small, but the box for the 4521 is 1"x10.2"x?? (probably around 6").
2. Utility. The 4521 comes with 2 10/100 ethernet ports and 2 PC Card ports. This box can be a gateway for your wired and wireless networks to your ethernet broadband connection.
3. Weight. Those old 486 laptops frequently weigh in around 8lbs (I used to have a compaq LTE 4/75cx... it was pretty heavy) This thing is just over 1lb.
4. Power Consumption. The 4521 draws a maximum of 14 watts. That means $16 worth of rechargeable NiMH AA Batteries (Energizer 1850 mAh, they aren't the best, but they are easy to come by at Target or Wal-mart) can power this thing at full draw for over an hour. The Battery for my LTE 4/75cx cost around $100 and had a life expectancy of just over an hour (though the battery did charge much faster than NiMH)
5. Processor speed. I haven't checked all those ebay listings, but the 4521 has a 133MHz 486 class processor, not many laptops had a processor that fast.
6. Memory. The 4521 comes with 64MB soldered right onto the board. My LTE 4/75cx had a maximum upgradeable potential of 32MB.
With all these features, the 4521 has potential to fill all sorts of hobbyist niches a laptop wouldn't be appropriate for.
An extreme example that I'm sure nobody can relate to: Model Gliders. I used to be into flying remote controlled model gliders. With this box I could create a remote control solution that gives me potential for all sorts of other add on hacks which won't interfere with the frequencies used by the other pilots (it's expensive to get several pairs of crystals, and if anybody else has your frequency, you have to share with them). Even the mere couple of pounds this would weigh would require at least a 3 meter plane to carry it, but it opens up the possibility of downlinking live video from a usb camera, as well as all sorts of nifty telemetry.
I could have a remote controlled flying wireless access point serving up MP3's. Let's see the RIAA come after me for THAT! I like to think of this as "Extreme Pirate Radio"
I would suspect that greenpeace is under stating how much of the ship is recyclable. After all if they said "100% of the ship is recyclable" nobody would care about small trace pollutants. If they said "85% of the ship is recyclable and 15% is pollutants" people would dismiss their claims as ridiculous, clearly less than 15% of the ship is non-recyclable pollutants.
I think they stated the best number they could to support their agenda, but I wouldn't be suprised if the true number were around 98-99.
I don't think that's true. According to this greenpeace site, 95% of a ship is recycleable material. Their beef is that these ships are sitting on beaches in asian countries while the non-recyclable 5% of them are pollutants being released into the environment. That and workers dismantling the ships without protection.
Uh.. also: Why would a company care that you're "NOT" reverse engineering their code?
You're kind of young aren't you? Read back a couple messages.
Come on! Objdump, chicken! Let's see your technical analysis of a simple hello-world executable!
Had you talked to a lawyer he would have already told you that if you go to court over a reverse engineering contractual breach, the complainant will need to show you reverse engineered their product and the respondent (you) will need to show permission to do so was granted via license. Are you going to rest that claim on the same thing you're suggesting I should do? I'm not "taking on the challenge" because I don't need to. You are making the claim, you back it up. Coincidentally you can (though case law suggests 14 lines of assembly is insufficient, but that gets back to your lawyer issue), but one of the reasons I doubt your technical skill is that you haven't. Of the two of us, you should be very interested in doing this yourself because it is your only defense when a company with bright corporate lawyers comes after you for breach of contract.
(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?)
I knew if you had talked to a lawyer his greatest concern would have been the intent established in the preamble. Since you didn't bring it up, I knew you were attempting to use an anonymous authority to give your case weight. It was sufficient to show the lack of merit of your argument on sections 5 and 6.
Have you noticed that the whole objdump thing started as you insisting that using memcpy always makes you subject to section 6, but once I showed it false you switched the argument to "where did all this other stuff come from?" which had nothing to do with memcpy?
Have you noticed that you use the argument for section 6 being valid if you dynamically link because 6b says you can use dynamic linking if section 6 applies to you? This is affirming the consequent. If 6 then 6b. 6b therefore 6. You can't use a consequent to establish a cause. Your alleged corporate lawyer would know this would be a completely unsuccessful argument in a legal pleading.
Uh yeah... clearly your interpretation is safer. 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.
I don't need anybody to be my technical advisor. And I already know you aren't as good as you think, you tipped your hat earlier... a couple times.
If you had really talked to a lawyer, you'd already know that any court argument over reverse engineering would focus on the lgpl's preamble. There is doubt among legal scholars that the gpl itself is enforceable. Fortunately anybody working for a real company considering reverse engineering a product reading this thread will have enough doubts from your evasive mode of argument, they will talk to one before taking your advice.
No, you lost. You just haven't realized it yet.
It was a yes or no question.
So did he or did he not say that section 5 is for most proprietary software?
I love how you're using as evidence to support your argument the exact statements that in actuality support mine.
Did Mr. Turner say that section 5 is for most proprietary software or not?
If he did, he is not supporting your argument.
If section 5 is for Maya, you have no right to reverse engineer it.
You actually don't know where the bootstrapping code came from (I do, but think it is rather humorous you haven't found it). But one thing is sure, memcpy is not in there.
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.
Here's what he said in my quote:
Here's what he said in your quote:
I do not consider his response to your question more authoritative when your question is leading and contains ambiguities. In my quote he specifically says most proprietary software does not distribute the library and is therefore covered under section 5.
Eben Moglen said if you link to an LGPL jar file, you may license your software any way you choose. He did not add on a qualifier like "but you must permit reverse engineering." I didn't try rehashing this point because it was clear you had little knowledge of how java works with jar files and trying to explain it would get off the primary argument which was dynamic linking against an lgpl library does not put you under section 6.
You made unqualified statements then spend a lot of time trying to explain how they are somehow qualified.
You said any program.
I provided a program that didn't.
You were wrong.
This "single, stupid little item" was the only example you've provided to show that compiling with glibc puts your code under section 6. It was wrong. You have not shown code larger than what is exempt making its way into an executable.
Unless you can do so, the merit of your argument is dubious.
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.
You made the argument that merely compiling against glibc placed a threshhold of glibc data in excess of what was exempted into an executable. You have failed to deliver on the claim. Asking me to prove that it doesn't is backwards.
Oh I read it, it was just a red herring. I caught you saying something patently untrue, provided an example of its untruth and you brought up disassembly which did not support what you said:
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.
So, is that statement true or not? If it is true, why didn't my example inline them?
Your argument that large programs are reverse engineerable rests on the assertion that linking at build time will put LGPL code into the executable larger than what is allowed. Are you now backtracking and saying that only those which have inlined non-trivial functions from glibc are?
Heck, read far enough back in this thread and we see you saying "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." I haven't changed the subject.
The standard calls aren't, but I'd bet you that the glibc-specific calls are copyrighted.
"Fair Use". A restrictive license cannot enforce something you could use anyway. But more to the point, what standard c library call will cause an executable to be created with a glibc-specific reference in it instead of the standard reference?
You sidestepped...
where does memcpy show up in the output of objdump?
Is it an inline function, or is that simply an option?
Try this:Then this:Didn't get inlined, did it?
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?
Let's take the easy case... glibc... Those symbolic references contain the name of the function you wish to call. The names of those functions in glibc are not copyrighted, patented or trademarked by FSF because they are part of an ANSI spec. The code for those functions is copyrighted by the FSF, not the name. You cannot say section 6 applies because you have a symbolic reference to "memcpy"! You can't enforce a license of something you do not own an interest in. Exemptions for symbolic references aren't in the LGPL because it wouldn't be enforceable even if it was (though one could argue that a symbolic reference is a single line macro and is therefore explicitly allowed).
Creating the dynamically-linked executable during compile-time using glibc headers is what puts it under the LGPL.
Okay, let's go back to this example. I've created a mammoth application that links to standard c library routines in glibc. I used glibc headers to create the application.
My object code contains: symbolic references to function names, structures and constants.
This is everything I would expect the executable code of a large application to contain from glibc. Section 5 says your object code can have as many of these as you want without being subject to section 6.
What does the maya executable contain that makes it subject to section 6? If it does not contain object code lifted from the library, except for macros and inline functions, it doesn't.
Running the executable and doing the runtime linking after the fact doesn't modify the license.
Thank you. Now we've determined that dynamic linking does not make you subject to section 6.
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.
Yes. Static linking is what makes it fall under the LGPL.
The only question is, how much can you statically link without it falling under section 6. And that is what the object code quote from section 5 is for. Constants, functions names, small macros and inline functions... you can have as many of those as you want and not be under section 6.
You've already said a dynamically linked executable falls under section 6. I said the OS that did the linking has no right to modify the executables license agreement. You asked how, I told you.
Would this result in a running executable linked against glibc or not?
Nice spin... but "final compiler jarfile" doesn't make sense. His statement is clear: link to a GPL jar, you're restricted, link to an LGPL jar and you are not.
Okay, here is how you can create an executable that contains no glibc code, but is dynamically linked at runtime to glibc:
1) compile your application with any c library implementation except glibc.
2) run your program on linux.
There, done.
He's not talking about the executables.
You shouldn't talk about what you don't know. JAR files can contain source but usually don't. A JAR file is the correct way to distribute an executable java application. He is referring to binary files. And he is saying the (LGPL binary + your binary) combined work can be released under any license.
what have you to say about Dave Turner's opinion?
Your quote from him contains ambiguity (dynamic or static? The only word used is "link"), mine does not. He said section 6 only applies if you are distributing the lgpl library.
You're just backpedaling here. You can use as many data structures, constants and symbolic function references to libc as you want, in as large an application as you want and section 5 gives you complete immunity. That is exactly what the section of section 5 I quoted says.
So go ahead and use Maya as your example, but you had better come up with a macro or inline function exceeding 10 lines or a statically included function from glibc, or your argument has no weight.
For someone who detests even things that smack of logical fallacies (but aren't) you sure like you use them yourself.
Which fallacy did I use?
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..
You may want to check your system... Chances are you don't have a "glibc.so". libc is the name for the library containing the functions from the standard c library. Even if you do have a glibc.so, you'll need to have a libc.so symlinked to it because compiled programs refer to the generic library name. A program can be compiled against any standard c library and will generate libc references. At runtime, your linux system will link the executable with its implementation of libc, which is glibc.
It takes very little wrangling.