12
Does the MPL 2.0 have a giant loop hole? (opensource.stackexchange.com)
submitted 3 months ago by to c/opensource@lemmy.ml
5 comments fedilink hide all child comments
 

It seems like you can trivially get around the intended rules of the MPL 2.0 by simply putting your changes in a separate file... and then you don't have to share 99% of your modifications?

all 5 comments

sorted by: hot top controversial new old
[–] 8 points 3 months ago (3 children)

That's not a loophole, it's the purpose of the license. The MPL was made to make embedding an otherwise open-source codebase into a new (non-open) project doable. There used to be several commercial products that used the gecko web engine and other mozilla code, and mozilla code was generally provided under a dual (MPL/GPL) or triple (MPL/GPL/LGPL) license so that developers could choose.

  • permalink
  • fedilink
  • source
  • hideshow 3 child comments
    •
  • [–] [S] 4 points 3 months ago* (2 children)

    Seems kinda pointless, no?... I mean, I get MPL is a weak copyleft license... but sheesh, that weak? If the consumers get to hide 99% of their code, why not just pick MIT? Having the consumers publish a 1 line change seems pretty worthless.

    I understand if I want stronger protections, I could move to a GPL license, but is there no middle ground? MPL doesn't really seem like middle... it seems like just 1 step away from MIT.

    LGPL seems interesting, but it doesn't really seem compatible with languages like Go, where everything is compiled statically.

    I guess I'm missing the context the MPL was created for.

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

    My guess would be that it's geard towards bugfixes. If a consumer discovers and fixes a bug in the original source, they're obliged to push it back upstream, or at least publish it so others can. Vut they still get the freedom of MIT to add new closed-source features or work it into a larger-scale closed-source project.

  • permalink
  • fedilink
  • source
  • parent
    • [–] [S] 1 point 3 months ago

    Spent some time reading this: https://rosenlaw.com/OSL3.0-explained.htm

    Section IV. Source Code And Derivative Works seems interesting.

    ... authorizes licensees "to translate, adapt, alter, transform, modify, or arrange the Original Work, thereby creating derivative works (" Derivative Works ") based upon the Original Work." ...

    Only the Source Code of the Original Work or the Source Code of a modified (altered, etc.) Derivative Work must be disclosed.

    If linking (by whatever technical means) can be accomplished by making and using unmodified copies of the Original Work, then 1(a) and 1(c) permit that; only the Source Code of the Original Work must be disclosed.

    I'm totally not qualified to comment on this, but it kiiiinda seems like OSL 3.0 would capture the work2.go file. At least, it doesn't seem to give up on work2.go as easily as the MPL 2.0...

    Maybe a better middle ground between GPL and MIT? It seems like: if you purely use my library, then you don't disclose anything. But if you touch my library, then you have to disclose the (entire) change?

  • permalink
  • fedilink
  • source
    •