Created attachment 863825 [details] discussion with ulm The other day, someone on IRC raised a concern with the @FREE license group, noting specifically that three licenses that are explicitly FSF-disapproved are permitted by the set, these being: - The NASA Open Source Agreement (NOSA) :: a license approved by the OSI, but not by the FSF[1] or Debian[2] (though, the latter seems to have had less discussion about this license than the former, with [2] being the only decisive statement about it I could find), as the license states: "Each Contributor represents that that its Modification is believed to be Contributor's original creation", - The Sybase Open Watcom Public License (Watcom-1.0) :: a license approved by the OSI, but not the FSF[3] or Debian[4] as it has a pretty large flaw in section 2.2 (c): "You must make Source Code of all Your Deployed Modifications publicly available" - The Artistic License 1.0 (Artistic) :: a license approved by the OSI and Debian[6] but not by the FSF[5] for being 'too vague' [1]: https://www.gnu.org/licenses/license-list.html#NASA [2]: https://wiki.debian.org/NonFreeTrackingSystem/SourcePackage/worldwind [3]: https://www.gnu.org/licenses/license-list.html#Watcom [4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431#22 [5]: https://www.gnu.org/licenses/license-list.html#ArtisticLicense [6]: https://wiki.debian.org/DFSGLicenses#The_Artistic_License I believe that the we should not admit the former two into @FREE, but don't have strong feelings about the latter (though, I lean on the side of 'too vague' not being convincing at this point in time). A few possible courses of action include: - Moving the pertinent licenses into OSI-APPROVED-NONFREE (as in the patch inlined in the attached chat log with ulm), and keeping OSI-APPROVED in FREE, as is the case currently, - Splitting OSI-APPROVED into OSI-APPROVED-FREE/OSI-APPROVED-NONFREE, and having the former delegate to the latter two, and changing FREE to include OSI-APPROVED-FREE only, and - Moving all OSI-APPROVED licenses besides the pertinent licenses into OSI-APPROVED-FREE and having FREE include that set. I've discussed this with ulm already, attached is a chat log with some information inline from the web.
Created attachment 863827 [details, diff] profiles: Exclude NOSA and Watcom-1.0 from the FREE-SOFTWARE group I don't want to anticipate a decision, but this is how it could look like in profiles/license_groups: - OSI-APPROVED group as before - New subgroup OSI-APPROVED-FREE excluding licenses that are largely considered nonfree - FREE-SOFTWARE would include OSI-APPROVED-FREE instead of OSI-APPROVED
Created attachment 863841 [details, diff] profiles: Exclude NOSA and Watcom-1.0 from the FREE-SOFTWARE group
As for affected packages, the licenses is used by exactly one package, respectively: NOSA: net-analyzer/multipath-tcp-tools Watcom-1.0: dev-lang/jwasm Neither package has any reverse dependencies.
My vote as both a member of the license team and a trustee would be to split OSI-APPROVED into OSI-APPROVED-FREE/OSI-APPROVED-NONFREE, and have the combined group still available. We're making @FREE/@FREE-SOFTWARE slightly stricter, but the only impact is that any users of those two packages will have to update their ACCEPT_LICENSE if they are using ACCEPT_LICENSE from base/make.defaults. Outside of the default ACCEPT_LICENSE: Users that have ACCEPT_LICENSE="... @OSI-APPROVED", e.g. those under requirements from their organizations to use only OSI-approved licenses, get to automatically keep the two problem licenses - in line with their organization's policies. No action would be required of those users.
Do we need an extra group for two licenses? Or can we get away without it, like this: OSI-APPROVED @OSI-APPROVED-FREE NOSA Watcom-1.0 I don't see a meaningful use case for a separate OSI-APPROVED-NONFREE group. Users could add the two licenses (or one of them) to ACCEPT_LICENSES individually, or they could add @OSI-APPROVED which is a superset.
(In reply to Ulrich Müller from comment #5) > Do we need an extra group for two licenses? Or can we get away without it, > like this: > OSI-APPROVED @OSI-APPROVED-FREE NOSA Watcom-1.0 > > I don't see a meaningful use case for a separate OSI-APPROVED-NONFREE group. > Users could add the two licenses (or one of them) to ACCEPT_LICENSES > individually, or they could add @OSI-APPROVED which is a superset. Sure, it covers both of my use cases. I just liked it for clarity of process, that the non-free licenses are in a distinct group, and OSI-APPROVED included both groups.
I don't mind either way as long as the solution is functionally the same as https://bugs.gentoo.org/908499#c1. I guess two groups seems a bit cleaner and more explicit. But I endorse the overall approach, as briefly discussed on IRC.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0216d238af8da331d00801da26a499266e84e288 commit 0216d238af8da331d00801da26a499266e84e288 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2023-06-14 17:44:22 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2023-06-20 16:35:54 +0000 profiles: Exclude NOSA and Watcom-1.0 from the FREE-SOFTWARE group Rationale for exclusion of NOSA: - Section 3G: "Each Contributor represents that that its Modification is believed to be Contributor's original creation [...]" - FSF: "[...] not a free software license because it includes a provision requiring changes to be your 'original creation'. Free software development depends on combining code from third parties, and the NASA license doesn't permit this." https://www.gnu.org/licenses/license-list.html#NASA Rationale for exclusion of Watcom-1.0: - Section 2.2(c): "You must make Source Code of all Your Deployed Modifications publicly available [...]" - FSF: "This is not a free software license. It requires you to publish the source code publicly whenever you 'Deploy' the covered software, and 'Deploy' is defined to include many kinds of private use." https://www.gnu.org/licenses/license-list.html#Watcom - Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431#22 - Presumably this also fails the "Desert Island" and "Dissident" tests: https://wiki.gentoo.org/wiki/License_groups#tests Add NOSA back to the BINARY-REDISTRIBUTABLE group (but not Watcom-1.0 because of its patent clauses). Closes: https://bugs.gentoo.org/908499 Signed-off-by: Ulrich Müller <ulm@gentoo.org> profiles/license_groups | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
Thank you all for moving 2 of the 3 nonfree licenses the OSI currently approves out of the @FREE license group so far, but please consider moving Artistic v1.0 to @OSI-APPROVED-NONFREE where it should go, as that is a proprietary license. The nonfree sections I've identified are; "2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version." "Public Domain", especially capitalised so has a specific legal meaning, which is; "not copyrighted". In some countries, "public domain" can have another meaning, but such ambiguity is worse, as this in effect forbids applying other people's modifications that carry out "bug fixes, portability fixes" unless such are not copyrighted, or that are publicly available, or both. As far as I can tell, if someone privately sent you a sizable portability fix, under MIT expat, or with sections licensed under thereof (from other copyright holders), you would not be legally allowed to apply that modification under copyright, as that modification is both copyrighted and not publicly available. This infringes freedom 1. Unfortunately, there doesn't seem to be any clause otherwise authorizing such modifications, as below is "otherwise" to modifications that aren't; "bug fixes, portability fixes" "3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: a) place your modifications in the Public Domain or otherwise make them Freely Available" "in the Public Domain or otherwise make them Freely Available" makes it clear that the "Public Domain" is intended to mean "not copyrighted", as opposed to distributed publicly under copyright, under the license terms. Also, it infringes freedom 2 by not allowing a copy of the software to be sold (under the license terms) - only the charging of a "copying fee", of a limited amount, requiring "justification" for the amount; "5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself." If anyone can provide a description as to how each section of the license meets the 4 freedoms and/or DFSG (the Debian one), that would be great. If nobody can, please put the proprietary license where it belongs. As for usability concerns, it really is only a minor inconvenience to receive a notice that a package under a masked license is installed, as it only takes a few seconds to modify ACCEPT_LICENSE or package.license to accept such license if wanted, plus it'll be a good thing for people to be realise that a certain package they use is proprietary, as that'll drive them to ask the copyright holder(s) to relicense to a free license, like the Clarified Artistic.
Let's do this in a new bug please.
(In reply to ganooslashlinus from comment #9) See the discussion in the attached IRC log. We are aware that there are different opinions about the three licenses mentioned there. For the Artistic license, we choose to follow the opinion of the OSI and Debian. The rationale given by the FSF is only that "it is too vague". They don't pinpoint any clause that they would explicitly consider non-free, and they confirmed that "The problems are matters of wording, not substance." [1] (At the same time, the FSF recommends usage of the Artistic license for Perl packages, as part of the Perl license disjunction.) [1] https://web.archive.org/web/20070705024717/http://www.gnu.org/licenses/license-list.html#ArtisticLicense
>Sam James Let's do this in a new bug please. https://bugs.gentoo.org/show_bug.cgi?id=920754 >Ulrich Müller >See the discussion in the attached IRC log. Thanks, I missed that, but the linked discussion seems to be about Watcom and NOSA and there doesn't seem to be any discussion about the freeness of Artistic. >For the Artistic license, we choose to follow the opinion of the OSI and Debian. In my opinion, when it comes to freedom, the OSI isn't trustworthy at all and Debian isn't anymore. >The rationale given by the FSF is only that "it is too vague". They don't pinpoint any clause that they would explicitly consider non-free, and they confirmed that "The problems are matters of wording, not substance." [1] Unfortunately, wording alone can make a license nonfree. I pinpointed a clause that I consider nonfree and I would like to be informed if I'm incorrect. >(At the same time, the FSF recommends usage of the Artistic license for Perl packages, as part of the Perl license disjunction.) I believe the FSF's recommendation is only to license under the GPLv{1,2,3} - they don't care if you also license under proprietary terms, as long as everyone can go with the GPLv{1,2,3} instead.
(In reply to ganooslashlinus from comment #12) > I pinpointed a clause that I consider nonfree and I would like to be > informed if I'm incorrect. I fear that nobody from the licenses team can give you a definite answer to this. (I certainly won't because IANAL.)
