Is it a sequence of related but not nearly identical images? Then it's probably a slide show, which is a kind of document, and ought to be stored in a document format like PDF or.odp (OpenDocument Presentation).
If I get a multi-page fax, I don't want it delivered as a slideshow -- I want a PDF or a multipage TIFF. Yes, PDF is a sensible choice in this situation -- but what basis do you have for saying that multipage TIFF isn't? It's widely used in that case, and there's software support for the tagging format (so I can use my fax-viewing software to pull up things like the caller ID information or the logs indicating the model of fax machine used by the sender).
Frankly, I think you're arguing at this point for the sake of being contrary.
Sure, it makes sense. Look at faxes -- they're multiple pages of bitmapped images. Does that compose a "document"? Maybe. Is it something TIFF is good for? Absolutely! There are standardized tags used for storing extra information about fax transmissions in TIFF documents, and there's a great deal of software which makes use of that metadata. The same thing is true of archiving documents composed of scanned images -- there are a great many tag types associated with metadata such as scanner model and configuration, and software support for those tags is widespread.
I've also seen good use made of TIFF in the context of medical imaging (where flexibility and storage of multiple pages/layers and keeping arbitrary metadata is important), though there are other, more specialized formats which are also important in that space. If you have multiple images in a file (ie. multiple layers from a scan), does that make it a "document"?
The distinction between a "image" and a "document" is a hazy one at times, and I don't think we have a good enough description of the problem space the parent is working in to make the kind of judgment you're arguing for. Certainly, whether something is composed of more than one page is not the place to draw the line.
Yeah, there's nothing to it. It's easy. Like everything else you can't do.
I couldn't, as a nonspecialist, implement a competitive virus-scanning engine. Give me that engine, though, and "X... on a gateway" is such a simple step as to be unworthy of protection; in short, it's something I could do, and that's the problem.
A specific and nonobvious mechanism for implementing a virus scanning engine... reasonable to expect that it would be patentable.
Putting a virus scanning engine on a gateway... no.
Your farmer's market might be accessible. Mine is way down south on the other side of downtown (whereas I live and work up north), meaning lots of driving and traffic and gas expenditure to get there and back. A half hour wouldn't cover one leg of the trip, much less any time shopping.
There are local delivery services for organic foods; tried that for a while, decided we couldn't afford it.
The "right answer" for one person isn't a suitable answer for everyone.
Yes, it makes sense for them to be multi-page. TIFF is a multi-page format -- it actually supports a huge number of subformats (and different compression algorithms) in addition.
The most effective compressors are commercial, but DjVu is a very effective image archival format; see DjVuLibre for the non-commercial tree.
Moving back towards the question in the article, I don't think there's much worry about either TIFF or PDF in terms of future proofing; they're both very widely used, have multiple implementations and third parties with substantial interest in keeping those implementations maintained, etc. The quality of TIFF implementations varies wildly, but the good ones are only going to get better, and I'd be shocked if libtiff ended up terminally bitrotted without a successor implementing a superset of its functionality inside my lifetime.
The Democrat majority in the House today is larger than the Republican majority was in 1998.
...but they were working with a President who was willing to compromise on occasion; as a result, both sides got useful things done.
So principles get sacrificed in the name of "getting things done," things like granting immunity to the telcos? And I'm still expected to back this party?
*sigh*. I think the party's presidential candidate has some principals (of course, his pending statement regarding this "compromise" will shed additional light on that one way or the other)... but otherwise it's just a lesser-of-two-evils thing.
I'm relying on good faith on Valve's part, and may well not have effective redress should they act contrary to that intention; your decision not to make that reliance is an entirely reasonable one.
I don't think your example is representative of the field: "A one-size-fits-all version control tool with a design that needs no hacks to make it work with any given development model" is exactly what Bazaar is intended to be.
Light checkouts and bound braches allow it to operate much like a traditional centralized SCM (with varying levels of space and bandwidth tradeoff), while its distributed operation provides all the available workflows of that model.
Heh -- it's been a while since I've seen Arch mentioned anywhere.
Tom Lord abandoned it, and most of the other core people jumped ship to Bazaar (and are now working for Canonical). Bazaar, as a result, has been extremely cautious not to make the same mistake, and focused on usability early in its development; I think it's come out to be a stronger project as a result.
Incidentally, bazaar has a Subversion plugin available; with that installed, SVK's interoperability with SVN becomes significantly less unique.
It's a pure luxury item. They have no means of compulsion.
Compulsion is not a necessary element; deception or lack of genuine consent also qualify. If one believes that the Steam Subscriber Agreement is reaffirming the terms of the Steam license, rather than providing terms governing the immediate purchase, there is not genuine consent inasmuch as the immediate transaction is concerned.
"This Steam Subscriber Agreement ("Agreement") is a legal document that explains your rights and obligations as a Subscriber. Please read it carefully." is perfectly clear to a layman.
It is entirely clear that the document is binding in some manner. It is not clear that the document applies to the product being purchased, rather than to Steam itself.
The price difference is relevant, as terms which overwhelmingly favor one side without reasonable compensation for the same is one of the tests for unconscionability. "Purchase a subscription" in not the wording they use when clicking on the button to indicate that one wishes to buy (what is presented as) a product; it may be the wording used in the license agreement subsequently displayed, but (largely on account of that distinction) that license agreement's applicability to the ongoing transaction is not immediately clear to the layman, and can be interpreted as a reaffirmation of the terms of use of Steam itself (without implication as to the product being "purchased", as purchase of a product is the manner in which the transaction has been presented up to and until that point, and the language of the agreement itself is the only indication to the contrary).
I'd ask my wife to weigh in here, but she's taking a week of vacation and has indicated she doesn't want to think about law in the interim.
I agree with you that this is too little, too late. That said, there's one respect where Git is well behind: Usability.
svn and bzr both have it beat -- hard -- in that respect; particularly svn, which has more pervasive tool support (but plenty of other disadvantages). That does little good, though, when you're picking a tool for use on a large project including artists, tech writers, win32 GUI developers, and other folks who have less of the appropriate inclinations.
I say this as someone using git on a daily basis. It's not a bad tool, but an end-all be-all it's not; for my own projects, I use bazaar.
You use the term "physical product". What is the physical product? My point at the start was that a physical product helps make you secure in ownership.
I was arguing that this would be clearly unconscionable in the sale of a physical product, and (if you accepted that premise) asking if and why such terms would be sufficiently reasonable as to be enforceable in the present context.
Again, I believe unconscionability clearly applies here. The Steam agreement can be easily misunderstood by a layman to govern the use of Steam itself, as opposed to the software "purchased" via that mechanism. Bargaining power is strongly one-sided, the terms (as you've admitted) overwhelmingly favor a single party, and there's no price disparity when purchasing through Steam sufficient to make it clear that the buyer is being reasonably compensated for agreeing to these terms.
Think All Publishing, L.L.C. (and its principal and successor) and the Federal Trade Commission.
The FTC's argument was (1) that they engaged in "unfair and deceptive practices", and (2) that the disclosure they provided (which, on further research, was not a popup but a checkbox affirming agreement to a document, behind a "terms of use" link, which fully detailed the charges the customer was agreeing to) was inadequate.
I don't see how. The precedent shows that Stream EULA is a binding legal contract.
The precedent in question shows that "shrinkwrap" software licenses presented post-purchase are not invalid on account of having been presented post-purchase. I never argued that the license in question was a "shrinkwrap", post-purchase license in the first place, so the question of whether such licenses are valid is irrelevant; indeed, I'm accepting for the purpose of this argument that this contract is every bit as valid as a form contract written on paper and provided as a precondition of purchase of a physical product.
My argument, however, is that such a form contract -- allowing the "seller" to prevent the "buyer" from enjoying the use of a physical product at will, even if it does so by couching the use of said product as a pre-paid "subscription" -- is unconscionable for that reason alone, which I don't believe ProCD addressed. What reasonable person would agree to such a thing, if they believed that the seller would/could actually exercise such a clause?
Not relevant but I'm asking out of curiosity. Please define "smacked down". Has there been a judgment?
A high-dollar settlement with a regulatory agency, requiring a full refund to all customers.
My understanding (which could be wrong, I haven't looked into it in detail) is that in that case the terms were presented as part of the click-through install process, and that the user had an opportunity to inspect them and cancel the installation; instead, all the relevant users chose to accept the terms and go through with the installation.
Part of the problem is that the conversion scripts coming from CVS have to make up some data that isn't in the repository, but which all newer SCMs track.
If you get yourself to something modern enough to support multi-file transactions, to recognize rename operations, to store merge history, and to manage branches in a reliable way (creating a file on a branch in CVS can also create that file in HEAD... or at least, it did last time I used CVS in production) future conversions won't be as necessarily painful and/or lossy.
CVS isn't even reliable in terms of storing history in such a way that you can guarantee that you haven't lost something; when I was maintainer of cscvs, I had several users having problems because their,v files had gotten truncated somewhere way back; because that only impacted attempts to retrieve revisions prior to the truncation point, nobody noticed until their backups had already been fully rotated past that point. More modern SCMs have provisions in their data formats for validating repository validity, and even for checking changesets against deliberate tampering.
If you're legitimately concerned about your data, you'll get off of CVS at the first opportunity.
On the flip side we have legal precedent at the circuit/district level in Valve's favor.
The only precedent you've referenced is not squarely on-point.
Valve is not required to negotiate. Declining every counter offer made and sticking to the original offer is completely legal.
I agree that negotiability is not a precondition to a valid contract, but it does demonstrate a "meeting of minds" and make unconscionably more difficult to demonstrate.
Saying one thing and meaning another, but explaining in the fine print, is the norm in advertising.
Going too far in that direction is hazardous. You've seen the folks getting smacked down lately for selling "free" software but burying details of a required subscription in the fine print, right?
Might I suggest you look into the whys and the consequences of Three Mile Island and Chernobyl? Chernobyl was incompetence on a scale which will never be seen again, and Three Mile Island was inconsequential and harmless.
They're not "preventing the paid customer from enjoying it's use without cause".
In the hypothetical situation you describe, that is bluntly and obviously what they're doing on its face, and the use of the term "subscription" in their agreement is simply disingenuous.
What they are doing is canceling a subscription in accordance to the contract both parties agreed on before the customer paid for the subscription.
Depends on how good you are at spinning it to the judge; "subscription" has some implications which aren't applicable here. Without negotiability, however, it's hard to argue meeting-of-the-minds, making that contract more assailable than it might otherwise be. Further, while the fine print might imply otherwise, Steam tells people to "buy" or "purchase" a game, which strongly implies a one-time payment in return for perpetual use; arguably, this conflation between purchase and subscription provides grounds to argue intentionally deceptive behavior on Valve's part.
How does couching it in terms of subscription make it less unconscionable or unjust to accept money in a transaction marketed and advertised as "purchase" or "sale" of an item, and later prevent the paid customer from enjoying the use of the item which was billed as "sold" without cause?
As I argued before -- large companies frequently don't even bother to show up in small claims (making a default judgment a shoo-in), and in some states their representative can't be a lawyer (ensuring that even if they are represented, the sides are evenly matched). In the event that they act against me (unlikely, as I am doing and intend nothing contrary to the letter or spirit of the agreement), I'll take my chances in small claims.
Between that redress and (perhaps more significantly) the negative media attention which can be brought to bear if Valve takes such actions against their paid "subscribers", I'm not worried at all.
Slashdot Mirror
Frankly, I think you're arguing at this point for the sake of being contrary.
Sure, it makes sense. Look at faxes -- they're multiple pages of bitmapped images. Does that compose a "document"? Maybe. Is it something TIFF is good for? Absolutely! There are standardized tags used for storing extra information about fax transmissions in TIFF documents, and there's a great deal of software which makes use of that metadata. The same thing is true of archiving documents composed of scanned images -- there are a great many tag types associated with metadata such as scanner model and configuration, and software support for those tags is widespread.
I've also seen good use made of TIFF in the context of medical imaging (where flexibility and storage of multiple pages/layers and keeping arbitrary metadata is important), though there are other, more specialized formats which are also important in that space. If you have multiple images in a file (ie. multiple layers from a scan), does that make it a "document"?
The distinction between a "image" and a "document" is a hazy one at times, and I don't think we have a good enough description of the problem space the parent is working in to make the kind of judgment you're arguing for. Certainly, whether something is composed of more than one page is not the place to draw the line.
A specific and nonobvious mechanism for implementing a virus scanning engine... reasonable to expect that it would be patentable.
Putting a virus scanning engine on a gateway... no.
Your farmer's market might be accessible. Mine is way down south on the other side of downtown (whereas I live and work up north), meaning lots of driving and traffic and gas expenditure to get there and back. A half hour wouldn't cover one leg of the trip, much less any time shopping.
There are local delivery services for organic foods; tried that for a while, decided we couldn't afford it.
The "right answer" for one person isn't a suitable answer for everyone.
Bah. Use libtiff, document that only readers which also use libtiff (>= the version you're using) are supported, and you're done.
Yes, it makes sense for them to be multi-page. TIFF is a multi-page format -- it actually supports a huge number of subformats (and different compression algorithms) in addition.
The most effective compressors are commercial, but DjVu is a very effective image archival format; see DjVuLibre for the non-commercial tree.
Moving back towards the question in the article, I don't think there's much worry about either TIFF or PDF in terms of future proofing; they're both very widely used, have multiple implementations and third parties with substantial interest in keeping those implementations maintained, etc. The quality of TIFF implementations varies wildly, but the good ones are only going to get better, and I'd be shocked if libtiff ended up terminally bitrotted without a successor implementing a superset of its functionality inside my lifetime.
Not all of the US. Going around topless is perfectly fine here in Austin, for instance, as long as one can do so without causing a disturbance.
51% isn't enough to push an impeachment -- or to get anything else done if one angers the party holding the veto.
Okay -- you win the thread.
I'm relying on good faith on Valve's part, and may well not have effective redress should they act contrary to that intention; your decision not to make that reliance is an entirely reasonable one.
It's been fun.
I don't think your example is representative of the field: "A one-size-fits-all version control tool with a design that needs no hacks to make it work with any given development model" is exactly what Bazaar is intended to be.
Light checkouts and bound braches allow it to operate much like a traditional centralized SCM (with varying levels of space and bandwidth tradeoff), while its distributed operation provides all the available workflows of that model.
Tom Lord abandoned it, and most of the other core people jumped ship to Bazaar (and are now working for Canonical). Bazaar, as a result, has been extremely cautious not to make the same mistake, and focused on usability early in its development; I think it's come out to be a stronger project as a result.
Incidentally, bazaar has a Subversion plugin available; with that installed, SVK's interoperability with SVN becomes significantly less unique.
The price difference is relevant, as terms which overwhelmingly favor one side without reasonable compensation for the same is one of the tests for unconscionability. "Purchase a subscription" in not the wording they use when clicking on the button to indicate that one wishes to buy (what is presented as) a product; it may be the wording used in the license agreement subsequently displayed, but (largely on account of that distinction) that license agreement's applicability to the ongoing transaction is not immediately clear to the layman, and can be interpreted as a reaffirmation of the terms of use of Steam itself (without implication as to the product being "purchased", as purchase of a product is the manner in which the transaction has been presented up to and until that point, and the language of the agreement itself is the only indication to the contrary).
I'd ask my wife to weigh in here, but she's taking a week of vacation and has indicated she doesn't want to think about law in the interim.
I agree with you that this is too little, too late. That said, there's one respect where Git is well behind: Usability.
svn and bzr both have it beat -- hard -- in that respect; particularly svn, which has more pervasive tool support (but plenty of other disadvantages). That does little good, though, when you're picking a tool for use on a large project including artists, tech writers, win32 GUI developers, and other folks who have less of the appropriate inclinations.
I say this as someone using git on a daily basis. It's not a bad tool, but an end-all be-all it's not; for my own projects, I use bazaar.
Again, I believe unconscionability clearly applies here. The Steam agreement can be easily misunderstood by a layman to govern the use of Steam itself, as opposed to the software "purchased" via that mechanism. Bargaining power is strongly one-sided, the terms (as you've admitted) overwhelmingly favor a single party, and there's no price disparity when purchasing through Steam sufficient to make it clear that the buyer is being reasonably compensated for agreeing to these terms.
Think All Publishing, L.L.C. (and its principal and successor) and the Federal Trade Commission.
The FTC's argument was (1) that they engaged in "unfair and deceptive practices", and (2) that the disclosure they provided (which, on further research, was not a popup but a checkbox affirming agreement to a document, behind a "terms of use" link, which fully detailed the charges the customer was agreeing to) was inadequate.
My argument, however, is that such a form contract -- allowing the "seller" to prevent the "buyer" from enjoying the use of a physical product at will, even if it does so by couching the use of said product as a pre-paid "subscription" -- is unconscionable for that reason alone, which I don't believe ProCD addressed. What reasonable person would agree to such a thing, if they believed that the seller would/could actually exercise such a clause?
My understanding (which could be wrong, I haven't looked into it in detail) is that in that case the terms were presented as part of the click-through install process, and that the user had an opportunity to inspect them and cancel the installation; instead, all the relevant users chose to accept the terms and go through with the installation.
Part of the problem is that the conversion scripts coming from CVS have to make up some data that isn't in the repository, but which all newer SCMs track.
,v files had gotten truncated somewhere way back; because that only impacted attempts to retrieve revisions prior to the truncation point, nobody noticed until their backups had already been fully rotated past that point. More modern SCMs have provisions in their data formats for validating repository validity, and even for checking changesets against deliberate tampering.
If you get yourself to something modern enough to support multi-file transactions, to recognize rename operations, to store merge history, and to manage branches in a reliable way (creating a file on a branch in CVS can also create that file in HEAD... or at least, it did last time I used CVS in production) future conversions won't be as necessarily painful and/or lossy.
CVS isn't even reliable in terms of storing history in such a way that you can guarantee that you haven't lost something; when I was maintainer of cscvs, I had several users having problems because their
If you're legitimately concerned about your data, you'll get off of CVS at the first opportunity.
Might I suggest you look into the whys and the consequences of Three Mile Island and Chernobyl? Chernobyl was incompetence on a scale which will never be seen again, and Three Mile Island was inconsequential and harmless.
How does couching it in terms of subscription make it less unconscionable or unjust to accept money in a transaction marketed and advertised as "purchase" or "sale" of an item, and later prevent the paid customer from enjoying the use of the item which was billed as "sold" without cause?
As I argued before -- large companies frequently don't even bother to show up in small claims (making a default judgment a shoo-in), and in some states their representative can't be a lawyer (ensuring that even if they are represented, the sides are evenly matched). In the event that they act against me (unlikely, as I am doing and intend nothing contrary to the letter or spirit of the agreement), I'll take my chances in small claims.
Between that redress and (perhaps more significantly) the negative media attention which can be brought to bear if Valve takes such actions against their paid "subscribers", I'm not worried at all.