The iPhone is hardware, and as such you can't disclaim warranties of fitness for purpose the way you can with software. It's amazing to me how many people here are so willing to just accept any sort of claim that a company can do anything it wants to your product, *after* you buy it. You probably voided your warranty, but if Apple intentionally pushes a brick update, or even has a good reason to believe it'll brick it, there's all kinds of justification for a claim.
Unlocking phones is something that is explicitly legal in the US - there's even a DMCA exemption for it. There's absolutely no legal justification for doing this.
Furthermore, Apple got their money, and so did AT&T - you can't buy an iPhone without a contract, so everyone with an unlocked phone already paid everyone involved. There's no moral justification for doing this either. Apple is getting arrogant in its success, and it's making the same old "lock everything down" mistakes that led to it being destroyed by the PC.
The people who have iPhones right now are, by and large, Apples best customers. They're early adopters, who love shiny gadgets and who are willing to pay a premium to get the latest thing right away. They're the bread and butter of Apples product line. They don't give a damn about AT&T, though, and bricking their phone in an attempt to force people to stay with them would be a huge mistake.
So you are saying that "retain" can't possibly be understood as to apply to the redistributed (supposedly modified and thus "derived") source, and thus imply a requirement for the derived work to use the same license?
No, because that's not what it says. Requiring that the notice remain intact is *not* the same as requiring that the rights be preserved. Note that it allows distribution "with modification". Since it places no limits on the license of a derived work, and the copyright of a derived work resides with the creator of the new work, there is no requirement that you apply the BSD license to the work, only that you retain the notice intact. The notice (and the rights it grants) apply only to the non-derived parts of the new work. Note that taking your viewpoint literally (since it has to retain a copyright notice) would mean that you'd have to gift your copyright to whoever the original author was, because it says (c) Original Author right at the top of the file.
I'm probably speaking with a little more certainty than is merited, but to my knowledge (I'm not a lawyer) my view is the common interpretation and where there is ambiguity intention and common interpretation do have legal weight, so there is some reason to believe that a court would agree.
But it does say "Redistributions of source code must retain (the license)".
It says it must retain *the text*, not the rights. Now, if you're distributing unmodified BSD source you have no copyright at all, so you can't prevent someone from exercising the rights granted by the license, but if you're distributing a derived work you can apply whatever license you want to the new work. The BSD rights don't apply to any of your parts of your derived work, and they don't apply to the derived work as a whole, only to the old parts (and, as a practical matter, only to the extent that they can be separated out).
And if it doesn't include modified source, then the license only grants redistribution of unmodified source, quite pointless.
Much less pointless than you'd think. This right, and the similar one granted by all OSS licenses is crucial to the working of open source infrastructure such as public SVN repositories and download mirrors.
But the terms of B say that you have the additional right, and that redistributed work should have license B (with that right.) How can that be compatible with G?
You weren't explicit about the right carrying onto derived works. This is why the GPL is carefully explicit, and why it states that if there is some other contraint (a patent claim or other contract or something) that conflicts with your GPL obligations, then you lose the right to distribute that the GPL grants.
I am sorry, but I still don't get it. How can the GPL get away with requiring derived works to be GPL'ed, then?
Lets take a step back for a moment. One of the rights reserved to copyright holders is the right to create derived works. Exactly what defines a derived work is extremely fuzzy - it's not well defined by law, and lots and lots of lawsuits rest on trying to find out whether it's a real derived work or not.
When you create a derived work, the copyright for that work belongs to you, not to the author of whatever you're deriving. So if you have permission to create a derived work, you can give that derived work whatever license you want, unless the license states differently.
Both the BSD and the GPL license give you permission to create a derived work. The BSD license requires few limitations - the BSD license has to stay on the original files, and in some version you have to provide attribution. However, there's no limitation on the license *of the derived work*. This is why you can mix BSD code with GPL code to create a new derived work, and why you can use BSD code as the basis for your closed-source application. Thus, the BSD license can be *effectively* superseded by the creator of a derived work, although the BSD license can't be removed from the original BSD code by anyone except the copyright holder.
The GPL, though, requires that your derived work also be under the GPL, so you can't do those things and the GPL can't be superseded by the license on a derived work - it's explicitly designed to not allow you to do that. This is why the old style BSD license with the attribution clause isn't GPL-compatible - the BSD license requires you to provide attribution to the author of the BSD code in any derived work, and that's an additional restriction that the GPL doesn't permit. So if you have to obey both an old-style BSD license, and the GPL (either because of a "double" license, or because you're mixing two projects with the two licenses), you can't legally distribute this derived work - you have two mutually incompatible obligations to meet.
If a new combined license is formed from B and G, then what rights does it grant? And under which conditions? Can a combined license be formed at all?
In your "hypothetical" example, the two licenses are identical except that G provides one less right than B does. Therefore, a combined license is effectively equivalent to G.
What would be the point of this requirement, if not the implication that the same license applies to the modified and/or redistributed file? Then how can you say it doesn't say that it doesn't
Because the distribution of derived works (that is, modified files) is a very different thing that the distribution of the original files verbatim. In a derived work, while the BSD notice must remain, the BSD license applies only to the original BSD licensed code, not to the derived work as a whole. This effectively allows you co-op BSD code by using as a basis for your own works and then distributing your derived work under a different license. This, of course, is half the point of the BSD license and is the activity which the GPL forbids. You could still extract the BSD code from such a derived work, of course, but the work as a whole certainly isn't under the BSD license.
As long as the BSD notice is intact, the file IS licensed under the BSD license!
Trivially untrue. The BSD notice can remain intact while not applying to the entire file.
My "theory" is that if you try to license your work with a dual license, and forget to grant the right to relicense under either of the licenses, IOW delete the other, then your licensee has no choice but to redistribute it with the entire dual license.
I'm not sure how you can "forget" this. If you just include the text of both licenses verbatim, the conservative assumption would be that both licenses apply. So yes, both licenses would have to be there because you have to obey *all* conditions of *both* licenses. In many cases this would make it illegal to distribute the file under any terms, like an attribution-required BSD + GPL license.
Whether the copyright owner actually intended to allow such relicensing doesn't matter, if he didn't explicitly allow it, my bet is it's just not allowed.
Intent of the copyright holder is actually of crucial importance. Firstly as a practical matter, because only the copyright holder has standing to bring a claim, and if it's not a violation of their intent then the specific legalities aren't relevant. Secondly, if some successor in interest decides to bring a suit over the ambiguities, the intent of the original author is certainly admissible evidence as to the extent of the license. It's certainly not ironclad (which is why being unambiguous is good, and why just stating "public domain" isn't), but the intent of the author is absolutely relevant.
Tools like VA actually tend to encourage spelling mistakes in some (many?) cases because when you spell it wrong the first time, VA (and other code completion tools) will faithfully repeat the mistake all the places where you use it.
What GP is saying is not some "legal theory"; it's copyright law.
The term "legal theory" means your interpretation of which laws are applicable and how they apply. When I ask for it, I'm asking for an explanation (and preferably a citation) of how copyright law supports the position, not a blanket assertion. The OPs claim does not mesh with my understand or interpretation of copyright law, so if we're just going to toss claims back and forth I can just response with "no, copyright law doesn't say that". I want his reasoning, not his claim.
The BSD license says that a modified source file must be redistributed *as BSD*.
The BSD license doesn't say this. If it did, it'd be (essentially) the GPL. The BSD license allows to create derived works, and to distribute those derived works under any license you want, so long as the BSD notice and copyright stay on the source files (and attribution clause, for those versions of the BSD license). This is why you can use BSD code in closed source projects.
So it is simply not within the rights obtained through the license to apply GPL to the changed file. NO CAN DO! Please note that I am talking here about the generic case of software initially released as BSD, addressing the misconception that you can "close", "GPL" or "render unfree" BSD licensed code. Only the original authors can do so, and already distributed copies remain distributable under the original conditions.
You can't change the BSD license on the original code, but if you make (sufficient) modifications, or if you distribute the BSD source as part of a derived work under a different license, you end up doing (almost) what Theo is describing - it's under *both* licenses and since almost any license is more restrictive than BSD, it's effectively under the second license.
Obviously anyone doing this doesn't have any effect on original source files from any other source (especially the original source), which remain BSD.
Of course, the copyright owner could grant the licensee the right to redefine the license, so that a licensee could redistribute with a different license - IOW relicense it - but I hope that a permission to relicense like that would have to be explicit in the license.
I am actually not sure of this. Remember that licenses are not an explicit copyright - the right to issue a license is based on the fact that someone wants to do something covered by copyright, and you can set whatever terms you wish for that. Given that, if you permit someone to redistribute I don't believe that there are any restrictions on *how* they redistribute except for the ones you spell out in the license. So the BSD license permits redistribution under another license so long as the BSD notice remains intact. This starts to get into very fine points of low, and I'm not a lawyer and I don't believe there's really any definitive case law here. It might even be questionable whether or not the BSD license, which must remain intact, must actually *apply*, even to source distributions. The GPL explicitly sets certain rights that must be preserved, not just the license text, so it's a little more robust in this regard.
If the original author's license conditions are simply "BSD or GPL", then this is a composite license which must be retained on any copy, including the choice.
What's the theory behind this? It certainly seems to preclude actually *using* the dual nature of the licenses, since if you must retain the choice then you can't effectively license derived works under GPL only. A license which you don't accept (since you have all the rights you need under an alternative license) has no legal force, so I don't see how the individual "this license must remain intact" notices can possibly be construed to both licenses. This is made all the more moot by the fact that the original author has confirmed that his intention was either BSD or GPL, not any sort of composite license, of course.
What so many people inexplicably seem to fail to understand is, that BSD source, when redistributed as source, has the same "stickyness" as GPL code
Care to explain your legal theory for this? The BSD license must remain, but it can be superseded by another license. If you modify BSD source, and you make your modifications GPL, the entire file is effectively GPL.
However, that's not what happened here. The original source files were, by the original author, under a *dual* GPL/BSD license. They were accepted and modified under the terms of the GPL, not the BSD license, and there's nothing about removing non-legally binding text that happens to look like a BSD license in the GPL. (I'm not 100% sure that all the files were dual licensed. If some of them were single license BSD, then obviously removing the license and placing them under the GPL is wrong).
Theo is claiming that since the BSD license prevents removal of its text, and the GPL license prevents removal of its text, that means you can't remove either of them. This is nonsense on it's face - if it were true, you would also have to comply with all the other provisions of both licenses, which is clearly not the intention and wouldn't even be possible in many cases.
It's true that the person themselves has no mechanism to force payment, but that's just true in general - if someone owes you money and won't give it to you, you have to petition the court for redress. The court has the power to enforce the judgment, up to and including having officers of the court forcefully seize property to auction and even piercing the corporate shield and finding the corporate officers in contempt and jailing them. It would require a blatantly, outright corrupted judge to refuse to enforce the ruling (you could possibly petition a superior court in that case) and they never would have won the judgment in first case if the judge was that corrupt and that willing to show it.
I don't believe that you have any requirement to communicate with someone who owes you a judgment at all, much less prove that you did. It's their obligation to pay, and to prove that they paid to the court. The legal document that needs to be sent certified mail is the complaint they're placing before the judge (and I'm sure it was), not the request for information that was sent via email.
I don't agree with most of his reasoning (I can see how it makes sense from a business perspective, but I think it's unethical) but the "arms race" metaphor is totally off base. He doesn't think we would have sophisticated worms and viruses today if we didn't have AV software, and he's probably right - but it's because the simplistic ones *would do the job just fine*. The amount of virus writers who wouldn't bother because there was no challenge would make no difference, because there'd be plenty of traffic from the guys who write them because they get paid money for botnets.
In fact, by the logic in the article, and implementation of any decryption system which does not involve a central copyright authority is a DMCA violation. Unless the program can extract keys from players automatically (which I don't believe it can) they don't have a leg to stand on and they're strongarming. If it can scan memory for things that look like keys automatically (so it becomes a "one stop shop" for copying) then things are hazier.
A) Use of Glider is a violation of the TOS.
B) The creators of Glider actively promote it's use (by selling and marketing it).
C) People who use Glider have their accounts banned for TOS violation, which harms blizzard financially.
That looks like enough to get the case into court to me. Your arguments are a combination of "it's the users choice", which ignores the very existence of this category of law, and "another one will pop up anyway", which misses the point entirely - suing bot creators is how Blizzard is attempting to keep these bots down to a minimal level.
Nobody is blaming every problem that exists in Linux on Microsoft. However, in this context, it is reasonable to do so because every single problem listed in TFA, and by the OP that I responded to, had to to do interaction between Linux applications and MS ones.
And for the record, I have personally seen and experience bugs just as bad, and worse, in Windows itself and in Microsoft products. One of my favorite ones is in SourceSafe, which handles running out of disk space by silently corrupting the repository. This was never fixed in any SourceSafe patch, and exists in the product to this day (although it has recently been superseded by Team... whatever MS calls it).
Your "dramatized" response is unwarranted, I'd say - a manager who received such a response would be justified in decided that support was insufficient and not using the product. Of course, people are willing to accept such "put offs" from Microsoft, so he might just live with it after all, at least if he had the emotional "comfort blanket" he has with Windows.
For example, the MS response to the bug above is "don't run out of disk space" and a common response to IE bugs is "don't click on hyperlinks".
But what you're describing is something totally different than the case in the article. If the problem were, say, that you can't authenticate against a PDC running Windows Server 2003, the Samba team would be perfectly justified in saying that, while they did what they could, they don't have enough information to fix it.
So by that logic, anything wrong that happens to me while I'm using my computer is my fault because I'm not properly ready for the idiosyncrasies of whatever OS I'm using?
I don't think I'm the one being defensive here. It's your (and I'm using "your" in a general sense of "your organization" here) fault for entering into a proprietary relationship with a specific vendor, and then placing blame on a third party for not giving you an escape hatch. It's like complaining that PCs aren't ready because they won't run your CICS applications. The PC platform is just fine. *You* aren't ready for it, because you aren't willing to leave behind an incompatible system.
Windows users just want to use Windows because they can get stuff done.
That's a total fabrication. *Most* Windows users use it because externalities push them in that direction - you have to go out of your way to by a non-Windows computer (even a Mac), and most corporate environments use Windows. They don't use it out of conscious choice, they use it because it's the default solution presented to them. "Just getting stuff done" has nothing to do with it.
Regardless, the "just use the default" user isn't even a topic in this conversation - you're making it because you're going to try to tread old, weary ground that "Linux makes you work to hard".
we should all be happy to occasionally open a terminal window and type a bunch of arcane gibberish to make something work
And oh look, here it is. This has been raised and refuted more times than I even know how to count. People prefer Windows because it's familiar, end of story. Normal use of a modern (even 5 years old) Linux system will rarely require use of the command line, any more than Windows does. Actual administration by skilled sysadmins is a totally different arena and there's just as much arcane shit and config files and command lines to use in Windows.
Linux users fight like dogs to try to prove the mettle and superiority of their OSes and interfaces and have ready excuses for stuff that doesn't work as expected (or intended or promised).
(Yes, I know I'm quoting out of order). Firstly, those are both subjective statements, and people coming from an all-Windows environment often have unrealistic and just plain stupid requirements. Like "my Linux machine should seamlessly work with Exchange". If you actually want this to happen, you need to talk to the vendor who is holding up the interoperability, and that would be Microsoft. Secondly, Linux is not Windows. People expect things to work the same, to be in the same location, and to be labeled identically. That is stupid, sloppy thinking and you deserve to be castigated for it. There are real, legitimate usability issues with Linux. They are addressed the same way they are in any OS, which is to say that it varies with how and who they are reported by, with who is responsible for fixing them, and by how much the person responsible cares.
In summary: You, again, like many Windows apologists, are placing a higher burden on Linux than you ever have on Windows. You excuse laziness and ill will by saying that a group of unpaid volunteers should rescue you from both. Windows is "easier" primarily because it's common. It's a path of least resistance. If you're going to go down that path, I'm not going to say your wrong - it might make very good sense for you. But don't blame anyone else for it being any easier to switch away. If you (or whoever your IT manager was) hadn't decided to convert to an all-MS shop 10 years ago, it wouldn't be hard for you to switch. You're the seed of your own problem. Linux is ready, and has been ready. You, with the aid of Microsoft (who essentially owns your organization), are the ones placing barriers in the way. Don't blame Linux because you won't climb your own walls. All you have to do is be honest with yourself.
The FA could have been written as "I wanted to use Linux but resistance to interoperability and change from outside prevented
It's not an "attitude". We all know that MS interoperability is key for Linux adoption in a corporate environment, because the corporate world sucks on the MS teat like a baby cow. Microsoft, and other vendors, *actively* work to prevent this interoperability. It's worth nothing that nothing, not one thing, in this article, or your sloppy rant, is about a usability problem with *Linux*.
When you've got a vendor who actively works to prevent you from interoperating with a different vendor, who is "at fault" here? Everything that you're bitching about not working was reverse engineered, from scratch, at an enormous cost in resources and ingenuity. The fact that it works at all is a massive testament to the power of the open source development model. It could be seamless. It could work much better than Windows works with itself. But there is active, continuing work done by Microsoft to prevent it.
So don't pull your snout out of the MS trough and gasp out between stuffing your face with proprietary, locked in interfaces that "Linux isn't ready". Linux is *perfectly* ready. You're the one who isn't ready, and your Microsoft owners won't let you be.
I think you have a severe problem here. Your problem is that you think that you get to decide for other people what spam is.
Any messages I get, that I don't want to see ever again, get marked as spam. I don't give a damn if you like it or not. It's my inbox, not yours, and I'll run it and mark stuff however I want. If I don't like your email, you can be damn sure I don't give a shit about your opinion, or about your desire to send email to anyone else.
But this brings up the crux of the problem: should companies assume that any IP in a dynamic range is a spammer email?
My email server, my rules. Anyone who has a legitimate internet presence has access to a correctly configured mail server in a static IP block. I'm surprised you didn't run into it before, actually, because blackholes for dynamic IP blocks are very common.
You don't have to own your own netblock, you just have to have an IP in a range that isn't marked for dynamic addresses. That's what the "business level" DSL and hosting services your ISP provides are for. If you are in such a block, send your email via your ISPs mail server. That's what it is for. You don't need to receive email that way, only send it. If you're smaller than "small business", like a couple guys working out of an apartment, trying to look bigger, then you need to be aware of stuff like this. If you really are a small manufacturer, get better hosting.
I'd go ahead and guess that Torvalds has a comprehensive, in depth knowledge of the Kernel
I wouldn't, and I'm pretty sure he'd agree with me. Torvalds, and most of his lieutenants, probably have comprehensive overviews, and in depth knowledge of several subsystems and parts of the kernel, but I seriously doubt that any one of them will claim to be an expert on all parts. And RMS might have had a comprehensive knowledge of the userland 15 years ago, but I bet he doesn't now. And certainly neither of them have comprehensive knowledge of *both*.
The contention of the OP was that with an open system, you can know everything that runs on your computer and thus are assured that it's nothing "bad". I think that's overstating the case to the point of inaccuracy, because it's just too much code. There's no reasonable way that a single person can evaluate that much. Especially on a running system, which, even if you made the effort, would be updated faster than you could audit it.
There are definite benefits to an open system, but the security of the system, as with all systems, is largely built on trust. It's just a matter of who you trust and how much.
If, on the other hand, you believe that the child did understand the consequences of his or her action, and was mature enough to understand that what they did was wrong and criminal, there's no reason they shouldn't be tried as an adult.
Criminal cases are the *only* circumstance where we allow "after the fact" recognition of children as adults. There's emancipation of minors, but you can't retroactively emancipate yourself or someone else. This is inconsistent and hypocritical.
I use statutory rape as an example because, by definition, statutory rape is consensual sex with a sexually mature partner. If you can, after committing a crime, be judged to understand the consequences of your action and mature enough to understand that what you did was wrong and criminal, then there is no reason why you can't make those same decisions about your sexual activity.
I've never heard anyone, not even serious far-out libertarian gun toting militants, suggest that parents installing censorware on their home computer was ever a violation of anyones rights. Things like the (now defunct, and somewhat infamous) censorware project were about extending your rights, as a parent, to know just what the software on your machine was blocking.
Outcries against censorware in Slashdot are almost universally about government mandated use of it, and/or it's use on public or semi-public computers, such as library machines.
Now, theres lots of reasons not to bother with censorware. One of them is that using it as a crutch instead of communicating and monitoring your child is poor parenting. But using it as a tool to assist you isn't any more a violation of anyones rights than putting a cover on the pool when you have a toddler is.
As an aside, because I don't feel like making a second post:
More children are victimized by their parents every day than have ever been attacked by someone they met through MySpace.
The bill doesn't state how to check if someone is a minor. That's because it's impossible, and the people writing it know it's impossible, and this is stupid political grandstanding.
As long as statutory rape is a crime, then the state has no business treating children as adults with adult responsibility in any area. This includes trying a minor as an adult just because they did a very bad thing, or even a thing which wasn't unusually bad but happened to get a lot of media attention.
OP was right. You don't know, and you can't know. The more open your platform, the more you *can* know, but it's not even possible in theory, much less in practice - a complete Linux environment is 10s of millions of LOC and you couldn't reasonably audit all that even if thats all you did.
I doubt that theres a single person who can realistically claim a comprehensive, in depth knowledge of all parts of the Linux kernel, much less the entire GNU userland, much less any of the dozens of programs that you'd need to do any real work. You don't even have to bring X or graphical environments into it.
And that's totally aside from more esoteric trust issues like trusting your compiler, and your bios, and your CPU, and the firmware in all your devices.
Wikipedia has a "no original research" policy - it's intended to model the encyclopedia, not to be an authoritative source on its own. Even articles written by experts should cite other sources (you don't become an expert in a vacuum - you learned from something, and things you discovered yourself should be published somewhere). So there should never be a case where you cite Wikipedia, any more than any other encyclopedia, directly. The summary (I confess I haven't RTFA yet) makes it sound like they're approaching it from the direction that wikipedia is too inaccurate to be a trusted source and that they thought about banning it entirely, which means that while this may be the right action they did it for totally the wrong reason.
Slashdot Mirror
Unlocking phones is something that is explicitly legal in the US - there's even a DMCA exemption for it. There's absolutely no legal justification for doing this.
Furthermore, Apple got their money, and so did AT&T - you can't buy an iPhone without a contract, so everyone with an unlocked phone already paid everyone involved. There's no moral justification for doing this either. Apple is getting arrogant in its success, and it's making the same old "lock everything down" mistakes that led to it being destroyed by the PC.
The people who have iPhones right now are, by and large, Apples best customers. They're early adopters, who love shiny gadgets and who are willing to pay a premium to get the latest thing right away. They're the bread and butter of Apples product line. They don't give a damn about AT&T, though, and bricking their phone in an attempt to force people to stay with them would be a huge mistake.
I'm probably speaking with a little more certainty than is merited, but to my knowledge (I'm not a lawyer) my view is the common interpretation and where there is ambiguity intention and common interpretation do have legal weight, so there is some reason to believe that a court would agree.
It says it must retain *the text*, not the rights. Now, if you're distributing unmodified BSD source you have no copyright at all, so you can't prevent someone from exercising the rights granted by the license, but if you're distributing a derived work you can apply whatever license you want to the new work. The BSD rights don't apply to any of your parts of your derived work, and they don't apply to the derived work as a whole, only to the old parts (and, as a practical matter, only to the extent that they can be separated out). Much less pointless than you'd think. This right, and the similar one granted by all OSS licenses is crucial to the working of open source infrastructure such as public SVN repositories and download mirrors. You weren't explicit about the right carrying onto derived works. This is why the GPL is carefully explicit, and why it states that if there is some other contraint (a patent claim or other contract or something) that conflicts with your GPL obligations, then you lose the right to distribute that the GPL grants.When you create a derived work, the copyright for that work belongs to you, not to the author of whatever you're deriving. So if you have permission to create a derived work, you can give that derived work whatever license you want, unless the license states differently.
Both the BSD and the GPL license give you permission to create a derived work. The BSD license requires few limitations - the BSD license has to stay on the original files, and in some version you have to provide attribution. However, there's no limitation on the license *of the derived work*. This is why you can mix BSD code with GPL code to create a new derived work, and why you can use BSD code as the basis for your closed-source application. Thus, the BSD license can be *effectively* superseded by the creator of a derived work, although the BSD license can't be removed from the original BSD code by anyone except the copyright holder.
The GPL, though, requires that your derived work also be under the GPL, so you can't do those things and the GPL can't be superseded by the license on a derived work - it's explicitly designed to not allow you to do that. This is why the old style BSD license with the attribution clause isn't GPL-compatible - the BSD license requires you to provide attribution to the author of the BSD code in any derived work, and that's an additional restriction that the GPL doesn't permit. So if you have to obey both an old-style BSD license, and the GPL (either because of a "double" license, or because you're mixing two projects with the two licenses), you can't legally distribute this derived work - you have two mutually incompatible obligations to meet.
In your "hypothetical" example, the two licenses are identical except that G provides one less right than B does. Therefore, a combined license is effectively equivalent to G.Tools like VA actually tend to encourage spelling mistakes in some (many?) cases because when you spell it wrong the first time, VA (and other code completion tools) will faithfully repeat the mistake all the places where you use it.
The BSD license doesn't say this. If it did, it'd be (essentially) the GPL. The BSD license allows to create derived works, and to distribute those derived works under any license you want, so long as the BSD notice and copyright stay on the source files (and attribution clause, for those versions of the BSD license). This is why you can use BSD code in closed source projects.
You can't change the BSD license on the original code, but if you make (sufficient) modifications, or if you distribute the BSD source as part of a derived work under a different license, you end up doing (almost) what Theo is describing - it's under *both* licenses and since almost any license is more restrictive than BSD, it's effectively under the second license. Obviously anyone doing this doesn't have any effect on original source files from any other source (especially the original source), which remain BSD. I am actually not sure of this. Remember that licenses are not an explicit copyright - the right to issue a license is based on the fact that someone wants to do something covered by copyright, and you can set whatever terms you wish for that. Given that, if you permit someone to redistribute I don't believe that there are any restrictions on *how* they redistribute except for the ones you spell out in the license. So the BSD license permits redistribution under another license so long as the BSD notice remains intact. This starts to get into very fine points of low, and I'm not a lawyer and I don't believe there's really any definitive case law here. It might even be questionable whether or not the BSD license, which must remain intact, must actually *apply*, even to source distributions. The GPL explicitly sets certain rights that must be preserved, not just the license text, so it's a little more robust in this regard. What's the theory behind this? It certainly seems to preclude actually *using* the dual nature of the licenses, since if you must retain the choice then you can't effectively license derived works under GPL only. A license which you don't accept (since you have all the rights you need under an alternative license) has no legal force, so I don't see how the individual "this license must remain intact" notices can possibly be construed to both licenses. This is made all the more moot by the fact that the original author has confirmed that his intention was either BSD or GPL, not any sort of composite license, of course.Care to explain your legal theory for this? The BSD license must remain, but it can be superseded by another license. If you modify BSD source, and you make your modifications GPL, the entire file is effectively GPL.
However, that's not what happened here. The original source files were, by the original author, under a *dual* GPL/BSD license. They were accepted and modified under the terms of the GPL, not the BSD license, and there's nothing about removing non-legally binding text that happens to look like a BSD license in the GPL. (I'm not 100% sure that all the files were dual licensed. If some of them were single license BSD, then obviously removing the license and placing them under the GPL is wrong).
Theo is claiming that since the BSD license prevents removal of its text, and the GPL license prevents removal of its text, that means you can't remove either of them. This is nonsense on it's face - if it were true, you would also have to comply with all the other provisions of both licenses, which is clearly not the intention and wouldn't even be possible in many cases.
It's true that the person themselves has no mechanism to force payment, but that's just true in general - if someone owes you money and won't give it to you, you have to petition the court for redress. The court has the power to enforce the judgment, up to and including having officers of the court forcefully seize property to auction and even piercing the corporate shield and finding the corporate officers in contempt and jailing them. It would require a blatantly, outright corrupted judge to refuse to enforce the ruling (you could possibly petition a superior court in that case) and they never would have won the judgment in first case if the judge was that corrupt and that willing to show it.
I don't believe that you have any requirement to communicate with someone who owes you a judgment at all, much less prove that you did. It's their obligation to pay, and to prove that they paid to the court. The legal document that needs to be sent certified mail is the complaint they're placing before the judge (and I'm sure it was), not the request for information that was sent via email.
I don't agree with most of his reasoning (I can see how it makes sense from a business perspective, but I think it's unethical) but the "arms race" metaphor is totally off base. He doesn't think we would have sophisticated worms and viruses today if we didn't have AV software, and he's probably right - but it's because the simplistic ones *would do the job just fine*. The amount of virus writers who wouldn't bother because there was no challenge would make no difference, because there'd be plenty of traffic from the guys who write them because they get paid money for botnets.
In fact, by the logic in the article, and implementation of any decryption system which does not involve a central copyright authority is a DMCA violation. Unless the program can extract keys from players automatically (which I don't believe it can) they don't have a leg to stand on and they're strongarming. If it can scan memory for things that look like keys automatically (so it becomes a "one stop shop" for copying) then things are hazier.
A) Use of Glider is a violation of the TOS.
B) The creators of Glider actively promote it's use (by selling and marketing it). C) People who use Glider have their accounts banned for TOS violation, which harms blizzard financially.
That looks like enough to get the case into court to me. Your arguments are a combination of "it's the users choice", which ignores the very existence of this category of law, and "another one will pop up anyway", which misses the point entirely - suing bot creators is how Blizzard is attempting to keep these bots down to a minimal level.
And for the record, I have personally seen and experience bugs just as bad, and worse, in Windows itself and in Microsoft products. One of my favorite ones is in SourceSafe, which handles running out of disk space by silently corrupting the repository. This was never fixed in any SourceSafe patch, and exists in the product to this day (although it has recently been superseded by Team... whatever MS calls it).
Your "dramatized" response is unwarranted, I'd say - a manager who received such a response would be justified in decided that support was insufficient and not using the product. Of course, people are willing to accept such "put offs" from Microsoft, so he might just live with it after all, at least if he had the emotional "comfort blanket" he has with Windows. For example, the MS response to the bug above is "don't run out of disk space" and a common response to IE bugs is "don't click on hyperlinks".
But what you're describing is something totally different than the case in the article. If the problem were, say, that you can't authenticate against a PDC running Windows Server 2003, the Samba team would be perfectly justified in saying that, while they did what they could, they don't have enough information to fix it.
I don't think I'm the one being defensive here. It's your (and I'm using "your" in a general sense of "your organization" here) fault for entering into a proprietary relationship with a specific vendor, and then placing blame on a third party for not giving you an escape hatch. It's like complaining that PCs aren't ready because they won't run your CICS applications. The PC platform is just fine. *You* aren't ready for it, because you aren't willing to leave behind an incompatible system.
Windows users just want to use Windows because they can get stuff done.
That's a total fabrication. *Most* Windows users use it because externalities push them in that direction - you have to go out of your way to by a non-Windows computer (even a Mac), and most corporate environments use Windows. They don't use it out of conscious choice, they use it because it's the default solution presented to them. "Just getting stuff done" has nothing to do with it.
Regardless, the "just use the default" user isn't even a topic in this conversation - you're making it because you're going to try to tread old, weary ground that "Linux makes you work to hard".
we should all be happy to occasionally open a terminal window and type a bunch of arcane gibberish to make something work
And oh look, here it is. This has been raised and refuted more times than I even know how to count. People prefer Windows because it's familiar, end of story. Normal use of a modern (even 5 years old) Linux system will rarely require use of the command line, any more than Windows does. Actual administration by skilled sysadmins is a totally different arena and there's just as much arcane shit and config files and command lines to use in Windows.
Linux users fight like dogs to try to prove the mettle and superiority of their OSes and interfaces and have ready excuses for stuff that doesn't work as expected (or intended or promised).
(Yes, I know I'm quoting out of order). Firstly, those are both subjective statements, and people coming from an all-Windows environment often have unrealistic and just plain stupid requirements. Like "my Linux machine should seamlessly work with Exchange". If you actually want this to happen, you need to talk to the vendor who is holding up the interoperability, and that would be Microsoft. Secondly, Linux is not Windows. People expect things to work the same, to be in the same location, and to be labeled identically. That is stupid, sloppy thinking and you deserve to be castigated for it. There are real, legitimate usability issues with Linux. They are addressed the same way they are in any OS, which is to say that it varies with how and who they are reported by, with who is responsible for fixing them, and by how much the person responsible cares.
In summary: You, again, like many Windows apologists, are placing a higher burden on Linux than you ever have on Windows. You excuse laziness and ill will by saying that a group of unpaid volunteers should rescue you from both. Windows is "easier" primarily because it's common. It's a path of least resistance. If you're going to go down that path, I'm not going to say your wrong - it might make very good sense for you. But don't blame anyone else for it being any easier to switch away. If you (or whoever your IT manager was) hadn't decided to convert to an all-MS shop 10 years ago, it wouldn't be hard for you to switch. You're the seed of your own problem. Linux is ready, and has been ready. You, with the aid of Microsoft (who essentially owns your organization), are the ones placing barriers in the way. Don't blame Linux because you won't climb your own walls. All you have to do is be honest with yourself.
The FA could have been written as "I wanted to use Linux but resistance to interoperability and change from outside prevented
When you've got a vendor who actively works to prevent you from interoperating with a different vendor, who is "at fault" here? Everything that you're bitching about not working was reverse engineered, from scratch, at an enormous cost in resources and ingenuity. The fact that it works at all is a massive testament to the power of the open source development model. It could be seamless. It could work much better than Windows works with itself. But there is active, continuing work done by Microsoft to prevent it.
So don't pull your snout out of the MS trough and gasp out between stuffing your face with proprietary, locked in interfaces that "Linux isn't ready". Linux is *perfectly* ready. You're the one who isn't ready, and your Microsoft owners won't let you be.
Any messages I get, that I don't want to see ever again, get marked as spam. I don't give a damn if you like it or not. It's my inbox, not yours, and I'll run it and mark stuff however I want. If I don't like your email, you can be damn sure I don't give a shit about your opinion, or about your desire to send email to anyone else.
My email server, my rules. Anyone who has a legitimate internet presence has access to a correctly configured mail server in a static IP block. I'm surprised you didn't run into it before, actually, because blackholes for dynamic IP blocks are very common.
You don't have to own your own netblock, you just have to have an IP in a range that isn't marked for dynamic addresses. That's what the "business level" DSL and hosting services your ISP provides are for. If you are in such a block, send your email via your ISPs mail server. That's what it is for. You don't need to receive email that way, only send it. If you're smaller than "small business", like a couple guys working out of an apartment, trying to look bigger, then you need to be aware of stuff like this. If you really are a small manufacturer, get better hosting.
I wouldn't, and I'm pretty sure he'd agree with me. Torvalds, and most of his lieutenants, probably have comprehensive overviews, and in depth knowledge of several subsystems and parts of the kernel, but I seriously doubt that any one of them will claim to be an expert on all parts. And RMS might have had a comprehensive knowledge of the userland 15 years ago, but I bet he doesn't now. And certainly neither of them have comprehensive knowledge of *both*.
The contention of the OP was that with an open system, you can know everything that runs on your computer and thus are assured that it's nothing "bad". I think that's overstating the case to the point of inaccuracy, because it's just too much code. There's no reasonable way that a single person can evaluate that much. Especially on a running system, which, even if you made the effort, would be updated faster than you could audit it.
There are definite benefits to an open system, but the security of the system, as with all systems, is largely built on trust. It's just a matter of who you trust and how much.
Criminal cases are the *only* circumstance where we allow "after the fact" recognition of children as adults. There's emancipation of minors, but you can't retroactively emancipate yourself or someone else. This is inconsistent and hypocritical.
I use statutory rape as an example because, by definition, statutory rape is consensual sex with a sexually mature partner. If you can, after committing a crime, be judged to understand the consequences of your action and mature enough to understand that what you did was wrong and criminal, then there is no reason why you can't make those same decisions about your sexual activity.
Outcries against censorware in Slashdot are almost universally about government mandated use of it, and/or it's use on public or semi-public computers, such as library machines.
Now, theres lots of reasons not to bother with censorware. One of them is that using it as a crutch instead of communicating and monitoring your child is poor parenting. But using it as a tool to assist you isn't any more a violation of anyones rights than putting a cover on the pool when you have a toddler is.
As an aside, because I don't feel like making a second post:
More children are victimized by their parents every day than have ever been attacked by someone they met through MySpace.
The bill doesn't state how to check if someone is a minor. That's because it's impossible, and the people writing it know it's impossible, and this is stupid political grandstanding.
As long as statutory rape is a crime, then the state has no business treating children as adults with adult responsibility in any area. This includes trying a minor as an adult just because they did a very bad thing, or even a thing which wasn't unusually bad but happened to get a lot of media attention.
I doubt that theres a single person who can realistically claim a comprehensive, in depth knowledge of all parts of the Linux kernel, much less the entire GNU userland, much less any of the dozens of programs that you'd need to do any real work. You don't even have to bring X or graphical environments into it.
And that's totally aside from more esoteric trust issues like trusting your compiler, and your bios, and your CPU, and the firmware in all your devices.
Are you unaware that boars are, by definition, male, or are you implying that male pigs suckle their young?
Wikipedia has a "no original research" policy - it's intended to model the encyclopedia, not to be an authoritative source on its own. Even articles written by experts should cite other sources (you don't become an expert in a vacuum - you learned from something, and things you discovered yourself should be published somewhere). So there should never be a case where you cite Wikipedia, any more than any other encyclopedia, directly. The summary (I confess I haven't RTFA yet) makes it sound like they're approaching it from the direction that wikipedia is too inaccurate to be a trusted source and that they thought about banning it entirely, which means that while this may be the right action they did it for totally the wrong reason.