You are probably right, and I should have expanded a little on what I said. Unfortunately I cannot find the link for the hardware I was thinking, but I seem to recall a dual motherboard dual processor 1U system out there for around this price.
I know 4 way machines have an advantage (shared resources), but they also have a disadvantage (shared resources).
What I'm unsure of is will the total cost of ownership of a $3500 4 way PPC system be comparable to a rack mount 1U 2x2 processor Athlon system? Will the performance of a 4 way system be substantially more than a 2x2 system?
Unfortunately I lack both a 4 way and a 2x2way rack mount server, so I just don't know.
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.
I've already pointed out that your continued reference to this anonymous lawyer is a fallacious mode of argument. But if you are so interested in what a lawyer says, here: read what Eben Moglen says.
My authority is not anonymous, is Professor of law at Columbia University and is General Counsel for the FSF.
In question 2 he answers:
If the author of the other code had chosen to release his JAR under the Lesser GPL, your contribution to the combined work could be released under any license of your choosing, but by releasing under GPL he or she chose to invoke the principle of "share and share alike."
There you have it, legal counsel saying dynamic linking to LGPL code allows you to release under any license of your choosing.
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 do you know it was compiled against GLIBC? 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".
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!
Okay, you quoted a partial paragraph AGAIN even though I previously quoted the whole thing. You say section 5 does not give specific exemption to object code. Section 5 states:
If such an
object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.
Ignoring the rest of your argument, I'll place the whole of it on this to show that you do not know what you are talking about. That quote comes from the lgpl, section 5, paragraph 4. You said section 5 gives no "specific exemption to object code", I say that paragraph says you are incorrect.
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.
Dynamic linking still puts chunks of the LGPL'd code into the executable.
Yes. Section 5 addresses and permits this without invoking section 6.
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?
Because *I* didn't write maya. But maya is going to get dynamically linked with glibc when I type "./maya", regardless of what header and development library files were used when it was built. You are saying that maya is now subject to reverse engineering because I, who had no hand in creation of the software, ran it on a Linux system. The OS linked maya and glibc when I typed "./maya".
When a "work that uses the Library" uses material from a header file that is part of the Library, the
object code for the work may be a derivative work of the Library even though the source code is not.
...are you REALLY SURE section 5 only covers source code?...
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.
Now how you can interpret that (all from section 5) to imply that object code is the same as source code?
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?
You have a logical fallacy in there. You are affirming the consequent. The fact that you can use 6b to satisfy 6 does not imply the truth of 6.
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.
As I pointed out, section 5 differentiates between source code and object code and gives exemption to object code. Does this mean LGPL's internal consistency is bald-faced mucked up?
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.
My argument is, and has been, that dynamically linked executables to GLIBC are NOT covered by section 6.
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.
Oh come on, that LGPL refers to ten line inline functions. As it says:
If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.
Symbolic references leave your object file unrestricted.
Linking against LGPL'd code requires access to and inclusion of its header files in the code you're compiling.
Yes, what of those header files ends up in the object code which is not already exempted?
What, you can manage to build an executable of a substantial Work without including large numbers of glibc-supplied header files in your code?
Yes you can. stdio.h is generic. But that doesn't really matter. Section 5 excludes whatever the header file may have brought in.
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.
No I disagree on exactly this point. Any LGPL code that is in the executable is excluded under section 5, unless you statically link the file.
Corporate lawyer's opinion trumps whatever you think you know about the matter
Who is this corporate lawyer? I'm almost certain it is Eben Moglen, but can you link this lawyer saying that any linking at any time makes your software subject to reverse engineering?
There is substantial reason to believe that the LGPL guarantees the right to reverse engineer any executable linked with an LGPL'd library.
Who linked my executable with an LGPL library? Did I link it, or did the kernel? In the case of dynamic linking it is the latter. libc is supposed to be generic, the executable should not be concerned with which implementation you are using. printf is printf no matter what library you have. How did the operating system gain the right to modify my license agreement without my permission?
" 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."
Notice that the GPL treats it as such. Grasp the connotation that LGPL will not.
"Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
You left out the part before that:
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library".
The "work" is the program. The program is not exclusively the source code.
However, the link itself results in an executable
Yes it does. Like I said and you reiterated:
"The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."
If I am not distributing a file which is the composition of my work and an LGPL library, then I can license my work without restriction. The mere existence of a program that is a composition of the two does not confer any obligation under section 6. The distribution of this program does.
On your computer, and in your memory there exists a running program that is the composition of these two. However you composited them, nobody distributed such a combined work to you. You have no right to distribute the composition of the two, but if you did then section 6 would apply.
Section 6 covers distribution, and as section 5 states, section 6 doesn't apply to you if your program contains no LGPL code.
So if my source code contains no LGPL code, and my executable contains no LGPL code. How does section 6 apply if I did not distribute an executable that contains code from both?
A note from the GNU foundation's people, and then a resulting corporate lawyer's opinion says you're a moron armchair lawyer idiot.
The GNU foundation's people? Are these the same people who have a strong dislike of LGPL? Are these the same people who have strong political feelings that all software should be free?
Here's the first paragraph of section 5:
A
program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
So you define "program" as "source code"? An executable is not a program? Do you think you could convince anybody of this in court?
The only time a program which links to glibc falls under section 6 is in the second paragraph of section 5.
However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library
(because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables.
There you have it... In order for section 6 to cover your program, your program must contain portions of the library. Now when you dynamically link a program it could be said that your program now contains portions of the library. Section 6 says:
As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and
distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
So if you try and distribute the memory image of an application dynamically linked to LGPL you are right. But only the copyright holder of all applications running in that memory space could authorize distribution to a third party of that memory image.
But paragraph 2 of section 5 is pretty clear... If you do not contain code from the LGPL library, you are free and clear.
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.
Whoa, I thought glibc like gcc was under a license where end products [e.g. binaries]are not under the GPL/LGPL.
I believe glibc is licensed under LGPL. If you dynamically link to glibc, section 5 of the LGPL frees you from any licensing restrictions in section 6. If you statically link, paragraph 2 of section 5 says that section 6 will apply to you.
You've allowed David Turner to skew your understanding of LGPL. Section 6 only applies if you distribute something statically linked against glibc.
Make no mistake, GNU doesn't like the LGPL, and they are attempting to do revisionist interpretations of what the LGPL says in order to make LGPL software unappealing to companies which make proprietary, closed source software with restrictive licenses.
Despite their apparent attempt to use ambiguous wording and specious re-interpretation, section 5 clearly states that no, BitKeeper is not subject to section 6.
Section 5 is for the case where you are not distributing the library
You are trying spin the definition of "program" as "the sum of all parts distributed in an archive in order to make a program work, regardless of whether or not those parts can be easily obtained separately." I don't buy it. The software I've written placed into my jar is my "program". By saving the user the trouble of having to find those components and install them himself your claim that other jars in my.zip/.tar.gz are now infected is dubious (and I say infected, because this is not "hereditary" at all).
As long as you don't mix the library and application jars into a single jar, you're in the clear. Isn't that what what Eben Moglen said back in February?
In any case, this is also a major narrowing of what you've previously said. Anybody can now offer up two archives: one containing all their application pieces except for lgpl components, and another containing all the lgpl jars. Now their even their archive is in isolation.
However, certainly if the two are in the same memory space, they are linked.
That is nonsense. If they are in the same memory space they are linked and fall under section 6, but since you aren't distributing a binary image of the memory space you are not limited by license.
You most certainly can circumvent the LGPL by building wrappers since doing so creates a work in isolation.
If any link in memory space means that the linked programs are restricted in license then running most proprietary code on a GNU/Linux system would be illegal since it binds to glibc. No court in this country would buy that a generic library, linked at runtime, could force a proprietary program to surrender its protections. As the LGPL says, and as I am saying, you only get that claim when you statically link.
Java never statically links (except for native compilers, the most popular of which GNU makes). This whole "it falls under section 6" is simply bull.
As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library
In the case of Java "import", the new work does not contain any portion of the library. Java is doing dynamic linking which is covered under section 5:
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
A Java class file does not contain anything except for constant values and name references to another class. All class files are isolated.
Re:the slashdot story is mis-interpreting the post
on
LGPL is Viral for Java
·
· Score: 1
Okay, after substantially more thought, I think I need to retract some of my previous post, and take a different tack:
The post states that you cannot import or "lift" any lgpl code
There is the problem, and the one I think the guy from the FSF had as well. The word "import" in Java does not mean "copy code from there into my application." It means "at runtime I will need to call out to this code, so generate the necessary references to do this."
I think we are seeing two camps that don't quite speak the same language. What you said is completely true, but to a Java programmer "import" means something entirely different.
Re:the slashdot story is mis-interpreting the post
on
LGPL is Viral for Java
·
· Score: 1
I don't think you are correct. If you read through the LGPL, the word they use for "lift" is "link". They define any "linking" as creating a derivative work (preamble). They then backpedal that some linking is not a derivative work, but are very unspecific as to what linking isn't (section 5). They then say that ALL static linking IS a derivative work (also section 5) that must be released as free code (section 6).
I believe in open court however the whole thing would fall apart because the preamble states that the purpose of the LGPL is to permit linking into proprietary code. Their preamble statement of intentions clashes with sections 5 & 6. When it comes to contract law, "intention" counts for a *lot*.
At first it seems like a compliment, but on another level, it seems to carry the implication that he's getting a bit senile in his old age...just a thought
I know it can be taken that way, but I think the writer, Louis Freedman, is actually just skilled at rhetoric. As director of the Planetary Society, we would expect this.
Freedman immediately acknowledges that Gold is a professor at a prestigious university whom he (Freedman) has studied under and learned much from. Freedman states that Gold does occasionally make wild claims that turn out to be false, but also concedes that he has contributed valuable assets to scientific knowledge.
This is all rhetoric 101. The audience sees that Freedman knows Gold well and is prepared to accept that his rebuttal comes from an intelligent individual.
the real means of travel is via distortion of spacetime around the ships which does not change your inertia but let you move in spacetime by modifying the geodesics.
Having watched the series far too many times, I assure you they moved by means of classical propulsion, and what's more the only ship in the fleet that could get up to light speed was the Galactica.
Maybe you are right afterall. When the Galactica did open the throttle and speed along at light speed, it managed to get to Apollo and Starbuck and back to the fleet without everyone in the fleet having to wait a few thousand millennia for their return.
incidentally, this is why these people do not feel the fictitious forces due to accelaration of the ships.
The one technology they must have had is artifical gravity. None of the big ships rotated, but they all had gravity. So they probably used the technology to counter the force of acceleration.
That's actually Lucifer, second in command on the basestar that Baltar is given by the Cylon Imperious Leader to track down and destroy the last of humanity.
Did the story arc ever explain why everyone spoke perfect English, used Grecco-Roman names, and were looking for 1970s Earth?
It kind of did. Though they never address the language thing.
There were 13 colonies of these space-faring folk. 12 of them were named after birth signs, and the 13th one didn't have a name, but they set sail and ended up founding earth. Thus the egyptian architecture and greco-roman names were all artifacts of the fact that they all come from the same planet and then branched out into space. Why the 13th colony decided to give up on technology after arriving on earth, I dunno.
Anyway, the Cylons apparently make peace with the 12 high tech colonies, but in reality they were just maneuvering for a suprise attack. They destroyed all 12 home worlds and all the battlestars except Galactica (and Pegasus, but we don't find that out until later). The remaining humans quickly figure out that chasing a pipedream towards the fabled 13th colony (which they've only heard in their mythology) is their best bet.
So they take whatever ships they have that are still usable (rag-tag fugitive fleet) and high tail it out of there (fleeing the Cylon tyranny). Every so often they stumble across a cylon outpost and have to blow stuff up.
Slashdot Mirror
You are probably right, and I should have expanded a little on what I said. Unfortunately I cannot find the link for the hardware I was thinking, but I seem to recall a dual motherboard dual processor 1U system out there for around this price.
I know 4 way machines have an advantage (shared resources), but they also have a disadvantage (shared resources).
What I'm unsure of is will the total cost of ownership of a $3500 4 way PPC system be comparable to a rack mount 1U 2x2 processor Athlon system? Will the performance of a 4 way system be substantially more than a 2x2 system?
Unfortunately I lack both a 4 way and a 2x2way rack mount server, so I just don't know.
I've already pointed out that your continued reference to this anonymous lawyer is a fallacious mode of argument. But if you are so interested in what a lawyer says, here: read what Eben Moglen says.
My authority is not anonymous, is Professor of law at Columbia University and is General Counsel for the FSF.
In question 2 he answers:
There you have it, legal counsel saying dynamic linking to LGPL code allows you to release under any license of your choosing.
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 do you know it was compiled against GLIBC? 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".
Okay, you quoted a partial paragraph AGAIN even though I previously quoted the whole thing. You say section 5 does not give specific exemption to object code. Section 5 states:
Ignoring the rest of your argument, I'll place the whole of it on this to show that you do not know what you are talking about. That quote comes from the lgpl, section 5, paragraph 4. You said section 5 gives no "specific exemption to object code", I say that paragraph says you are incorrect.
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.
You seem quite skilled at committing argumentative fallacies.
Dynamic linking still puts chunks of the LGPL'd code into the executable.
Yes. Section 5 addresses and permits this without invoking section 6.
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?
Because *I* didn't write maya. But maya is going to get dynamically linked with glibc when I type "./maya", regardless of what header and development library files were used when it was built. You are saying that maya is now subject to reverse engineering because I, who had no hand in creation of the software, ran it on a Linux system. The OS linked maya and glibc when I typed "./maya".
Let's read Section 5 once again:
...are you REALLY SURE section 5 only covers source code?...
Now how you can interpret that (all from section 5) to imply that object code is the same as source code?
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?
You have a logical fallacy in there. You are affirming the consequent. The fact that you can use 6b to satisfy 6 does not imply the truth of 6.
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.
As I pointed out, section 5 differentiates between source code and object code and gives exemption to object code. Does this mean LGPL's internal consistency is bald-faced mucked up?
My argument is, and has been, that dynamically linked executables to GLIBC are NOT covered by section 6.
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.
Oh come on, that LGPL refers to ten line inline functions. As it says:
Symbolic references leave your object file unrestricted.
Linking against LGPL'd code requires access to and inclusion of its header files in the code you're compiling.
Yes, what of those header files ends up in the object code which is not already exempted?
What, you can manage to build an executable of a substantial Work without including large numbers of glibc-supplied header files in your code?
Yes you can. stdio.h is generic. But that doesn't really matter. Section 5 excludes whatever the header file may have brought in.
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.
No I disagree on exactly this point. Any LGPL code that is in the executable is excluded under section 5, unless you statically link the file.
IBM expects a 20x increase in the number of PPC Linux servers by 2006
So that's like how many? 20 PPC servers in 2006?
(no no, seriously I do like the idea, it's just hard to tell if $3500 is going to get me more than a similarly equiped Intel/AMD system)
Corporate lawyer's opinion trumps whatever you think you know about the matter
Who is this corporate lawyer? I'm almost certain it is Eben Moglen, but can you link this lawyer saying that any linking at any time makes your software subject to reverse engineering?
There is substantial reason to believe that the LGPL guarantees the right to reverse engineer any executable linked with an LGPL'd library.
Who linked my executable with an LGPL library? Did I link it, or did the kernel? In the case of dynamic linking it is the latter. libc is supposed to be generic, the executable should not be concerned with which implementation you are using. printf is printf no matter what library you have. How did the operating system gain the right to modify my license agreement without my permission?
Notice that the GPL treats it as such. Grasp the connotation that LGPL will not.
"Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
You left out the part before that:
The "work" is the program. The program is not exclusively the source code.
However, the link itself results in an executable
Yes it does. Like I said and you reiterated:
"The executable is therefore covered by this License. Section 6 states terms for distribution of such executables."
If I am not distributing a file which is the composition of my work and an LGPL library, then I can license my work without restriction. The mere existence of a program that is a composition of the two does not confer any obligation under section 6. The distribution of this program does.
On your computer, and in your memory there exists a running program that is the composition of these two. However you composited them, nobody distributed such a combined work to you. You have no right to distribute the composition of the two, but if you did then section 6 would apply.
Section 6 covers distribution, and as section 5 states, section 6 doesn't apply to you if your program contains no LGPL code.
So if my source code contains no LGPL code, and my executable contains no LGPL code. How does section 6 apply if I did not distribute an executable that contains code from both?
The GNU foundation's people? Are these the same people who have a strong dislike of LGPL? Are these the same people who have strong political feelings that all software should be free?
Here's the first paragraph of section 5:
So you define "program" as "source code"? An executable is not a program? Do you think you could convince anybody of this in court?
The only time a program which links to glibc falls under section 6 is in the second paragraph of section 5.
There you have it... In order for section 6 to cover your program, your program must contain portions of the library. Now when you dynamically link a program it could be said that your program now contains portions of the library. Section 6 says:
So if you try and distribute the memory image of an application dynamically linked to LGPL you are right. But only the copyright holder of all applications running in that memory space could authorize distribution to a third party of that memory image.
But paragraph 2 of section 5 is pretty clear... If you do not contain code from the LGPL library, you are free and clear.
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.
Oh really? Not even David Turner agrees with that.
I'm sorry, who was the moron armchair idiot?
Whoa, I thought glibc like gcc was under a license where end products [e.g. binaries]are not under the GPL/LGPL.
I believe glibc is licensed under LGPL. If you dynamically link to glibc, section 5 of the LGPL frees you from any licensing restrictions in section 6. If you statically link, paragraph 2 of section 5 says that section 6 will apply to you.
Sorry no, you're wrong. Read section 5. Read section 6. Read the preamble. Deal with it.
You've allowed David Turner to skew your understanding of LGPL. Section 6 only applies if you distribute something statically linked against glibc.
Make no mistake, GNU doesn't like the LGPL, and they are attempting to do revisionist interpretations of what the LGPL says in order to make LGPL software unappealing to companies which make proprietary, closed source software with restrictive licenses.
Despite their apparent attempt to use ambiguous wording and specious re-interpretation, section 5 clearly states that no, BitKeeper is not subject to section 6.
Section 5 is for the case where you are not distributing the library
.zip/.tar.gz are now infected is dubious (and I say infected, because this is not "hereditary" at all).
You are trying spin the definition of "program" as "the sum of all parts distributed in an archive in order to make a program work, regardless of whether or not those parts can be easily obtained separately." I don't buy it. The software I've written placed into my jar is my "program". By saving the user the trouble of having to find those components and install them himself your claim that other jars in my
As long as you don't mix the library and application jars into a single jar, you're in the clear. Isn't that what what Eben Moglen said back in February?
In any case, this is also a major narrowing of what you've previously said. Anybody can now offer up two archives: one containing all their application pieces except for lgpl components, and another containing all the lgpl jars. Now their even their archive is in isolation.
However, certainly if the two are in the same memory space, they are linked.
That is nonsense. If they are in the same memory space they are linked and fall under section 6, but since you aren't distributing a binary image of the memory space you are not limited by license.
You most certainly can circumvent the LGPL by building wrappers since doing so creates a work in isolation.
If any link in memory space means that the linked programs are restricted in license then running most proprietary code on a GNU/Linux system would be illegal since it binds to glibc. No court in this country would buy that a generic library, linked at runtime, could force a proprietary program to surrender its protections. As the LGPL says, and as I am saying, you only get that claim when you statically link.
Java never statically links (except for native compilers, the most popular of which GNU makes). This whole "it falls under section 6" is simply bull.
but it's still linking
The LGPL treats static and dynamic linking differently. Java always dynamically links.
Section 6 only covers static linking:
As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library
In the case of Java "import", the new work does not contain any portion of the library. Java is doing dynamic linking which is covered under section 5:
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
A Java class file does not contain anything except for constant values and name references to another class. All class files are isolated.
Okay, after substantially more thought, I think I need to retract some of my previous post, and take a different tack:
The post states that you cannot import or "lift" any lgpl code
There is the problem, and the one I think the guy from the FSF had as well. The word "import" in Java does not mean "copy code from there into my application." It means "at runtime I will need to call out to this code, so generate the necessary references to do this."
I think we are seeing two camps that don't quite speak the same language. What you said is completely true, but to a Java programmer "import" means something entirely different.
I don't think you are correct. If you read through the LGPL, the word they use for "lift" is "link". They define any "linking" as creating a derivative work (preamble). They then backpedal that some linking is not a derivative work, but are very unspecific as to what linking isn't (section 5). They then say that ALL static linking IS a derivative work (also section 5) that must be released as free code (section 6).
I believe in open court however the whole thing would fall apart because the preamble states that the purpose of the LGPL is to permit linking into proprietary code. Their preamble statement of intentions clashes with sections 5 & 6. When it comes to contract law, "intention" counts for a *lot*.
At first it seems like a compliment, but on another level, it seems to carry the implication that he's getting a bit senile in his old age...just a thought
I know it can be taken that way, but I think the writer, Louis Freedman, is actually just skilled at rhetoric. As director of the Planetary Society, we would expect this.
Freedman immediately acknowledges that Gold is a professor at a prestigious university whom he (Freedman) has studied under and learned much from. Freedman states that Gold does occasionally make wild claims that turn out to be false, but also concedes that he has contributed valuable assets to scientific knowledge.
This is all rhetoric 101. The audience sees that Freedman knows Gold well and is prepared to accept that his rebuttal comes from an intelligent individual.
I watch a show to be entertained, not educated.
Maybe if you watched some quality science fiction you could get both.
the real means of travel is via distortion of spacetime around the ships which does not change your inertia but let you move in spacetime by modifying the geodesics.
Having watched the series far too many times, I assure you they moved by means of classical propulsion, and what's more the only ship in the fleet that could get up to light speed was the Galactica.
Maybe you are right afterall. When the Galactica did open the throttle and speed along at light speed, it managed to get to Apollo and Starbuck and back to the fleet without everyone in the fleet having to wait a few thousand millennia for their return.
incidentally, this is why these people do not feel the fictitious forces due to accelaration of the ships.
The one technology they must have had is artifical gravity. None of the big ships rotated, but they all had gravity. So they probably used the technology to counter the force of acceleration.
That's actually Lucifer, second in command on the basestar that Baltar is given by the Cylon Imperious Leader to track down and destroy the last of humanity.
Did the story arc ever explain why everyone spoke perfect English, used Grecco-Roman names, and were looking for 1970s Earth?
It kind of did. Though they never address the language thing.
There were 13 colonies of these space-faring folk. 12 of them were named after birth signs, and the 13th one didn't have a name, but they set sail and ended up founding earth. Thus the egyptian architecture and greco-roman names were all artifacts of the fact that they all come from the same planet and then branched out into space. Why the 13th colony decided to give up on technology after arriving on earth, I dunno.
Anyway, the Cylons apparently make peace with the 12 high tech colonies, but in reality they were just maneuvering for a suprise attack. They destroyed all 12 home worlds and all the battlestars except Galactica (and Pegasus, but we don't find that out until later). The remaining humans quickly figure out that chasing a pipedream towards the fabled 13th colony (which they've only heard in their mythology) is their best bet.
So they take whatever ships they have that are still usable (rag-tag fugitive fleet) and high tail it out of there (fleeing the Cylon tyranny). Every so often they stumble across a cylon outpost and have to blow stuff up.