lib/licenses: mark watcom as non‐Free

[emilazy]

Although this license is approved by the OSI, Fedora, Debian, and the FSF all consider it non‐Free due to an onerous use restriction that requires publication of even privately‐deployed modifications (failing the “desert island test” and the “dissident test”).

See: https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Aleksanaa]

Would be good to add an annotation here (as it's not obvious)

[emilazy]

I have added a comment.

[SuperSandro2000]

Only affects watcom, uasm and through that virtualbox and 7zz. That alone doesn't sound bad at all.

7zz could be a problem as it affects some kde games and composer

nixpkgs/pkgs/development/php-packages/composer/default.nix

Line 102 in 862fc0e

_7zz

Maybe we can just swap it out for something else?

[emilazy]

Well, technically VirtualBox is a channel blocker through the OVA. But it’s broken precisely because of Open Watcom weirdness, so we’re switching to either using the precompiled assembly sources they provide and/or removing it from the channel blockers.

For 7zz, it looks like it is only used on x86_64-linux:

  # Only used for Linux's x86/x86_64
, uasm
, useUasm ? (stdenv.hostPlatform.isLinux && stdenv.hostPlatform.isx86)

Probably we could just disable that on all platforms and let it be slower?

[Aleksanaa]

We should probably appeal to one authority here (rather than to several) to avoid meaningless discussions based on this, because I'm afraid we don't have enough understanding of this kind of content, and even if you ask lawyers, they may have different opinions.

failing the “desert island test”

The Debian wiki specifically lists Vim license as failing desert island test, while we still mark it as free. Okay, here Debian's legal team has made a good start for us. What about other licenses? If there is ambiguity in interpretation, how should we judge for ourselves (we don’t even have an official legal team yet)?

[emilazy]

I believe the Vim licence issue was resolved, given that Debian continue to ship it. I see no such onerous publication requirement in the current version of the licence text, at least. Debian, Fedora, and the FSF all agreeing on a license’s unsuitability is pretty strong consensus IMO. If we do defer to one single authority, I would much prefer Fedora or Debian – who are in the same distribution‐making business as us – rather than the OSI which has made some interesting calls in the past.

[Aleksanaa]

I see no such onerous publication requirement in the current version of the licence text, at least.

When the maintainer asks you (in any way) for a copy of the modified Vim you distributed, you must make your changes, including source code, available to the maintainer without fee.

https://spdx.org/licenses/Vim.html

Which is probably why in Debian wiki they say:

For example, if the vim maintainer flies over the island and drops down a message saying "you must hereby send me your changes", how are the people down below to comply?

given that Debian continue to ship it.

So that either Debian is wrong ... or Debian is wrong?

[emilazy]

I don’t think you can attribute one email message by Thomas Bushnell (who is not a lawyer) that is cited as having happened to coin a commonly‐used rubric to the Debian project as a whole. The Debian project did make a decision on Open Watcom, which is why they did not package it, so we are not simply independently re‐applying their rubric ourselves. The Vim license clause also includes the text “When it is completely impossible to contact the maintainer, the obligation to send him your changes ceases.”; I wouldn’t be surprised if that was added because of that discussion, though I have not reviewed the history of Vim’s licensing, but clearly Debian’s position on the current version of the Vim licence is not the position that Thomas Bushnell had in one email message in 2002 about whatever version of the licence was current at the time.

By your standard, we would never make any changes to lib/licenses.nix at all before finishing an RFC bikeshed on establishing a legal team, and could never add new software with previously unknown licences because who can say whether they’re FOSS or not? I agree that our licence compliance needs a lot more work and better structure, but I consider this case to be fairly clear‐cut and I think making sure we actually comply with the basic notice preservation requirements of our unambiguously FOSS licences is a far bigger priority than appointing licensing czars. Note that we are the only distribution other than Haiku(!) that packages Open Watcom at all.

[alyssais]

What about other licenses? If there is ambiguity in interpretation, how should we judge for ourselves (we don’t even have an official legal team yet)?

We figure it out as they come up. Sometimes, the answer is just "wait and see", like in #265873. Usually, it's pretty clear, and that seems to be the case here as the distributions that put the most effort into compliance agree that it's non-free. Hard cases make bad law. We do not need to figure out all the edge cases to be able to make any decision.

[Aleksanaa]

You are right, the correct approach here is not to mention “desert island test” and “dissident test” at all. I don't think they are strictly coined terms to make formal judgments, and there is this difference between it and the actual practice that I mentioned above, which will only make people more confused.

A better way is to quote the FSF's own definition, which has been recognized for a long time and is the real source of "common practice":

You should also have the freedom to make modifications and use them privately in your own work or play, without even mentioning that they exist. If you do publish your changes, you should not be required to notify anyone in particular, or in any particular way.

https://www.gnu.org/philosophy/free-sw.html#four-freedoms

[Aleksanaa]

Suggested change

	# modifications, failing the “desert island test” and the
	# “dissident test”.
	# modifications, which is against the freedom to redistribute
	# copies.

[emilazy]

I have modified the message to mention the FSF’s rubrics before Debian’s rubrics, though I disagree that Linux distributions give the FSF’s rubrics especially more weight than the highly‐respected DFSG and its accompanying rubrics.

[emilazy]

#352610 was merged, so this should no longer prevent any non‐leaf packages from being built on Hydra and is ready for merge.

[Ma27]

7zz could be a problem as it affects some kde games and composer

fwiw composer seems to fall back on unzip if needed: https://github.com/composer/composer/blob/5a75d3241418c47128647c9d55e599dec492d406/README.md?plain=1#L56

Also, building composer is relatively cheap, so I wouldn't consider it that bad. Can't talk about the KDE stuff.

Feel free to perform the change here, otherwise I'd do it in a follow-up soonish.

[emilazy]

7zz should be fine now; I just disabled the x86‐only assembly, which probably makes it slower, but is less hassle than replacing it in every downstream package. (How come there’s both that and p7zip?)

[Ma27]

Apologies, was too focused on understanding the license topic itself that I missed that 7zz isn't directly using the license in question. Never mind then!