If you cannnot protect what you own, you own nothing. This is true if the law doesn't help you and its true if you don't have the will to act. SCO is exposing the weakness of the GPL: it means nothing if you aren't willing to use the courts to enforce it.
SCO's attempts to impose additional restrictions on the Linux kernel could not be a more blatent violation of the copyrights of the many kernel developers who have released legitimately GPL'd code into the kernel. There is exactly one way for this idodicy to stop: kernel developers must sue SCO for copyright infringement.
Even under the rosiest scenario for SCO, the fact that SCO has a contract dispute with IBM, and that perhaps IBM infringed their code does not given them any right to flout the GPL and usurp the work of the kernel developers.
Re:the slashdot story is mis-interpreting the post
on
LGPL is Viral for Java
·
· Score: 4, Insightful
But there is a clear distinction. The LGPL library is loaded from one jar on the classpath at runtime and the rest of the code is loaded from somewhere else. They're clearly separable. If you modify anything in the LGPL jar (or class) and distribute it, you must include full source to everything packaged in that jar, but if you don't do that you are fine, even if you're dealing with full GPL java code.
The JVM plays the same role as bash does: it loads separately packaged programs into memory, and handles messages being sent back and forth, none of which implicates any right held by the copyright holder of either. I my propietary class calls your GPL'd or LGPL'd class, so what!? How is that different than my proprietary bash script calling grep? As long as I don't modify or distribute your code, or copy parts of it into mine, I don't need a licence.
If you say the method calls are me copying your code, I'll argue back that public method names are a fair use for interoperability.
I can understand why Apache code can't be distributed with LGPL or GPL java code included in the same jars. But why can't it issue import statements to it and just expect it to be installed separately?
Just do it the way the LGPL implies: let it load at runtime from the classpath. Java is OO, so of course you are only relying on the public methods to interface.
Re:The phrase in question seems to be:
on
LGPL is Viral for Java
·
· Score: 3, Insightful
I'm really baffled by what the issue is. It appears to me that the LGPL works just fine for Java.
Suppose I write a libarary in Java and place it under the LGPL. I also create a jar file for it. You write some code which uses my library and includes some import statements that name a package in my jar. You compile your stuff into a separate package jar. You distribute your jar which contains none of my code source or bytecode other than calls to public methods. I don't see any reason to think the LGPL places any requirements on your jar.
Java's built in class loader seems ideal as a "suitable shared library mechanism". So long as the LGPL library is on the classpath, it will get loaded at run time, as modified or not, and it will work so long as the public method signitures don't change. This is what the LGPL means when it uses "interface" -- it is NOT talking about a declared interface in the Java sense, but simply the public method calls treated as an API.
The difference between the standard contstructor form and the Class.forName form seems like a distinction without a difference to me. Both use whatever library class is on the classpath at runtime and don't depend on it being unmodified aside from the method signatures.
I'm baffled by this article and the claim that the LGPL is problematic in Java. It seems to me that so long as you distribute your code which uses an LGPL class or jar without including your own copy of that LGPL libary, you are fine. Heck, you could even distribute the LGPL library as long as you do it in a separate download.
In fact, I would go one further. Even if the class you are using was full GPL, how does my program care so long as I don't distribute your code? Because of OO encapsilation, my code does not depend on anything other than the public methods I call, and I'm not sure an API can be copyrighted, or if it can that interoperability is not a fair use. What right of yours would I be violating? I'm not distributing a derivitive of your code (unless you think like SCO), nor modifying it. The only thing that I copy is API call signatures. So what?
First, thank you doing this interview. Most people here take IP very seriously and want laws and law enforcement that does what the Constitution intended.
Contrary to what many lay-people believe, open source software relies (heavily) on copyright and the legal system that assures those rights. In fact, among Slashdot readers are a large number of people who own copyrights to open source software. My question is what services your organization offers in practice to "real people". Our community creates software whose quality competes with that of multi-billion dollar corporations, so we clearly have a significant interest in having our own rights as authors protected. We all have no doubt that if Jack Valenti finds a website selling pirated versions of his movies that law enforcement will descend upon the infringer with a fury comparable to that weilded against drug smugglers and violent criminals.
Few among us would really object to enforcing the law against such a clear violation, however, I cannot help but wonder if there is equity in the system. I wonder whether an individual author's rights as a copyright owner would be similary protected? For example, if substantial quantities of code that one of us has written ends up in a company's product in a way that clearly violates the terms of an open source licence, how would the infringed copyright holder go about seeking your services?
What policy governs your decision whether or not to act on behalf of a copyright owner when a complaint is raised? What assures that the heavy hand of the law protects an individual's rights with the same fury that it defends those of the RIAA or a major software corporation?
I agree completely. Any metric based on Lines of Code anything is a harmful metric. Any metric based on defect counts is also harmful. Both of these are left-overs from attempts to (mis)-apply statistical process control. Control of crappy metrics give crappy quality.
Suppose I had 100K lines of code with 100 defects. After reviewing my code I discovered that I could refactor it to 80K lines and suppose further that doing so had no effect on the defect count. Defects per line of code would look worse after an improvement.
Also, given that this is an automated program, I have to ask how they calibrate and validate its results. How many of the 32 errors found actually aren't errors? How many existing known bugs were not found by this program. I really can't accept these results as anything more than fluff with numbers.
One of the best ways to get to know a large code base like Apache or something else is to find a repeatable bug and track it down. To fix a bug you do not need to understand the whole program, just the relevent parts. I've submitted bug fixes to several projects, so I must strenuously disagree, especially because, ahem, I have never submitted a bug fix to a proprietary project because its impossible.
I'm really getting tired of this crap. When are kernel developers going to sue SCO for violating the GPL? All of SCO's past profits from selling Linux are a direct result of their piracy. This is a big pot of gold -- why is nobody going after it?
Well, that's the one glimmer of hope from this otherwise lamentable decision. It would seem to follow that the majority of the court would find a filter system that did not support user turn off requests to be unconstitutional.
Basically, a majority found filtering is ok, but only opt-out filtering. The question now is that if you have a non-porn site that the filters say is a porn site, what legal recourse do you have?
Re:SCO's case looks pretty strong
on
My Visit to SCO
·
· Score: 3, Informative
This can be very damaging for IBM depending on how their contracts with SCO are worded.
Well, the SCO-IBM contract is posted on SCO's site as Exhibit D. The confidentiality clauses are section 3 on pages 11 and 12.
Specifically, 3.04(v) discounts confidentiality requirements for code which is "independently created" by IBM. Also 3.04(iii) discounts confidentiality when the information is "received... independently from a third party" who has "no obligation of confidentiality to SCO" (which makes ESR's 60 affidavits highly relevent).
Moreover, 3.06 is a "no tainted worker" clause that allows people who have seen the code to use the ideas when they are "residual information mentally retained" provided they don't try to write it down or memorize it verbatim and don't otherwise infringe copyrights or patents.
Actually, we already know what it is. It's just that most peoples expectations of what SCO is alleging are not accurate. Read the Cringly article for more explaination.
As for the code, there are four primary areas that have surfaced: SMP, JFS, NUMA, and RCU.
I'm pretty confident that SCO's NUMA claim is based on the new NUMA code submitted by Martin Bligh of IBM to the 2.5 kernel. See this post for more details.
Fair use has four tests, the most important of which is the affect on the market value. Publishing the checksums probably increase the market value, since they are a conscious effort to prevent infringement. Another factor in fair use is the quantity of original work that is copied. Since md5 isn't invertible, this is zero. Another test is the purpose: commercial or non-profit. The checksums here are not designed to profit from somebody else's work, they are designed to protect against such profiting. The final test is the nature of the material used: Here it is solely to prevent or identify infringement.
I think it is almost a no brainer that a checksum lookup would be "fair use".
The problem is that suppose in files X and Y there is a checksum match at lines n and m respectively? You can't say anything more than that the lines match. X could have copied from Y, Y from X, or both could duplicate some other source Z.
Has anyone, besides SCO, looked at the Linux code and tried to determine what might have come from SCO, and what might have come from a common predecessor?
So far four components of the Linux source have been implicated: SMP, RCU, NUMA, and JFS.
I have done a little digging into the NUMA code. IBM has contributed several people who have participlated in developing NUMA under linux. Some names I've run across: Martin Bligh, Matthew Dobson, Patricia Gaughen, John Stultz, Michael Hohnbaum. IBM even has a Linux NUMA news archive. It appears that IBM jumpstarted it's NUMA efforts when it purchased Sequent which was intitally intended to boost its participation in Project Monterey, which is no doubt the origin of SCO's objections.
The most obvious source file for NUMA is/usr/src/linux/mm/numa.c in the 2.4 series kernels. This file contains a comment header stating it was "Written by Kanoj Sarcar, SGI, Aug 1999". This file has been removed from later 2.5 kernels (its gone by at least 2.5.46), appearently because Linux accepted an IBM NUMA patch as reported here. This patch was announced by Martin Bligh and is likely the code in question in this lawsuit.
Read my post again. Better yet, click the link and read paragraph 4. You missed the part about IBM having to approve changes to the contract. Unless you have an IBM signature agreeing to "s/AT&T/SCO/" that provision is not enforcable against IBM.
If SCO bought the rights to the contract, then they have the right to watch AT&T decide when to terminate IBM's rights after a breach.
The licences between AT&T and IBM that are posted on SCO's site as Exhibit A and Exhibit B.
In section 3.03 of exhibit B it clearly states that "AT&T" may revoke the licence for non-compliance. Moreover paragraph 4 of the cover page contains a standard "no alterations unless signed in writing" clause. I see nothing that allows AT&T to sell this termination right without IBM's approval. There are similar sectoin in Exhibit A, section 6.03 and paragraph 4 of the cover page.
Actually, money in the bank helps hostile take overs, because the purchasing entity can essentially use it to pay the share-holders.
EG, suppose a company with 17.2 billion in market cap has 5.5 billion in the bank? How much money do you have to make a credible offer to buy the company? You need 11.7 billion. To see this, just imagine that such a company borrowed the other 5.5 billion, and then when it controlls the bank accounts, decides immediately to pay off the loan.
I don't think that case has much applicability here for lots and lots of reasons:
1) SCO advertises its linux expertise and supports linux. They can't really claim they didn't know the cow was pregnant here. For example, in the case of NUMA, SCO's datasheets advertise NUMA support in Linux
2) If you read the case, the court found that because of the mutual mistake of thinking the cow was barren, Walker had a "right to rescind, and to refuse to deliver" the prgenant cow. SCO already delivered the pregnant cow. It had babies and grandbabies. Is SCO ready to rescind all the profits they made selling the mistake?
3) The case cited is a Michigan state common law contract case. The GPL issues make this a federal copyright case. State of mind and knowledge of infringement (ie mistakes) are NOT an element of copyright infringement. (see below) They're going to have to do a lot better than state contract law citations to make this argument. Unless they have federal copyright caselaw to cite, I don't think they'll get very far with this argument.
4) This is also a trade secret case. It is settled law that revealing your own trade secret destroys it, mistake or otherwise. You can't "rescind" the destruction of a secret. Moreover, copyright issues aside, Linus has no duty to keep the secret. Even if IBM did screw up and violate their NDA, that doesn't taint Linux. Only copyright issues can taint Linux.
5) Even if the GPL as pertains to SCO is declared void, SCO still needs some licence to distribute the kernel.org owned IP in Linux. SCO can't make up some other licence for Linux, that is not their right. They must choose to accept the GPL or admit infringing the legitimate parts of Linux via their distribution, modification, and copying thereof. Again state of mind (intent) and knowledge of infringement (ie mistakes) are NOT an element of copyright infringement. This is firmly established law, the best examples of which are the "Dance Hall" cases, where vicarious liability was found when dance hall owners allowed the unauthorized public performance of musical works by the bands they hired, even when the owners had no knowledge of the infringements and had even expressly warned the bands not to perform copyrighted works without a license from the copyright owners. [see Shapiro, Bernstein & Co. v. H.L. Green Co., 316 F.2d 304, 307 (2d Cir. 1963) (citing some 10 cases)].
6) Finally, suppose the GPL is deemed breached. Whenever a contract is breached (and this would be especially true if the GPL here was breached by mutual mistake) there is a duty to mitigate damage to the other party. It is important to realize that the alleged wrong-doing here is by IBM, not Linus Torvalds who did little more than commit the same mistake SCO itself claims to have made but without the opportunity SCO had to know it. SCO has steadfastly refused to inform kernel.org of the technical details of the mistake which would allow it to be fixed. Their insistence on an NDA obviously precludes an open source release to fix the problem. Moreover, the actions such as the threat letter sent by SCO to all those companies seem coldly calculated to maximize damage to kernel.org. I think it is inarguable that the damage caused (intentionally) by SCO to Linux is far more substantial than any damage to SCO's IP, which could be easily fixed by simply distentangling the two code bases.
Laura Didio at least identified some of the code areas: "The claims are not limited to just one area of the Unix System V kernel. SCO claims there are multiple instances of copyright violations. SCO said these include: NUMA (Non Uniform Memory access) a mechanism for enabling large multiprocessing systems, RCU (Read Copy Update) (and) SMP."
As far as NUMA goes, this is clearly aimed at the Monterey project. For a good laugh read the SCO Press Release on Industry Support for Project Monterey
I don't see how SCO can make it's "mutual mistake" (aka the pregnant cow) argument for NUMA. Their SCO Linux 4 datasheet advertises NUMA functionality as a feature of the GPL'd "Linux kernel 2.4.19" and trumps up SCO's Linux expertise and support for this kernel. I really don't see how they can win a trade secret case when they ADVERTISE and SUPPORT the open source release of the secret.
I was discouraged by reading post after post beating down the question. I can only imagine how Slashdot would have responded to somebody asking in 1905 what limitations had to be overcome to make flying machines. Frankly, I was a little cranky yesterday too and I probably should not have singled out any specific post, since my annoyance was really with the quality and dismissive tone of the entire discussion. I note that several other late posters expressed general dismay at the lack of vision in most responses.
The simple fact is that citizen owned wireless networks are already forming. These networks are going to grow both from more people getting involved and from improvements in technology. These networks are going to encounter all sorts of problems as they try to grow and connect to each other, but one thing is certain -- they WILL grow and connect to each other. It is a really important question to ask "How far can we go with things as they are" and to have some vision to ask "How far can we go if we solve a few problem".
The article poster obviously understands that there are various barriers out there that make his vision not exist under the status quo. I share his optimism that it looks like the obstacles can be cataloged and conquered over time. Nothing worth doing is easy, but you have to identify and define the problems before you can solve them.
You raise some good points in your most recent follow up, and I just wish that the tone wasn't "It'll never work because of X, Y, Z" but instead something like "currently X is a barrier because affordable solutions are at level X1 and they need to be at X2 in reach the next level and if you could get it to X3, then wow".
For example, you state "high-density peer-to-peer wireless is only tenable in a dense urban environment". OK, what density is needed? It seems like current ranges are a few hundred yards, so in metro areas your fine today because it is less than the population density and convincing more people to get involved is viable. When it's not you have to improve the technology, so what improvements help the density requirement? If costs were to improve in response to demand for things like directional anteneas and repeaters then I think existing technology can bump the radius up by a factor of 10 or so. Now we're talking. What radius do we have to get to so that typical rural populations can support it?
You also said wireless is "totally worthless for trans-oceanic links". That is too dismissive. I know several Ham radio guys who regularly talk to people all over the world using personally owned equipment, so this can be translated into some non-zero bandwidth. What is the theoretical limit using these frequencies? I don't know, but I'd like to. When it isn't enough, then the different wireless connected components need to be linked up with a few high bandwidth gateways.
There is another question of radius vs cost, but there would probably be some pooling of private resources among people within a connected graph in order to reach out farther and provide connectivity. There are some ham radio guys that privately own some pretty big towers. Could Britain talk to France via wireless if a few hundred people on each side wanted to make it happen? Even for remote islands, there are always ships and planes going back and forth -- if those can be leveraged the connectivity radius decreases.
It's not a stupid question. IMHO it is the most important question of the next decade.
You identify two main obstacles to be overcome: reliablity of connectivity and security/trustworthiness. Instead of ragging on the question (as people did above) why not simply answer it by stating those are the problems, and trying to look at what it takes to solve them. By the way, I think both of those are solvable problems.
The problem of dealing with assholes requires a way to quickly identify and shun them. There is a lot of research going into trust networks, which probably has solved the shunning mechanism pretty well. I think identification of rogue nodes is a newer problem, but it's one that P2P music networks have come across as the RIAA polutes them with crap in an attempt to attack them.
Simple network connectivity is purely a technical problem. It comes down to range, density and "quality" of nodes, and cost. They question is how many transmitters do I personally have to buy and administrate so that I can get enough people in my transmission range to be confident that somebody out there will cooperate.
Actually, solving the latter problem would re-introduce something very valuable back into modern life: the concept of neighborhood community and actually knowing the people who live near you. Back in the frontier days, people new their neighbors well, because they needed them. Today we are so used to being able to anonymously live that it seems strange to suggest that it might be OK for a solution to require that everybody find somebody they can trust within a quarter mile.
Great Question. As I said above Boo-Hiss to the early responses and moderation. I'll try a serious answer.
The technological barriers are: 1) Wireless equipment cost -- it has to come down by a factor of 10 or 20 so that ordinary people can afford to solve their own personal connectivity problems by direct personal action. The range and bandwidth per dollar have to imporve. Mass production of cheep roof-based antenae and other WiFi gear needs to happen. When you can get a 1 mile range for $30, this will take off.
2) Routing protocols -- TCP/IP probably wont work because there will be too many hops and it is too hard to administrate. The network topology will be an order of magnitude more complicated. TCP/IP doesn't deal well with ad-hoc roaming connectivity. Rest assured some really smart people are working on these problems.
3) Making the technology user-friendly and turnkey. Joe sixpack isn't going to want to look at a linux prompt to administrate his peer-to-peer router.
4) New application protocols -- if you throw out TCP/IP to deal with adhoc roaming P2P, you have to rethink everything that rides on top of it: DNS, EMAIL, HTTP, etc... Consider something as simple as establishing your default gateway. What if it wanders out of range?
The geographic isolation problem is directly a function of cost, range, and popularity. Keep in mind that in rural settings, people generally don't have cable or DSL anyway, so the pressure is even greater to find a high bandwidth solution. People were willing to put antenaes on their roofs to get TV -- I'd exect they'd do it for free broadband too. It's a simple matter of making it affordable to use repeaters when necessary.
The political barriers are IMHO the most likely to kill this. AT&T, Sprint, WorldCom etc simply don't want people to obsolete them. You think the RIAA and MPAA are a formidable lobby? Try the telcos. They would attack the uncontrollability of such networks. How do you stop child porn on a P2P wireless network? How do you stop copyright infringement? How do you wiretap terrorists and organized crime when there are no wires?
The economic barriers for deployment are pretty straight forward: equipment cost, range, and bandwidth. But the real question is how do you deal with malicious behavior by network participants? I imagine that trust networks problems have to be solved. How do you avoid the tradgedy of the commons (ie bandwidth hogs). Spam will still be a problem.
Wow. Slashdot has really lost it. I have never been more ashamed of crap moderation in any thread I can remember. This is a great question and it deserves a serious answer. None of the parents of this post have said a single usefull thing.
Boo-Hiss to the idiots who posted all of the ancestor posts above this one. Double boo-hiss to the idiots who moderated this article. As I post this, all four ancestors of my reply are +5 posts, none of which has ANY FUCKING MERIT AT ALL.
"Yeah, I want everything for free too. Give me a break." -- Sorry, not funny. Not interesting. Should be (-1 TROLL)
"I'm glad it's free to run giant fiber optic cables across the ocean." -- Sorry the question is not about running fiber across the ocean. It's about high density peer-to-peer WIRELESS networks and more specifically what the barriers are that need to be overcome to achieve it. Should be (0 Offtopic)
"Basically what the guy wants is nationalization of all telcos, so that your taxes pay for everything." -- Should be (-2 YOU ARE ON CRACK) The guy said he wanted TO ELIMINATE THE NEED FOR TELCOS, not socialize them. Wow, that is a moronic post.
"And of course, the upkeep costs on lines that are already there" -- I'll be kind (0 Offtopic) It's about the potential for WIRELESS peer-to-peer networks to allow people to unplug themselves from these upkeep costs.
No, the big problem is that the question is stupid and that it makes no sense.
It's a pretty damn simple question and it make perfect sense.
it costs money to lay wires and run all of the routers on the internet
That's why he proposes to eliminate wires and massive highly centralized backbone ownership. You really did miss the boat.
Wireless infrastructure is stupid on a large area network, as you waste virtually all of your power transmitting to areas where there are no listening machines
This problem has two independent solutions: strongly directional signals and/or very good signal-to-noise ratio receivers. Short wave radio solved both problems decades ago.
The real question is cost of equipment and standards for adhoc peer-to-peer packet routing (which is exactly what he was asking about). A WiFi access point today costs about $100 and has an omnidirection range of a few hundred yards and a directional range of a mile or two with a cheap antenea. If the cost of this equipment improves by 20X then it might be feasible to route from DC to boston across 1500 hops.
Slashdot Mirror
If you cannnot protect what you own, you own nothing. This is true if the law doesn't help you and its true if you don't have the will to act. SCO is exposing the weakness of the GPL: it means nothing if you aren't willing to use the courts to enforce it.
SCO's attempts to impose additional restrictions on the Linux kernel could not be a more blatent violation of the copyrights of the many kernel developers who have released legitimately GPL'd code into the kernel. There is exactly one way for this idodicy to stop: kernel developers must sue SCO for copyright infringement.
Even under the rosiest scenario for SCO, the fact that SCO has a contract dispute with IBM, and that perhaps IBM infringed their code does not given them any right to flout the GPL and usurp the work of the kernel developers.
But there is a clear distinction. The LGPL library is loaded from one jar on the classpath at runtime and the rest of the code is loaded from somewhere else. They're clearly separable. If you modify anything in the LGPL jar (or class) and distribute it, you must include full source to everything packaged in that jar, but if you don't do that you are fine, even if you're dealing with full GPL java code.
The JVM plays the same role as bash does: it loads separately packaged programs into memory, and handles messages being sent back and forth, none of which implicates any right held by the copyright holder of either. I my propietary class calls your GPL'd or LGPL'd class, so what!? How is that different than my proprietary bash script calling grep? As long as I don't modify or distribute your code, or copy parts of it into mine, I don't need a licence.
If you say the method calls are me copying your code, I'll argue back that public method names are a fair use for interoperability.
I can understand why Apache code can't be distributed with LGPL or GPL java code included in the same jars. But why can't it issue import statements to it and just expect it to be installed separately?
Just do it the way the LGPL implies: let it load at runtime from the classpath. Java is OO, so of course you are only relying on the public methods to interface.
I'm really baffled by what the issue is. It appears to me that the LGPL works just fine for Java.
Suppose I write a libarary in Java and place it under the LGPL. I also create a jar file for it. You write some code which uses my library and includes some import statements that name a package in my jar. You compile your stuff into a separate package jar. You distribute your jar which contains none of my code source or bytecode other than calls to public methods. I don't see any reason to think the LGPL places any requirements on your jar.
Java's built in class loader seems ideal as a "suitable shared library mechanism". So long as the LGPL library is on the classpath, it will get loaded at run time, as modified or not, and it will work so long as the public method signitures don't change. This is what the LGPL means when it uses "interface" -- it is NOT talking about a declared interface in the Java sense, but simply the public method calls treated as an API.
The difference between the standard contstructor form and the Class.forName form seems like a distinction without a difference to me. Both use whatever library class is on the classpath at runtime and don't depend on it being unmodified aside from the method signatures.
I'm baffled by this article and the claim that the LGPL is problematic in Java. It seems to me that so long as you distribute your code which uses an LGPL class or jar without including your own copy of that LGPL libary, you are fine. Heck, you could even distribute the LGPL library as long as you do it in a separate download.
In fact, I would go one further. Even if the class you are using was full GPL, how does my program care so long as I don't distribute your code? Because of OO encapsilation, my code does not depend on anything other than the public methods I call, and I'm not sure an API can be copyrighted, or if it can that interoperability is not a fair use. What right of yours would I be violating? I'm not distributing a derivitive of your code (unless you think like SCO), nor modifying it. The only thing that I copy is API call signatures. So what?
First, thank you doing this interview. Most people here take IP very seriously and want laws and law enforcement that does what the Constitution intended.
Contrary to what many lay-people believe, open source software relies (heavily) on copyright and the legal system that assures those rights. In fact, among Slashdot readers are a large number of people who own copyrights to open source software. My question is what services your organization offers in practice to "real people". Our community creates software whose quality competes with that of multi-billion dollar corporations, so we clearly have a significant interest in having our own rights as authors protected. We all have no doubt that if Jack Valenti finds a website selling pirated versions of his movies that law enforcement will descend upon the infringer with a fury comparable to that weilded against drug smugglers and violent criminals.
Few among us would really object to enforcing the law against such a clear violation, however, I cannot help but wonder if there is equity in the system. I wonder whether an individual author's rights as a copyright owner would be similary protected? For example, if substantial quantities of code that one of us has written ends up in a company's product in a way that clearly violates the terms of an open source licence, how would the infringed copyright holder go about seeking your services?
What policy governs your decision whether or not to act on behalf of a copyright owner when a complaint is raised? What assures that the heavy hand of the law protects an individual's rights with the same fury that it defends those of the RIAA or a major software corporation?
I agree completely. Any metric based on Lines of Code anything is a harmful metric. Any metric based on defect counts is also harmful. Both of these are left-overs from attempts to (mis)-apply statistical process control. Control of crappy metrics give crappy quality.
Suppose I had 100K lines of code with 100 defects. After reviewing my code I discovered that I could refactor it to 80K lines and suppose further that doing so had no effect on the defect count. Defects per line of code would look worse after an improvement.
Also, given that this is an automated program, I have to ask how they calibrate and validate its results. How many of the 32 errors found actually aren't errors? How many existing known bugs were not found by this program. I really can't accept these results as anything more than fluff with numbers.
One of the best ways to get to know a large code base like Apache or something else is to find a repeatable bug and track it down. To fix a bug you do not need to understand the whole program, just the relevent parts. I've submitted bug fixes to several projects, so I must strenuously disagree, especially because, ahem, I have never submitted a bug fix to a proprietary project because its impossible.
I'm really getting tired of this crap. When are kernel developers going to sue SCO for violating the GPL? All of SCO's past profits from selling Linux are a direct result of their piracy. This is a big pot of gold -- why is nobody going after it?
Well, that's the one glimmer of hope from this otherwise lamentable decision. It would seem to follow that the majority of the court would find a filter system that did not support user turn off requests to be unconstitutional.
Basically, a majority found filtering is ok, but only opt-out filtering. The question now is that if you have a non-porn site that the filters say is a porn site, what legal recourse do you have?
This can be very damaging for IBM depending on how their contracts with SCO are worded.
... independently from a third party" who has "no obligation of confidentiality to SCO" (which makes ESR's 60 affidavits highly relevent).
Well, the SCO-IBM contract is posted on SCO's site as Exhibit D. The confidentiality clauses are section 3 on pages 11 and 12.
Specifically, 3.04(v) discounts confidentiality requirements for code which is "independently created" by IBM. Also 3.04(iii) discounts confidentiality when the information is "received
Moreover, 3.06 is a "no tainted worker" clause that allows people who have seen the code to use the ideas when they are "residual information mentally retained" provided they don't try to write it down or memorize it verbatim and don't otherwise infringe copyrights or patents.
Actually, we already know what it is. It's just that most peoples expectations of what SCO is alleging are not accurate. Read the Cringly article for more explaination.
As for the code, there are four primary areas that have surfaced: SMP, JFS, NUMA, and RCU.
I'm pretty confident that SCO's NUMA claim is based on the new NUMA code submitted by Martin Bligh of IBM to the 2.5 kernel. See this post for more details.
Fair use has four tests, the most important of which is the affect on the market value. Publishing the checksums probably increase the market value, since they are a conscious effort to prevent infringement. Another factor in fair use is the quantity of original work that is copied. Since md5 isn't invertible, this is zero. Another test is the purpose: commercial or non-profit. The checksums here are not designed to profit from somebody else's work, they are designed to protect against such profiting. The final test is the nature of the material used: Here it is solely to prevent or identify infringement.
I think it is almost a no brainer that a checksum lookup would be "fair use".
The problem is that suppose in files X and Y there is a checksum match at lines n and m respectively? You can't say anything more than that the lines match. X could have copied from Y, Y from X, or both could duplicate some other source Z.
Has anyone, besides SCO, looked at the Linux code and tried to determine what might have come from SCO, and what might have come from a common predecessor?
/usr/src/linux/mm/numa.c in the 2.4 series kernels. This file contains a comment header stating it was "Written by Kanoj Sarcar, SGI, Aug 1999". This file has been removed from later 2.5 kernels (its gone by at least 2.5.46), appearently because Linux accepted an IBM NUMA patch as reported here. This patch was announced by Martin Bligh and is likely the code in question in this lawsuit.
So far four components of the Linux source have been implicated: SMP, RCU, NUMA, and JFS.
I have done a little digging into the NUMA code. IBM has contributed several people who have participlated in developing NUMA under linux. Some names I've run across: Martin Bligh, Matthew Dobson, Patricia Gaughen, John Stultz, Michael Hohnbaum. IBM even has a Linux NUMA news archive. It appears that IBM jumpstarted it's NUMA efforts when it purchased Sequent which was intitally intended to boost its participation in Project Monterey, which is no doubt the origin of SCO's objections.
The most obvious source file for NUMA is
No you won't. Who are you kidding? You wouldn't be posting to a SCO article, if that were true.
Read my post again. Better yet, click the link and read paragraph 4. You missed the part about IBM having to approve changes to the contract. Unless you have an IBM signature agreeing to "s/AT&T/SCO/" that provision is not enforcable against IBM.
If SCO bought the rights to the contract, then they have the right to watch AT&T decide when to terminate IBM's rights after a breach.
The licences between AT&T and IBM that are posted on SCO's site as Exhibit A and Exhibit B.
In section 3.03 of exhibit B it clearly states that "AT&T" may revoke the licence for non-compliance. Moreover paragraph 4 of the cover page contains a standard "no alterations unless signed in writing" clause. I see nothing that allows AT&T to sell this termination right without IBM's approval. There are similar sectoin in Exhibit A, section 6.03 and paragraph 4 of the cover page.
Actually, money in the bank helps hostile take overs, because the purchasing entity can essentially use it to pay the share-holders.
EG, suppose a company with 17.2 billion in market cap has 5.5 billion in the bank? How much money do you have to make a credible offer to buy the company? You need 11.7 billion. To see this, just imagine that such a company borrowed the other 5.5 billion, and then when it controlls the bank accounts, decides immediately to pay off the loan.
I don't think that case has much applicability here for lots and lots of reasons:
1) SCO advertises its linux expertise and supports linux. They can't really claim they didn't know the cow was pregnant here. For example, in the case of NUMA, SCO's datasheets advertise NUMA support in Linux
2) If you read the case, the court found that because of the mutual mistake of thinking the cow was barren, Walker had a "right to rescind, and to refuse to deliver" the prgenant cow. SCO already delivered the pregnant cow. It had babies and grandbabies. Is SCO ready to rescind all the profits they made selling the mistake?
3) The case cited is a Michigan state common law contract case. The GPL issues make this a federal copyright case. State of mind and knowledge of infringement (ie mistakes) are NOT an element of copyright infringement. (see below) They're going to have to do a lot better than state contract law citations to make this argument. Unless they have federal copyright caselaw to cite, I don't think they'll get very far with this argument.
4) This is also a trade secret case. It is settled law that revealing your own trade secret destroys it, mistake or otherwise. You can't "rescind" the destruction of a secret. Moreover, copyright issues aside, Linus has no duty to keep the secret. Even if IBM did screw up and violate their NDA, that doesn't taint Linux. Only copyright issues can taint Linux.
5) Even if the GPL as pertains to SCO is declared void, SCO still needs some licence to distribute the kernel.org owned IP in Linux. SCO can't make up some other licence for Linux, that is not their right. They must choose to accept the GPL or admit infringing the legitimate parts of Linux via their distribution, modification, and copying thereof. Again state of mind (intent) and knowledge of infringement (ie mistakes) are NOT an element of copyright infringement. This is firmly established law, the best examples of which are the "Dance Hall" cases, where vicarious liability was found when dance hall owners allowed the unauthorized public performance of musical works by the bands they hired, even when the owners had no knowledge of the infringements and had even expressly warned the bands not to perform copyrighted works without a license from the copyright owners. [see Shapiro, Bernstein & Co. v. H.L. Green Co., 316 F.2d 304, 307 (2d Cir. 1963) (citing some 10 cases)].
6) Finally, suppose the GPL is deemed breached. Whenever a contract is breached (and this would be especially true if the GPL here was breached by mutual mistake) there is a duty to mitigate damage to the other party. It is important to realize that the alleged wrong-doing here is by IBM, not Linus Torvalds who did little more than commit the same mistake SCO itself claims to have made but without the opportunity SCO had to know it. SCO has steadfastly refused to inform kernel.org of the technical details of the mistake which would allow it to be fixed. Their insistence on an NDA obviously precludes an open source release to fix the problem. Moreover, the actions such as the threat letter sent by SCO to all those companies seem coldly calculated to maximize damage to kernel.org. I think it is inarguable that the damage caused (intentionally) by SCO to Linux is far more substantial than any damage to SCO's IP, which could be easily fixed by simply distentangling the two code bases.
Laura Didio at least identified some of the code areas: "The claims are not limited to just one area of the Unix System V kernel. SCO claims there are multiple instances of copyright violations. SCO said these include: NUMA (Non Uniform Memory access) a mechanism for enabling large multiprocessing systems, RCU (Read Copy Update) (and) SMP."
As far as NUMA goes, this is clearly aimed at the Monterey project. For a good laugh read the SCO Press Release on Industry Support for Project Monterey
I don't see how SCO can make it's "mutual mistake" (aka the pregnant cow) argument for NUMA. Their SCO Linux 4 datasheet advertises NUMA functionality as a feature of the GPL'd "Linux kernel 2.4.19" and trumps up SCO's Linux expertise and support for this kernel. I really don't see how they can win a trade secret case when they ADVERTISE and SUPPORT the open source release of the secret.
I was discouraged by reading post after post beating down the question. I can only imagine how Slashdot would have responded to somebody asking in 1905 what limitations had to be overcome to make flying machines. Frankly, I was a little cranky yesterday too and I probably should not have singled out any specific post, since my annoyance was really with the quality and dismissive tone of the entire discussion. I note that several other late posters expressed general dismay at the lack of vision in most responses.
The simple fact is that citizen owned wireless networks are already forming. These networks are going to grow both from more people getting involved and from improvements in technology. These networks are going to encounter all sorts of problems as they try to grow and connect to each other, but one thing is certain -- they WILL grow and connect to each other. It is a really important question to ask "How far can we go with things as they are" and to have some vision to ask "How far can we go if we solve a few problem".
The article poster obviously understands that there are various barriers out there that make his vision not exist under the status quo. I share his optimism that it looks like the obstacles can be cataloged and conquered over time. Nothing worth doing is easy, but you have to identify and define the problems before you can solve them.
You raise some good points in your most recent follow up, and I just wish that the tone wasn't "It'll never work because of X, Y, Z" but instead something like "currently X is a barrier because affordable solutions are at level X1 and they need to be at X2 in reach the next level and if you could get it to X3, then wow".
For example, you state "high-density peer-to-peer wireless is only tenable in a dense urban environment". OK, what density is needed? It seems like current ranges are a few hundred yards, so in metro areas your fine today because it is less than the population density and convincing more people to get involved is viable. When it's not you have to improve the technology, so what improvements help the density requirement? If costs were to improve in response to demand for things like directional anteneas and repeaters then I think existing technology can bump the radius up by a factor of 10 or so. Now we're talking. What radius do we have to get to so that typical rural populations can support it?
You also said wireless is "totally worthless for trans-oceanic links". That is too dismissive. I know several Ham radio guys who regularly talk to people all over the world using personally owned equipment, so this can be translated into some non-zero bandwidth. What is the theoretical limit using these frequencies? I don't know, but I'd like to. When it isn't enough, then the different wireless connected components need to be linked up with a few high bandwidth gateways.
There is another question of radius vs cost, but there would probably be some pooling of private resources among people within a connected graph in order to reach out farther and provide connectivity. There are some ham radio guys that privately own some pretty big towers. Could Britain talk to France via wireless if a few hundred people on each side wanted to make it happen? Even for remote islands, there are always ships and planes going back and forth -- if those can be leveraged the connectivity radius decreases.
It's not a stupid question. IMHO it is the most important question of the next decade.
You identify two main obstacles to be overcome: reliablity of connectivity and security/trustworthiness. Instead of ragging on the question (as people did above) why not simply answer it by stating those are the problems, and trying to look at what it takes to solve them. By the way, I think both of those are solvable problems.
The problem of dealing with assholes requires a way to quickly identify and shun them. There is a lot of research going into trust networks, which probably has solved the shunning mechanism pretty well. I think identification of rogue nodes is a newer problem, but it's one that P2P music networks have come across as the RIAA polutes them with crap in an attempt to attack them.
Simple network connectivity is purely a technical problem. It comes down to range, density and "quality" of nodes, and cost. They question is how many transmitters do I personally have to buy and administrate so that I can get enough people in my transmission range to be confident that somebody out there will cooperate.
Actually, solving the latter problem would re-introduce something very valuable back into modern life: the concept of neighborhood community and actually knowing the people who live near you. Back in the frontier days, people new their neighbors well, because they needed them. Today we are so used to being able to anonymously live that it seems strange to suggest that it might be OK for a solution to require that everybody find somebody they can trust within a quarter mile.
Great Question. As I said above Boo-Hiss to the early responses and moderation. I'll try a serious answer.
The technological barriers are:
1) Wireless equipment cost -- it has to come down by a factor of 10 or 20 so that ordinary people can afford to solve their own personal connectivity problems by direct personal action. The range and bandwidth per dollar have to imporve. Mass production of cheep roof-based antenae and other WiFi gear needs to happen. When you can get a 1 mile range for $30, this will take off.
2) Routing protocols -- TCP/IP probably wont work because there will be too many hops and it is too hard to administrate. The network topology will be an order of magnitude more complicated. TCP/IP doesn't deal well with ad-hoc roaming connectivity. Rest assured some really smart people are working on these problems.
3) Making the technology user-friendly and turnkey. Joe sixpack isn't going to want to look at a linux prompt to administrate his peer-to-peer router.
4) New application protocols -- if you throw out TCP/IP to deal with adhoc roaming P2P, you have to rethink everything that rides on top of it: DNS, EMAIL, HTTP, etc... Consider something as simple as establishing your default gateway. What if it wanders out of range?
The geographic isolation problem is directly a function of cost, range, and popularity. Keep in mind that in rural settings, people generally don't have cable or DSL anyway, so the pressure is even greater to find a high bandwidth solution. People were willing to put antenaes on their roofs to get TV -- I'd exect they'd do it for free broadband too. It's a simple matter of making it affordable to use repeaters when necessary.
The political barriers are IMHO the most likely to kill this. AT&T, Sprint, WorldCom etc simply don't want people to obsolete them. You think the RIAA and MPAA are a formidable lobby? Try the telcos. They would attack the uncontrollability of such networks. How do you stop child porn on a P2P wireless network? How do you stop copyright infringement? How do you wiretap terrorists and organized crime when there are no wires?
The economic barriers for deployment are pretty straight forward: equipment cost, range, and bandwidth. But the real question is how do you deal with malicious behavior by network participants? I imagine that trust networks problems have to be solved. How do you avoid the tradgedy of the commons (ie bandwidth hogs). Spam will still be a problem.
Wow. Slashdot has really lost it. I have never been more ashamed of crap moderation in any thread I can remember. This is a great question and it deserves a serious answer. None of the parents of this post have said a single usefull thing.
Boo-Hiss to the idiots who posted all of the ancestor posts above this one. Double boo-hiss to the idiots who moderated this article. As I post this, all four ancestors of my reply are +5 posts, none of which has ANY FUCKING MERIT AT ALL.
"Yeah, I want everything for free too. Give me a break." -- Sorry, not funny. Not interesting. Should be (-1 TROLL)
"I'm glad it's free to run giant fiber optic cables across the ocean." -- Sorry the question is not about running fiber across the ocean. It's about high density peer-to-peer WIRELESS networks and more specifically what the barriers are that need to be overcome to achieve it. Should be (0 Offtopic)
"Basically what the guy wants is nationalization of all telcos, so that your taxes pay for everything." -- Should be (-2 YOU ARE ON CRACK) The guy said he wanted TO ELIMINATE THE NEED FOR TELCOS, not socialize them. Wow, that is a moronic post.
"And of course, the upkeep costs on lines that are already there" -- I'll be kind (0 Offtopic) It's about the potential for WIRELESS peer-to-peer networks to allow people to unplug themselves from these upkeep costs.
No, the big problem is that the question is stupid and that it makes no sense.
It's a pretty damn simple question and it make perfect sense.
it costs money to lay wires and run all of the routers on the internet
That's why he proposes to eliminate wires and massive highly centralized backbone ownership. You really did miss the boat.
Wireless infrastructure is stupid on a large area network, as you waste virtually all of your power transmitting to areas where there are no listening machines
This problem has two independent solutions: strongly directional signals and/or very good signal-to-noise ratio receivers. Short wave radio solved both problems decades ago.
The real question is cost of equipment and standards for adhoc peer-to-peer packet routing (which is exactly what he was asking about). A WiFi access point today costs about $100 and has an omnidirection range of a few hundred yards and a directional range of a mile or two with a cheap antenea. If the cost of this equipment improves by 20X then it might be feasible to route from DC to boston across 1500 hops.