63
This AI Tool Rips Off Open Source Software Without Violating Copyright (www.404media.co)
submitted 4 months ago by to c/foss@beehaw.org
28 comments fedilink hide all child comments
 

Malus, which is a piece of "satire" but also fully functional, performs a "clean room" clone of open source software, meaning users could then sell, redistribute, etc. the software without crediting the original developers. But I have a hard time with the "clean room" argument since the LLM doing the behind-the-scenes work has already ingested the entire corpus of open source software -- and somehow the output of the LLMs isn't considered a derivative work.

you are viewing a single comment's thread
view the rest of the comments
[–] -3 points 4 months ago (2 children)

I know. But there are parasitic licenses that try to force your commercial software to become open source even if used as a minor component. That's stupid. And potentially dangerous to both the public, the asset producer, and the open source community.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 4 months ago* (1 child)

    Im not expressing an opinion on the viral nature of the licence itself, nor the pros and cons of FOSS, nor am I a FOSS evangelist of any kind.

    But you understand it's optional right? if you don't like it, don't use it.

    This isn't some gotcha, you can literally decide not to use the thing under the licence you don't like. That will solve 100% of the problems you are describing (though it sounds like it'd introduce new, non-licence based problems in whatever example you are thinking of)

    Well... I say that, but im actually not sure what you mean by "dangerous to the public", if you could go in to a bit more detail about what you mean there, I'd appreciate it

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 4 months ago (1 child)

    My issue with viral licensing is that it means you got to rewrite the code or use another product. Also software bom is a hassle.

    Some advanced manufacturing techniques rely on advanced software. So does infrastructure which is often only secured by obscurity. Also all software is filled with vulnerabilities which can get easier to exploit if you have access to the source code.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago* (last edited 4 months ago) (1 child)

    TL;DR;

    Sounds like a bunch of organisational issues using licensing as a scapegoat.

    Again, not giving an opinion on FOSS licencing pro's and cons, just on the implementation of licensing in general.

    My issue with viral licensing is that it means you got to rewrite the code or use another product.

    Or...comply with the licence.

    but yes, that's entirely the intention of a licence.

    You can use this thing as long as you adhere to the rules set forth, if you don't want to then feel free to create your own or find something with a licence more to your liking.

    They aren't forcing this on you, using these products is optional.

    Also software bom is a hassle.

    Absolutely.

    However, that feels more like a procurement/evaluation issue.

    e.g : "is bringing in this open source, viral GPL audio processing library worth the trade-off of dealing with the compliance vs paying money for a similar commercial product (or building our own)"

    Some advanced manufacturing techniques rely on advanced software. So does infrastructure which is often only secured by obscurity. Also all software is filled with vulnerabilities which can get easier to exploit if you have access to the source code.

    That sounds again like a person or persons have royally fucked up their evaluation/procurement duties when selecting the components to use in the building of the product a, quality/security/systems design issue rather than a licensing one.

    if complying with an open source license causes a product to become a danger to the public, many people, at many stages, have utterly failed to do their job.

    Also,i'm sure you know this, but security through obscurity is a poor systems design choice in almost all scenarios.

    As you say though, it does happen in the real world.

    In those cases someone needs to wear the grown up hat and evaluate the options available, such as removing or replacing the component that requires opening up your source code, or evaluating the trade off of how severe a risk opening up the source code is vs the costs involved in replacing it, or even the potential legal liability of just ignoring the licence.

    If you can't afford any options then your product isn't viable ( in an "everybody follows the rules" kind of scenario, at least).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 4 months ago

    Also,i'm sure you know this, but security through obscurity is a poor systems design choice in almost all scenarios.

    The only time I can think of from the top of my head where obscurity aids security is when secret keys are kept obscure. This isn't even what people mean by "security through obscurity" though, so I'd actually beg someone to give an example where obscurity is actually beneficial to security and doesn't just give a false sense of security instead.

    That's not to say everything can or should be open source, of course, just that relying on it being closed source for your application to be secure is a good way to open yourself up to attacks.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 4 months ago (1 child)

    If you're referring to GPL variants, that depends. You can absolutely use GPL software and libraries with closed source software. You just need to separate the GPL portions from the closed source portions with some sort of boundary, like running it as a service of some sort or turning it into a CLI tool. You're just not allowed to create derivative works of GPL software that isn't also GPL.

    Also, there should be nothing dangerous about open sourcing code (unless you're referring to financial risk to the business I guess). Secrets should never live in code, and obscurity is never secure.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 4 months ago (2 children)

    Pretty sure that e.g. manufacturing techniques for physics based design are highly problematic. So is the software for military communications. The real world is in fact real.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 4 months ago (1 child)

    Your first example isn't even code, and in your second if the "software" was remotely well architectured its configuration (not code) is what would need to be kept secret. You're also very rude!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago

    What does any of this have to do with GPL or open source licenses? Military applications all have strict validation requirements that rule out the majority of open source anyway, and your first example doesn't even explain how the software being open source would be dangerous at all. Actually, for that matter, nor does the military example. Encryption doesn't work because the other party doesn't know your algorithm lol, it works because the other party doesn't know your secret keys.

  • permalink
  • fedilink
  • source
  • parent