Pkg.jl: `Pkg3` should support custom or non-Open Source license types with custom Git Repository.

[sambitdash]

Please refer to the PkgDev Issue #134 for details.

[ChrisRackauckas]

There should be a warning though for non open source licenses so that way people won't accidentally break the license. This already shows up in packages like ODEInterface.jl which has a commercial restriction for its license but you'd only know if you really make sure you read that.

[ghost]

@ChrisRackauckas If licenses were represented as types instead of just string labels you’d be able to add extension points for prompting on license restrictions. This would work for supporting commercial licenses, but it’d also support dual licenses or licenses with share alike provisions. (That are lawyer vetted of course 😉)

Such a strategy would also allow for company specific policies for banning specific licenses.

I can prototype an example of what this could look like in a few.

[StefanKarpinski]

I think it makes sense to be able to set a default license locally, and "no license" could be an option.

Part of the problem here is that package generation time is actually not the ideal time for license selection since it may be too early to know what the license should be. The real point at which one _needs_ to select a license and has sufficient information to know which licenses are acceptable is at package registration time. Moreover, where one tries to register a package dictates which licenses are acceptable. For example, if you're registering your package in an official Julia registry, then you should be required to choose an OSI-approved open source license and anything that deviates from that is a problem. If, on the other hand, you're registering your package with your company's private registry, the company will likely want to require that you use an "Copyright (c) Company. All rights reserved." license and not allow anything else to be registered. _Except_ (of course there is an except) for registering private versions of public packages. So this is a somewhat subtle and complicated issue.

[ghost]

Part of the problem here is that package generation time is actually not the ideal time for license selection since it may be too early to know what the license should be.

This isn't the case if you're doing proprietary software work. You know ahead of time that you need to use your employer's license when you generate a project, so ideally the project generation machinery should be flexible to accommodate your need.

It's not unreasonable to expect someone to consistently use a license that is not known to the julia core devs. (BSD3, AGPL, Dual Licenses, ETC)

For example, if you're registering your package in an official Julia registry, then you should be required to choose an OSI-approved open source license and anything that deviates from that is a problem.

Are there other package managers in languages that force you into a narrow band of software licenses? This seems restrictive and unusual to me. I get it: You probably want a good, vetted license. But it's certainly not a requirement, why couldn't you release something under the WTFPL?

If we don't want to support custom licenses, fine. But at least make it easy enough to hack in the license you want to use. The current extension point for adding new licenses (adding the file to /res/ in PkgDev and then twiddling around with a dictionary) doesn't feel good to me,

---

@ChrisRackauckas This isn't for Pkg3 (Still need to get my head around it, but probably will wait until after I have two other things done first.) but I've implemented a type-driven solution for forbidding licenses and adding licenses in the generate and license portions of PkgDev. Same approach could be used to support the prompting behavior some folks are craving for commercial licenses.

