Could you try to argue the facts or at least logical inferences that might be drawn from what I've said. Did I ever say OSS developers should implement it, no - I've said some might be able to under the licenses they use.
But that isn't true--you cannot have a piece of open source software (i.e., something that meets the definition of open source) that incorporates patented technology that requires developers to execute individual patent licensing agreements with Microsoft.
I don't want nor can I impose anything on OSS developers. I'm not afraid to come out and say anything I believe I just don't happen to believe the words you are trying to stick into my mouth.
It's clear that you feel uncomfortable with when I restate your position in the way I did. What I am saying is that I think your position amounts to that: you think OSS developers should consider incorporating such licenseable technology into their software. You just don't recognize that such a suggestion is pretty much the same as if you said "guys, why don't you consider giving up on this OSS stuff altogether and just develop proprietary software". Your intention may not be to say something so obviously controversial to OSS developers, but that's what it amounts to.
And I believe you when you say that you personally are in a position to impose anything on OSS developers (that's why I said "people like you"). But your view reflects the views that the IETF committee members have stated regarding these kind of licenses, and the IETF is indeed trying to use its clout as a standards body to change the way OSS developers develop software. But, like you, the IETF is apparently unwilling to state clearly that their position is the same as basically telling OSS developers "we don't want you to implement our standards under OSS licenses".
We aren't disagreeing on "sources" or "facts", we are disagreeing on their interpretation and consequences. You cite a bunch of random facts, but you draw unsupportable conclusions from them. Your problem isn't your facts, it's your reasoning from those facts.
9. you did not work for years as a paralegal in a district attorney's office -- I did.
Perhaps your limited ability to reason explains why you were a paralegal rather than becoming a lawyer.
3. you don't respond to specific points of my discourse, but instead cite a part and repeat your argument over and over.
Funny, that's what I think you are doing. Maybe you aren't making your argument clearly enough. What you have said comes down to:
Licenses are only waivers of rights on the part of the licensor.
The GPL is a license.
The GPL applies to the copyrighted work that is being licensed and to its derivative works under copyright.
So far so good. We can completely agree on that if we use the term "license" in a narrow legal sense.
Then you go on to conclude something like:
Therefore, the GPL cannot force you to do anything that does not pertain to the work itself or derivative works under copyright law.
Now, can you explain how the GPL is any different here from, say, a Microsoft EULA? Or are you saying that the MS EULA is unenforceable?
Furthermore, you keep claiming that (I'm paraphrasing):
Contracts under which you can be granted software licenses must be written, signed, and conform to one of a set of standard formats in order to be valid and enforceable.
The GPL cannot be simultaneously a grant of a license and be a legally binding agreement that obligates the licensee to do something that goes beyond their obligations under copyright law.
Even if the license and contractual parts of the GPL were separated, the licensor and the licensee could not reach a legally binding agreement merely through the act of downloading a piece of software from a web site.
That position would make shareware, web-based sales of software, and verbal contracts impossible. Are you saying all of those are unenforceable and invalid? Is much of the US economy built on quicksand?
Your problem isn't a paucity of facts, it is that your arguments based on those facts just don't make any sense. Either you don't understand what you are talking about or you are just incapable of expressing yourself clearly. (And the fact that you are trying to apply concepts from a different legal tradition to the US probably also doesn't help.)
The GPL has been around for decades and it has stood the test of time. It is reasonable to assume that it is legally valid and enforceable, at least in the US. And the GPL 3 will likely impose further restrictions on the licensee, like a requirement to make patents available freely to anybody. You can bet that those requirements will be legally scrutinized extensively by IP experts. But if you want to operate under the assumption that the GPL is legally unenforceable because all it can be, according to you, is a "waiver of rights", go right ahead.
There are other licenses besides FSF. People already appear to be saying that there are license that would be fine Sendmail Open Source License,BSD license,IBM Common Public License amoung them.
Those licenses may be compatible with Microsoft's patent licensing requirement, in the sense that you can put those licenses on a piece of software and also impose a patent licensing requirement. But once you incorporate the patented invention into, say, a piece of BSD-licensed software, the end product is not BSD-licensed anymore, it is covered by a "BSD-license with additional restrictions".
And that's not an academic or semantic distinction: those additional restrictions seriously interfere with day-to-day open source software development.
but I won't dismiss it out of hand on purely religious reasons.
And that's your problem: you dismiss the FSF's concerns as "purely religious reasons". They aren't. The FSF and other OSS community members are concerned about the costs that such license changes impose on their projects and operations, and those costs are high.
It always makes sense to look up to see if the world is passing you by; IE if this type of license is being accepted by the IETF and W3C maybe things are changing and the OSS community should be aware of that.
The OSS community is fully aware of what is happening and that some institutions are trying to go in that direction. Whether that's a good thing for the industry is one question.
But one thing is absolutely clear: software that comes with such restrictions does not meet the definition of open source software and it means that software falling under such restrictions cannot be developed under an open source model anymore. So, if the IETF and the W3C are releasing standards with such licensing requirements, they are saying that they are not interested in open source implementations.
The problem with people like you is that you lack the courage of your own convictions: you think that OSS developers are just a bunch of religious morons that complain too much, yet you are afraid to come out and say that we don't need OSS development. You want the buzz-word value of OSS licenses while imposing non-OSS licenses on developers.
In Brazilian contract law, there is a figure called "formal properties of a valid contract": every contract has a form (i.e., a minimum set of clauses, a set of forbidden clauses, it must be in paper, where should it be signed, some types of contract must be notarized, other types of contract are renewable automatically or not etc) that is defined by law and by law only. This means I can't come up with a new type of contract.
Well, I know nothing about Brazilian contract law, and I don't really care. But in the US, people have considerably more latitude for entering into contracts; for example, you can enter into verbal contracts.
If you voluntarily agree to do something in return for something else, you are a priori legally bound by that agreement. In the case of the GPL, if you agree to make some of your software available under the GPL in return for using someone else's GPL'ed software, you are going to be bound by that agreement if that agreement is legally valid. If a court should rule, against all odds, that the agreement is not legally valid, well, then things will revert to the way they were before the agreement was made: you don't have to license your software under the GPL, but you also lose all licenses you may have had to the GPL'ed software in question.
You seem to be living in some kind of dream world where people give you licenses under certain conditions, you then argue that the conditions are not legally valid, and you think you can keep the license but ignore the conditions. Sorry, but the world doesn't work that way. In fact, entering into legally binding agreements if you already know that will not be honoring your part of the agreement is fraudulent.
Four-year-olds can use GPL'd software, can download and install them from the internet.
Four year olds can also use Dad's credit card to order goods and services over the Internet. Or they can download a pirated copy of MS Word. Or they can upload company secrets from their father's PC to some web site. Their legal guardians are legally responsible for that sort of behavior. If they don't want that to happen, then they have to supervise their kids better.
Of course, in the case of GPL'ed software, there isn't any problem with downloading and installing it anyway because that doesn't trigger any financial or other tangible obligations on anybody's part.
its clauses (the ones that are not void) are enforceable because without claiming you have a waiver of rights in the form of the GPL, you have no authorization to distribute a program or derivative works of it,
The GPL does give you authorization to distribute a program or derivative works, but it requires you to make a payment in order to do so. If you reneg on your payment, you don't have a valid license. That is the same with shareware or commercial software.
For example, if you buy MS Word, pay by check, and your check bounces, you don't actually have a valid license to MS Word because you did not actually fulfill the purchase contract that led to you getting a license to MS Word in the first place.
Your payment for a piece of GPL'ed software is a commitment on your part to cross-license specific software that you hold copyright to. You can copy the GPL'ed software only subject to that condition. If you don't hold up your end of the bargain, you simply have no license to copy (and hence use) the GPL'ed software in the first place.
As far as your last point please I'm not concerned with wether it meet your definition of OSS (Or anyone elses) I am concerned with is it better or worse then license that have already been accepted and are in use in software and protocols around the world.
Well, then you are missing the point. The point is that there is lots of software distributed under OSS licenses, licenses that conform to the official OSS definition. Since Microsoft's licensing terms for this patent are incompatible with the OSS definition, that means that packages that incorporate Microsoft's patented invention cannot be distributed under an OSS license anymore.
So, that means that there are several things that can happen: (1) OSS developers change their licenses to make them compatible with Microsoft's terms, (2) OSS developers challenge or ignore the patent, (3) OSS developers don't use Microsoft's patented invention (they come up with their own system), or (4) OSS developers ignore Microsoft's sub-licensing restrictions and just redistribute the software in source form without executing license agreements.
You seem to think that (1) will happen because Microsoft's terms seem pretty benign to you. I'm telling you, hell will freeze over before people change their OSS licenses to accomodate such licenses--not because they are stubborn, but because it's impractical. (2) would be an option in this case, but it isn't worth it, since the feature that Microsoft patented isn't all that important and since there are non-patented alternatives around.
(4) is a real worry because it would give Microsoft grounds for making claims on OSS projects. But the community is mature and smart enough not to let that happen and all major OSS development portals and organizations are going to see to it that that doesn't happen with software under their control.
So, it will come down to (3): OSS developers will do their own thing and Microsoft will have yet another proprietary feature that works only among a few products in the Microsoft universe. Of course, that's nothing new.
The major effect of this is that people will take the IETF even less seriously than they already do.
A contract is an agreement between two (or +) consenting parties, on their own volition: a license is an unilateral grant, to whom it may concern.
You are confusing two common usages of the term "license". Yes, a "license" is a unilateral grant of rights. But that unilateral grant of rights is usually done in return for some consideration, under a contractual agreement. That contractual agreement is commonly also called a "license" (or "license agreement"), and it imposes obligations on both parties. Those obligations may be of a monetary nature or they may involve obligations to cross-license your software or they may be something completely different.
What GPL and other Free Software licenses try to do is: waive the rights that are protected by copyright law, asking for nothing in return.
The GPL is not asking you to "waive any rights", nor does it even involve any kind of copyright transfer. The GPL is an agreement by two parties over transferable licenses to software to which each party holds copyright.
but then you also can't distribute a derivative work of the GPL'd software. Can you use the GPL'd software? HELL YES. You could use it from the moment you put your hands legally on it. Can you make a derivative work -- without accepting the terms of the GPL? NO -- USC17 protects the copyright holders from you doing it, not the GPL.
You are bound by the terms of the GPL as soon as you copy the GPL'ed software (i.e., its source or binary form) because without agreeing to the GPL, you would be violating copyright law. But the terms that govern your subsequent behavior are a combination of copyright law and the terms of the GPL. Whether you prepare derivative works has nothing to do with it. In fact, if you violate the terms of the GPL, you rights even to using the GPL'ed software in question terminate.
You are required to license your "derivative works" under the GPL not because of copyright law, but because you entered into a legal agreement that you would do so. In fact, the GPL can (and probably does already) define "derivative works" broader than copyright law. The fact that the notion of "derivative works" in the GPL happens to be close to the copyright notion is convenient but not necessary for the GPL to apply. And in future versions of the GPL, the notion of "derivative works" will probably be broadened further. Probably, the next GPL should avoid the term "derivative works" in order to avoid this confusion.
As I said before, this is all well, as long as you're talking about contracts, formally correct, signed and notarized by legally consenting parties, willing to enter the contract.
Well, you may take the position that license agreements like the GPL are not valid contracts because they aren't signed pieces of paper. If that were the case, then your arguments would be right, in the sense that then only the provisions of copyright apply, but I think that's wishful thinking. The prevailing legal opinion, practice, and assumption seems to be that the terms of EULAs and the GPL are valid and enforceable.
I will repeat here the position I have after carefully studying the GPL, copyright law, and case law: the GPL regulates the licensing to derived works of the GPL'd work, but it cannot regulate the licensing of encompassing "anthology" works.
The GPL is a license--i.e., a contract between the licensor and the licensee. Within a few general limitations given by contract law, a license can regulate whatever it wants. The most common thing for a license to do is to regulate the transfer of money from the licensee's pocket into the licensor's pocket.
The GPL happens to regulate what you do with certain other works to which you hold copyright. In particular, if you agree to the GPL for a piece of software to which you don't hold the copyright, you may be forced to accept an obligation of licensing some software to which you hold copyright to others. If you don't want that to happen, you just don't agree to the GPL, but then you also can't use the GPL'ed software.
There is nothing unusual about such agreements and they are certainly valid and enforceable: I give you a limited transferable license for software A if you give me a limited transferable license for software B. Those kinds of agreements exist between many different commercial entities, and if they weren't valid, a lot of companies would be in big trouble.
The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
Clearly, this would be violated if using the source would require execution of a license with Microsoft. That the MARID people don't understand this is just a testament to how naive they are.
The IETF Legal counsel has not to the best of my knowledge published a finding one way or the other.
Well, another example of how out of touch the IETF is; this is something that IETF Legal counsel should have checked during negotiations with Microsoft and before much work was expended on the standard.
As most people on the Net are not lawyers it might actaully be more useful to look at this license in terms of how it compares to other licenses granted the IETF. Is it more or less restrictive?
You're missing the point. The point is that the question of whether the IETF standard will be adopted by OSS is not something that OSS developers have the power to decide or negotiate over (as the parent poster suggested), it doesn't depend on whether the license is "good" or "more restrictive" or "less restrictive", and it doesn't depend on whether Microsoft is making an honest effort or trying to control the world. Whether the IETF standard will be adopted by OSS simply depends on whether the licenses required for the IETF standard are compatible with the definition of OSS. If they aren't, then, by definition, OSS software can't implement it.
Actually, I'd call it nearly useless. And, not surprisingly, it seems to be off out of the box.
There are, in fact, no satisfactory grammar checkers out there.
Until OO.org offers such features, I can't imagine them gaining dominance.
In my experience, most Word users don't even know more than a tiny fraction of the features Word offers--they need a word processor with fewer features, not with more features.
But Word is still a better program for the average user.
Microsoft Works is a better program for the average user than Microsoft Word.
There are a bunch of USB-powered harddisks out there. Several companies offer the 1-4G variety. Freecom offers USB-powered drives with up to 80G capacity, and they have really tiny 20-40G drives.
How many things must something be "compatible" (whatever that means in each context) with before it can be considered "good" considering most of you can't make up your minds about them to begin with?
This isn't a question of "good" or "making up one's mind" or "arguing". The patent licensing requirements are just incompatible with the GPL and other OSS licenses--that's a legal fact. Therefore, IETF SPF can't be fully implemented by OSS--there is nothing to debate or negotiate or decide.
Now, there are two possible consequences: either hundreds of thousands of OSS developers throw away all their existing code (whose licenses they can't change) and start over, or they just don't implement IETF SPF. Which one do you think is more likely to happen?
you'd be giving Microsoft a run for their money by now.
OSS developers generally don't care about Microsoft's money; the only thing they care about is when Microsoft interferes with their ability to develop and use software.
Microsoft is apparently trying to play hard-ball with OSS developers, forcing them to accept some kind of licensing terms or forcing them to stop developing this kind of software. But OSS developers don't have a choice: there simply is no way under which OSS developers can give in to Microsoft's licensing terms, even if they wanted to, since the terms are just fundamentally incompatible with most OSS licenses.
Furthermore, going to IETF with such standards proposals is pointless: the only producers of software that count in this space are Microsoft and OSS. If IETF starts producing standards under terms that are not acceptable to OSS developers, then that just makes the IETF irrelevant but it won't help with adoption of a solution.
In this case, if IETF's SPF standard isn't 100% compatible with OSS licenses, OSS software will not incorporate it and Microsoft Exchange installations will be unable to use IETF SPF with a significant fraction of Internet hosts. If Microsoft were competing with a commercial vendor of mail server software, that vendor would be in deep trouble and it might induce that vendor to come crawling to Microsoft begging for a license. But OSS developers won't do that: OSS projects don't have the same kinds of short-term pressures on them as commercial software vendors, and even if they wanted to give in, OSS licenses make it impossible.
Microsoft's management just doesn't seem to understand that they are not dealing with another business anymore: the strategies that they have used against commercial competitors just don't work against OSS. All they are accomplishing with this sort of behavior is to taint their own credibility and the credibility of the standards bodies they get involved.
Microsoft has a whole lot more leverage to push their own solution. If Microsoft decides that their way is the way to go, they can implement it in all of their product offerings, thus forcing others to follow suit or risk being cut off from the vast majority of the Internet using public.
SPF is not necessary for exchanging electronic mail. If Microsoft servers fail to exchange mail with any significant number of OSS mail servers, the result won't be that OSS gives up and everybody signs patent license agreements with Microsoft, but rather that SPF won't get used. The long term fall-out would be that people would take Microsoft even less seriously when they come to standards bodies, and to hurt IETF credibility even further (IETF is already largely irrelevant).
ReiserFS has a bunch of new features, like the ability to use files as directories. The people who created ReiserFS intend for those features to be used for functionality like ACLs, multiple streams/forks, etc. Those are features that application programs see and access. But if you write software that relies on those ReiserFS features, you won't be able to use that software with any other Linux file system because no other Linux file system supports those features. So, the question is whether software newly written to work specifically with ReiserFS can be backwards compatible with non-ReiserFS file systems. If it can't be, people will be reluctant to use the ReiserFS features. And I'm saying that creation of a user-mode emulation of ReiserFS features would help the adoption of ReiserFS.
The question of whether existing programs are compatible with ReiserFS is a separate question. It is not obvious that they are. For example, if ReiserFS allows "cat > foo/bar" to succeed even when foo is a file, some existing software may start failing. Furthermore, existing UNIX utilities won't work correctly anymore; for example, "cp -a" or a tar pipe won't make full copies of a directory tree anymore.
Plenty of safe, clean language are cool: OCAML, Python, Scheme, etc.
What makes Java uncool is the fact that it is and remains a proprietary language. Also, it is uncool because both the language and the libraries are full of avoidable design flaws; Java's roots as a failed project for a set-top box programming language sadly still show to this day.
But foremost, what makes Java uncool is that it takes forever to get anything done in it: a language does not have to be cumbersome in order to be safe, and forcing programmers to write lots of LOC to get the simplest task accomplished does not make the resulting code more readable.
But whether Java is "cool" doesn't matter as much; what matters is that these problems with Java also get in the way of using Java for real work.
ReiserFS is great, and this seems like a tasteful way of implementing some of the complex things people seem to want to do with file systems.
But I would feel uncomfortable relying on any of these features right now because any software that does would fail with any other file system. ReiserFS is free software, but you still end up needing to run software on other file systems in many cases.
I think for these features to become widely adopted, we need some kind of library-based emulation, something that uses ReiserFS if it runs on it and otherwise emulates ReiserFS features like files-as-directories in user mode on top of existing file systems (by using funny file names, etc., similar to UMSDOS).
It's not "duress" (that's when someone holds a gun to your head), it's merely a form of price fixing. Being the victim of price fixing does not completely and automatically invalidate a contract, although you may have legal recourse, depending on how the legal and legislative winds are blowing. In the current climate, however, price fixing by music distributors seems to be tolerated, so your only choice is civil disobedience.
Faster all around, modular & with atomic commits so you don't lose stuff in case of a power loss!!!
It's not that simple. Support for atomic operations in the file system eliminates a few sources of catastrophic data loss and it enables applications to avoid some other sources of data loss. But you will still lose unsaved data, you may still lose file system changes that haven't been committed, and, unless applications are changed, you will still end up with partially written files if the power fails while an application saves its data.
Aren't these things a violation of the agreement they made when they decided to use the software and download songs?
Where are you going to get music? You can buy the CDs, you can download them from a Windows-based service, or you can download them with iTunes. That is, in reality, you don't have the kind of choice of contracts that you might get in a free market.
So, why are people rebelling and breaking their agreements? Because they feel that those agreements have been forced upon them and therefore feel they are not ethically bound by them (even if there is a small legal risk in doing so).
Why do people have to come up with so uncreative names?
Because those names properly confer the meaning that (1) it is related to iTunes, but (2) it is different from iTunes. And that's exactly why Apple doesn't like it: they don't like the competition, and they are going to try to kill it any way they can, even if that means asserting trademark rights they don't actually have.
The name is lawyerfood, and rightfully so. Xtunes felt the wrath of Apple lawyers
Neither "xtunes" nor "ourTunes" are confusable with "iTunes", therefore there is no trademark violation. The fact that a multi-billion dollar company can successfully intimidate some non-profit open source developers isn't evidence of trademark infringement, it just shows that Apple is still up to their old legal tricks.
So, 900 noisy Apple users complain, as usual; why should they care? What counts is the bottom line: how many songs is Real selling to iPod users. If that works out OK, they'll keep doing it.
... in medicine, and one in physics, and probably one in chemistry, waiting for anyone who can demonstrate a possible mechanism of action for health effects of non-ionizing radiation at athermal levels.
There are plenty of such mechanisms. For example, just about any circuit with a nonlinearity (like most biological cells) near a radio station will pick up a small audio frequency signal. Those signals are strong enough to be audible in stereo equipment, telephones, etc. that aren't well shielded. And low frequency electrical signals definitely have biological effects.
Your problem is that you think of the radio transmitter just as a source of steady, high frequency radiation. That would indeed probably not have any biological effects. But that's not what real-world RF signals are like.
Apple is a design leader, and there's a portion of the PC hardware industry that watches Apple designs and makes knock-offs on the PC side.
Yes, and Apple watches the trends in the PC industry and knocks off their designs. Because they are smaller and more focused than the PC industry, Apple can take an emerging trend, patent it, and then sell gadgets around it.
The question with patents is always: if this patent were not granted, would companies still have the incentive to innovate in this area with the same intensity?
"Innovation" in the area of case modding? Oh, please. Sticking any kind of blinking, computer controled, colorful light inside a case is something teenagers have done for years. In this case, it happens to be a light whose color can be changed. Big deal, you can get those off the shelf.
Look around the web a little for case mods and you'll see that Apple's designs are hardly the most innovative out there, nor even the best.
It's a physical thing. But in order to be a "real invention", it would have to be novel, rather than an obvious, trivial combination of existing elements. Light sources whose color you can tune have been around for decades, and so have been cases with light sources inside them, even light sources under computer control.
Slashdot Mirror
Could you try to argue the facts or at least logical inferences that might be drawn from what I've said. Did I ever say OSS developers should implement it, no - I've said some might be able to under the licenses they use.
But that isn't true--you cannot have a piece of open source software (i.e., something that meets the definition of open source) that incorporates patented technology that requires developers to execute individual patent licensing agreements with Microsoft.
I don't want nor can I impose anything on OSS developers. I'm not afraid to come out and say anything I believe I just don't happen to believe the words you are trying to stick into my mouth.
It's clear that you feel uncomfortable with when I restate your position in the way I did. What I am saying is that I think your position amounts to that: you think OSS developers should consider incorporating such licenseable technology into their software. You just don't recognize that such a suggestion is pretty much the same as if you said "guys, why don't you consider giving up on this OSS stuff altogether and just develop proprietary software". Your intention may not be to say something so obviously controversial to OSS developers, but that's what it amounts to.
And I believe you when you say that you personally are in a position to impose anything on OSS developers (that's why I said "people like you"). But your view reflects the views that the IETF committee members have stated regarding these kind of licenses, and the IETF is indeed trying to use its clout as a standards body to change the way OSS developers develop software. But, like you, the IETF is apparently unwilling to state clearly that their position is the same as basically telling OSS developers "we don't want you to implement our standards under OSS licenses".
We aren't disagreeing on "sources" or "facts", we are disagreeing on their interpretation and consequences. You cite a bunch of random facts, but you draw unsupportable conclusions from them. Your problem isn't your facts, it's your reasoning from those facts.
9. you did not work for years as a paralegal in a district attorney's office -- I did.
Perhaps your limited ability to reason explains why you were a paralegal rather than becoming a lawyer.
3. you don't respond to specific points of my discourse, but instead cite a part and repeat your argument over and over.
Funny, that's what I think you are doing. Maybe you aren't making your argument clearly enough. What you have said comes down to:
So far so good. We can completely agree on that if we use the term "license" in a narrow legal sense.
Then you go on to conclude something like:
Now, can you explain how the GPL is any different here from, say, a Microsoft EULA? Or are you saying that the MS EULA is unenforceable?
Furthermore, you keep claiming that (I'm paraphrasing):
That position would make shareware, web-based sales of software, and verbal contracts impossible. Are you saying all of those are unenforceable and invalid? Is much of the US economy built on quicksand?
Your problem isn't a paucity of facts, it is that your arguments based on those facts just don't make any sense. Either you don't understand what you are talking about or you are just incapable of expressing yourself clearly. (And the fact that you are trying to apply concepts from a different legal tradition to the US probably also doesn't help.)
The GPL has been around for decades and it has stood the test of time. It is reasonable to assume that it is legally valid and enforceable, at least in the US. And the GPL 3 will likely impose further restrictions on the licensee, like a requirement to make patents available freely to anybody. You can bet that those requirements will be legally scrutinized extensively by IP experts. But if you want to operate under the assumption that the GPL is legally unenforceable because all it can be, according to you, is a "waiver of rights", go right ahead.
There are other licenses besides FSF. People already appear to be saying that there are license that would be fine Sendmail Open Source License,BSD license,IBM Common Public License amoung them.
Those licenses may be compatible with Microsoft's patent licensing requirement, in the sense that you can put those licenses on a piece of software and also impose a patent licensing requirement. But once you incorporate the patented invention into, say, a piece of BSD-licensed software, the end product is not BSD-licensed anymore, it is covered by a "BSD-license with additional restrictions".
And that's not an academic or semantic distinction: those additional restrictions seriously interfere with day-to-day open source software development.
but I won't dismiss it out of hand on purely religious reasons.
And that's your problem: you dismiss the FSF's concerns as "purely religious reasons". They aren't. The FSF and other OSS community members are concerned about the costs that such license changes impose on their projects and operations, and those costs are high.
It always makes sense to look up to see if the world is passing you by; IE if this type of license is being accepted by the IETF and W3C maybe things are changing and the OSS community should be aware of that.
The OSS community is fully aware of what is happening and that some institutions are trying to go in that direction. Whether that's a good thing for the industry is one question.
But one thing is absolutely clear: software that comes with such restrictions does not meet the definition of open source software and it means that software falling under such restrictions cannot be developed under an open source model anymore. So, if the IETF and the W3C are releasing standards with such licensing requirements, they are saying that they are not interested in open source implementations.
The problem with people like you is that you lack the courage of your own convictions: you think that OSS developers are just a bunch of religious morons that complain too much, yet you are afraid to come out and say that we don't need OSS development. You want the buzz-word value of OSS licenses while imposing non-OSS licenses on developers.
In Brazilian contract law, there is a figure called "formal properties of a valid contract": every contract has a form (i.e., a minimum set of clauses, a set of forbidden clauses, it must be in paper, where should it be signed, some types of contract must be notarized, other types of contract are renewable automatically or not etc) that is defined by law and by law only. This means I can't come up with a new type of contract.
Well, I know nothing about Brazilian contract law, and I don't really care. But in the US, people have considerably more latitude for entering into contracts; for example, you can enter into verbal contracts.
If you voluntarily agree to do something in return for something else, you are a priori legally bound by that agreement. In the case of the GPL, if you agree to make some of your software available under the GPL in return for using someone else's GPL'ed software, you are going to be bound by that agreement if that agreement is legally valid. If a court should rule, against all odds, that the agreement is not legally valid, well, then things will revert to the way they were before the agreement was made: you don't have to license your software under the GPL, but you also lose all licenses you may have had to the GPL'ed software in question.
You seem to be living in some kind of dream world where people give you licenses under certain conditions, you then argue that the conditions are not legally valid, and you think you can keep the license but ignore the conditions. Sorry, but the world doesn't work that way. In fact, entering into legally binding agreements if you already know that will not be honoring your part of the agreement is fraudulent.
Four-year-olds can use GPL'd software, can download and install them from the internet.
Four year olds can also use Dad's credit card to order goods and services over the Internet. Or they can download a pirated copy of MS Word. Or they can upload company secrets from their father's PC to some web site. Their legal guardians are legally responsible for that sort of behavior. If they don't want that to happen, then they have to supervise their kids better.
Of course, in the case of GPL'ed software, there isn't any problem with downloading and installing it anyway because that doesn't trigger any financial or other tangible obligations on anybody's part.
its clauses (the ones that are not void) are enforceable because without claiming you have a waiver of rights in the form of the GPL, you have no authorization to distribute a program or derivative works of it,
The GPL does give you authorization to distribute a program or derivative works, but it requires you to make a payment in order to do so. If you reneg on your payment, you don't have a valid license. That is the same with shareware or commercial software.
For example, if you buy MS Word, pay by check, and your check bounces, you don't actually have a valid license to MS Word because you did not actually fulfill the purchase contract that led to you getting a license to MS Word in the first place.
Your payment for a piece of GPL'ed software is a commitment on your part to cross-license specific software that you hold copyright to. You can copy the GPL'ed software only subject to that condition. If you don't hold up your end of the bargain, you simply have no license to copy (and hence use) the GPL'ed software in the first place.
As far as your last point please I'm not concerned with wether it meet your definition of OSS (Or anyone elses) I am concerned with is it better or worse then license that have already been accepted and are in use in software and protocols around the world.
Well, then you are missing the point. The point is that there is lots of software distributed under OSS licenses, licenses that conform to the official OSS definition. Since Microsoft's licensing terms for this patent are incompatible with the OSS definition, that means that packages that incorporate Microsoft's patented invention cannot be distributed under an OSS license anymore.
So, that means that there are several things that can happen: (1) OSS developers change their licenses to make them compatible with Microsoft's terms, (2) OSS developers challenge or ignore the patent, (3) OSS developers don't use Microsoft's patented invention (they come up with their own system), or (4) OSS developers ignore Microsoft's sub-licensing restrictions and just redistribute the software in source form without executing license agreements.
You seem to think that (1) will happen because Microsoft's terms seem pretty benign to you. I'm telling you, hell will freeze over before people change their OSS licenses to accomodate such licenses--not because they are stubborn, but because it's impractical. (2) would be an option in this case, but it isn't worth it, since the feature that Microsoft patented isn't all that important and since there are non-patented alternatives around.
(4) is a real worry because it would give Microsoft grounds for making claims on OSS projects. But the community is mature and smart enough not to let that happen and all major OSS development portals and organizations are going to see to it that that doesn't happen with software under their control.
So, it will come down to (3): OSS developers will do their own thing and Microsoft will have yet another proprietary feature that works only among a few products in the Microsoft universe. Of course, that's nothing new.
The major effect of this is that people will take the IETF even less seriously than they already do.
A contract is an agreement between two (or +) consenting parties, on their own volition: a license is an unilateral grant, to whom it may concern.
You are confusing two common usages of the term "license". Yes, a "license" is a unilateral grant of rights. But that unilateral grant of rights is usually done in return for some consideration, under a contractual agreement. That contractual agreement is commonly also called a "license" (or "license agreement"), and it imposes obligations on both parties. Those obligations may be of a monetary nature or they may involve obligations to cross-license your software or they may be something completely different.
What GPL and other Free Software licenses try to do is: waive the rights that are protected by copyright law, asking for nothing in return.
The GPL is not asking you to "waive any rights", nor does it even involve any kind of copyright transfer. The GPL is an agreement by two parties over transferable licenses to software to which each party holds copyright.
but then you also can't distribute a derivative work of the GPL'd software. Can you use the GPL'd software? HELL YES. You could use it from the moment you put your hands legally on it. Can you make a derivative work -- without accepting the terms of the GPL? NO -- USC17 protects the copyright holders from you doing it, not the GPL.
You are bound by the terms of the GPL as soon as you copy the GPL'ed software (i.e., its source or binary form) because without agreeing to the GPL, you would be violating copyright law. But the terms that govern your subsequent behavior are a combination of copyright law and the terms of the GPL. Whether you prepare derivative works has nothing to do with it. In fact, if you violate the terms of the GPL, you rights even to using the GPL'ed software in question terminate.
You are required to license your "derivative works" under the GPL not because of copyright law, but because you entered into a legal agreement that you would do so. In fact, the GPL can (and probably does already) define "derivative works" broader than copyright law. The fact that the notion of "derivative works" in the GPL happens to be close to the copyright notion is convenient but not necessary for the GPL to apply. And in future versions of the GPL, the notion of "derivative works" will probably be broadened further. Probably, the next GPL should avoid the term "derivative works" in order to avoid this confusion.
As I said before, this is all well, as long as you're talking about contracts, formally correct, signed and notarized by legally consenting parties, willing to enter the contract.
Well, you may take the position that license agreements like the GPL are not valid contracts because they aren't signed pieces of paper. If that were the case, then your arguments would be right, in the sense that then only the provisions of copyright apply, but I think that's wishful thinking. The prevailing legal opinion, practice, and assumption seems to be that the terms of EULAs and the GPL are valid and enforceable.
I will repeat here the position I have after carefully studying the GPL, copyright law, and case law: the GPL regulates the licensing to derived works of the GPL'd work, but it cannot regulate the licensing of encompassing "anthology" works.
The GPL is a license--i.e., a contract between the licensor and the licensee. Within a few general limitations given by contract law, a license can regulate whatever it wants. The most common thing for a license to do is to regulate the transfer of money from the licensee's pocket into the licensor's pocket.
The GPL happens to regulate what you do with certain other works to which you hold copyright. In particular, if you agree to the GPL for a piece of software to which you don't hold the copyright, you may be forced to accept an obligation of licensing some software to which you hold copyright to others. If you don't want that to happen, you just don't agree to the GPL, but then you also can't use the GPL'ed software.
There is nothing unusual about such agreements and they are certainly valid and enforceable: I give you a limited transferable license for software A if you give me a limited transferable license for software B. Those kinds of agreements exist between many different commercial entities, and if they weren't valid, a lot of companies would be in big trouble.
The Open Source definition states clearly:
Clearly, this would be violated if using the source would require execution of a license with Microsoft. That the MARID people don't understand this is just a testament to how naive they are.
The IETF Legal counsel has not to the best of my knowledge published a finding one way or the other.
Well, another example of how out of touch the IETF is; this is something that IETF Legal counsel should have checked during negotiations with Microsoft and before much work was expended on the standard.
As most people on the Net are not lawyers it might actaully be
more useful to look at this license in terms of how it compares
to other licenses granted the IETF. Is it more or less restrictive?
You're missing the point. The point is that the question of whether the IETF standard will be adopted by OSS is not something that OSS developers have the power to decide or negotiate over (as the parent poster suggested), it doesn't depend on whether the license is "good" or "more restrictive" or "less restrictive", and it doesn't depend on whether Microsoft is making an honest effort or trying to control the world. Whether the IETF standard will be adopted by OSS simply depends on whether the licenses required for the IETF standard are compatible with the definition of OSS. If they aren't, then, by definition, OSS software can't implement it.
The Word grammar checker isn't perfect
Actually, I'd call it nearly useless. And, not surprisingly, it seems to be off out of the box.
There are, in fact, no satisfactory grammar checkers out there.
Until OO.org offers such features, I can't imagine them gaining dominance.
In my experience, most Word users don't even know more than a tiny fraction of the features Word offers--they need a word processor with fewer features, not with more features.
But Word is still a better program for the average user.
Microsoft Works is a better program for the average user than Microsoft Word.
There are a bunch of USB-powered harddisks out there. Several companies offer the 1-4G variety. Freecom offers USB-powered drives with up to 80G capacity, and they have really tiny 20-40G drives.
How many things must something be "compatible" (whatever that means in each context) with before it can be considered "good" considering most of you can't make up your minds about them to begin with?
This isn't a question of "good" or "making up one's mind" or "arguing". The patent licensing requirements are just incompatible with the GPL and other OSS licenses--that's a legal fact. Therefore, IETF SPF can't be fully implemented by OSS--there is nothing to debate or negotiate or decide.
Now, there are two possible consequences: either hundreds of thousands of OSS developers throw away all their existing code (whose licenses they can't change) and start over, or they just don't implement IETF SPF. Which one do you think is more likely to happen?
you'd be giving Microsoft a run for their money by now.
OSS developers generally don't care about Microsoft's money; the only thing they care about is when Microsoft interferes with their ability to develop and use software.
Microsoft is apparently trying to play hard-ball with OSS developers, forcing them to accept some kind of licensing terms or forcing them to stop developing this kind of software. But OSS developers don't have a choice: there simply is no way under which OSS developers can give in to Microsoft's licensing terms, even if they wanted to, since the terms are just fundamentally incompatible with most OSS licenses.
Furthermore, going to IETF with such standards proposals is pointless: the only producers of software that count in this space are Microsoft and OSS. If IETF starts producing standards under terms that are not acceptable to OSS developers, then that just makes the IETF irrelevant but it won't help with adoption of a solution.
In this case, if IETF's SPF standard isn't 100% compatible with OSS licenses, OSS software will not incorporate it and Microsoft Exchange installations will be unable to use IETF SPF with a significant fraction of Internet hosts. If Microsoft were competing with a commercial vendor of mail server software, that vendor would be in deep trouble and it might induce that vendor to come crawling to Microsoft begging for a license. But OSS developers won't do that: OSS projects don't have the same kinds of short-term pressures on them as commercial software vendors, and even if they wanted to give in, OSS licenses make it impossible.
Microsoft's management just doesn't seem to understand that they are not dealing with another business anymore: the strategies that they have used against commercial competitors just don't work against OSS. All they are accomplishing with this sort of behavior is to taint their own credibility and the credibility of the standards bodies they get involved.
Microsoft has a whole lot more leverage to push their own solution. If Microsoft decides that their way is the way to go, they can implement it in all of their product offerings, thus forcing others to follow suit or risk being cut off from the vast majority of the Internet using public.
SPF is not necessary for exchanging electronic mail. If Microsoft servers fail to exchange mail with any significant number of OSS mail servers, the result won't be that OSS gives up and everybody signs patent license agreements with Microsoft, but rather that SPF won't get used. The long term fall-out would be that people would take Microsoft even less seriously when they come to standards bodies, and to hurt IETF credibility even further (IETF is already largely irrelevant).
ReiserFS has a bunch of new features, like the ability to use files as directories. The people who created ReiserFS intend for those features to be used for functionality like ACLs, multiple streams/forks, etc. Those are features that application programs see and access. But if you write software that relies on those ReiserFS features, you won't be able to use that software with any other Linux file system because no other Linux file system supports those features. So, the question is whether software newly written to work specifically with ReiserFS can be backwards compatible with non-ReiserFS file systems. If it can't be, people will be reluctant to use the ReiserFS features. And I'm saying that creation of a user-mode emulation of ReiserFS features would help the adoption of ReiserFS.
The question of whether existing programs are compatible with ReiserFS is a separate question. It is not obvious that they are. For example, if ReiserFS allows "cat > foo/bar" to succeed even when foo is a file, some existing software may start failing. Furthermore, existing UNIX utilities won't work correctly anymore; for example, "cp -a" or a tar pipe won't make full copies of a directory tree anymore.
Plenty of safe, clean language are cool: OCAML, Python, Scheme, etc.
What makes Java uncool is the fact that it is and remains a proprietary language. Also, it is uncool because both the language and the libraries are full of avoidable design flaws; Java's roots as a failed project for a set-top box programming language sadly still show to this day.
But foremost, what makes Java uncool is that it takes forever to get anything done in it: a language does not have to be cumbersome in order to be safe, and forcing programmers to write lots of LOC to get the simplest task accomplished does not make the resulting code more readable.
But whether Java is "cool" doesn't matter as much; what matters is that these problems with Java also get in the way of using Java for real work.
ReiserFS is great, and this seems like a tasteful way of implementing some of the complex things people seem to want to do with file systems.
But I would feel uncomfortable relying on any of these features right now because any software that does would fail with any other file system. ReiserFS is free software, but you still end up needing to run software on other file systems in many cases.
I think for these features to become widely adopted, we need some kind of library-based emulation, something that uses ReiserFS if it runs on it and otherwise emulates ReiserFS features like files-as-directories in user mode on top of existing file systems (by using funny file names, etc., similar to UMSDOS).
It's not "duress" (that's when someone holds a gun to your head), it's merely a form of price fixing. Being the victim of price fixing does not completely and automatically invalidate a contract, although you may have legal recourse, depending on how the legal and legislative winds are blowing. In the current climate, however, price fixing by music distributors seems to be tolerated, so your only choice is civil disobedience.
Faster all around, modular & with atomic commits so you don't lose stuff in case of a power loss!!!
It's not that simple. Support for atomic operations in the file system eliminates a few sources of catastrophic data loss and it enables applications to avoid some other sources of data loss. But you will still lose unsaved data, you may still lose file system changes that haven't been committed, and, unless applications are changed, you will still end up with partially written files if the power fails while an application saves its data.
Aren't these things a violation of the agreement they made when they decided to use the software and download songs?
Where are you going to get music? You can buy the CDs, you can download them from a Windows-based service, or you can download them with iTunes. That is, in reality, you don't have the kind of choice of contracts that you might get in a free market.
So, why are people rebelling and breaking their agreements? Because they feel that those agreements have been forced upon them and therefore feel they are not ethically bound by them (even if there is a small legal risk in doing so).
Why do people have to come up with so uncreative names?
Because those names properly confer the meaning that (1) it is related to iTunes, but (2) it is different from iTunes. And that's exactly why Apple doesn't like it: they don't like the competition, and they are going to try to kill it any way they can, even if that means asserting trademark rights they don't actually have.
The name is lawyerfood, and rightfully so. Xtunes felt the wrath of Apple lawyers
Neither "xtunes" nor "ourTunes" are confusable with "iTunes", therefore there is no trademark violation. The fact that a multi-billion dollar company can successfully intimidate some non-profit open source developers isn't evidence of trademark infringement, it just shows that Apple is still up to their old legal tricks.
if there are elephant turds, then there are elephants. And where there are elephants, there must be water. Ergo, there must be water on Mars.
So, 900 noisy Apple users complain, as usual; why should they care? What counts is the bottom line: how many songs is Real selling to iPod users. If that works out OK, they'll keep doing it.
... in medicine, and one in physics, and probably one in chemistry, waiting for anyone who can demonstrate a possible mechanism of action for health effects of non-ionizing radiation at athermal levels.
There are plenty of such mechanisms. For example, just about any circuit with a nonlinearity (like most biological cells) near a radio station will pick up a small audio frequency signal. Those signals are strong enough to be audible in stereo equipment, telephones, etc. that aren't well shielded. And low frequency electrical signals definitely have biological effects.
Your problem is that you think of the radio transmitter just as a source of steady, high frequency radiation. That would indeed probably not have any biological effects. But that's not what real-world RF signals are like.
Apple is a design leader, and there's a portion of the PC hardware industry that watches Apple designs and makes knock-offs on the PC side.
Yes, and Apple watches the trends in the PC industry and knocks off their designs. Because they are smaller and more focused than the PC industry, Apple can take an emerging trend, patent it, and then sell gadgets around it.
The question with patents is always: if this patent were not granted, would companies still have the incentive to innovate in this area with the same intensity?
"Innovation" in the area of case modding? Oh, please. Sticking any kind of blinking, computer controled, colorful light inside a case is something teenagers have done for years. In this case, it happens to be a light whose color can be changed. Big deal, you can get those off the shelf.
Look around the web a little for case mods and you'll see that Apple's designs are hardly the most innovative out there, nor even the best.
It's a physical thing, a real invention.
It's a physical thing. But in order to be a "real invention", it would have to be novel, rather than an obvious, trivial combination of existing elements. Light sources whose color you can tune have been around for decades, and so have been cases with light sources inside them, even light sources under computer control.