4 ms·

MPL is a copyleft license, actually, just like EPL and EUPL. What it is not is a viral copyleft license. Anyone making changes to TF code and productionizing it

MPL is a copyleft license, actually, just like EPL and EUPL. What it is not is a viral copyleft license. Anyone making changes to TF code and productionizing it is expected to contribute back but only the direct changes to TF itself, not the extensions around it. That's my reading of EPL/MPL/EUPL. Does that match your reading?

bayindirh 3y ago
You're right. MPL is a weak-copyleft license. I mistyped it, I don't know why. Fixed my comment with a note, thanks. However, it still allows your code to be bundled inside a bigger work. The bigger work can be in any license (maybe not GPL, need to check), but MPL stays MPL. This doesn't prevent white-labeling the codebase, though. As far as I read the MPL, the contribution back part is not mandatory, but encouraged by not affecting the larger work. It keeps the MPL part open, but doesn't enforce a "send patches back" policy.
- smarx007 3y ago
  > As far as I read the MPL, the contribution back part is not mandatory That's not how I read it. > the contribution back part is not mandatory In that case weak copyleft would not be any different from MIT/BSD. First, assuming you are distributing only the larger work: "3.3. Distribution of a Larger Work You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. [...]" Assuming the covered (OSS) work is distributed as an executable: "3.2. Distribution of Executable Form If You distribute Covered Software in Executable Form then: (a) such Covered Software must also be made available in Source Code Form, as described in Section 3.1 [...]" Finally, 3.1: "3.1. Distribution of Source Form All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License." The only wiggle room I see is not triggering the distribution clause by a SaaS-only offering. By the way, EUPL is a non-viral copyleft license that closes the SaaS loophole in MPL/EPL/LGPL.
  - bayindirh 3y ago
    By contributing back, I mean rolling up a patchset (or a tar of your source tree) and sending back to upstream. Otherwise, I think I clearly noted that the MPL part's source stays available whatever you do by saying "MPL part stays open". It's not the earliest hour here, so sorry if I can't articulate my thoughts clearly. You need to keep MPL part's source open and accessible, yet MPL doesn't prevent abuse like permissive licenses, much.
    - smarx007 3y ago
      True, sending back to upstream is not required by the license. But even AGPL does not require this. Rolling up a tar of your source tree, however, will be required if you get a request from one of your customers by email. The difference from GPL is that you will only have to tarball a portion of the tree that was MPL-licensed. That tar must include your patches, as §3.1 requires. As I said before, many companies argue that using a private fork of an MPL/EPL/LGPL software in a SaaS does not trigger the distribution clause as customers never get a source or a binary of the program that runs in the cloud. EUPL closes that loophole. It's also possible that many companies violate EPL/MPL/LGPL terms (knowingly or unknowingly). One good example of non-viral copyleft working as intended is the Eclipse IDE. There are many closed-source tools that use Eclipse IDE under the hood (the part that Eclipse calls RCP), but there are no commercial forks of the IDE itself because any such company would have to open-source their changes to the fork.

bayindirh 3y ago

You're right. MPL is a weak-copyleft license. I mistyped it, I don't know why. Fixed my comment with a note, thanks. However, it still allows your code to be bundled inside a bigger work. The bigger work can be in any license (maybe not GPL, need to check), but MPL stays MPL. This doesn't prevent white-labeling the codebase, though. As far as I read the MPL, the contribution back part is not mandatory, but encouraged by not affecting the larger work. It keeps the MPL part open, but doesn't enforce a "send patches back" policy.

smarx007 3y ago
> As far as I read the MPL, the contribution back part is not mandatory That's not how I read it. > the contribution back part is not mandatory In that case weak copyleft would not be any different from MIT/BSD. First, assuming you are distributing only the larger work: "3.3. Distribution of a Larger Work You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. [...]" Assuming the covered (OSS) work is distributed as an executable: "3.2. Distribution of Executable Form If You distribute Covered Software in Executable Form then: (a) such Covered Software must also be made available in Source Code Form, as described in Section 3.1 [...]" Finally, 3.1: "3.1. Distribution of Source Form All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License." The only wiggle room I see is not triggering the distribution clause by a SaaS-only offering. By the way, EUPL is a non-viral copyleft license that closes the SaaS loophole in MPL/EPL/LGPL.
- bayindirh 3y ago
  By contributing back, I mean rolling up a patchset (or a tar of your source tree) and sending back to upstream. Otherwise, I think I clearly noted that the MPL part's source stays available whatever you do by saying "MPL part stays open". It's not the earliest hour here, so sorry if I can't articulate my thoughts clearly. You need to keep MPL part's source open and accessible, yet MPL doesn't prevent abuse like permissive licenses, much.
  - smarx007 3y ago
    True, sending back to upstream is not required by the license. But even AGPL does not require this. Rolling up a tar of your source tree, however, will be required if you get a request from one of your customers by email. The difference from GPL is that you will only have to tarball a portion of the tree that was MPL-licensed. That tar must include your patches, as §3.1 requires. As I said before, many companies argue that using a private fork of an MPL/EPL/LGPL software in a SaaS does not trigger the distribution clause as customers never get a source or a binary of the program that runs in the cloud. EUPL closes that loophole. It's also possible that many companies violate EPL/MPL/LGPL terms (knowingly or unknowingly). One good example of non-viral copyleft working as intended is the Eclipse IDE. There are many closed-source tools that use Eclipse IDE under the hood (the part that Eclipse calls RCP), but there are no commercial forks of the IDE itself because any such company would have to open-source their changes to the fork.