cross-posted from: https://ponder.cat/post/1631485

Open source software projects are frequently enmeshed with the interests of corporations. We should update mental models of who works on open source accordingly, and build or modify power structures to be more resilient to corporate capture.

  • refalo@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    6 days ago

    In my experience most of the people that are vehemently against corporate influence in open source, are just against capitalism in general.

    But most people don’t want to drop off the grid and go live in the woods… a middle-ground compromise would be nice.

    • AnyOldName3@lemmy.world
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      6 days ago

      The Free Software movement was generally a leftist objection to the limitations on computer use that capitalism was causing, and the open source movement was a pro-corporate offshoot to try and make the obvious benefits more compatible with capitalism (which it’s been pretty successful at, even if it has reintroduced some of the problems Free Software was trying to stop in the first place). Anyone who’s making a distinction between the two at the minimum is recognising that capitalism is why we can’t have certain specific nice things, so it’s not a huge leap to blame it for other problems, too.

      As for a sensible middle ground, the Free Software movement designed its licences to work in the capitalist societies they operated in, so the incompatibility with corporate use has never been as big a deal as it’s been made out to be. Corporations can use copyleft-licenced software just fine as long as they’re not unreasonable about it. It’s totally fine for a corporation to use a GPL tool internally and even have an internal fork as long as they put the source code for their internal fork on the company’s file share so the employees using the tool can improve it if they get the urge. They can even sell products that depend on LGPL or MPL libraries if they make the source of the builds of those libraries they used available on their website or otherwise accessible to their customers (and use a DLL/.so/.dylib build of the library of it’s LGPL). These restrictions are all less of a pain than making an MIT-licenced clone of an existing project, but companies have opted to make clones instead. The only bonus this gives them is that they can make it proprietary again later, and it has the added risk that one of their competitors could make a proprietary fork with a killer feature they can charge for, which isn’t a nice risk. There are other benefits to investing in making your own clone of something, but they don’t depend on the license it uses.