Non Commercial licensing in mainstream Julia Packages

General Usage
1

Just saw my first rejection from our company’s Nexus license compatibility checker for non-commercial use license.

Is there a way to adopt a philosophy to not include licenses into mainstream packages that prohibit non-commercial use. Somehow segregate them so they can be easily rejected?

It’s a big deal that can add another monkey in the list of excuses on why to not adopt Julia as a viable tool for commercial engineering work, etc.

Also, can anyone offer a mechanism to allow for easy package substitutions without rewriting vast amounts of the ecosystem?

1 Like
2

Not sure, but it seems to me the license on those colorschemes would mean that you cannot use the julia colorschemes for commercial purposes. A code file enumerating the colorschemes is not the same thing, is it?

1 Like
3

The policy for registration in the General registry is spelled out in GitHub - JuliaRegistries/General: The official registry of general Julia packages, which includes:

Registered packages MUST have an Open Source Initiative approved license, clearly marked via the license file (see below for definition) in the package repository.

This is checked when determining whether the package/version is eligible for automatic merging, but the checking code doesn’t go as far as investigating every individual file and following links.

This case I think is a borderline false positive, but it would certainly be good if license checking software in practical use didn’t trip over it.

5 Likes
4

CC-BY-NC-4.0 is not an open-source license.

8 Likes
5

So does this mean that the auto-checkers need work… either on the OSI side or the nexus side of things? If it is a false positive, if I can get evidence of that, I can probably feed that back. If it is a missed hit, then I guess that needs to spawn a robustness improvement on whatever is passing that.

6

It’s not a false positive. It’s not an open-source licence — aside from the fact that it’s not on the OSI list, the noncommercial-use (NC) restriction violates OSI’s open-source definition.

12 Likes
7

If it’s just the Julia logo colors, I don’t think these necessarily have to have the same license as the Julia logo.

I don’t see why the licence couldn’t be changed for that jcolors.jl file.

PRs are always welcome.

2 Likes
8

That much is clear. What is less clear to me is whether extracting the colors from the Julia logo has enough height for the license of the “design” to apply. The source code in the repository is MIT licensed and julia-logo-graphics/src/compare_color_to_named_colors.jl at master · JuliaLang/julia-logo-graphics · GitHub does things with colors, but I can’t say what bearing it has.

1 Like
9

As I understand it, it depends on whether the list of colors is copyrightable — anything “expressive” is copyrightable, and anything copyrightable needs permission (i.e. a license) from the copyright holders to redistribute (outside of narrow exceptions).

Fortunately, apparently there is some (US) case law on whether color schemes are copyrightable. Apparently a color scheme can be trademarked but not copyrighted (separate from the arrangement of colors in space). See e.g. this article from the Center for Art Law (which cites a 1995 US Supreme Court case) or this article from briffa.com (IP law firm).

7 Likes
10

Color schemes are not eligible for copyright protection, so that license link isn’t necessary. I’ve opened a PR to remove it. It’s good that Nexus caught this issue, but it’s a false alarm for subtle reasons that I wouldn’t expect an automated checker to catch:

  • Logos in the julia-logo-graphics repo are CA-BY-NC-4.0 because we do not want people to be able to use the Julia logos for commercial purposes without asking permission.
  • Code in that repo is covered by the MIT license since we do want people to be able to use the code freely.
  • Neither license is required to use the colors since color schemes are not eligible for copyright protection.
  • The code doesn’t appear to come from that repo, just the color values. Even if the code was copied from that repo it would be fine since the MIT license applies to code and no license is required for the colors.
  • The only way the CA-BY-NC-4.0 license would apply to the ColorSchemes package would be if it included the actual Julia logo, which it does not.
16 Likes
11

Thanks Stefan - the hero we needed! :grinning:

4 Likes
12

Offtopic: that didn’t prevent Mathworks from claiming vague “intellectual property” protection for their parula colormap when Matplotlib asked if they could use it. Not sure if that would have held up in court (as a trademark? or maybe a court would rule that you can copyright an ordered sequence of colors?), but fortunately it inspired Matplotlib to just create their own superior colormaps, uncovering a bug in parula (which used an outdated model of color distance) in the process.

11 Likes
13

To add a little to Stefan’s answer, the code in julia-logo-graphics actually just calls out to Luxor.julialogo, the code for which includes the colours, and Luxor is MIT licensed. So even if you didn’t know whether colour schemes can be licensed or not, they’d be MIT.

2 Likes
14

The problem is more than just that one file, see: Unnecesary licence files · Issue #122 · JuliaGraphics/ColorSchemes.jl · GitHub

15

For some relevant non-OSI compliance (it’s ok in this case, but could have been different), consider Llama2.jl

We currently support:

  • GGUF models: Llama 2, Llama 3, and Phi-3 (not all quantization variants may work)
  • Andrej Karpathy’s llama2.c format
julia> model = load_gguf_model("Meta-Llama-3-8B.Q4_K_S.gguf")

There this is ok, since it only opens a file, and the burden seems to be on you to first get that file. Still note:

These models are not open source, despite Meta’s claim. They are almost, but some are not borderline at all, full proprietary. [I do recommend DeepSeek R1 “Code and models are released under the MIT License: Distill & commercialize freely!” Their older V3 is open for the code (MIT), and similar to Llama for weights, not as open: Apache 2.0-like (with e.g. Patent grant), but with restrictions in “Attachment A”, e.g. military use disallowed. Still allowing non-commercial. Their JanusPro seems also interesting.]

Now lets say this package (or some other one, depending on it), would:

  1. Download it for you, then in practice, using this package with the model, e.g. only allowing non-commercial, or say both commercial and not, just not for military use (very common, but non-OSI compliant), would that fulfill the licence for that package?
  2. What if it allowed not just this model but others downloaded, and the default one is fully OSI compliant, others not?
  3. What if the models weights for one or more models provided in the package, i.e. its download/Artefact, is non-OSI [AI] (one exception might be ok), but the code to run is still fully OSI-compliant?

I believe we have packages that do 2. I think PromptingTools.jl is an example, but some of us would really like to do fully local AI, and then option 3. would be very convenient.

I believe we have packages that do 2. I think PromptingTools.jl is an example, but some of us would really like to do fully local AI, and then option 3. would be very convenient.

We do not want Apps as packages in the Registry (Pkg still has some new App support, so there might be exceptions), such as full desktop apps, e.g. e.g. App-like, games.

But we might want a game engine (we do have!) in Julia, and we might want simple example games with it. Would it be ok if some had a restrictive, e.g. non-commercial license? Most doing games would like them fully proprietary, not even allowing non-commercial, so wouldn’t want to allow downloading games this way anyway… Stallman is e.g. adamant on games also being free software, but if I recall, that only applies to the code for the games, and he’s ok with artwork not free/OSI compliant, would we be ok with that?