back to article Log4j doesn't just blow a hole in your servers, it's reopening that can of worms: Is Big Biz exploiting open source?

The disclosure of a critical security hole in Log4j last week has renewed calls to rethink how open-source software gets developed, paid for, and maintained, not that the long-simmering issue ever really went away. The Log4j bug, an unauthenticated remote code execution flaw (CVE-2021-44228) in Apache's open-source Log4j Java- …

  1. elDog

    Don't forget the other bugs introduced by copy-n-paste software

    Log4J is a easily incorporated package so it shows up in many applications.

    There is also a ton of software that is wholesale lifted from one application and pasted into another. A few minor modifications to accommodate the new home.

    There are no serious integrity checks run on newly-acquired libraries or on code cruft. "It's been working before, it should work now.)

    1. AMBxx Silver badge

      Re: Don't forget the other bugs introduced by copy-n-paste software

      Modern software development is a 'house of cards'. Dependencies are multiple levels deep, there's no way to keep track of what's happening under the covers.

      I checked an application running on Tomcat yesterday as part of these problems. It was using the older 1.x version of Log4j so not affected. However, there were dozens of copies of the jar file scattered all over the place.

      This is no way to write maintainable software. Time for a rethink on all these frameworks and plugins.

      1. big_D Silver badge

        Re: Don't forget the other bugs introduced by copy-n-paste software

        And don't forget, version 1 has other security problems of its own...

        1. Anonymous Coward
          Anonymous Coward

          Re: Don't forget the other bugs introduced by copy-n-paste software

          Like being EOL'd for 5 years, and yet still being in use by corporate projects.

          1. Anonymous Coward
            Anonymous Coward

            Re: Don't forget the other bugs introduced by copy-n-paste software

            Since 2015 I believe

      2. Blank Reg

        Re: Don't forget the other bugs introduced by copy-n-paste software

        if you think that's bad, check out the mess that is modern Javascript development. Endless layers of libraries calling libraries. Start writing something using React or Node for example and you will have 1000s of dependencies in the first hour, and that can easily balloon out to 10k+

        1. Graham 32

          Re: Don't forget the other bugs introduced by copy-n-paste software

          My current project has a node component where the build generates 2GB of data in about 300k files. The final output is a zip of 12.5MB. And doing this on NTFS makes cleaning the build painfully slow.

          1. AMBxx Silver badge
            Joke

            Re: Don't forget the other bugs introduced by copy-n-paste software

            That's just for 'Hello World'!

        2. Wibble

          Re: Don't forget the other bugs introduced by copy-n-paste software

          Who was it that was fined millions for a poisoned JavaScript library that pilfered card details...?

    2. waldo kitty

      Re: Don't forget the other bugs introduced by copy-n-paste software

      There are no serious integrity checks run on newly-acquired libraries or on code cruft. "It's been working before, it should work now.)[sic]

      you know this is part of the problem, too, right? everyone checks for their "desired working output" but who in their right mind bothers to check for "undesired output"? i mean, this is what unit testing was developed for but who actually uses that any more? "it is too old!" "it is too '90s" whaaawhaaawhaaa

      this is in the same vein of not bothering to use stack or heap checking or even bothering to check that a buffer is large enough to hold what you are trying to stuff into it... this is the kind of c4rp that has allowed buffer overruns and so many of today's infestation techniques to proliferate... Kappa Kappa Kappa

  2. Anonymous Coward
    Anonymous Coward

    https://xkcd.com/2347/

    1. EnviableOne

      exactly how I described this issue to the higher-ups

      1. Cederic Silver badge

        Excellent suggestion. Certain managementy types I work with are now giggling without even realising they've been educated.

    2. Gene Cash Silver badge

      AKA the "iceberg problem" where 70% of the code is "below the waterline" and not really visible (and prone to sinking your project)

    3. Alan Brown Silver badge

      It's way worse than that.

      The person maintaining it starts copping abuse from entitled assholes to the point where it's a drag to keep running it and frequently gets hit with threats of legal action (or worse) when he finally says "fuckit" and throws in the towel

      It's like the anecdote of the guy in the rowing club who took on the task of cleaning the shed and hulls every week years ago so he could use them himself, misses it once and finds an abusive message on the noticeboard from the golden boys of the club to "whoever didn't do their duty". Most times such a volunteer will never lift a finger again

      1. Claverhouse Silver badge

        Just... unspeakable...

  3. Anonymous Coward
    Anonymous Coward

    Frameworks...

    There is an increasing tendency to use large and complex frameworks where only a small part is actually required.

    Proper testing would then require testing the entire framework, which clearly doesn't happen.

    Just cut down on all the massive bloated frameworks. At least make the default feature set as minimal as possible.

    But sure, businesses don't put enough back into the open source that they rely on. This is inevitable when something is free.

    1. devin3782

      Re: Frameworks...

      If I had a £ for every time I've said this I'd be able to fund open source.

    2. Anonymous Coward
      Anonymous Coward

      Re: Frameworks...

      I don't disagree overall, but I do disagree with the inevitability of it.

      An easy example are roads: everybody relies on that free to use infrastructure, and yet everybody is also required to pay for them via taxes, because it's long been understood that roads don't spontaneously sprout out of the soil.

      Maybe an understanding that FOSS isn't spontaneous generation is long overdue.

      1. Anonymous Coward
        Childcatcher

        Re: Frameworks...

        "and yet everybody is also required to pay for them via taxes"

        You don't pay your taxes to govt any more, you pay it to your freedom loving partner of choice.

      2. Anonymous Coward
        Anonymous Coward

        Re: Frameworks...

        Or it gets tacked onto the national deficit.

      3. SundogUK Silver badge

        Re: Frameworks...

        Who are you going to tax to pay for FOSS then?

    3. Doctor Syntax Silver badge

      Re: Frameworks...

      "But sure, businesses don't put enough back into the open source that they rely on."

      In this case, a feature added for big business according to TFA, perhaps one of those businesses should have written and tested it themselves and then submitted it to the maintainers for incorporation.

    4. Charlie Clark Silver badge

      Re: Frameworks...

      Done right, frameworks can dramatically reduce exposure to exploits by solving the NIH (not invented here) problem. But doing this right involves extensive software and penetration testing and, if problems are found, finding someone to fix them.

    5. Anonymous Coward
      Anonymous Coward

      Re: Frameworks...

      I don't think this was a money problem this was a brain-fart. It just doesn't seem to be a good idea for a logging library to perform external lookups that can bring in executable content. Just log.

  4. GeezaGaz

    But, but, but, but... Java is secure right?

    1. Blank Reg

      Any language is dangerous if you write stupid code. And what could be more stupid than providing a mechanism to execute remote code and having it enabled by default?

      1. Mark 65

        This is the real point. Free or paid makes no difference. One maintainer or a team of hundreds makes no difference. One really bad idea on by default is what matters.

    2. aaaa

      well, I only have 1 vendor application written in Java, and yes, it uses log4j.

      So far I'm not a fan of Java applications, because it doesn't seem like I as a customer can replace an application library with a newer version without the vendors help. Maybe that's just this application.

      It's not that the API is different, it's that the calling program is looking for library-1.1.1.jar and so I can't replace it with 1.1.1a.jar or whatever.

      For that reason, yes, I think Java (or at least this Java app) is very insecure.

      Bugs will be found. Updates will be needed. At least if the app is in C/C++ - I can just apt-get update to load a new ssl lib or glib and get the fixes with no intervention from the vendor of the app.

      So now we need to re-install this vendors Java application from source just so we can apply security updates...

      1. Charlie Clark Silver badge

        And who's paying to maintain those ssl libs or glibs? And who knows whether they're safe.

    3. Ian Johnston Silver badge

      Possibly not, but all open source software is secure because of all the people who read through and check the code. There isn't the slightest chance that, for example, a huge, horrible, insecure bug could persist in ssh for twenty years without anybody noticing.

      Oh, wait.

      https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-lets-crooks-log-in-just-by-asking-nicely/

      1. Plest Silver badge
        Unhappy

        Anyone CAN read FOSS source to ensure there's not security issues....but very few bother.

        1. Charlie Clark Silver badge

          There are numerous examples, but I think SSH is the most salutory one, where security issues persisted, sometimes for years, despite active maintenance, extensive peer reviewing and testing

  5. Howard Sway Silver badge

    Ignore all these megacorp whingers

    who could fund massive teams of developers to audit and maintain every bit of open source software they use, and still profit hugely from the donation of time and effort of other people who've kindly donated useful software freely to the community. Any company using open source should see it as a massive head start in getting what they want, rather than a finished end product.

    If they want quality assurance and support, then they should provide it themselves, instead of complaining that they can't make even more profit than they already do because community projects won't do what they demand.

    This just sounds like wealthy people whining that the volunteer open source contributors aren't making them enough money. It's the companies that need to understand that it wasn't written for that purpose, it was to share around something they thought might be useful to others.

    1. Anonymous Coward
      Anonymous Coward

      "no company pays their law firm on Patreon"

      No law firm will move a finger unless you pay them. And if you don't pay them handsomely, you'll find yourself in courts...

      Really a bad analogy. No surprise it comes from one of the worst open source exploiter.

      Anyway FOSS projects were promoted by big companies exactly because it produces "code for free". It allows them to cut expenses to develop code for whatever is not their core profit generators.

      The naive and quite religious belief that the "World would become better" and companies using code will happily contribute to each and every project is utterly flawed.

      Even GPL won't save the day with companies that just sell services, not software, so aren't bound to return anything to the "community" - and anyway there would be no way to check it.

      1. Alan Brown Silver badge

        Re: "no company pays their law firm on Patreon"

        Companies which sell services tend to write or adapt software to do it and derived works do get pushed back out

        GPL at least has a chance of that happening, BSD or Apache licensing is a black hole which allows parasites to thrive

        1. Charlie Clark Silver badge
          Stop

          Re: "no company pays their law firm on Patreon"

          The BSD licence was explicitly designed not to attach strings and encourage adoption, wherever possible: it was unix with bells. Without it we wouldn't have much of the excellent software and infrastructure and arguably even the internet. The GPL was always political and has largely been a commercial failure, which is why it's fallen out of favour.

    2. Anonymous Coward
      Anonymous Coward

      Re: Ignore all these megacorp whingers

      However, the article does miss the point that some companies do pay their own staff to work on open software.

      Here is the log4j dev team of 10 : https://logging.apache.org/log4j/2.x/team-list.html

      Of those 4 have an "organization" listed with their name. Don't know for certain that means their listed orgs are funding them, but probably so.

      1. Plest Silver badge

        Re: Ignore all these megacorp whingers

        While I appreciate you're simply adding some info to a discussion based on public info, I can imagine the devs of log4j are probably drowing in a tide of abuse and death threats right now and this sort of post will not help.

        1. doublelayer Silver badge

          Re: Ignore all these megacorp whingers

          They posted information relevant to the discussion I.E. whether the project has maintainers from the businesses supposedly exploiting it. Are you assuming that someone wants to send a death threat to the authors but wouldn't have done it except the link to a public page was posted here? It only takes thirty seconds to find that. Composing a death threat takes longer (I hope). I think your concerns may be unneeded.

  6. Phil O'Sophical Silver badge

    The solution is in their own hands

    The exploitation of open-source software by companies that use freely available without giving back to the community has been a sore spot among open source project maintainers for years.

    You can't give something away for free, and then complain that someone using it is "exploiting" it.

    Long before "open source" became the trendy term for it, lots of developers made their software "freely distributable". Those who didn't want big corporations freeloading just added conditions to their licence to say that the software was only free for non-commercial use. Commercial users were either barred, or free to negotiate a paid licence agreement. What prevents current FOSS authors doing the same? The software author owns the copyright, which means they have the freedom to decide how it will be distributed.

    Part of the problem is that many authors release their code in a genuine attempt to help other enthusiasts, and love the warm glow they get when seeing their weekend hack picked up and widely used/praised. It's only later,when they realise that someone else is making far more money out of it than they do, that they start to regret their initial well-meaning generosity.

    1. Anonymous Coward
      Anonymous Coward

      Re: The solution is in their own hands

      > Commercial users were either barred, or free to negotiate a paid licence agreement. What prevents current FOSS authors doing the same? The software author owns the copyright, which means they have the freedom to decide how it will be distributed.

      Ideological reasons aside, most FOSS of commercial value has a multitude of authors. How would the income from a paid license be distributed? Or would the company have to negotiate a license with each author?

      "Open-source" companies often try to get around this with requiring copyright assignments or contributor agreements, but then you're just moving the "exploiting free labour" from one commercial entity to another.

      Another question is what constitutes "commercial use". Eg. it has been argued that merely having display ads on a website makes that website "commercial", and thus would be required to negotiate a commercial license to use or distribute such software.

      Experiences of artists using Creative Commons Non-Commercial licenses are generally that most prospective users who would like to use a work for commercial purposes won't bother to negotiate a license, but just find an alternative they can use for free.

      The FOSS ecosystem is such that, if a project is unsuited to a particular set of users, an alternative to the project will likely arise. Especially when the prospective users are large corporations with a lot of resources. One would likely soon find the "non-commercial" project overshadowed by the fully free project started, funded, and marketed, by the large corporation.

      1. Anonymous Coward
        Anonymous Coward

        Re: The solution is in their own hands

        It is only a "question" whether it is commercial use when someone is trying to evade their bills.

        If you generate revenue with your site, it is a commercial operation, however small.

        Pay up.

        1. Charles 9

          Re: The solution is in their own hands

          Gross or net? That tells us whether or not you include such things as nonprofits in your qualification.

    2. Anonymous Coward
      Anonymous Coward

      @Phil O'Sophical - Re: The solution is in their own hands

      We can replace the word exploitation with let's say, abuse.

      1. Fazal Majid

        Re: @Phil O'Sophical - The solution is in their own hands

        It's not really abuse, more freeloading, really.

    3. Anonymous Coward
      Anonymous Coward

      Re: The solution is in their own hands

      When open source projects do this, they get pissed on and told they are not open source anymore and have exploited all the users that have supplied code as its no longer what they agreed too. Then their project is forked before the license change, a company, let's say making up one, Amazonia, then produces a version off that code, says its compatible, not being so with future versions and continues to sell it / provide it, getting other gullible users to contribute code to it for their profit, instead of helping fund the original projects by buying the licenses for commercial use.

      1. doublelayer Silver badge

        Re: The solution is in their own hands

        Yes, and I stand by this. If I have to choose which project to send my code contributions to, I generally choose the one where I get to use my code afterward over the one where I could then pay them for that privilege. If they want to charge for the project they helped develop, that's fine, but don't expect me to volunteer for their profit. Free software includes some level of generosity, and generosity doesn't always result in profit.

        1. Anonymous Coward
          Anonymous Coward

          Re: The solution is in their own hands

          But in general these licenses wouldn't exclude you from using it for free, that is, unless you are a large 'cloud' provider.

          Also ones that exclude all commercial use, for example, chef, you could still use in a commercial setting, you need to remove all references to chef in it.

          "Free software includes some level of generosity, and generosity doesn't always result in profit."

          Especially when the generosity is only seen from one side.

          1. doublelayer Silver badge

            Re: The solution is in their own hands

            "But in general these licenses wouldn't exclude you from using it for free, that is, unless you are a large 'cloud' provider."

            I don't like the ambiguity. What counts as a large cloud provider? If I run it on a server and sell the use of that to someone, do I violate the license? That's enough to make the license nonfree and it's enough for me to volunteer somewhere else. I don't need to feed a company that now has the position to do an invasive license check on me. At least Oracle doesn't expect me to fix their code for them.

            "Also ones that exclude all commercial use, for example, chef, you could still use in a commercial setting, you need to remove all references to chef in it."

            Sorry, I'm confused. I've never used Chef but it seems to be Apache licensed. And I also don't understand your statement: I can use a noncommercial thing as long as I remove it? I know it doesn't count if I just slice off the names (in fact that's something a lot of open source licenses require). I think you may be wrong about this.

            Me: "Free software includes some level of generosity, and generosity doesn't always result in profit."

            You: "Especially when the generosity is only seen from one side."

            It's an interesting ethical discussion. At what point do I have to return the generosity offered to me? If a company offers me something for free, am I obligated either to refuse it or to pay them in some way to return the favor? We would like companies to do that with open source that they rely on, and it would probably help them as well as the community, but I doubt people will tell me that I must find a way to give to a company with billions in profit because I downloaded something for free and benefited from doing so.

      2. Phil O'Sophical Silver badge

        Re: The solution is in their own hands

        their project is forked before the license change

        I'm not suggesting a post-release licence change, as you say it's too late by then. The time to consider this is before the first release, make sure that you've though through a the likely consequences of whatever licence/copyright statement you choose first.

  7. ZenaB

    JNDI concerns

    the Log4j vulnerability underscores the problem of catering to big business because the bug arose from a feature maintained to appease companies concerned about backward compatibility LDAP/JNDI URLs.

    So why was it enabled BY DEFAULT then? Let those one or two big businesses who need it enable it and keep everyone else running as expected!

    1. malfeasance

      Re: JNDI concerns

      Enabling it by default was a choice made in a kinder gentler age. That was the decision, turns out it was a poor decision viewed with the prism of what we know now.

      Once something is "in production" then backwards compatibility should be a goal. Breaking users expectations isn't something that should be done lightly which means that the status quo and inertia are quite a big anchor.

      1. Naselus

        Re: JNDI concerns

        "Enabling it by default was a choice made in a kinder gentler age."

        It was a choice made in 2014. We're not talking about something buried in the code since 1993 and forgotten about. The same behaviour existed and was disabled by default in every 1.x version of log4j.

        It's not like RCE vulns were completely unheard of seven years ago. I've a great deal of sympathy for the maintainer's complaint about getting zero corporate support for a FOSS package that appears to be running the log files of half the internet, but the decision to change it to enabled by default in version 2.0 was clearly a bad idea even when it was implemented.

      2. yetanotheraoc Silver badge

        Re: JNDI concerns

        "Breaking users expectations isn't something that should be done lightly"

        It's something that should be done with extreme prejudice when security is involved.

        Option A: Leave it enabled by default, some users get pwned, all users have to scramble once the CVE is created.

        Option B: Change it to disabled by default, no users get pwned, a few users have to scramble to re-enable it because of the "breaking" change but the majority never even notice.

        It's perverse to enable this by default because the users who need it are the ones most likely to be aware of the security implications. The ones who don't need it are mostly now saying WTF?

        1. Anonymous Coward
          Anonymous Coward

          Re: JNDI concerns

          Re Option B, because users are not updating their versions regularly, the fix could have been more drawn out. It would make the news that the patch was not back compatible for some users, and what the patch was for, and the hackers would start looking for the non-updates users anyway.

        2. malfeasance

          Re: JNDI concerns

          And yet they have done it with extreme prejudice haven't they, they've taken option-b and rightly so, but the decision to enable it by default is basically down to the Apache committer.

          If you look at the log4j jira and search for the original ticket (https://issues.apache.org/jira/browse/LOG4J2-313); the use-case seems reasonable on the face of it. With hindsight "we can all say, there's no way that's secure, don't be soft!". But, think about the sea change in security perspective in the intervening 8 years. How many of us employed by corporates have now been on mandatory secure-by-design training. If you've been with the same company for a while, when did the powers-that-be mandate it? (I suspect it was post equifax...)

          Developers are ultimately lazy and haven't been forced to have the discipline to consider all the side-effects of their changes on the entire system.

          To take a case in point, the javax package move to jakarta is one that irks me, because they've broken backwards compatibility in a completely nonsensical way. jakarta.mail.jar contains some "com.sun.mail" packages in situ, but have renamed all the javax.mail -> jakarta.mail. There's a circular dependency in one of the classes (a com.sun.mail class now takes a jakarta.mail class; this conflicts the same class that might have been provided by javamail-api.jar, because method signatures right)

          They committed the change, the unit tests passed, so they released jakarta.mail-2.0.0, because the unit tests passed 100% code coverage. It's all good.

          There are a lot of things out that that still depend on javax.mail.*, but this means that you can't include javamail-api-1.6.2.jar and jakarta.mail-2.0.1.jar in your classpath. Backwards compatibility is now broken irretrievably; there will be projects that pull an open source library that is orphaned (but serves its purpose) that depends on javax.mail (because javax.mail.mime isn't awful) and they can't upgrade to jakarta.mail to take advantage of security updates because they need working software.

    2. Anonymous Coward
      Anonymous Coward

      Re: JNDI concerns

      I wonder if some company who contributed to log4j, or had an employee on log4j dev team, put some pressure on to make that choice about the default value because it would be easier for them.

      About changing the default later - since the problem had less to do with creating the patch, and more to do with user realizing they needed a patch and figuring out how to apply a patch at their end, even if the change had been made earlier it would have an almost equally chaotic drawn out process to fix it.

  8. aaaa
    Devil

    Businesses are simply not in the business of fair dealing.

    The article says "Businesses are simply not in the business of fair dealing." but I think that generalisation needs unpacking.

    I've been responsible for a small open source project for almost 20 years.

    From the outset, I've seen a very big difference in how users in different parts of the world approach us.

    My technical lead explained it to me on day 1: the Germans can't use the software unless they've paid for it.

    Contrast that to a large American bank that asked me "are you going to sue us" (I said no) and they said "then we won't pay you".

    In another role, I've worked closely with a software vendor based in The Netherlands, and when they were bought by American Private Equity I watched with interest as the P/E firm came to realise they couldn't run the business into the ground because of the "employee board" vetoed any action which would be detrimental to the staff or the wellbeing of the company.

    I'm not trying to say business in Europe is all sunshine and roses, but that actually "fair dealing" can be a part of business, and is a part of business throughout the world (but maybe a little more in some parts than others).

    1. Gene Cash Silver badge

      Re: Businesses are simply not in the business of fair dealing.

      I'm not trying to say business in Europe is all sunshine and roses, but that actually "fair dealing" can be a part of business, and is a part of business throughout the world (but maybe a little more in some parts than others).

      Part of it is American law saying "anything not directly for shareholder benefit is basically illegal" and stuff like "inventory is taxable" despite it already being taxed when built, and taxed again when sold. This leads to the current problem exposed by COVID where no-one keeps inventory on-hand now. It also leads to things like books being quickly out of print.

      1. Anonymous Coward
        Anonymous Coward

        Re: Businesses are simply not in the business of fair dealing.

        The COVID supply chain problems are not a mere issue of "no one keeps inventory on-hand now."

        You can't keep inventory for sales "on-hand" when you can't GET the inventory to your warehouses because of problems with shipping or production.

        Besides, you think "inventory" gets kept for free? That is capital tied up, which is money, and somebody is paying for that money to be sitting there doing nothing. I don't blame ANY company for trying to "right size" their inventories.

        1. Anonymous Coward
          Anonymous Coward

          Re: Businesses are simply not in the business of fair dealing.

          Part of the whole JIT strategy was intended to leave a buffer on inventory on site to handle things like shipping problems, the fabbery burning down, etc. And because the shipping portion of it worked out well enough, some dim bulb decided to greatly reduce (or eliminate!) that buffer of inventory in order to save a few pennies and earn themselves a bonus, and then put on their surprised pickachu face when the fabbery burned down AND shipping went to hell in a hand basket. The US automotive industry played this one especially tight, which is why they can't get chips for their products not.

          There's "right size" done correctly, and then there's what we actually ended up with which is the current Charlie Foxtrot.

          1. Anonymous Coward
            Anonymous Coward

            Re: Businesses are simply not in the business of fair dealing.

            It is largely a question of what "reasonable odds" are.

            Certainly the combination of factors affecting the silicon producers are rather unique in the history of North America and would probably not even have been calculated. What are the odds of a global pandemic that lasts more than 2 years?

            Why are you picking on the auto industry? Have you tried to order computer parts lately? Or worse, whole systems?

          2. Alan Brown Silver badge

            Re: Businesses are simply not in the business of fair dealing.

            "Part of the whole JIT strategy was intended to leave a buffer on inventory on site to handle things like shipping problems, the fabbery burning down, etc."

            The Toyota Way (the basis of JIT) has hundreds of pages dedicated to this point and one of the poinbts of this is that in the aftermath of the 2011 earthquake Toyota bumped up their stockholding of semiconductors due to the downtime such events caused fabs - to the point of having a 7 month buffer. Similarly when other carmakers were cancelling orders they kept on ordering and accepting semiconductors

            That's why they were able to stay producing cars for so long and have had fewer cutbacks than other makers

            "some dim bulb decided to greatly reduce (or eliminate!) that buffer of inventory in order to save a few pennies and earn themselves a bonus"

            Yup, they read the first page of JIT philosophy and didn't bother with the risk assessments that go with it

        2. teebie

          Re: Businesses are simply not in the business of fair dealing.

          "You can't keep inventory for sales "on-hand" when you can't GET the inventory to your warehouses because of problems with shipping or production."

          That's...why you build up your inventory when everything is going smoothly, so you HAVE inventory in your warehouse when there are there are shipping and production problems

          1. Anonymous Coward
            Anonymous Coward

            Re: Businesses are simply not in the business of fair dealing.

            Conveniently skipping my points on risk assessment to bang on about some miraculous world where people sit on millions of dollars of parts in a stock room just because teebie wanted a Playstation 4 for Christmas... :)

            1. Charles 9

              Re: Businesses are simply not in the business of fair dealing.

              And THEN, when times are good, a rival firm running lean undercuts you because of the lower overhead and steals your business. See, it can cut both ways, and there's no way to predict which way it'll turn out tomorrow.

      2. Cederic Silver badge

        Re: Businesses are simply not in the business of fair dealing.

        Re: "Part of it is American law saying "anything not directly for shareholder benefit is basically illegal""

        Compliance the law overrides that specific mandate - including copyright laws. Breaching open source licences is not permitted just because it's better for the shareholders than paying a licence fee.

      3. Plest Silver badge

        Re: Businesses are simply not in the business of fair dealing.

        Do you know how books pass through Amazon for sale? They have to be on hand stored in warehouses that publishers rent space in to store millions of books so you can one-click and Amazon look like heroes for sending you in 24 hours.

        I know, my publisher has about 100,000 books right now sitting in a specialist book storage warehouse in the Midlands ready to be shipped the second a supplier like Amazone needs to buy 20 more copies. My publisher, a small one-man band rents the special temp/moisture controlled warehouse space at a very high price, to ensure high quality books can be sold quickly to places like Amazon.

        Oh yes, that's the other thing, Amazon and such like only buy a few dozen books at a time, or enough to ensure they only keep enough in stock to make quick sales. Amazon don't take risks or waste space with book storage, they leave all that on the shoulders of the publisher to worry about.

        1. Alan Brown Silver badge

          Re: Businesses are simply not in the business of fair dealing.

          "Amazon and such like only buy a few dozen books at a time, or enough to ensure they only keep enough in stock to make quick sales. Amazon don't take risks or waste space with book storage, they leave all that on the shoulders of the publisher to worry about"

          The solution for that is deep quantity price breaks. When I was purchasing from book wholesalers, buying in 100 books was only slightly more expensive than ordering 60 and 1000 copies only slightly more expensive than 600

  9. Doctor Syntax Silver badge

    "Corporations have a budget and are willing to spend, but it takes too much time,...Finding projects that need help and maintainers willing to help in exchange for money is hard."

    No harder than finding the projects they want to use. Check which projects you use. Find the maintainers from GitHub or wherever the project lives. Offer them money.

    1. J. Cook Silver badge
      Devil

      If you'll allow me to play devil's advocate for a minute or two:

      Some companies find it difficult (or impossible!) to pay the maintainer or author, because they aren't an authorized vendor, are not licensed to do business with the company without a three foot high stack of paperwork, or other corporate bureaucracy crap.

      There's ways around it (expense it through a purchasing card, launder the money through a friendly vendor that's already authorized, etc.) but it's still a pain.

      I'm not saying that it's morally right to not give back (it's not!), but corporates are sometimes just not set up to make it easy to do, or make it too much of a pain to do it.

      1. Alan Brown Silver badge

        This is a huge problem which keeps recurring. Finance departments really don't like dealing with this shit

        A clearing house for licensing/payments sounds like a nice idea but greed always takes over with the assholes skimming 80-90% (RIAA royalty model, etc)

    2. adam 40 Silver badge

      I tried offering money - it doesn't work

      If the Open Source developer doesn't even reply to your emails how can you get anything off the ground?

      In this case the co I was working for had a commercial use for the source but it had a non-commercial license.

      It takes two to tango!

  10. alain williams Silver badge

    I give to projects that I depend on

    Not a lot(I am an individual), but I figure that several £20 by many will add up.

    I encourage my customers to also give £20 to what they depend on - but I doubt that many do, in spite of spending a lot on the proprietary software that they use. They cannot see that giving little amounts will long term help what is vital to them - just expect others to pay. It is like climate change where everyone seems to expect everyone else to act to prevent a cataclysmic future.

    I also release some of what I do as open source.

  11. irrelevant

    Licences

    I've written lots of odd bits of code in my time; those which I've felt might be useful to others I've shared on github or other places. It's usually on a BSD licence, because it's simple, and these releases are more of a fire-and-forget thing. I have no expectation of making money off them.

    The one big project I've been working on has, so far, not seen a public release. I'm in two minds about this, though. It's been a lot of work, but as a commercial venture I've probably got less potential customers than I have fingers on one hand.

    Serves me right for mostly concentrating on stuff to support really obscure (these days) retro-tech I suppose! But it's fun, and makes me feel good, knowing I'm helping in some small way with preservation of our digital heritage.

    (compared to if anybody needs some freelance BOS\COBOL support, I'd be happy to revisit my old day-job to help, but I'll need some pennies throwing my way to get the same level of enthusiasm!)

    1. AMBxx Silver badge
      Megaphone

      Re: Licences

      >>> I have no expectation of making money off them.

      Can your users have any expectation that problems will be fixed? That's the nub of the problem

    2. Alan Brown Silver badge

      Re: Licences

      I use GPL, for the simple reason that nothing I do is highly original and I don't like seeing my work disappearing into someone's proprietary expensive product without acknowledgement

      To my mind, a "must contribute back to the commons" rule is a form of enforcing "pay it forward"

  12. Starace
    Devil

    Whinging ideologue developers

    If you do something and hand it out for free you can hardly expect to whinge when people use it; if you want to be paid for your efforts then charge, otherwise just accept that your stuff will be 'exploited' if you haven't excluded that option through a contract.

    The other issue with projects with a small developer team - and especially when one or two people drive most of the dev - is that they tend to become very protective of their project and ignore or reject any offers of input. External bug reports and code submissions get ignored. So even when the evil corporate bastards spend the time to check the code, find the faults and provide assistance it doesn't get accepted.

    Funnily enough lots of OSS does get plenty of support and submissions from corporates spending engineering time on them, it's only certain things that stay stuck with the 'volunteers' who own the project. So maybe it's a people issue not a philosophical one?

    1. Alan Brown Silver badge

      Re: Whinging ideologue developers

      It also leads to code forking and some interesting religious arguements in OSS projects - especially when the project starts out really well but the initiator retires and the corporates who take it on are more concerned with profits or "purity" than what the end users actually want

  13. Bitsminer Silver badge

    what's hard

    "Finding projects that need help and maintainers willing to help in exchange for money is hard."

    No.

    OpenBSD, OpenSSH, OpenBGPD, LibreSSL...

    Python

    There are other organizations that distribute funding and equipment for open-source software.

    1. EnviableOne

      Re: what's hard

      agreed, anyone using Log4j just had to pay dues to the apache software foundation, and its easy to do

      1. Cederic Silver badge

        Re: what's hard

        Hmm. Funding the Apache Foundation is a moral and just thing to do, and would help with the hosting costs for Log4J, but is distinct from funding the developers/maintainers of Log4J itself.

        1. -tim
          Facepalm

          Re: what's hard

          The Apache foundation was helping the odd good project and then it adopted a Tomcat. It has now became a crazy cat lady. It needs to learn to say no more.

  14. Anonymous Coward
    Anonymous Coward

    Maybe Tech companies undertake to donate 1% of revenue a year to OS ?

    Better than most of the virtue signalling they do.

    1. Anonymous Coward
      Anonymous Coward

      Re: Maybe Tech companies undertake to donate 1% of revenue a year to OS ?

      And how are you going to distribute it among FOSS developers?

      1. Anonymous Coward
        Anonymous Coward

        Re: Maybe Tech companies undertake to donate 1% of revenue a year to OS ?

        I expect companies will have their favourites, run a poll among their employees or ask a distinguished OS guy or two to make some recommendations. Hardly difficult.

        1. Anonymous Coward
          Anonymous Coward

          "I expect companies will have their favourites"

          It's exactly what happens now. Linux Foundation gets $177M a year, and other projects widely used don't get enough, and maybe not at all.

          Wasn't PHP that told it was actually a couple of developers? How much money and support got OpenSSL before it became clear it became a liability?

          Funding open source projects is far more complex than you think. Especially now any software could be easily made of hundreds of dependencies....

  15. Anonymous Coward
    Anonymous Coward

    > Is Big Biz exploiting open source

    Can we stop this mindset? No one is being exploited. Every is a volunteer, and the licence they choose explicitly allows this. It is for this. Open source is not exploitable - the software is provided without warranty.

    The issue doesn't re-open a can of worms; articles such as this do. Until we get past this silliness, we aren't going to improve anything. And if we stick with this silliness, we might drastically reduce the relevance of open source software worldwide.

  16. The Empress

    Expensive software is rarely better though

    Your main assumption, that big corps use 'free' software because it's free and good enough even when it breaks, ignores another equally important aspect. Paid-for software, often very expensive paid-for software doesn't do a great job of preemptively finding problems and correcting is, let's say, uneven. Moreover when you stumble into a major problem with their software, good luck getting it fixed unless you're a huge company or a nation-state.

    1. Alan Brown Silver badge

      Re: Expensive software is rarely better though

      "good luck getting it fixed unless you're a huge company or a nation-state"

      THIS is exactly the reason why my employers tend to gravitate towards opensource. We also contribute back to the pool.

      It's "free" because I'm being paid to write it. Not all free software is being put out by hobbyists (and not all free software is zero cost)

    2. J. Cook Silver badge
      Go

      Re: Expensive software is rarely better though

      ... like some of the long-standing issues with Microsoft's products that are classed as "won't fix".

      Finding the responsible person for some obscure IBM Product that even the company that sold it to you can't even find.

      Like finding out that a certain corporation that took on an open source product decided to start demanding licensing fees, because Larry the CEO needs a new 100 foot yacht because last year's model is no longer shiny.

  17. Anonymous Coward
    Anonymous Coward

    resistance to paying for software

    "Yet the notion that companies will ante up if just asked nicely using corporate vernacular, rather than gig economy tooling, doesn't sit well with everyone."

    I've seen projects of mine save companies hundreds of millions of dollars whilst costing me thousands - and whist the companies in questions were happy to crow about the savings, a suggestion that they fund the project before it went under was usually met with an assertion that they couldn't afford to do that.

    Until about 30 minutes after projects get permanently switched off - by which point it's just too late

  18. Lorribot

    For me the most shocking thing is the amount of vendors saying "we are okay as we ship a version that was before the problem was introduced". IE version 1.x.

    Yes, but that version went EoL in 2015 and has a number of CVE listed against it which are unpatched so you are not in a safe place are you?

    I am looking at Microsoft, ships this in the the Extensions folder for SQL 2019 and Visual studio 2017 and maybe others, SAP, IBM and numerous other other companies that really should know better.

    If you are going to ship other companies products/plugins and other buggy crap you really need to make sure it is kept on a supported version and you bundle it up in to your own regular support releases, which is certainly not the case with Log4J and I suspect some of the other flavours of Log4 such .NET and PHP.

    1. adam 40 Silver badge

      But that's a problem too, hoovering in upstream latest and not-so-greatest with the latest zero-day attacks or worse, intentional vulnerability injections.

      If you do it properly, you start with a version, freeze it, and then patch only the relevant security fixes on top.

      I found that, after a while, the security fixes that _were_ relevant became vanishingly small, because no new unwanted functionality had been dragged in with its associated vulnerability baggage.

      1. Lorribot

        But

        Yes, but that version went EoL in 2015 and has a number of CVE listed against it which are unpatched so you are not in a safe place are you?

  19. This post has been deleted by its author

  20. Ian Johnston Silver badge

    Misquotation

    Gonzalez argues that Log4j is a symptom of a larger problem: that public companies are exploitative and abusive toward open-source projects.

    She didn't. She actually wrote (in th eblog post to which you link) "The log4j incident is a symptom of a larger problem: many large and publicly-traded companies are exploitative and abusive and open source projects that simp for these large companies aren’t doing themselves any favors.". The closest she gets to your claim is a bit later: I’m not an expert on fixing this problem, but I also don’t believe that open source developers need to accept exploitative working conditions.

    Deserves a bit of editing, I think.

  21. steviebuk Silver badge

    Could it also be

    similar to what Cliff Harris of Positech Games mentioned in his blog recently. That too many job applications require the applicant to be familiar with 10 different languages. He said this then you get someone who is mediocre in lots of different ways. Instead of asking people to speciallise and just be really good with one language.

  22. J27

    A Feature of the System

    I personally believe that the primary reason open source exists is to be exploited by big business. Big businesses fund open source because it would cost them a lot more to do all the development in house. Sure, there are some awesome developers who just post code because they can, but a lot of it is funded by big business, for big business and the rest of us just latch onto it like lampreys.

  23. Omnipresent Bronze badge

    Java is so 1990's

    You should have stopped using java decades ago, so.....

    1. waldo kitty
      Facepalm

      Re: Java is so 1990's

      Java is so 1990's

      You should have stopped using java decades ago, so.....

      sounds like you are also saying that COBOL, FORTRAN, ADA, and even C and its derivatives should also not be being used... are you suggesting that we should return to ASM or is that also ""too old"" for you?? i mean... Kappa

      1. oliversalmon

        Re: Java is so 1990's

        Plus C++, Python etc which are all older than Java

  24. Adam Inistrator

    "At the end of the day, companies are responsible for ensuring the code they ship to production is safe, secure, and reliable,"

    Open source maintainers dont ship to production. They ship to repository. The users of those repositories ship to production and are therefore responsible to ensure the code is safe and secure. Since open source has many advantages over closed source make this a value judgement. Is the poor chain of responsibility in open source worth it or not? There is no way to force the big open source users to connect with the open source producers but finding new ways to fund open source like patreon etc. could improve the situation.

    1. Cederic Silver badge

      Depends on the project. LibreOffice is shipped to production.

    2. jasonbrown1965

      at the end of the day, it's night.

  25. Claverhouse Silver badge
    Angel

    The Closed Source Solution

    Obviously since all Open Source efforts are exploitive and wicked, things are better off when reliable big tech holds all the keys, meaning nothing insecure or poor quality is released in their products.

    Perhaps all these small but vital implementations and their codes [ such as OpenSSL, whose Heartbleed caused the Apocalypse and devastated a generation ] should be handed over entire to a benevolent SuperBoss, or consortium of SuperBosses, such as Larry, Bill, Jeff, Apple and the CIA to control forever, and protect private enterprise in all its glory.

  26. TheMeerkat

    Open Source created a culture of importing tons of third-party libraries. If they cost money, we would not do that - if a developer has to go to the management they would not do it for something that they can develop themselves.

    Open Source also created a situation when nobody can make a living from developing tooling for others, as you can’t compete with free.

    If you are a programmer, Open Source is not beneficial for you.

    1. Cederic Silver badge

      As someone that's used and contributed to open source software for decades I disagree entirely.

      People picking up litter reduces the demand for street cleaners but everybody in the village benefits.

      1. TheMeerkat

        People picking up litter reduces the demand for street cleaners but everybody in the village benefits.

        Except those who used to be employed as cleaners and are now unemployed…

  27. Anonymous Coward
    Anonymous Coward

    I don't think it is unreasonable to expect to get some support for a project and its team from the corporations that use the source in whatever form. In an honest world, the likes of Amazon would feel obligated to pay some meagre millions to each of the projects they've built their business on every year, the same way they make money off the sweat of those projects year after year.

    But if anyone ever thought "industry" had "integrity", well, the truth is out there in the form of many tens of thousands of unsupported open source developers, if not millions.

    It would almost have been worthwile to leverage something like the Log4J bug when it was discovered to enact some penalties on the industry. Unfortunately, the people who work on open source projects have too much pride in their work to actually do something like that, no matter how justified I think it might be... :)

  28. glennsills

    Was CloudFlare open source?

  29. APA

    I had a developer on my project that had a tendency to run into an issue and find a library to incorporate to solve it, rather than re-purposing an existing solution in a library we already had. Combine that with dependencies having their own dependencies, when it comes to a version bump it can quickly become unmanageable figuring out they all interact and what is even safe to bump. Consequently I've always thought the fewer externals the better, and if you do bring one in make good use of it.

    One of the dependencies (indirectly) brought in was SLF4J which has proved to be a god-send and dodged a bullet for me with regards to this Log4J issue (hey, a stopped clock is right twice a day, right?). The gist of library being that it's an API abstraction of a logging library, the implementation of which can be wired up to a JUL (or Log4j, or even nothing) at deployment. The developer in question had somehow completely wired it up backward by using the slf4j-log4j compatibility layer instead (intended for codebases that have already used Log4J to move away without actually having to change code) but somehow brought IN log4j-core and a whole heap of errors on the console. After he left and I was cleaning up the mess of dependencies I actually read library's documentation(!), kept the abstraction and re-pointed the implementation to use the library the EE application server already had (payara itself uses JUL so I could piggy back off that), now happy that logging actually worked and (perversely) there were less errors in the console.

    Long story short, thanks to that developer who horded libraries I discovered http://www.slf4j.org/index.html which ended up reducing the dependency footprint by allowing re-use of something already available. Can't help but think that other people may now find the compatibility layer quite useful. The theory goes that you can just replace the .jar with news ones at runtime - no compilation required http://www.slf4j.org/legacy.html#log4j-over-slf4j .

  30. jasonbrown1965

    Funding FUDGE fogs up log jam FIGHT

    Interesting?

    Unless me and my ctrl+F are much mistaken, all mention of "funding" or even 'fund' seems to have disappeared from the blog post linked for #tailscale.

    Given that tailscale has been mentioned elsewhere in a similar manner to systemd - too much of a good thing in one place - removal of references to funding for open source software a la logj (if that is indeed what happened) seems to sugest this is something of a sensitive subject?

    If this was the old register, a headline might have been:

    Funding FUDGE fogs up log jam FIGHT

    Speaking of which, admins, what did happen to the SHOUTY headlines?

    Really miss the irreverence. No more biting hands that feed?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like