Oftentimes the clients share a hard-coded key. The key can either be used to sign the download request, or the document key can be encrypted with it so that the content can't be decrypted unless you have access to the client's key.
Either solution can be hacked if you just pick apart the licensed client for a copy of the key-- after all, millions of clients will share it. But I'm sure the DMCA will be used to prevent widescale distribution of "illegal" clients.
From the above post, it looks pretty clear that Nullsoft wanted it released under the GPL. I suppose there's a faint possibility that the release was undertaken by a rogue employee, but I'd be astonished.
That's because it is copyright law, not contract law.
No, first and foremost it is a matter of contract law. The court will have to determine whether or not SCO's actions can be considered protected by the GPL. No copyright case can be made until it has been determined that SCO does not deserve protection under the GPL.
The unreasonable part is that they are simultaneously claiming that the code they received was not properly licenced, so that the terms therein don't apply to them, at the same time they are pretending this isn't a problem for them as distributors. Which is it? If the code was improperly licenced, they commited copyright infringement, if the code was properly licenced, they gave up their patent and trade secret claims as part of exercising that licence.
First off, it has nothing to do with the validity of the license they received. It has everything to do with what they redistributed.
Furthermore, I'm not trying to burst your bubble, but the world of contracts and licenses is is a lot more complicated than a piece of boolean logic. IANAL, but I've learned this through experience.
You assume that there is no middle ground in which portions of the GPL can be held enforceable while others can be relaxed, given the circumstances. My bet is that the court will choose to enforce Section 7 in a limited manner: if you can convince the court that you could not reasonably have known that you were in violation, you won't be held for past distributions. As I said before, Section 7 is the most legally questionable area of the GPL, and not coincidentally is the only section with a sort of severability clause that anticipates that it may or may not be enforceable by a court.
Why can't they use diff to examine changes, like the rest of the world does?
I think this statement illustrates how much you're underestimating the seriousness of the problem. Let's imagine that you take SCO to court and tell the judge, "SCO could have just used diff to locate the infringing sections; this is a common industry technique."
SCO's lawyers will immediately respond that the infringing code was added by an outside party. Even though SCO did a careful audit of every shred of code it modified, there was no way for it to realize that its (stolen) proprietary code was in the source before it did a single edit. For instance, SCO may have quite reasonably assumed that since it made no changes to kernelfoobar.c, there would be no way for its proprietary source to get into that file. A diff wouldn't have found this problem.
The judge, upon hearing how badly even the plaintiff underestimates the magnitude of the problem, will be inclined to believe SCO when it claims that a full audit was a major task, and not something it reasonably need have done.
But even you would agree that since they began preparing this case, that at some point they did know. At that point, their violation of the GPL became wilfull, since they continued to ship it. Do you disagree?
I don't disagree, but I think a judge will want to consider a) how many copies were distributed after SCO became aware, b) how quickly SCO acted to halt the distribution, and c) any changes SCO might have made to remove infringing sections from the code it was distributing. One likely outcome I imagine is that SCO could be held liable for every copy of Linux it distributed after becoming aware of the situation, but none of the copies it distributed before. How many copies are we talking about, and is it worth an expensive infringement suit?
The fact that they did discover the problem only proves that an argument that they had "no reasonable way of knowing" what they were shipping is untenable.
I don't think this is going to hold up. We have no idea what brought the infringment to SCO's attention. Perhaps it was a random fluke so unlikely that no reasonable person could argue that SCO "ought to" have discovered it before shipping Linux. Alternatively, they could have someone inside IBM who notified them of the infringements. In any case, all SCO has to do is convince a judge that it needn't have imagined the possibility of stolen code being in the Linux distro.
Is SCO really going to suggest that reading the code to the product they are shipping is impossible? Since when is "I didn't read what I was agreeing to" a defense?
It becomes a defense when the total size of the code exceeds several dozen megabytes, and even "reading" the code won't be enough to discover copyright violations. In order to reliably find this sort of problem, SCO would need to actively machine-audit every line of Linux code, against every single line of its own code. That's a daunting task, and certainly it would be a compelling argument to note that-- as far as I know-- nobody else in the business does it.
On the other hand, a victory by Linux or the FSF would damn well insure that every company does start doing this before releasing GPLed code. And I imagine the cost will drive companies the hell away from the GPL.
SCO has no right to say "Oh great, this licence is screwed -- let's ship it anyway".
They don't. But can they be held liable for every copy they shipped before they became aware? I highly doubt it, and I doubt that the few copies they shipped afterward are going to be the axe that brings down this particular monster.
Even if there is a legal reason to keep the specific violations secret, that does not help SCO in terms of compliance with the GPL. Section 7 states that if you cannot follow the terms of the GPL for legal reasons, then you are not allowed to use it.
It's clear that Section 7 bars a company from distributing GPLed code when they know that there are factors preventing it. The question facing a potential judge will be: does section 7 allow a plaintiff to collect damages for past distributions even when the defendant had every good reason to believe that it was obeying the terms of the GPL?
Given the circumstances of this case, the judge may find that SCO is barred from distributing further copies of the code, but that they cannot be held financially responsible for their earlier actions, given that they were caused by a bad-faith action of a third party.
Section 7 even allows that it may not be fully enforceable under all circumstances. Read the middle paragraph: "If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances."
Actually, very few licenses outside of the Open Source community require you to re-license any code in a redistributable fashion. Sure, if I accidentally include the wrong code in my proprietary product, other people will receive it-- but they generally can't redistribute it at will. In fact, there are very few licenses that require you to distribute the source code at all.
I suppose there's the occasional, rare situation where you contribute code to a third-party application under some strange license-- say, you're writing a plugin for some application and the license demands that you automatically grant rights to the company that publishes the application.
But even in those unusual cases, you're generally only required to give up the object code, not the source. And it's only one company that you're licensing to, not the entire world.
So yeah, this problem is not unique to the GPL. It could affect other GPL-like Open Source licenses. I don't see how this makes anything better.
It doesn't matter if they knew. Knowledge is not an element of copyright infringement...
The fact that they did eventually know dismantles any argument they try to make.
You may have a point, but again, you're looking at this as a matter of copyright law, not contract law. All SCO has to do is convince a judge that they complied with the terms of the GPL to an eminently reasonable degree, and they can be protected from copyright infringement charges.
And I'm not sure that their eventual identification of the code represents damning proof that they should have known before they shipped copies of Linux. Who knows what bizarre circumstances brought it to their notice.
The answer is very simple: they should have immediately sent IBM and the Linux community a C&D letter stating what parts of the code were proprietary. They should have refused to ship that code themselves under the GPL.
I'm with you on the second part, though as I've said before, it depends on how quickly they stopped shipping. They might even be held liable for those copies they shipped after determining that there was proprietary code in the source, but not for any copies shipped before that point.
As to notifying the Linux community... I'm not sure they're actually required to do so. Certainly nothing in the license compels them to do so, and if there's a valid legal reason-- demanded by the courts-- for keeping that info under wraps until it reaches trial, then they could have a legitimate excuse not to notify the Linux community of the precise violations.
I never said the law was just.
Does this place a burden on them to actually understand everything they ship? Yes, it does, but only if they want to keep their proprietary stuff cleanly separated from their GPL stuff.... Only if the company wants to ship two such code bases that are candidates for mixing. Consider Corel from before: there was little risk that WorkPerfect code and linux code would intermix.
I think SCO has a pretty good defense on that score. They could simply point out that they audited all of the changes they made. How were they to know that their proprietary code was present in, say, a file that they didn't even modify? Like it or not, this argument has a pretty good chance of convincing a judge; especially when he or she considers the sheer size and complexity of a full audit.
In fact, in your post above you mention "looking at the diff". Had SCO "looked at the diff" after modifying the code, they wouldn't have noticed the proprietary code, anyway. That code was allegedly added by IBM before it got to SCO, so it would have been transparent to diff.
If somebody else sends them a patch that adds large chunks of their proprietary RDBMS code in, should they blindly smile and ship it out? Um, no. They should be checking every patch submission they get
Ultimately that's what a court is going to have to determine. Is is reasonable to expect every company to scan through every single piece of code in a potentially enormous project for code that some malicious third party may have stolen and incorporated? The answer could be yes, in which corporate contributions to GPLed applications are going to become a rare phenomenon. That sort of auditing can be too damned expensive to be worth the trouble.
One answer, as I see it, is a new version of the GPL that explicitly requires companies to take steps to prevent tainted code from getting out into the wild, and to immediately give licensees notice of how to remove it should it get out. Naturally this would only apply in situations where the leak was due to serious outside violations, not just anytime some company has second thoughts abour releasing a piece of code. It's much safer to provide for these extreme circumstances than to leave it for the courtroom.
... that we could well avoid this whole mess, thanks to the Novell announcement today. But sooner or later we're going to have to deal with this for real.
Neither legal solution is ideal, depending on whose shoes you imagine yourself in. It's pretty scary to thing that someone could steal my top-secret "I'm gonna make a million bucks with this" code and stick it into a GPLed project I also work on, thereby screwing me. It's also scary to think that a company like SCO can taint the entire Linux codebase with a couple of snippets of code.
The answer, I would imagine, lies in a few new clauses in the GPL. Should you find that some third party has placed you in violation, you should be legally required to hold all downstream parties blameless for some period of time, and immediately hand them the information required to remove the tainted code.
Such a requirement protects copyright holders, but might also prevent a repeat of SCO's "we're gonna sue every Linux user, but we won't tell you exactly why" situation.
Considering that they only stopped distributing Linux on the day that they sent out the infamous letter threatening end users, I think it will be incredibly difficult for SCO to argue that they did not know about any copyright or patent infringements while they were still distributing.
I agree that continuing distribution for long after they had confirmed the existence of the code would seriously undermine their case. I guess it's a question of how quickly they stopped distributing, and more importantly, whether they acted to remove the proprietary bits from their distributions. They could argue that they took immediate actions to correct the situation, but there were certain legitimate complications that slowed them down. A court might buy it. Nothing in the legal system is black and white.
And even so, I don't get the impression that they distributed too many copies of that code after they announced it was tainted. Perhaps they're prepared to risk an infringment suit on that handful of copies, knowing that it wouldn't be worth the legal fees to prosecute it.
SCO can't be forced to give away any rights to their proprietary code. They can either decide to abide by the terms of the GPL and stop all of this nonsense, or they can admit that they violated the Linux copyrights and face the consequences.
I disagree. Though we may look at these two things as alternatives, companies considering contributions to GPLed software will see it as a rock and a hard place. Why mess with GPLed source at all if it could potentially force you to decide between giving up your precious proprietary code, or going bankrupt paying damages?
Of course, I think that's a perfectly reasonable set of alternatives to present to a company who has actively violated the terms of the GPL. But when a company can work diligently to comply with the GPL and still be faced with that Devil's Alternative-- due to some malicious outsider, perhaps-- the only reasonable answer will be to avoid the GPL like the plague, and perhaps require your employees to do so as well.
If they discovered that there was illegal code in Linux and stopped distributing immediately, notified the developers about the violations and waited for them to be corrected, then none of this would be a problem.
As I said, you may be right about the first part of that sentiment. Their case depends on the rapidity with which they stopped distributing. However, I honestly don't know if their notifying developers of the violations will make much of a difference. If there is a strong legal reason to keep the violations confidential until the case reaches a judge, the legal system might not consider that an important component in determining SCO's compliance. If SCO can argue that they had to keep the information secret because of a legal requirement, it's going to be hard for the court to hold that against them.
There is nothing "good faith" about trying to retain trade secret status for something that you yourself distributed for-profit as part of a GPL'd product, when that licence forbids you from adding any "further restrictions". If SCO want to call "mulligan" then it better pony up all the profits it got along the way.
I hate to defend SCO, but if things happened the way they say they did, then they acted very reasonably. Somebody else violated an agreement and illegally copied SCO's proprietary code into a GPLed product. SCO redistributed that product, with no reasonable way of knowing that they were distributing their own code. Their decision to distribute under the terms of the GPL was logical, given the information they possessed at the time.
Contracts have certain real-world standards for reasonability. For instance, a contract cannot demand that you display a supernatural ability to detect wrongdoing by a third party. If a judge determines that it was not possible for SCO to uphold certain aspects of the contract no matter what, and that SCO could not have known this, he/she may rule that certain aspects of the contract cannot be enforced.
The GPL even has a provision for this: "If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances." The FSF recognized that the restrictions of the license might be limited under certain circumstances, without invalidating the entire license.
Is it unfair that IBM has a higher burden that SCO? Not necessarily. After all, IBM is (allegedly) the party at fault in both cases. If they accidentally released somebody else's code, then there are no mitigating circumstances; it's their screwup, they have to deal with it. In SCO's case, SCO acted reasonably, and their non-compliance was actually brought about by an illegality on the part of IBM. One could even argue that IBM (or someone at IBM) acted with the deliberate intention of bringing about this circumstance, which is an even better argument against holding SCO to the full conditions of the contract.
But here's the real reason to know your line of argument is defunct. Nobody's pursuing it. With all of the high-powered lawyers and Free Software advocates on the case, it's not like you're the only person to come up with this one. Either they know that the interpretation of the GPL is likely to be a lot more flexible that you give it credit, or they understand that the potential blowback to the Free Software movement makes this a lousy solution.
It isn't the GPL that exposes them to legal immolation, it is non-compliance with the GPL that exposes them
But it is the GPL that exposes you to potentially being non-compliant, even when you've made all reasonable efforts to comply.
If someone breaks into your company and steals proprietary code, all they have to do is insert it into a GPLed software package that you also contribute to and distribute. At that point, you're screwed. You get a very unpleasant choice: either give up rights to your own code, or pay millions in damages.
What sin have you committed to place yourself in this situation? You had what you thought were legitimate dealings with a GPLed product. The only reliable way to protect yourself from this sort of inadvertant exposure is to avoid doing any work on GPLed products, and perhaps to prevent your employees from doing so as well.
Please explain to me any reason why Red Hat (say) would change its business if SCO was called to the carpet for copyright infringement here.
Any company that relies on proprietary code and also works on GPLed code could be at risk. I'd be a lot less concerned about Red Hat than, say, a major contributor like IBM, though I'm sure Red Hat has proprietary code it doesn't want to lose.
Furthermore, it would pretty much confirm Microsoft's earlier ramblings about the GPL putting a company's IP at risk. You could lose your IP because of the actions of one disgruntled employee or even a hacker. The GPL starts to look downright dangerous.
Tom Clancy is something you read when you want to take your brain out of gear, rather than engage it.
I used to think so... But no I'm just daunted by the stuff. Six hundred pages just to repeat the same damned plot-line from your last book, with an even more unbelievable set of bad-guys? Last book I bothered to read, I found myself skimming through pages at a time and not missing much.
It's so bad that your brain actually wants to come back into gear... So it can get the hell away.
My work ID badge can operate through my wallet. In fact, I can often just touch my hip or coat pocket to the reader and the door will open, depending on how lazy I'm feeling.
My concern would be that unscrupulous individuals would use portable readers to get your card number. It would be a form of pick-pocketing that wouldn't actually require any contact or much risk of getting caught.
Hopefully, the cards would use some sort of challenge/response system, rather than a fixed number that could be replayed to a terminal. Still, there are bound to be vulnerabilities, and we'll probably be reading about them in a couple of years.
No!! You can go back in time (up to the statute of limitations) and say "I just discovered that way back in 1998 you distributed your product FOO which included unlicensed portions of my work. Pay up. Oh, and I want your profits from the infringing sales, too." Just ask Dr. Dre who just lost 1.5 million in such a verdict.
Unfortunately, you're looking at this as a pure copyright case, when it's actually going to be judged as a contract/license case.
SCO would argue that they attempted, within all bounds of reasonable good faith, to comply with the terms of the GPL, and that their efforts were undermined by bad-faith actions of a third party-- actions that they didn't even know about. The plaintiff (Linus, the FSF, whomever) would then have to convince a judge that this faithful attempt at compliance is worth zero, and that SCO should be still be liable for every copy of Linux that they ever shipped.
It will come down to a matter of contract law, not copyright law. Does the judge hold SCO to an impossible contractual standard? Or does he/she seek a reasonable middle-ground? If the judge determines that the demands of the plaintiff are unreasonable, then he/she can decide that certain aspects of the GPL are unenforceable, while leaving SCO protected under the remaining sections. In that case, the plaintiff has no copyright infringment case against SCO.
The funniest part of this all is the alternative. Let's say the FSF or Linus does prevail, and forces SCO to give away rights to its proprietary code, or alternatively, collects millions in damages. Such an outcome would put a stake through the heart of the GPL. Who in god's name would ever deal with GPLed code if there's even the slightest chance that it could expose their business to this sort of legal immolation? Hell, Microsoft couldn't do a better job of scaring people away from GPLed software.
The FSF would be insane to take the route you suggest. Their "victory" would be the greatest defeat in the history of free software.
Linus should and frankly MUST sue SCO for copyright infringement for distributing a derivitive of his work without a licence. In fact, any other kernel contributor could do the same so long as their original work is included in what SCO has distributed.
It depends whether or not SCO continued to distribute after they'd verified that their proprietary IP had entered the Linux codebase, and for how long.
If they stopped distribution, or removed the offending code after discovering it, then it could be said that they'd made a good-faith effort to obey the terms of the GPL. Do they lose the right to control that proprietary code? Probably not. Can they continue to distribute? No. Should they be held responsible for copyright violations? Probably not.
If you did allow Linus or the FSF to sue for copyright infringement, you'd essentially be saying that SCO should be penalized because somebody else stole their proprietary code and stuck it into a piece of Open Source Software that-- unknown to them-- passed through their hands. That's a pretty perverse result.
In fact, section 7 of the GPL offers some clarifications on this. It says that any company that knows it cannot legally redistribute must cease distribution. It does not necessarily hold that a company may be penalized for previous distributions where it acted in good faith, but was undermined by the actions of some third party.
In fact, the GPL is not at all clear on this situation, which is why it would be problematic if it went to court. A judge would have to make a very tough call, and the results are hard to predict.
Firewalls and Internet Security: Repelling the Wily Hacker by Cheswick, Bellovin and Rubin.
A great primer on some of the fundamentals of the field, along with a few of the more common attacks (mind you, any technique you find in a printed book is liable to be slightly behind the cutting edge.)
One of the things he found was a for-loop in which the author had on a certain condition break out of.
This person could either be a lousy coder or a brilliant C maven.
Having spent a few years with old-school Unix guys I've been regularly amazed by their coding skill. The code is entirely rotten, and undebuggable by anyone else, but they can produce it better and faster than anyone I know. Breaking for-loops and all.
And in order to read the article, you must provide your sex, date of birth, and physical location...
Oh come on, they practically give you instructions on what to fill in. "What year were you born (example, 1965)", "What is your zipcode (example: 20171)".
I wouldn't be surprised if that site wasn't receiving an inordinate number of 38-year-old readers from the 20171 zip code.
how many people really believe that the government is out to get them? Face it, you're just not that important and your life just isn't that interesting
That's the wonderful thing about modern database technology. Your life doesn't have to be that interesting for the government to keep detailed watch on you; you get such an economy of scale maintaining a nationwide database that the cost of monitoring an individual electronically approaches zero.
You're absolutely right that the government isn't going to display much interest in 99% of the people it sureveils. But since it's watching everyone, it'll know the instant any individual does start being interesting, and it'll know their whole background.
Join a political party that's considered non-mainstream? You can be shunted to the front of a list automatically, and the government will know everything about you, down to your taste in pornography. If you believe that the gov't won't use its power against alternative political groups, think again; they've already prevented certain members of the Green party from flying on national airlines. And, of course, the FBI had no qualms about harrassing Martin Luther King, why should it be any different now? TIA just makes these abuses easier and more dangerous.
If you don't see the power of these systems, that's not a comment on their nature. It's merely a reflection of your lack of understanding. I assure you that the Pentagon realizes how powerful they can be.
Today's Washington Post has an article on the various ways the Justice Department has applied terrorism laws to non-terrorism-related cases.
The Justice Department has used many of the anti-terrorism powers granted in the wake of the Sept. 11, 2001, attacks to pursue defendants for crimes unrelated to terrorism, including drug violations, credit card fraud and bank theft, according to a government accounting released yesterday.
The present shuttle's main engines burn hydrogen + oxygen --> H2O. The "pollution" in question is... WATER!
How much oil/coal/plutonium do you have to go through in order to produce the tons of hydrogen and oxygen used by the main engines in a single launch?
The best solution will be some sort of ramjet-powered passenger vehicle. It won't necessarily help with satellite launches, but it would help reduce the costs of manned flights. Of course, that technology isn't ready for prime time, but it will be eventually (at this rate, probably before NASA gets around to selecting a replacement.)
The original Matrix unveiled a mindbending premise over a period of about 50% of the movie. It was artfully done, so as not to overload the viewer, but to keep him guessing. Once the premise was out, then the movie could move on to a satisfying action-oriented conclusion.
Reloaded spent 95% of the time asking and answer precisely nothing. When Neo got to the Architect, suddenly there was an enormous amount to think about-- but it was dumped on you so quickly that you didn't have time to absorb it, or really mull the implications. Then you were running again, and then it was over.
The point is, anyone can come up with plot twists. Good moviemakers also have to keep you interested.
It is a step back to the corny special effects of previous decades where the audience is asked to not look to closely at the screen
I'm not sure there was ever any period where non-CGI special effects got so sophisticated that we're now taking a "step back" by using CGI. In the 80s, I recall lots of "superimpose one piece of film onto another" kind of effects. In the 90s, there was just lots of lousy CGI.
The current CGI techniques are a major improvement over both of the previous styles. I do miss some of the inventiveness that old-fashioned special effects necessitated, but I'm not sure it's the end of the world.
Why would they buy Napster? All the record industry had to do was release their catalogs on a convenient pay site (which they still haven't really done.) Napster's "innovation" (which wasn't patented) was useful, but hardly necessary for this business.
All Napster really had was a name, and the public demonstrated that they were willing to go elsewhere for free music.
Slashdot Mirror
Either solution can be hacked if you just pick apart the licensed client for a copy of the key-- after all, millions of clients will share it. But I'm sure the DMCA will be used to prevent widescale distribution of "illegal" clients.
From the above post, it looks pretty clear that Nullsoft wanted it released under the GPL. I suppose there's a faint possibility that the release was undertaken by a rogue employee, but I'd be astonished.
No, first and foremost it is a matter of contract law. The court will have to determine whether or not SCO's actions can be considered protected by the GPL. No copyright case can be made until it has been determined that SCO does not deserve protection under the GPL.
The unreasonable part is that they are simultaneously claiming that the code they received was not properly licenced, so that the terms therein don't apply to them, at the same time they are pretending this isn't a problem for them as distributors. Which is it? If the code was improperly licenced, they commited copyright infringement, if the code was properly licenced, they gave up their patent and trade secret claims as part of exercising that licence.
First off, it has nothing to do with the validity of the license they received. It has everything to do with what they redistributed.
Furthermore, I'm not trying to burst your bubble, but the world of contracts and licenses is is a lot more complicated than a piece of boolean logic. IANAL, but I've learned this through experience.
You assume that there is no middle ground in which portions of the GPL can be held enforceable while others can be relaxed, given the circumstances. My bet is that the court will choose to enforce Section 7 in a limited manner: if you can convince the court that you could not reasonably have known that you were in violation, you won't be held for past distributions. As I said before, Section 7 is the most legally questionable area of the GPL, and not coincidentally is the only section with a sort of severability clause that anticipates that it may or may not be enforceable by a court.
I think this statement illustrates how much you're underestimating the seriousness of the problem. Let's imagine that you take SCO to court and tell the judge, "SCO could have just used diff to locate the infringing sections; this is a common industry technique."
SCO's lawyers will immediately respond that the infringing code was added by an outside party. Even though SCO did a careful audit of every shred of code it modified, there was no way for it to realize that its (stolen) proprietary code was in the source before it did a single edit. For instance, SCO may have quite reasonably assumed that since it made no changes to kernelfoobar.c, there would be no way for its proprietary source to get into that file. A diff wouldn't have found this problem.
The judge, upon hearing how badly even the plaintiff underestimates the magnitude of the problem, will be inclined to believe SCO when it claims that a full audit was a major task, and not something it reasonably need have done.
But even you would agree that since they began preparing this case, that at some point they did know. At that point, their violation of the GPL became wilfull, since they continued to ship it. Do you disagree?
I don't disagree, but I think a judge will want to consider a) how many copies were distributed after SCO became aware, b) how quickly SCO acted to halt the distribution, and c) any changes SCO might have made to remove infringing sections from the code it was distributing. One likely outcome I imagine is that SCO could be held liable for every copy of Linux it distributed after becoming aware of the situation, but none of the copies it distributed before. How many copies are we talking about, and is it worth an expensive infringement suit?
The fact that they did discover the problem only proves that an argument that they had "no reasonable way of knowing" what they were shipping is untenable.
I don't think this is going to hold up. We have no idea what brought the infringment to SCO's attention. Perhaps it was a random fluke so unlikely that no reasonable person could argue that SCO "ought to" have discovered it before shipping Linux. Alternatively, they could have someone inside IBM who notified them of the infringements. In any case, all SCO has to do is convince a judge that it needn't have imagined the possibility of stolen code being in the Linux distro.
Is SCO really going to suggest that reading the code to the product they are shipping is impossible? Since when is "I didn't read what I was agreeing to" a defense?
It becomes a defense when the total size of the code exceeds several dozen megabytes, and even "reading" the code won't be enough to discover copyright violations. In order to reliably find this sort of problem, SCO would need to actively machine-audit every line of Linux code, against every single line of its own code. That's a daunting task, and certainly it would be a compelling argument to note that-- as far as I know-- nobody else in the business does it.
On the other hand, a victory by Linux or the FSF would damn well insure that every company does start doing this before releasing GPLed code. And I imagine the cost will drive companies the hell away from the GPL.
SCO has no right to say "Oh great, this licence is screwed -- let's ship it anyway".
They don't. But can they be held liable for every copy they shipped before they became aware? I highly doubt it, and I doubt that the few copies they shipped afterward are going to be the axe that brings down this particular monster.
It's clear that Section 7 bars a company from distributing GPLed code when they know that there are factors preventing it. The question facing a potential judge will be: does section 7 allow a plaintiff to collect damages for past distributions even when the defendant had every good reason to believe that it was obeying the terms of the GPL?
Given the circumstances of this case, the judge may find that SCO is barred from distributing further copies of the code, but that they cannot be held financially responsible for their earlier actions, given that they were caused by a bad-faith action of a third party.
Section 7 even allows that it may not be fully enforceable under all circumstances. Read the middle paragraph: "If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances."
I suppose there's the occasional, rare situation where you contribute code to a third-party application under some strange license-- say, you're writing a plugin for some application and the license demands that you automatically grant rights to the company that publishes the application.
But even in those unusual cases, you're generally only required to give up the object code, not the source. And it's only one company that you're licensing to, not the entire world.
So yeah, this problem is not unique to the GPL. It could affect other GPL-like Open Source licenses. I don't see how this makes anything better.
You may have a point, but again, you're looking at this as a matter of copyright law, not contract law. All SCO has to do is convince a judge that they complied with the terms of the GPL to an eminently reasonable degree, and they can be protected from copyright infringement charges.
And I'm not sure that their eventual identification of the code represents damning proof that they should have known before they shipped copies of Linux. Who knows what bizarre circumstances brought it to their notice.
I'm with you on the second part, though as I've said before, it depends on how quickly they stopped shipping. They might even be held liable for those copies they shipped after determining that there was proprietary code in the source, but not for any copies shipped before that point.
As to notifying the Linux community... I'm not sure they're actually required to do so. Certainly nothing in the license compels them to do so, and if there's a valid legal reason-- demanded by the courts-- for keeping that info under wraps until it reaches trial, then they could have a legitimate excuse not to notify the Linux community of the precise violations.
I never said the law was just.
Does this place a burden on them to actually understand everything they ship? Yes, it does, but only if they want to keep their proprietary stuff cleanly separated from their GPL stuff. ... Only if the company wants to ship two such code bases that are candidates for mixing. Consider Corel from before: there was little risk that WorkPerfect code and linux code would intermix.
I think SCO has a pretty good defense on that score. They could simply point out that they audited all of the changes they made. How were they to know that their proprietary code was present in, say, a file that they didn't even modify? Like it or not, this argument has a pretty good chance of convincing a judge; especially when he or she considers the sheer size and complexity of a full audit.
In fact, in your post above you mention "looking at the diff". Had SCO "looked at the diff" after modifying the code, they wouldn't have noticed the proprietary code, anyway. That code was allegedly added by IBM before it got to SCO, so it would have been transparent to diff.
If somebody else sends them a patch that adds large chunks of their proprietary RDBMS code in, should they blindly smile and ship it out? Um, no. They should be checking every patch submission they get
Ultimately that's what a court is going to have to determine. Is is reasonable to expect every company to scan through every single piece of code in a potentially enormous project for code that some malicious third party may have stolen and incorporated? The answer could be yes, in which corporate contributions to GPLed applications are going to become a rare phenomenon. That sort of auditing can be too damned expensive to be worth the trouble.
One answer, as I see it, is a new version of the GPL that explicitly requires companies to take steps to prevent tainted code from getting out into the wild, and to immediately give licensees notice of how to remove it should it get out. Naturally this would only apply in situations where the leak was due to serious outside violations, not just anytime some company has second thoughts abour releasing a piece of code. It's much safer to provide for these extreme circumstances than to leave it for the courtroom.
Neither legal solution is ideal, depending on whose shoes you imagine yourself in. It's pretty scary to thing that someone could steal my top-secret "I'm gonna make a million bucks with this" code and stick it into a GPLed project I also work on, thereby screwing me. It's also scary to think that a company like SCO can taint the entire Linux codebase with a couple of snippets of code.
The answer, I would imagine, lies in a few new clauses in the GPL. Should you find that some third party has placed you in violation, you should be legally required to hold all downstream parties blameless for some period of time, and immediately hand them the information required to remove the tainted code.
Such a requirement protects copyright holders, but might also prevent a repeat of SCO's "we're gonna sue every Linux user, but we won't tell you exactly why" situation.
I agree that continuing distribution for long after they had confirmed the existence of the code would seriously undermine their case. I guess it's a question of how quickly they stopped distributing, and more importantly, whether they acted to remove the proprietary bits from their distributions. They could argue that they took immediate actions to correct the situation, but there were certain legitimate complications that slowed them down. A court might buy it. Nothing in the legal system is black and white.
And even so, I don't get the impression that they distributed too many copies of that code after they announced it was tainted. Perhaps they're prepared to risk an infringment suit on that handful of copies, knowing that it wouldn't be worth the legal fees to prosecute it.
SCO can't be forced to give away any rights to their proprietary code. They can either decide to abide by the terms of the GPL and stop all of this nonsense, or they can admit that they violated the Linux copyrights and face the consequences.
I disagree. Though we may look at these two things as alternatives, companies considering contributions to GPLed software will see it as a rock and a hard place. Why mess with GPLed source at all if it could potentially force you to decide between giving up your precious proprietary code, or going bankrupt paying damages?
Of course, I think that's a perfectly reasonable set of alternatives to present to a company who has actively violated the terms of the GPL. But when a company can work diligently to comply with the GPL and still be faced with that Devil's Alternative-- due to some malicious outsider, perhaps-- the only reasonable answer will be to avoid the GPL like the plague, and perhaps require your employees to do so as well.
If they discovered that there was illegal code in Linux and stopped distributing immediately, notified the developers about the violations and waited for them to be corrected, then none of this would be a problem.
As I said, you may be right about the first part of that sentiment. Their case depends on the rapidity with which they stopped distributing. However, I honestly don't know if their notifying developers of the violations will make much of a difference. If there is a strong legal reason to keep the violations confidential until the case reaches a judge, the legal system might not consider that an important component in determining SCO's compliance. If SCO can argue that they had to keep the information secret because of a legal requirement, it's going to be hard for the court to hold that against them.
I hate to defend SCO, but if things happened the way they say they did, then they acted very reasonably. Somebody else violated an agreement and illegally copied SCO's proprietary code into a GPLed product. SCO redistributed that product, with no reasonable way of knowing that they were distributing their own code. Their decision to distribute under the terms of the GPL was logical, given the information they possessed at the time.
Contracts have certain real-world standards for reasonability. For instance, a contract cannot demand that you display a supernatural ability to detect wrongdoing by a third party. If a judge determines that it was not possible for SCO to uphold certain aspects of the contract no matter what, and that SCO could not have known this, he/she may rule that certain aspects of the contract cannot be enforced.
The GPL even has a provision for this: "If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances." The FSF recognized that the restrictions of the license might be limited under certain circumstances, without invalidating the entire license.
Is it unfair that IBM has a higher burden that SCO? Not necessarily. After all, IBM is (allegedly) the party at fault in both cases. If they accidentally released somebody else's code, then there are no mitigating circumstances; it's their screwup, they have to deal with it. In SCO's case, SCO acted reasonably, and their non-compliance was actually brought about by an illegality on the part of IBM. One could even argue that IBM (or someone at IBM) acted with the deliberate intention of bringing about this circumstance, which is an even better argument against holding SCO to the full conditions of the contract.
But here's the real reason to know your line of argument is defunct. Nobody's pursuing it. With all of the high-powered lawyers and Free Software advocates on the case, it's not like you're the only person to come up with this one. Either they know that the interpretation of the GPL is likely to be a lot more flexible that you give it credit, or they understand that the potential blowback to the Free Software movement makes this a lousy solution.
But it is the GPL that exposes you to potentially being non-compliant, even when you've made all reasonable efforts to comply.
If someone breaks into your company and steals proprietary code, all they have to do is insert it into a GPLed software package that you also contribute to and distribute. At that point, you're screwed. You get a very unpleasant choice: either give up rights to your own code, or pay millions in damages.
What sin have you committed to place yourself in this situation? You had what you thought were legitimate dealings with a GPLed product. The only reliable way to protect yourself from this sort of inadvertant exposure is to avoid doing any work on GPLed products, and perhaps to prevent your employees from doing so as well.
Please explain to me any reason why Red Hat (say) would change its business if SCO was called to the carpet for copyright infringement here.
Any company that relies on proprietary code and also works on GPLed code could be at risk. I'd be a lot less concerned about Red Hat than, say, a major contributor like IBM, though I'm sure Red Hat has proprietary code it doesn't want to lose.
Furthermore, it would pretty much confirm Microsoft's earlier ramblings about the GPL putting a company's IP at risk. You could lose your IP because of the actions of one disgruntled employee or even a hacker. The GPL starts to look downright dangerous.
I used to think so... But no I'm just daunted by the stuff. Six hundred pages just to repeat the same damned plot-line from your last book, with an even more unbelievable set of bad-guys? Last book I bothered to read, I found myself skimming through pages at a time and not missing much.
It's so bad that your brain actually wants to come back into gear... So it can get the hell away.
My concern would be that unscrupulous individuals would use portable readers to get your card number. It would be a form of pick-pocketing that wouldn't actually require any contact or much risk of getting caught.
Hopefully, the cards would use some sort of challenge/response system, rather than a fixed number that could be replayed to a terminal. Still, there are bound to be vulnerabilities, and we'll probably be reading about them in a couple of years.
Unfortunately, you're looking at this as a pure copyright case, when it's actually going to be judged as a contract/license case.
SCO would argue that they attempted, within all bounds of reasonable good faith, to comply with the terms of the GPL, and that their efforts were undermined by bad-faith actions of a third party-- actions that they didn't even know about. The plaintiff (Linus, the FSF, whomever) would then have to convince a judge that this faithful attempt at compliance is worth zero, and that SCO should be still be liable for every copy of Linux that they ever shipped.
It will come down to a matter of contract law, not copyright law. Does the judge hold SCO to an impossible contractual standard? Or does he/she seek a reasonable middle-ground? If the judge determines that the demands of the plaintiff are unreasonable, then he/she can decide that certain aspects of the GPL are unenforceable, while leaving SCO protected under the remaining sections. In that case, the plaintiff has no copyright infringment case against SCO.
The funniest part of this all is the alternative. Let's say the FSF or Linus does prevail, and forces SCO to give away rights to its proprietary code, or alternatively, collects millions in damages. Such an outcome would put a stake through the heart of the GPL. Who in god's name would ever deal with GPLed code if there's even the slightest chance that it could expose their business to this sort of legal immolation? Hell, Microsoft couldn't do a better job of scaring people away from GPLed software.
The FSF would be insane to take the route you suggest. Their "victory" would be the greatest defeat in the history of free software.
It depends whether or not SCO continued to distribute after they'd verified that their proprietary IP had entered the Linux codebase, and for how long.
If they stopped distribution, or removed the offending code after discovering it, then it could be said that they'd made a good-faith effort to obey the terms of the GPL. Do they lose the right to control that proprietary code? Probably not. Can they continue to distribute? No. Should they be held responsible for copyright violations? Probably not.
If you did allow Linus or the FSF to sue for copyright infringement, you'd essentially be saying that SCO should be penalized because somebody else stole their proprietary code and stuck it into a piece of Open Source Software that-- unknown to them-- passed through their hands. That's a pretty perverse result.
In fact, section 7 of the GPL offers some clarifications on this. It says that any company that knows it cannot legally redistribute must cease distribution. It does not necessarily hold that a company may be penalized for previous distributions where it acted in good faith, but was undermined by the actions of some third party.
In fact, the GPL is not at all clear on this situation, which is why it would be problematic if it went to court. A judge would have to make a very tough call, and the results are hard to predict.
A great primer on some of the fundamentals of the field, along with a few of the more common attacks (mind you, any technique you find in a printed book is liable to be slightly behind the cutting edge.)
This person could either be a lousy coder or a brilliant C maven.
Having spent a few years with old-school Unix guys I've been regularly amazed by their coding skill. The code is entirely rotten, and undebuggable by anyone else, but they can produce it better and faster than anyone I know. Breaking for-loops and all.
Oh come on, they practically give you instructions on what to fill in. "What year were you born (example, 1965)", "What is your zipcode (example: 20171)".
I wouldn't be surprised if that site wasn't receiving an inordinate number of 38-year-old readers from the 20171 zip code.
That's the wonderful thing about modern database technology. Your life doesn't have to be that interesting for the government to keep detailed watch on you; you get such an economy of scale maintaining a nationwide database that the cost of monitoring an individual electronically approaches zero.
You're absolutely right that the government isn't going to display much interest in 99% of the people it sureveils. But since it's watching everyone, it'll know the instant any individual does start being interesting, and it'll know their whole background.
Join a political party that's considered non-mainstream? You can be shunted to the front of a list automatically, and the government will know everything about you, down to your taste in pornography. If you believe that the gov't won't use its power against alternative political groups, think again; they've already prevented certain members of the Green party from flying on national airlines. And, of course, the FBI had no qualms about harrassing Martin Luther King, why should it be any different now? TIA just makes these abuses easier and more dangerous.
If you don't see the power of these systems, that's not a comment on their nature. It's merely a reflection of your lack of understanding. I assure you that the Pentagon realizes how powerful they can be.
How much oil/coal/plutonium do you have to go through in order to produce the tons of hydrogen and oxygen used by the main engines in a single launch?
The best solution will be some sort of ramjet-powered passenger vehicle. It won't necessarily help with satellite launches, but it would help reduce the costs of manned flights. Of course, that technology isn't ready for prime time, but it will be eventually (at this rate, probably before NASA gets around to selecting a replacement.)
Reloaded spent 95% of the time asking and answer precisely nothing. When Neo got to the Architect, suddenly there was an enormous amount to think about-- but it was dumped on you so quickly that you didn't have time to absorb it, or really mull the implications. Then you were running again, and then it was over.
The point is, anyone can come up with plot twists. Good moviemakers also have to keep you interested.
I'm not sure there was ever any period where non-CGI special effects got so sophisticated that we're now taking a "step back" by using CGI. In the 80s, I recall lots of "superimpose one piece of film onto another" kind of effects. In the 90s, there was just lots of lousy CGI.
The current CGI techniques are a major improvement over both of the previous styles. I do miss some of the inventiveness that old-fashioned special effects necessitated, but I'm not sure it's the end of the world.
Why would they buy Napster? All the record industry had to do was release their catalogs on a convenient pay site (which they still haven't really done.) Napster's "innovation" (which wasn't patented) was useful, but hardly necessary for this business.
All Napster really had was a name, and the public demonstrated that they were willing to go elsewhere for free music.