(Code is heinous, and there's a million places I want to refactor and the testing story is suboptimal. )

Package that includes my custom licenses that I use for generation here: https://github.com/polytomous/PolyPkg/
Definition for BSD/AGPL should live in different files but they're here for now: https://github.com/polytomous/PolyPkg/blob/c814bc9a9e7cdf97991453e8a2e19c07aed362b1/src/PolyPkg.jl#L9

The forked code for PkgDev is here: https://github.com/polytomous/PkgDev.jl Logic for preventing you from generating a project with a forbidden license here https://github.com/polytomous/PkgDev.jl/blob/35a66d428c0ea46d1fb2591b0a2c49576d934ea7/src/generate.jl#L163 (again: bear with me, I needed a similar problem in code I already knew, this could easily port elsewhere)

Use patterns are the same as PkgDev normally is.

using PkgDev
using PolyPkg
PkgDev.generate("SomeCoolProject","BSD3") 
# This fails. We don't do AGPL here. 
PkgDev.generate("SomeForbiddenProject", "AGPL3")

(Oh and one cool bit about my solution is you can easily define overridden tokens. So you can define one method to support something like PkgDev.generate("SomeWorkProject","WORK") which would shell out to whatever work license you had to use.)

[StefanKarpinski]

This isn't the case if you're doing proprietary software work. You know ahead of time that you need to use your employer's license when you generate a project, so ideally the project generation machinery should be flexible to accommodate your need.

That is why the first thing I said was that it should be possible to set a local default license, for example on your work machine on which any code developed is copyright of your employer. However, that is only one case and there are other cases where the decision is better made at registration time. Such a local default license should be allowed to be whatever text people want.

Are there other package managers in languages that force you into a narrow band of software licenses? This seems restrictive and unusual to me. I get it: You probably want a good, vetted license. But it's certainly not a requirement, why couldn't you release something under the WTFPL?

Absolutely. R only allows packages with this list of licenses: https://cran.r-project.org/web/licenses/. Linux distros like Debian are well known for being very strict about what licenses code can have in order to be packaged. You are certainly free to release your code under the WTFPL or any other license, but that doesn't mean that we have to accept it into the official Julia package registries. I would be annoyed if I installed some package only to learn that it has a questionable license that makes it a legal liability for me to use it.

If we don't want to support custom licenses, fine. But at least make it easy enough to hack in the license you want to use. The current extension point for adding new licenses (adding the file to /res/ in PkgDev and then twiddling around with a dictionary) doesn't feel good to me,

At no point has _anyone_ said we don't want to support proprietary software or licenses. In fact, I went to great lengths to make sure that Pkg3 supports private registries. Believe me, life would have been a lot easier if I'd decided not to bother making registries completely federated and only supporting a single shared global namespace of open source registered packages instead. We _are_ having a conversation right here, right now about how to best support developing proprietary software in Pkg3. So please, just chill and we can all work towards a constructive solution instead of just assuming that we're "against you" and digging in your heels against everything I suggest based on that assumption.

The old PkgDev tool is explicitly a tool for open source package development. Moreover, is is end-of-life so we're not adding any more features to it. If people are using it for proprietary software development, that's cool, but every feature that's added is a maintenance burden and we're not accepting any new ones in any case.

The whole point I was making about doing license choice/enforcement at registration time is that by doing so, it decouples package development – which can be proprietary or open source – from package registration, which is the point where you want to check/enforce licenses, and perhaps have another choice point in cases where a licenses isn't acceptable with regards to a registry.

[StefanKarpinski]

Another way of putting it is that PkgDev was always designed around the assumption that you were going to eventually register your package in METADATA.jl. That's why there was pushback about adding support for licenses that we don't want to have in METADATA. (That and the fact that every feature is a maintenance burden.)

In Pkg3, the federated design makes that very much not the case: code generated by Pkg3 dev tools could end up in a private or a public registry. But you don't generally know that when the code is generated. Here are some development scenarios:

1. Work/home machine on which I always want to use the same license (e.g. all rights reserved at work or MIT at home).
2. Machine on which I develop software with different licenses, I may not know which at project creation time and in general may want to defer the decision until registration time, at which point I _have_ to make a decision.
3. I may start out with one license but change my mind at registration time.

It seems like we could add three features to support these cases pretty well:

1. Default local license: if this is configured, all generated packages use a given template and you are never prompted for which license you want to use. This supports use case (1) above for work/home.

2. Have "Decide later" as a license choice at package generation time. This would skip license generation and not produce a license file at all. The user can add one later manually if they want, but if they don't, the lack of a license file lets the tooling know that when registering a package the package still needs a license.

3. Allow registries to supply a default license or a list of allowable licenses to choose from at registration time. This puts the list of allowable licenses / default license where it belongs: in the registry, instead of in the package generation tool.

[ghost]

You are certainly free to release your code under the WTFPL or any other license, but that doesn't mean that we have to accept it into the official Julia package registries.

In fact if you use WTFPL they probably won't, in which case just copy the code and change the license to one of the OSI-approved ones to up the chances of acceptance until this limitation is addressed.

[sambitdash]

No longer needed as Pkg3 has support for non-opensource license types.

[StefanKarpinski]

I still think the plan I outlined here should be executed:

1. Default local license for new packages you generate.
2. "Decide later" option to defer choosing a license at generation time.
3. Allow registries to specify a default license to suggest when registering a package that hasn't yet chosen a license (i.e. used feature 2).

But most of these are PkgDev features, which we've mostly decided to remove from this repo.

[ghost]

👍 I agree with this plan, sounds great to me. I appreciate the idea of a local default license, really jives well with the spirit of this issue.