Weekly Edition
Return to the Front pageRecent Features
| |||||||||||||
New rules for software contracts
On May 18, the Linux Foundation announced
that it had sent a joint letter to the American Law Institute protesting
some provisions in the ALI's proposed principles to be applied to the law of
software contracts. That was likely the first that many LWN readers had
heard of this particular initiative - or, indeed, of the ALI in general.
Your editor, being a masochistic sort of person, has plowed through all 305
pages of the principles (which were made official by the ALI on
May 20) with an eye toward their effect on free software. What
follows is a non-lawyerly summary of what he found.
In the U.S. justice system, the written law which emerges from the legislative branch is just a starting point. The actual law that one must follow is determined by the rulings of a wide variety of courts across the country. At times, divergent rulings can result in different interpretations of the same law in different regions. The process of creating a coherent set of high-court precedents can be long and messy, and it can create a great deal of uncertainty while it is happening. Uncertainty about the law is never a good thing. The ALI sees its purpose as improving that process through the creation of documents stating its view of how laws should be interpreted. The process is long and detailed; in some ways, it resembles how technical standards are created. But, certainly, the ALI believes it carries a strong influence in how the courts work:
The final product, the work of highly competent group scholarship,
thus reflects the searching review and criticism of learned and
experienced members of the bench and bar. Many Institute
publications have been accorded an authority greater than that
imparted to any legal treatise, an authority more nearly comparable
to that accorded to judicial decisions.
So if this group sets itself to the task of directing the interpretation of the law around software, it's probably worth paying attention to what they are saying. Unfortunately, the draft principles must be purchased ($40 for the PDF version) and cannot be redistributed, so your editor will be restricted to an exercise of his fair-use rights in talking about this text. The ALI has set itself the task of clarifying the law around software, and software contracts in particular. So the principles apply to "agreements for the transfer of software for a consideration. Software agreements include agreements to sell, lease, license, access, or otherwise transfer or share software." One might think that this restriction would move much free software activity out of the scope of the principles, but the ALI makes it clear that the source-release requirements found in licenses like the GPL are "consideration." While not taking a firm stance, the principles also suggest that a court would treat the GPL as a contract. The result is a clear statement that GPL-licensed software falls within the scope of this document. Whether software distributed under more permissive licenses would be covered is not addressed. Much text is expended toward the question of when a contract is formed. In particular, the ALI takes a clear stance that shrinkwrap (or "clickwrap") agreements do, indeed, form a contract which can be enforced. It goes beyond that, though, in that even the "I agree" button click may not be necessary. The reasoning is interesting:
For several reasons, § 2.02(b) does not establish a bright-line
rule for enforcement requiring, for example, clicking "I agree" at
the end of an electronic standard form. First, as already
mentioned, case law already presents a wide variety of formation
types that are not easily captured by a narrow rule and, for the
most part, handle the issues in an effective manner. These include
situations in which the transferee is aware of the terms because of
a course of dealing or because the transferor delivered an update
of previously downloaded software. The safeguard of requiring a
click at the end of the form does not seem necessary in either
case. Second, open-source transfers rarely follow the current
click-wrap model, and these Principles should not upset an
established custom unless problematic.
So the ALI says that it's pretty easy to be bound under a software contract. Doing something which requires the permissions in the GPL (redistributing software, for example) is enough. This is important: if the GPL is interpreted as a contract by some court, it will be relatively easy to demonstrate that somebody who is (say) distributing software in violation of the GPL's terms did, in fact, agree to be bound by that contract. Warranties are treated in detail; this is the section that the Linux Foundation and Microsoft dislike. There are several types of warranties which are discussed:
Anybody who has actually read a software license agreement knows that software vendors routinely disclaim all of those warranties. And, in fact, the ALI principles allow them to do that - except for the last one. The text reads:
A transferor that receives money or a right to payment of a
monetary obligation in exchange for the software warrants to any
party in the normal chain of distribution that the software
contains no material hidden defects of which the transferor was
aware at the time of the transfer. This warranty may not be
excluded.
So, if you are distributing free software under free-beer terms, you need not provide a warranty against "material hidden defects." The language is clear here: "consideration" is not enough to force the warranty; there must be actual money involved. But if you are, say, an enterprise Linux distributor, there could be a real problem here. Distributors and others shipping or supporting Linux in exchange for real money will, under these principles, be forced to provide a warranty against hidden defects in that software. One might think that this is not a huge problem. Linux distributions do not, as a rule, have hidden defects. The list of defects that the distributor knows about is, almost by definition, found in the distributor's bug tracking system, and that information is usually widely available. The problem is that simply maintaining a publicly-available bug tracker is not, in the ALI's view, good enough:
Disclosure of a material hidden defect occurs when a reasonable
transferee would understand the existence and basic nature of a
defect. Disclosure ordinarily should involve a direct communication
to the transferee, if feasible. A mere posting of defects on the
transferor's website generally should be insufficient.
What a distributor will have to do is not exactly clear. Printing out the entire bug tracker seems like an unsatisfactory solution. Perhaps getting the customer to sign a piece of paper acknowledging awareness of the bug tracker would be sufficient. There is an unpleasant vagueness here, right in the portion of the principles which has proved to be most controversial. The remainder of the document is concerned with breach of contracts and remedies. One term states that software providers must accept a recipient's cure of a specific breach. In the free software realm, that means that one cannot terminate somebody's right to use GPL-licensed software if that somebody acts in good faith to fix a failure to distribute source. In general, nobody wants to do that anyway, so this term really just goes along with existing practice. The remedies section is mostly straightforward contract-enforcement stuff. There is one interesting paragraph in the discussion:
For example, software "hobbyists" (who do not "deal in software of
the kind transferred" or "hold [themselves] out by occupation as
having knowledge or skill peculiar to the software") may provide
open-source software without charge under terms that disclaim all
responsibility for performance and provenance. Under the
circumstances, no remedy at all may be the appropriate result when
the software does not perform or infringes a third party's
intellectual property right. In other words, the transfer of
open-source software in this context may be a case in which,
essentially, there can be no breach by the transferor that supports
the grant of a remedy to the transferee.
One might interpret this as saying that, say, patent holders cannot go after free software developers who distribute code held to be infringing. That would all depend on the interpretation of "hobbyist," though. Developers working in a corporate setting would certainly not qualify. The principles also take on the topic of remote disablement of software - an interesting issue, even if it does not really apply to free software. In summary, remote disablement is allowed, but only in tightly constrained circumstances. It cannot be used with mass-market software, and, in any other situation, it requires a court order first. So, while remote disablement is allowed in principle, it is made difficult in practice. The meeting of the ALI which approved these principles debated the topic for all of 30 minutes. Clearly the participants do not see much here which strikes them as controversial. For the most part, they may be right; this exercise would seem to make sense. If the courts adhere to these principles, the result should be increased clarity and predictability around software contract law. Beyond that, the proposed principles are generally friendly to free software, acknowledging that it operates under different circumstances and that our licenses are valid. These are good things. The one real sticking point is the issue pointed out by Microsoft and the Linux Foundation: mandatory warranties. Even that could turn out to not be a huge problem in practice for free software; it relates to hidden defects, and we do not hide our defects. Proprietary vendors - who do tend to hide defects - will have a harder time with this provision. As long as some sort of reasonable interpretation of "disclosure" is reached, Linux distributors should be in reasonable shape. So, while it would have been nice to have a wider, more public debate about this document, the end result does not appear (to your most certainly not-a-lawyer editor) to be all that bad. We can probably live with those terms. (Log in to post comments)
New rules for software contracts Posted May 22, 2009 20:30 UTC (Fri) by jengelh (subscriber, #33263) [Link]
The I agree forms should remain, especially with, for example, the Windows installer. There is sometimes no other chance to see the license terms, as they are not printed in the CD cover. It may be in the accompanying Installation Guide Manual, but who reads that, anyway? Even with tarballs I have that chance: after unpacking them. If I do not like the license terms which are usually provided in files called COPYING, LICENSE or similar I can return the product (or whatever applies for the given method of distribution). I would hate for a product to skip the EULA screen and install itself without notice. People call such software viruses, normally. :-)
New rules for software contracts Posted May 28, 2009 10:42 UTC (Thu) by NAR (subscriber, #1313) [Link]
The license terms can be on the webpage that contains the "Install software" link. Or software could be installed e.g. by clicking on the "Install patch" button in a game, there might be not much point in showing an other "I agree" form.
Will something like disclaimer on DVD suffice? Posted May 22, 2009 20:45 UTC (Fri) by khim (subscriber, #9252) [Link] I've seen this "note" (or similar notes) on DVDs: A NOTE to the VIEWER:Obtained from the original source in Japan, the video masters used to make these DVDs are the best avalable. Although the small glitches contained within do not reflect the full potential of the DVD format, they were in fact unavoidable if this box set were to be released. Thank you. Will something like this disclaimer plus pointer to bugzilla enough to satisfy requirements?
Will something like disclaimer on DVD suffice? Posted Jun 4, 2009 12:53 UTC (Thu) by Duncan (guest, #6647) [Link]
That note is very similar to notes that appeared for years on CDAudio CDs,
generally, on those whose original masters and mix masters were analog. There was a three-character legend called the SPARS Code that used to go with it as well, with each character either A or D, analog or digital.
The first referred to the source masters, the last to the production
Much less common is DAD, where a mix engineer preferred to work with
The SPARS Code has become less common in recent years for a number of
Here's the Wikipedia article on it. (I had to google to find the SPARS
http://en.wikipedia.org/wiki/SPARS_Code
I hadn't thought about that in years but your post brought on a wave of
As for whether something similar might suffice for software, I'd guess
Duncan
License != contract Posted May 22, 2009 20:49 UTC (Fri) by yann.morin.1998 (subscriber, #54333) [Link]
I thought that the FSF insisted on that the General Public _License_ was just that: a license, and by no means was it a _contract_. In which the ALI would kind of clash on that subject...
Can any one confirm or invalidate? Pointers welcome!
Rgds,
License != contract Posted May 22, 2009 21:33 UTC (Fri) by ncm (subscriber, #165) [Link] Lawyers, as a rule, prefer to have everything treated as a contract, partly because they studied so hard for their contract law courses, but mainly because of the bewildering variety of case law around contracts. For any theory about contract obligations, they can point to dozens of cases supporting it and dozens more opposing it. Copyright license law is relatively simple, and doesn't lead as directly to enormous billings. Intelligent judges, for much the same reasons, prefer to apply license law.It's particularly sneaky, not to say duplicitous, for the authors of the ALI to treat acknowledgment of Free Software license terms as an example of no-click contract agreement, because the courts applying the Uniform Commercial Code have almost uniformly rejected such notions. I personally have a policy of never reading a click-through document that the UCC indicates cannot be a valid contract.
License != contract Posted May 25, 2009 8:30 UTC (Mon) by kleptog (subscriber, #1183) [Link]
I thought the reason they wanted the GPL as a licence was because the remedies are different. With copyright law you can actually forbid someone from distributing. Contract law is less rigid and the problem can be reduced to "adequate compensation", whatever that means.
Mvg,
License != contract Posted May 30, 2009 19:38 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I thought the reason they wanted the GPL as a licence was because the remedies are different. With copyright law you can actually forbid someone from distributing. Contract law is less rigid and the problem can be reduced to "adequate compensation", whatever that means. That's how I remember it too. But of course, wishing doesn't make it so. The ALI probably has more clout than the FSF on this, especially since the FSF created the thing, so has a conflict of interest. Lawyers, as a rule, prefer to have everything treated as a contract, partly because they studied so hard for their contract law courses, but mainly because of the bewildering variety of case law around contracts. For any theory about contract obligations, they can point to dozens of cases supporting it and dozens more opposing it. Copyright license law is relatively simple, and doesn't lead as directly to enormous billings. That's an interesting theory, but I think it paints lawyers with too broad a brush. There are few generic lawyers in the world. Instead, there are contract lawyers and IP lawyers. I think IP lawyers study as hard for their IP courses as for their core contract course. I'm a contract lawyer and I do prefer things to be contracts, but not because contract law is more vague. Rather, it's the opposite: It mostly makes sense to me and I can advise someone quickly, with confidence. I can charge less and have more customers. But I wouldn't take money for copyright advice, because it would take me much too long to come up with merchantable advice. It's particularly sneaky, not to say duplicitous, for the authors of the ALI [document] to treat acknowledgment of Free Software license terms as an example of no-click contract agreement, because the courts applying the Uniform Commercial Code have almost uniformly rejected such notions. The authors probably don't. The document is 305 pages long and presumably says everything in flexible, conditional, run-on sentences which LWN has just simplified for us. As for contracts without some formal action such as clicking "I agree," I haven't seen courts uniformly reject those. I see them supported by UCC everywhere, with the trend toward more of them. E.g. shrinkwrap: you don't have to sign anywhere; you just have to use the product.
New rules for software contracts Posted May 22, 2009 21:13 UTC (Fri) by joey (subscriber, #328) [Link]
"we do not hide our defects"
Except, perhaps for those:
* posted to the closed vendor-sec before coordinated disclosure
New rules for software contracts Posted May 23, 2009 2:04 UTC (Sat) by shmget (subscriber, #58347) [Link]
"* fixed by a commit with a misleading commit message"
If it is fixed, it's not a defect, hidden or otherwise...
New rules for software contracts Posted May 23, 2009 15:24 UTC (Sat) by jejb (subscriber, #6654) [Link]
> If it is fixed, it's not a defect, hidden or otherwise...
You're not thinking like a lawyer. It might be fixed in your updates but the shipping product, the one the customers actually paid for and to which these rules refer, might not have the fix. In that case, at point of sale under these principles it must be disclosed in a manner a reasonable person would understand ... obfuscated bugzilla reports, even if enclosed with the medium, might not satisfy the requirement that "Disclosure of a material hidden defect occurs when a reasonable transferee would understand the existence and basic nature of a defect"
The second problem is reported but unfixed security bugs: The current methodology we all employ is to keep the bug secret until we come up with a fix to avoid encouraging exploits. This is specifically a breach of the disclosure warranty.
New rules for software contracts Posted May 23, 2009 17:52 UTC (Sat) by shmget (subscriber, #58347) [Link]
"The current methodology we all employ is to keep the bug secret until we come up with a fix to avoid encouraging exploits. This is specifically a breach of the disclosure warranty."
Yes, I agreed that it is a breach. I also think that such secrecy is evil and dangerous.
"You're not thinking like a lawyer."
"It might be fixed in your updates but the shipping product, ...."
No, that was not the issue.
So the objection here is not about fixed after "the one the customers actually paid for and to which these rules refer", but about a 'misleading commit message' for the fix, prior to the transaction.
"Disclosure of a material hidden defect occurs when a reasonable transferee would understand the existence and basic nature of a defect"
That transpose the original question to the problem of 'misleading', inaccurate or incomprehensible bug report. The crux is what is a 'reasonable transferee' ? Is a 'reasonable transferee' deemed capable of understanding terms like 'race condition', 'leaks', 'buffer overrun', 'stack overflow', 'segmentation fault', 'privileges escalation', 'exception handler', 'signal handler', etc... or are we talking of the kind of 'reasonable transferee' that need a warning not to try to dry their cat in a microwave ?
Bug reports are, by nature, often confused and inaccurate. At best they described perceived symptoms, at worse they theorized on the underlying cause. In most case if the cause was crystal clear, you would not have a bug report, but a patch.
Furthermore, should the project be liable for poor or misleading bug report ? after all, many such reports come from the users themselves.
No matter how you look at this, the result cannot be good, for anyone.
New rules for software contracts Posted May 23, 2009 22:57 UTC (Sat) by joey (subscriber, #328) [Link]
I never said anything about "prior to the transaction".
New rules for software contracts Posted May 24, 2009 5:53 UTC (Sun) by shmget (subscriber, #58347) [Link]
"I never said anything about "prior to the transaction". "
No, you did not. That part was a response to jejb.
New rules for software contracts Posted May 22, 2009 22:58 UTC (Fri) by lorien420 (guest, #44036) [Link]
"the software contains no material hidden defects of which the transferor was aware at the time of the transfer"
If this statement stood alone without a disclosure clause, then no software could ever be released again. Not only does everybody with a QA team release software with known bugs, everybody that receives software knows that there must be bugs in it.
Thinking about the purpose of this document it seems like the Linux Foundation should be looking to it for places that need advocacy. If ALI is defining what they consider the meaning of current law and current practices, then this is really a document guiding us to what might need to change. If software warranty law is vague and puts an inappropriate burden on developers as it is currently written then we now have a description of where the legal end of Free Software should put some of its efforts.
New rules for software contracts Posted May 23, 2009 9:48 UTC (Sat) by nix (subscriber, #2304) [Link]
The thing is, I can see why the law would require that. Before the days of
software one really did *not* release, say, cars or aircraft or even kids' toys with known faults. That's because fixing faults in physical objects is horribly expensive, because in some cases they can endanger life if they go wrong, and because (at least in the kids' toys cases) they're simple enough that it is reasonable to expect freedom from faults.
None of this is true of the sort of software users buy: the sort that
New rules for software contracts Posted May 23, 2009 15:09 UTC (Sat) by butlerm (subscriber, #13312) [Link]
Cars, aircraft, and kids toys are released with known faults, weaknesses, and
deficiencies. Everything is. That is why the qualifier "material" is present, which more or less means "significant" or "serious". Most of the stuff in a typical OSS bug tracking system probably wouldn't qualify under the "material" standard.
The other problem, is that by any rational standard, the extent of an implied
"material" and "hidden" Posted May 23, 2009 14:38 UTC (Sat) by kirkengaard (subscriber, #15022) [Link]
And here's the thing: we habitually release software that is, if not known to be defective, certainly understood to contain bugs. As the old saws go, we make a policy of "release early, release often" because "many eyes make all bugs shallow." The statement in question comes from a very proprietary-finished-product headspace. We disclaim warranties of implied merchantability or fitness for a particular purpose for much the same reasons. F/OSS is never final, and its most frequent use case is testing. Stability is not the absence of defects; it is the asymptotically approached norm of "works for all use cases." The *best* we get is "works for most use cases and has documented edges."
I suppose the key words here are "hidden," which we've caught, and "material," which in legal language is an adjective with another meaning. (Hence "material hidden defects," not "hidden material defects.") As far as I can see, the term in most contexts implies a defect which causes the product not to be worth the value assigned to it. "Material" is "relevant/important/essential to the item under consideration." The ALI approach only deals in monetary value here, and not mere consideration, because material defects by most definitions produce a devaluation of the product being purchased.
By those off-the-cuff readings of the key phrase "material hidden defects," this is much the same as buying a house or car or any other product of which the consumer has a reasonable expectation that its advertised condition is a true and complete statement of facts based on the due diligence of the seller. Likewise that the price agreed upon and paid for the product is appropriate to its value thus determined. Any defects which are not disclosed, therefore "hidden," cause the product not to be worth its stated value, which then becomes a question of liability. Here the key phrase modifying "hidden" is "of which the transferor was aware at the time of the transfer." In this case, liability expressly attaches to the seller if due diligence was done, and relevant defects were discovered but not disclosed, causing the price to be set based on a false understanding of material value. (IANAL, so I'm sure I missed some nuances.)
So, on this reading, ALI is saying that no one can disclaim liability for fraudulent monetary valuation of a product, with the implicit understanding that said monetary valuation is a reflection of its quality or freedom from relevant defects. That, in my mind, raises the real question: is the value of software determined in a way that makes this a relevant standard?
Ah, crap. The problem gets bigger. Posted May 23, 2009 15:15 UTC (Sat) by kirkengaard (subscriber, #15022) [Link]
Next thought: and then we need a definition of what is, and is not, material to the operation of a given product. Liability-land sucks. You are not allowed to sell a product on the intimation that it might work for a purpose, if in point of fact it is not tested and warrantied for that purpose, because if it fails you have become liable for the failure. In part, this is why you see many, many cans of remarkably similar permethrin and pyrethrin insecticides labeled each for very specific use cases. Can't sell ant killer on the premise that it will also kill wasps, unless the manufacturer has so tested and warrantied the product. This sort of defect liability becomes liability for fitness for a particular purpose, and hence merchantability, very quickly, and it leaps from the manufacturer to the merchant almost as quickly.
This is no kind of legal environment in which to develop free software. This is part of the reason for proprietary development pathology, and the refusal to open code. F/OSS's success is based on the disclaimer of warranties and liability because of the retention of the absolute freedom to do anything with it at any development stage, and pass it along to others likewise. We intentionally release "broken" code because we are allowed and encouraged to think of all code as essentially broken. Sure, we try to release the best broken code we can, but we know nothing is ever perfect, and nothing gets better by restricting access. Proprietary code is also broken, but can only be fixed in-house because their liability coverage only goes so far. Liability requires control. Maximal liability requires maximal control, and shuts off external freedoms. That's the problem I see under the whole issue -- mandatory liability creeps into every little corner, and attaches itself to every possible recipient. This is why the GPL is maximally important as a legal framework for development.
Ah, crap. The problem gets bigger. Posted Jun 4, 2009 13:27 UTC (Thu) by Duncan (guest, #6647) [Link]
Well written, but for one thing. As Corbet pointed out, the hidden defect
liability clause only applies where money was charged.
Thus, the developers doing the release early, release often, can continue
They just can't charge for those test releases, or they then have to be
That leaves paid distributions, which admittedly do fund a decent portion
But for these paid distributions, the discomfort during the adaptation
Duncan
New rules for software contracts Posted May 23, 2009 17:09 UTC (Sat) by DusteD (guest, #49423) [Link]
There can never be hidden defects in an opensource product, since the source is not hidden, any defects in that source is not hidden.
Source code is documentation on the workings of the product, and therefore, any defect will be visible from the source code.
Open source as disclosure won't fly legally. Posted May 24, 2009 23:46 UTC (Sun) by mrjk (subscriber, #48482) [Link]
You would lose with that argument. If a Developer knows of a bug that "materially" affects the use
of a program and doesn't disclose it, the fact that source is available isn't going to help. Nobody would find the bug by looking at the source. That isn't disclosing anything.
No mention of patent holders on grant of remedies Posted May 24, 2009 15:39 UTC (Sun) by mtorni (subscriber, #3618) [Link]
While reading the paragraph about remedies in case of non-performance or infringement of third-parties rights I can find no mention of protection from patent holders.
My reading tells me only that the developer would not be obliged to pay to the recipient of the software, but I did not see any mention of lack of remedies to third parties.
Is there extra information in the original document which points to protection from patent holders?
No mention of patent holders on grant of remedies Posted May 25, 2009 4:22 UTC (Mon) by corbet (editor, #1) [Link] No, there would be no protection for developers under direct attack from patent holders. This document covers software contracts - relationships between people distributing software and those receiving it. Third parties are beyond its scope.
ALI helpful to software purchasers or lawyers? Posted May 25, 2009 2:13 UTC (Mon) by jhhaller (subscriber, #56103) [Link]
Lawyers make their money by writing legal documents and by litigating. Contracts which disclaim all warranties are an anathema to lawyers, as it leaves nothing which can be litigated. This has the joint issue that no money can be made on litigation, and that the lawyers are not able to protect a client who has bought a non-functional product. While I'm sure that the primary purpose of the document wasn't to increase legal fees, that it would create additional reasons to sue was not far from the front of their minds.
In most US states, there is an implied warranty of merchantability. If you go to a store to buy a hammer, it is implied that it will be able to drive nails. If it doesn't, you can return it for a full refund. It doesn't mean that the hammer is flawless. A splinter on the handle wouldn't prevent the hammer from being used for its intended purposes, but a crack in the handle might. When applied to software, this means that the software should accomplish the purpose it was said to perform. A word processor should produce documents, and probably shouldn't lose much work due to crashes. As a consumer, I don't want to spend money on something that doesn't work. But, as a software professional, I know that it is impossible to economically produce non-trivial defect-free code. Between those, I think there is room to allow return of consumer software for a refund for a short period of time, no more than a month. Contracted software, such as that associated with large failures, are a different matter for which I don't understand well enough propose a solution.
New rules for software contracts Posted May 25, 2009 5:02 UTC (Mon) by butlerm (subscriber, #13312) [Link]
If a court ever sets an actual precedent that a source release requirement or
something comparably trivial was sufficient consideration to enforce an implied warranty, that would be groundbreaking news.
Until then, the suggestion that a court is going to enforce an implied
New rules for software contracts Posted May 26, 2009 15:16 UTC (Tue) by hppnq (guest, #14462) [Link] This is about commercial software, free (as in speech) or not. To me, by the way, it is not entirely clear why the Linux Foundation jumped at the opportunity to cooperate with Microsoft to express their worries about what this means for the "well-functioning software market".But to answer your question: yes, of course, if you sell software which does not perform, and rather-obvious-legal-yadda-yadda, customers should be in a position to expect a complete refund. Or, at least, that is what I have always thought to be a good principle. IANAL, YMMV.
New rules for software contracts Posted Jun 1, 2009 16:38 UTC (Mon) by butlerm (subscriber, #13312) [Link]
Primarily about commercial software, yes. However the ALI maintains that a
source release requirement is adequate consideration to form a binding contract even on software given away for free. That is what I am dubious about. Even if there is a binding contract, the traditional scope for damages is typically limited to the purchase price. Of course other legal avenues may come into play (even with cost free software) if there are significant safety issues involved.
New rules for software contracts Posted May 27, 2009 17:25 UTC (Wed) by quotemstr (subscriber, #45331) [Link] Your editor, being a masochistic sort of person, has plowed through all 305 pages of the principles...This is the kind of thing that makes me happy to be a lwn.net subscriber. :-)
Hidden defects Posted May 28, 2009 23:44 UTC (Thu) by chrisV (subscriber, #43417) [Link]
Be careful with "hidden defects". The word "hidden" has two different meanings. In its broadest sense it means "latent" or "not known about", which if the intended meaning would be disastrous for free software. On this approach the ability to disclaim liability would be limited to cases of explicit disclosure: "we do not warrant the particular problem with our software which unfortunately occurs when you try to save a file on a leap day". This reading would have a very chilling effect on free software by the main distributors.
The sense in which you are reading it is "deliberately hidden defects" - in effect, the supply of software with known defects without disclosing the defects, something close to fraudulent behavior. Does the context in which the expression is used justify this construction?
Hidden defects Posted May 30, 2009 18:53 UTC (Sat) by giraffedata (subscriber, #1954) [Link] In law, it's a common phrase well understood (see any legal dictionary) to mean only that the defect was not discoverable by a normal inspection. It doesn't imply someone actively hid the defect. I doubt that reading the source code is a normal inspection. Even reading open bug reports in some public Bugzilla probably isn't.
New rules for software contracts Posted Jun 3, 2009 5:29 UTC (Wed) by willezurmacht (guest, #58372) [Link]
So what's the problem with the "no hidden -known- defects" mandatory warranty? Would you buy a car if you knew the car company didn't have any kind of binding legal agreement to indemnify and compensate you if a failure causes damages directly due to factory and design defects?
Would you buy an Xbox 360 from Microsoft if you wouldn't have a proper warranty program which can replace your console with a new one at no cost (not even shipping or handling)?
The same applies to several other industries.
Please, let's try to get a little bit serious and realize, one and for all, that corporate America needs to know GPL doesn't mean you can feed them with something you know to be broken. If you ship software which has security flaws or defects in it, you should be liable and accountable for any statutory damages caused by those issues. It's called responsibility.
If your corporate developers produce faulty software, something isn't working. Either ensure they receive proper training or improve themselves on their own, or fire them for good. There will be someone better elsewhere.
New rules for software contracts Posted Jun 3, 2009 6:22 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
what is the last software that you know of being shipped that had zero known bugs in it? what if you expand the definition of 'defects' to include design flaws?
I don't care if you are talking about opensource or commercial, as a practical matter it just doesn't exist.
software is shipped based on many different reasons, but the only software where they really try to erradicate all bugs is software where failure will cost lives (and even then they ship one version of software while working on the next version that makes improvements, unless those improvements are all new features, doesn't that make the lack a 'defect'?)
New rules for software contracts Posted Jun 3, 2009 15:27 UTC (Wed) by nix (subscriber, #2304) [Link]
Proof: a recent coreutils release fixed a bug in cat(1).
And if *cat* has bugs, why then *everything* has bugs.
New rules for software contracts Posted Jun 3, 2009 16:07 UTC (Wed) by foom (subscriber, #14868) [Link]
Cat is actually fairly complex: it has 7 options which transform the input data one of which (-v) the
exact behavior is somewhat controversial (what does nonprintable mean?), and requires locale support.
Now head -- that's a simple command.
New rules for software contracts Posted Jun 3, 2009 20:49 UTC (Wed) by nix (subscriber, #2304) [Link]
Yes indeed. Of course head and tail have had controversies and bugs as
well (e.g. the deprecation of -{num}), and tail is much harder to do right, and is prone to eating all memory if you get it wrong.
the deprecation of -{num} Posted Jun 4, 2009 8:15 UTC (Thu) by xoddam (subscriber, #2322) [Link]
Is that what happened to head and tail?
I thought *my* brain was turning to mush, and I had only caffeine as an excuse.
the deprecation of -{num} Posted Jun 4, 2009 20:16 UTC (Thu) by nix (subscriber, #2304) [Link]
Newer POSIXes for a time banned purely numeric arguments, including -{num}
to head and tail. coreutils followed it for a while depending on the setting of _POSIX2_VERSION at runtime or _DEFAULT_POSIX2_VERSION at configure time or the POSIX compliance level of glibc. As nobody ever set those configure- or runtime things, the effect was that everyone's shell scripts suddenly broke.
POSIX reversed this decision in early 2005, and coreutils accepted -{num}
|
|||||||||||||