Proposal: Enable devs to opt-out of OSI licenses

Request Feedback
1

I know this as a contentious topic, so I want to try to set aside the following:

  • My own personal criticisms of OSI and their values.
  • Whether or not other people agree with ‘Ethical Source’ licenses or think they are practical or legally enforceable.

The issue

There’s a growing interest in what I’m going to call ‘Ethical Source’ licenses, which is licensing that not only specifies how code can be used and modified, but also how software can be used on ethical grounds (eg. WeTransfer started moving their open source repos to the Hippocratic License in 2019). They may be young, but they are not novelty licenses and I think we can definitely expect to see more developments in this space in the future.

I really like Elm, but I think it’s at least fair to say that OSI has a particular philosophical viewpoint about code, one I do not agree with and one that opposes my own moral sensibilities, and I’m not alone in this. I would rather not use OSI licenses for my work in Elm, opting for ‘Ethical Source’ licenses instead.

dzuk@DESKTOP-XXXXXX:~/parastat/ui-framework$ elm make
Dependencies ready!
-- UNKNOWN LICENSE ---------------------------------------------------- elm.json

I got stuck while reading your elm.json file. I do not know about this type of
license:

5|     "license": "CNPL-4",
                  ^^^^^^^^
Elm packages generally use "BSD-3-Clause" or "MIT", but I accept any OSI
approved SPDX license. Here some that seem close to what you wrote:

    CPL-1.0
    NGPL
    AAL
    AGPL-3.0

Check out https://spdx.org/licenses/ for the full list of options.

The problem is is that Elm’s package JSONs can only have OSI-approved licenses. This also applies to private packages - the Elm compiler will simply not compile if there is not a “license” object in elm.json and it will do the same if that license value is not an OSI-approved license.

The only way to currently have Elm code that both compiles and doesn’t have an OSI-approved license involves usability issues - pretending that the code is OSI approved in the JSON and then trying to notify the user in some way in the README that it’s in fact something else. I already do this with several open source repositories I am working on (ones that are not published on the Elm package system).

Possible solutions

1. Let people publish on Elm Packages with an opt-out

This issue could possibly be simply resolved with the use of a new ‘custom’ value for license that could act as an opt-out, and then the Elm Package UI could then tell the user to look at the license manually to find out what it’s been licensed.

{
	"type": "package",
	"name": "dzuk-mutant/nice-screen-buckets",
	"summary": "Track your browser's screen size and compare them against set boundaries.",
	"license": "custom",
	"version": "4.0.0",
    ...

Pasted image 20210130145435

2. Let people opt-out but only in private packages

If letting people opt out of OSI in the packages system is not desirable, I think the Elm compiler should at least let people opt-out for their own private packages with a ‘custom’ value and not fail to compile. And then an error can still be raised about the lack of an OSI license when the user tries to do elm publish.

Conclusion

I understand that the preexisting system of having specific licensing options to choose from enables people to easily match up where they are at and I think it should largely stay that way (maybe Elm could even could consider adding Ethical Source licenses as specific options as they get more mature in the future). However, it doesn’t reflect changing social circumstances and it doesn’t enable developers to be able to publish or even compile code under emerging licenses that may match their conscience and I think people should be given the choice in a way that doesn’t cause possible confusion.

8 Likes
2

I would prefer other instead of custom, because to me custom implies completely custom license and wouldn’t include known non-OSI licenses.

ps. If this is not accepted, then fixing this for private use seems to be trivial. Just add , "other" ==> "Other" to list at end of src/Elm/Licenses.hs.

2 Likes
3

I agree, other does sound better than custom :slight_smile:

4

Being able to programatically track licenses licenses is an mimportant task for the professional environment. Opting out from licenses would feel like a loose in this context. Another approach, like adding a licenseType with the values of osi or custom still keeps license tracking as a first class citizen while allowing the compiler to verify the osi licenses.

1 Like
5

An ethical license restricts the use of a package - that is its intention. The difficulty might be that someone using Elm packages might not realize they are pulling in an ethical license, say if they pull in a package as a transitive dependency.

But the same issue already exists with GPL, someone could pull in a package with that accidentally, not realizing that it requires them to provide the source of their entire application. So this means my point above is not really much of an objection to adding some ethical licenses to Elm - its still up to application authors to do their due diligence checks on licensing thoroughly.

====

Allowing non-OSI licenses needs to be part of my private package tool, and is something that I did not address yet in the spec, so thanks for bringing this up:

2 Likes
6

What about applying something like the idea of dependency management to licenses?

That is, add a field to elm.json like dependency_licenses, which would have the subkeys allowed and disallowed, which are each arrays. Within those arrays, you can have specific licences as well as meta licenses, such as (perhaps) @osi

Proposed default template:

{
  ...
  “dependency_licenses”: {
    “allowed”: [
      “@ethical”,
      “@osi”
    ],
    “disallowed”: []
  }
...
}
3 Likes
7

I think this will do what you want elm-review-license 1.0.1 though you’ll need to install the elm-review tool first.

4 Likes
9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.