Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Crime Your Rights Online

Arrests For Selling Poison-Ware In Spain 178

An anonymous reader writes "Spain's FBI equivalent has arrested the management of a software company (Google translation; Spanish original) for selling custom software to small and medium-sized businesses with 'controlled errors' that resulted in the software bombing on a predetermined date. They would then charge for fixing the problem and press the client into buying a maintenance contract. More than 1,000 clients were affected."
This discussion has been archived. No new comments can be posted.

Arrests For Selling Poison-Ware In Spain

Comments Filter:
  • Microsoft (Score:3, Funny)

    by Dexter Herbivore (1322345) on Tuesday June 22, 2010 @08:08PM (#32660542) Journal
    Sooo, they were following the Micro$oft business model then?
    • Re:Microsoft (Score:4, Insightful)

      by Anonymous Coward on Tuesday June 22, 2010 @08:25PM (#32660644)

      There's nothing the least bit controlled about Microsoft's errors, so I fail to see how this could apply to them.

      • Re: (Score:3, Funny)

        Those who did not learn from the history of Windows 3.0 are doomed to repeat it.
      • Re: (Score:1, Interesting)

        by Anonymous Coward

        I don't agree, and I'm not saying they deliberately cripple the code. By going for cheaper development process they can ensure continued product enhancements and a much stronger need for product support in mission-critical environments. (ugh, did I say mission-critical? How come Microsoft products even end up in that sector???)

      • Re: (Score:2, Insightful)

        by mysidia (191772)

        That's right... plausible deniability.

        You have to pay for non-security bugfixes to Windows 2003 now, by buying a contract within 90 days of Jul 12, if you want support.

        There are no "bomb on X date" bugs, but who in their right mind doesn't think there will eventually think there will eventually be some nasty bugs found? :)

        • Re: (Score:2, Insightful)

          by mysidia (191772)

          [Er.... there are no known "bomb on X date" bugs]... Until the next Y2k-style event that is, when system clock reaches the maximum.

          Many 32-bit OSes will be screwed in Jan 2038.

        • by rjstanford (69735)

          You have to pay for non-security bugfixes to Windows 2003 now, by buying a contract within 90 days of Jul 12, if you want support.

          Which seems reasonable considering that the product came out 7 years ago, during which time there have been many free patches; also, a newer fully supported version was released 2 years ago. How long would you expect a company to maintain old versions of software for free?

          I'm pretty impressed that they're still willing to support it for money, quite frankly.

      • Re: (Score:3, Insightful)

        by pegdhcp (1158827)
        My dear Sir, the correct expression should be:
        "There's nothing the least bit controlled _by the user_ about Microsoft's errors."
    • by badboy_tw2002 (524611) on Tuesday June 22, 2010 @08:32PM (#32660688)

      Mod parent up! Epic slam at the '$oft, brah.

    • Troll? Some people around here have no sense of humour...
    • Adobe's ColdFusion kind of does such by not renewing the Java "trusted" certificate for older versions such that a warning pops up when using Java widgets from those versions. It's not a show-stopper because it's only a warning dialog, but it essentially forces an upgrade for serious businesses who don't want nag screens for their clients.

  • Shenanigans! (Score:2, Insightful)

    I hope they throw the book at them. They're basically holding their customers hostage.
    • Re:Shenanigans! (Score:4, Insightful)

      by Meshach (578918) on Tuesday June 22, 2010 @08:15PM (#32660574)

      I hope they throw the book at them. They're basically holding their customers hostage.

      Even worse, they are breaking some contract for sure. Bugs are one thing; every written piece of software contains bugs. But when you intentionally code the program to fail at certain intervals you are cheating the customers.

      What if cars were programmed to randomly stop at some random interval? GM's head would be served up on a plate.

      • Re: (Score:2, Informative)

        by Stoutlimb (143245)

        That kind of thing has been happening for generations, where have you been?. []

        • Re:Shenanigans! (Score:4, Insightful)

          by Meshach (578918) on Tuesday June 22, 2010 @08:29PM (#32660670)
          Planned obsolescence (planning for a product to go out of service) has no relation to selling someone a product that explicitly developed from the start to not do it's advertised capabilities.
          • by Stoutlimb (143245)

            Sure it does. There are varying degrees of that kind of behaviour, and some cross the line of legality, depending on what is promised in the advertising and contracts. XP was advertised to be very secure, but it won't be after they stop supporting it. I'm not even sure it's secure now. It's a matter of the company trying to get away with as much planned obsolescence as possible without being nailed by the law, and it happens all the time. This is just an example of planned obsolescence that is obviousl

          • by T Murphy (1054674)
            There's some expectation of the software being as error-free as possible (given they aren't advertising it as a beta). Intentionally including a bug could therefore be argued as going against advertised capabilities, if only implied capabilities.
        • by Ungrounded Lightning (62228) on Tuesday June 22, 2010 @08:37PM (#32660726) Journal

          [Planned obsolescence] has been happening for generations, where have you been?

          It's not always ENTIRELY shenanigans.

          For instance: The "design lifetime" in the auto industry is not just about selling another car. It's also about not spending a lot of extra money making, say, the transmission good for 750,000 miles when several other major systems are going to go out at a small fraction of that time. (When you're making several million units a year, saving a nickel each adds up to enough to hire two more full-time engineers to figure out how to do it.)

          Making mechanical parts that last can be tough and costly. (And half a century ago it was a lot tougher, without the major advances in materials science since then.) If you design all the parts to last for at least some design lifetime and not much longer you can accumulate a lot of savings. If some major system was going to unavoidably fail shortly after that design lifetime anyhow, having the rest not good for much longer doesn't appreciably affect the utility of the vehicle for the consumer. But the cost savings can be used to lower the price (and grab market share, for a net profit increase) - which DOES help him out significantly.

          The ideal in the limit is the "Preacher's marvelous one-horse shay, which lasted a hundred years and all fell apart on the very same day."

          • some cars have oil change light that only dealer can trun off. But there are other laws that stop the them going to far.

            Just wait for the AIR force to get shut off and then this carp will die fast and some may go hidden jail.

        • Re:Shenanigans! (Score:4, Insightful)

          by DigiShaman (671371) on Tuesday June 22, 2010 @09:41PM (#32661068) Homepage

          Per Wiki regarding software

          Software companies are sometimes thought to deliberately drop support for older technologies as a calculated attempt to force users to purchase new products to replace those made obsolete[citation needed]. Most proprietary software will ultimately reach an end-of-life point, at which the manufacturer will cease updates and support. As free software can always be updated and maintained by the end user, the user is not at the sole mercy of a proprietary vendor.

          Noticed that there's no mention of disabling a program or set of features on a set date. You can still run MS DOS if you wish for as long as you want. Just don't expect to get any support from Microsoft. You're on your own. That's the difference between planned obsolescence and poison-ware.

        • Re: (Score:3, Informative)

          by zwarte piet (1023413)
          There is a story of Henry Ford sending out employees to look on the salvage yards for Ford cars and write down wich parts would still be in excellent shape. If that happend too often for a certain part he knew he could use cheaper materials for that part in new cars.
          • Likewise there are stories about WWII fighter aircraft designers looking at beat-up planes, finding out which pieces hadn't broken, and removing material from them to make the plane lighter and more maneuverable.
      • by Fluffeh (1273756)

        Bugs are one thing; every written piece of software contains bugs. But when you intentionally code the program to fail at certain intervals you are cheating the customers.

        Doesn't that also fling the doors WIDE open for damages suits to be filed against the company for losses in the clients companies?

      • What if cars were programmed to randomly stop at some random interval? GM's head would be served up on a plate.

        I envision a future where all the use of all hardware and software is leased, and it can be disabled at will when the vendor changes the terms of service("terms of use are subject to change at any time") as per the EULA. Vendor just got sued for patent violations, wanna continue to run their software? Help pay their legal fees the extra $5 monthly surcharge. Wanna get back on the internet? Pay yo

        • This is kind of stuff that jigsaw guy does not like.

        • by enjerth (892959)

          Oh, so you want to get the customers on the hook, using software that's violating a hundred patents, and then make them pay again to keep using the software? Then if the user doesn't agree to the new EULA, shouldn't there be a refund?

          That's not the way EULAs should work. If the EULA changes and you don't agree, wouldn't that mean that the former contract is still agreed on by both parties? I mean, if EULAs are lawful contracts, then the only way to invalidate a former contract is to agree on a new contract.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        Then there is Toyota - their cars are randomly programmed *not* to stop at random intervals.


        fun captcha = Kicked

      • by JWSmythe (446288)


        Since you brought the car analogy in... :)

        Cars have a given lifespan. It's not totally precise, but it's good enough. Many parts are designed to wear. It's better for the manufacturer if the car lasts about 100k to 150k miles. You liked the car til it got old and started breaking down, therefore you buy another car from them. Manufacturers also maintain a lifespan where they will continue to produce replacement parts. From what I found online, that

        • by Golddess (1361003)
          And yet Craftsman and their lifetime warranty hasn't seemed to impact their sale of hand tools.

          And yet Jansport and their lifetime warranty hasn't seemed to impact their sale of backpacks.

          There may be others, but those are the only two I've had personal experience with.
          • by JWSmythe (446288)

            Craftsman has limits on their lifetime warranty policy. I worked at Sears for a while and had to deal with some of those returns.

            If the tool isn't being made any more, it may be replaced with a newer version.

            If the tool was used in a manner not consistant with it's proper use, it will not be replaced. If there are hammer marks in the handle of a screwdriver, or dents in the head of a ratchet, that shows misuse.

            If the tool was abused (i.e., rusted

      • by Golddess (1361003)

        But when you intentionally code the program to fail at certain intervals you are cheating the customers.

        Unless the contract stipulated that you only licensed it for use for x amount of time.

        Which, yeah, doesn't sound like that's what happened here, but just saying.

    • by mysidia (191772)

      Yes... I suppose the question is.. did they specifically pick an arbitrary date, just for the sake of generating revenue, or was there a reasonable technical justification for the limitation?

      Did they know about it or not? And if they did, then why did they not inform their customers of when the software would stop working and need an update?

      See... a LOT of software, that relies on dates and times, if still in service, is going to stop working on a certain X date, that X date is Jan 1, 2038.


  • And i made some decent money undoing their damage. Donno why the customer never bothered to press charges.

  • by Improv (2467)

    Some of us, regrettably, have seen business practices not entirely dissimilar to this in places we've worked. "I found a bug that could cause our really important software service to crash" "Don't fix it - wait until someone on a service contract reports it". Sigh.

    • Any business has to weigh priorities. If you are spending your time fixing bug X, then that means either bug Y or feature Z is not being done.

      Just because you know bug X exists does not mean it is more important than bug Y or feature Z, especially if no customers have reported it occurring.

      Of course this all depends on the nature of the bug and what you mean by "crash".

    • by LingNoi (1066278)

      Hold on a second dude. That's not similar at all. Not fixing a discovered bug in a years old client's software when they've not paid you to do it is simply business. If the client cares about it then they'll hire someone to work on it. You don't go back to a builder years after he's worked on your house and expect him to fix a mistake without payment, just because it's software doesn't mean reality changes.

      If that's what your company does then please hand out the URL. I'll be the first in line to say that o

    • by msobkow (48369)

      Personally I've never run into a company that didn't log the bugs encountered during development and testing. The question was whether they were considered high-enough priority to fix before release.

    • Wait? You ask for permission?

      Where I currently work, if we encounter a bug with a trivial enough fix, we'd just fix it. Especially if you are already working on that section of code for another reason. Though this way the fix would only be released in the next major version.

      If the bug is serious enough and might impact any existing clients we'd immediately raise a change request to track it and ask our client management / support staff if each client needs it fixed. (This is a pretty large software system

  • Why didn't I think of that?
  • Nice (Score:3, Insightful)

    by DoofusOfDeath (636671) on Tuesday June 22, 2010 @08:39PM (#32660742)

    In the US, the corporation, not the people, would be charged with a crime. And then they'd settle with the Government for a fine and no admission of wrongdoing.

    It sounds like Spain out-justiced the US this time around.

    • Re: (Score:2, Interesting)

      I'm not an expert but I'd say that depends on what kind of company it was. If you have a SRL (Sociedad de Responsabilidad Limitada, Limited Liability Company), they can go after you for fraud (the limitation of liability is restricted to debts), otherwise I think it's harder...

    • Re:Nice (Score:4, Informative)

      by mcoca (264601) on Wednesday June 23, 2010 @05:10AM (#32663034)

      The people were charged because it was a criminal case. Had it been a civil action, they would have gone after the company. Pretty sure it's the same in the US.

  • Hang on, isn't that a good thing, because it's creating 'more work'?


    When will some people start to realize that efficiency is all about reducing jobs, instead of creating them... sigh.

  • by Ungrounded Lightning (62228) on Tuesday June 22, 2010 @08:42PM (#32660764) Journal

    (Subject line says it all.)

    • The folks at the obfuscated C contest would like to point out that just because you see the source doesn't mean you'll easily be able to figure out what it's doing.

      • by Ungrounded Lightning (62228) on Tuesday June 22, 2010 @09:52PM (#32661108) Journal

        The folks at the obfuscated C contest would like to point out that just because you see the source doesn't mean you'll easily be able to figure out what it's doing.


        But it's a lot easier than with a closed source program with the code owned by the crooks.

      • How often does anything that looks like an obfuscated C contest entry actually get committed to a repository ?
        • Re: (Score:3, Funny)

          by nacturation (646836)

          How often does anything that looks like an obfuscated C contest entry actually get committed to a repository ?

          Check out any project on SourceForge that is written in Perl. :)

        • How often does anything that looks like an obfuscated C contest entry actually get committed to a repository ?

          If it's obfuscated well enough, you don't really know. That's the whole point.

        • by Mike610544 (578872) on Tuesday June 22, 2010 @10:52PM (#32661418)

          How often does anything that looks like an obfuscated C contest entry actually get committed to a repository ?

          It happens all the time where I work. I maintain some old code written by an old hacker (he's got a credit in the K&R book!) Shit like this is not uncommon:
          *(&z + z) |= ~tqq + m ? u9 >> 2: 741 | w & 0x8F ? ~(~t11) : foo

          • by SmallFurryCreature (593017) on Wednesday June 23, 2010 @02:17AM (#32662314) Journal

            I wonder which programmer should be more worried, the one who can't read the above, or the one who can.

            • by KiloByte (825081) on Wednesday June 23, 2010 @05:09AM (#32663028)

              In this case, the one who wrote that. And I don't mean just readability by novices.

              *(&z + z) -- unless it's C++, this makes sense only for referring to the zth next variable after z. Like: int z, a, b, c; -- z=1 will select a, z=2 will select b, z=3 will select c. In an old compiler, this will always work. In an optimizing one, it's damn likely to break.

              Mixing dec and hex numbers, and writing down constants for bit operations using decimal numbers in general is prone to mistakes.
              So is using addition in an expression that consist mostly of bit operations, you want | there instead.

              0x8F is a complex mask, it definitely should be a #define with a name. There's nothing wrong with masks like 0x7F or 0x1F, but for 0x8F, it's not obvious enough.

              ~(~t11) -- uhm, what's the point?

              With these issues fixed, though, with a bit of comments such a code isn't that bad.

          • I'd like to point out that the fact that perl allows this kind of aberration doesn't mean it enforces or promotes it.

            In fact, that code (or a very similar one) can be written in other languages, such as ruby.

            This just points out that the programmer in question had serious issues in understanding fundamental concepts such as maintainability, and was more interested in amusing himself than in doing a professional job.

            The credit on K&R doesn't mean a thing if you program like that on a day-to-day basis.

      • Unless the vendor is working on the software in its obfuscated form rather than using a processor to generate it, they would still be violating the GPL if all they released was the obfuscated source code.

        From the text of the GPL:

        The "source code" for a work means the preferred form of the work for making modifications to it.

      • by CAIMLAS (41445) on Tuesday June 22, 2010 @11:40PM (#32661612) Homepage

        Sure. And who, exactly, is going to contribute to an open source project written intentionally obfuscated? Nobody. Then the project gets the reputation of being shoddy, and nobody uses it.

        Or, there's also the "we'll just rewrite this little obfuscation and fork it" scenario.

        Open Source thrives on its quality and dies from crap like this. People don't contribute to dead projects: they fork them or reimplement them.

      • It's a very, very slim margin. You would have to have enormously talented programmers to be able to restrict errors to "controlled errors" while programming in such an obfuscated way, and you'd have to be more talented than the people trying to debug your code. To hide the error effectively, obfuscating a small amount of code would make the error obvious, but obfuscating large swaths of code would make the code unmaintainable.

        Even then, if you can view the source, you can usually make some kind of judgement

  • It was a feature :-).
  • by zennyboy (1002544) on Tuesday June 22, 2010 @08:50PM (#32660812)
    I live here in Spain and this doesn't surprise me. Meanwhile, back on the ranch, I'm surprised someone managed to program something so reliable they had to code in a time-bomb to make the software fail!

    Spanish coders did that!

    I'm proud :-)

    (English ex-pat)
    • Manager: Why is it programmer that all our software keeps failing? The customers are demanding a solution even if they have to pay it. Can't you just write code that works?

      Programmer: Eh...

      Manager: Mind you, it is a good thing it failed we can really use the income.

      Programmer: eh?

      Manager: It is almost perfect, we sell them code, then half a year later they got to come in to get it serviced. Like a timebomb goes of ensuring future profits.

      Programmer: Ah! Yeah, that is it sir. It is like your car needing

      • by Alex Belits (437) *

        Springtime! For Hitler! and Germany!

      • First of all: No Spanish worker will call his boss "sir". That's very much anti-Spanish. Just to give you an example: a recent unofficial competition asked Spanish people to come up with lyrics for the Spanish national Anthem (which is lyric-less). One of the candidates had the following text:

        "Un jefe muy cabrón / soy un buen español"

        Which translates to:

        "A very bastard boss / I'm a good Spanish citizen"

        Also, we use expletives when giving/receiving bad news. They are solely lacking on your text.

  • The article does not name the software company. Two of our main competitors timebomb their software - though it is written into the contracts, so its essentially above board. Still, I'd like to get a company name so that we can publish something to our customer base about this...
  • These guys should be hung in the public square especially the technicians that re-wrote the software to fail again after the "fix"
  • I've worked in a few places that have basically been held hostage with 'support' contracts for their shoddy products. They prey on total lack of knowledge and short term thinking.

    I recall identifying some changes that would reduce the need for the ongoing support and having such a company cost them unrealistically so as to price it out of our reach.

    They then resumed gouging us for UI changes that I probably could have done myself.

  • Sounds like Eliot Carver from Tomorrow Never Dies.

    I just hope they don't try to start a war between Britain and China.

      Oh, wait, wrong stereotypical nerd bad-guy henchman who can make satellites fall directly into the middle of a US city using a PDA with bluetooth and a Pringle's can antenna.
  • It's amazing how greed feeds on itself like an addiction. They could have fleeced a dozen or so companies and kept under the radar. Instead they moved on up bigger, wider, and bolder so much so that the risk of getting caught became almost a certainty. Enron and Madoff are also examples of this.

  • by mrjb (547783) on Wednesday June 23, 2010 @02:57AM (#32662502)

    Software bombing on a certain date, just so you can charge for "fixing" it is evil.
    But that assumes that the software was paid for to start with.

    I remember my father adding just this "feature" to the software
    of a difficult client that only requested feature upon feature
    but had a track record of being months late with their payments
    (not very nice if you have a family to feed!)

    When the payment was once again long overdue, the client was
    faced with a friendly dialog stating that the software was
    not paid for yet, and that it would only be re-activated after
    payment in full. The payment cleared less than 24 hours later.

    It probably would have held up in court, too.

  • Huh, thats odd. (Score:2, Interesting)

    by The Hatchet (1766306)

    Here in the US, not only is it not illegal to do that, but several companies hold patents on different ways of doing that. It seems to be heavily encouraged to ass-rape every customer you have ever had here, but there is actually a place where this is not so!!?!?!? EGADS!

  • It seems like, if you were a company that did this and were taken to court over it, you'd use the "How is this different from the Y2K?" defense? ;-/
  • by eennaarbrak (1089393) on Wednesday June 23, 2010 @06:14AM (#32663280)

    A friend of mine works for a company that sells software to a government department a central African country (I want to keep the details vague to avoid incrimination). After completing the contract and delivering the software, reps arrived one day and simply stated "We're not going to pay full price for the software - we're not making as much money out of it as we thought we would." This country does not have much of a justice system to appeal to if you don't have a politician in your pocket, so my friend's company intentionally released code to make the system stop working if the payments are late. AFAIK that fixed the problem.

    I'm just curios if these companies were perhaps faced with a similar situation...

  • A PHB tells Dilbert to tweak the software they sell so blah blah blah.

    Almost another case of life imitating art.

Keep the number of passes in a compiler to a minimum. -- D. Gries