Clojurians Log v2

Almost no OSS licenses are compatible with CC-BY-SA-4.0 so 🤷🏻‍♂️ you can't really combine anything from http://Practical.li with other Clojure code if you're concerned about that... CC-BY-SA-4.0 effectively requires everything produced from those templates to also be CC-BY-SA-4.0 if they're published. I don't know if that's what @jr0cket intended? My understanding is that you can relicense CC... code under GPLv3 (but not vice-versa) and that won't work for businesses since GPL is "viral" too, like CC...

🤔 I should probably "upgrade" my EPL-1.0 stuff to EPL-2.0 and add Apache-2.0 as an explicit secondary license to make it more widely available. EPL-1.0 is not compatible with Apache-2.0 (but EPL-2.0 code can be).

Yeah I wanted to suggest EPL-2.0 but did not want to digress too much from the task at hand. Glad you're considering it. Your comment made me look up and realize CC-BY-SA-4.0 is actually more viral than EPL. In my case I'm considering MIT for a lib because it's really small, and copying its code may be preferable, so I'd like that to be possible in all cases.

but then looking further into licenses I see CC0 or MIT-0 are even more permissive, no need for attribution

AI says: Key differences: • Scope: CC0 targets all creative works; MIT-0 targets code. • Patents: MIT-0 implicitly grants patent rights; CC0 explicitly excludes them. • Legal mechanism: CC0 waives rights; MIT-0 licenses them. For software, MIT-0 is often preferred due to better patent coverage and compatibility with corporate policies.

Yeah, MIT is good, depending on what you want as an author. I prefer Apache 2.0 myself but in many ways MIT should be most people's default if they don't really understand OSS licenses. EPL is a weird default (and, frankly, a bit of weird choice for Clojure libraries -- okay for the language itself but really not for Contrib or any community stuff).

If we analyze project metadata for all clojars libs (at least) and check how licenses are mixed I'm sure we would find some interesting cases of head scratching. Everything being EPL does help. But with with an increasing number of clojure derivatives, and cljc combining them, I suppose we'll confront many more licenses, and see even more interesting cases, or dead-ends.

FYI the https://github.com/practicalli/project-templates/pull/38 is now updated with the latest deps-new and default license is CC-BY-SA-4.0.

Lots of nice little typo fixes in there too -- you have a good eye for detail @fmjrey!

Yeah those typo changes are part of the previous PR in case the bigger one does not go through!

Hi @jr0cket If you don't want any license just don't use :license/* in any template file. I actually did a https://github.com/practicalli/project-templates/pull/38 to use the new deps-new, but it overrides your current CC-BY-SA-4.0 license. To keep using CC-BY-SA-4.0 while still allowing your users to choose their own license, you can set :license/id CC-BY-SA-4.0 on the command line. Otherwise we'll need to devise a way for template projects to specify their default for deps-new to pick up, via the template.edn I suppose.

CC-BY-SA-4.0 is the SPDX id for the license you use: https://spdx.org/licenses/CC-BY-SA-4.0.html

If that PR left the various files alone that relate to licenses, the templates would use whatever was in the templates (since nothing would use the new {{license/*}} substitutions.

Existing templates that don't have licenses are not affected by this change. Only the built-in templates get the new license stuff.

But if you want your template users to choose a license you will need to use :license/* in template files.

Since you're here @seancorfield what would be the best way to specify in template.edn an overriding default :license/id, without using a data-fn.

I thought adding :license/id in template.edn would work but it's not picked up.

I'd have to give that some thought. I think the current (new) license machinery happens earlier in the pipeline than the template.edn file could override. For now, those project-templates could just update the deps-new version (and no other changes) and nothing would be affected -- users would get CC licenses per the templates as they do now and could change it manually if they wanted.

@jr0cket My suggestion for now is to ignore that PR.

I'll create a GH issue to think about how to specify a default license declaratively.

Issue #70.

I think moving the license lookup from preprocess opts into create, between the calls to apply-template-fns and ->subst-map (acting on and merging into final-opts) would be the simplest way to solve this.

yes I thought of something like that, will try later today (Paris time)

Try https://github.com/seancorfield/deps-new/pull/71

I'll work on this more later today.

Thank you. I will have time next week to update and try these nice changes out.

Setting a default license via :license/id in template.edn is now supported on the develop branch. @fmjrey is going to make some tweaks to the Codox doc gen alias, then I'll cut a new v0.11.1 release.

Actually CC-BY-SA-4.0 and EPL-1.0 are not compatible, they both require their derivatives to use the same license. Consequently code and templates from deps-new and practicalli/project-templates cannot be mixed even with dual licensing 🙁

But then if I generate from each a project using the same license, I can then copy code from one to the other right? 🤔

The generated projects have whatever license the user selects (or the default from the template used) -- and those projects are all independent. Could someone argue that because the app, lib, etc templates are in the deps-new, those templates are covered by EPL-1.0 since deps-new is EPL-1.0? Yes, perhaps for the templates themselves, but I think you'd have a very hard time claiming the generated projects are inherently under EPL-1.0, when the tool lets you select whatever license you want at generation time. FWIW, I went through a similar discussion with the legal team at Adobe, about 20 years ago (sheesh, hard to read that it's been nearly 20 years since I quit Adobe!). That discussion involved a framework that generated code -- that was used with the framework itself -- and that was the deciding line for the lawyers: if the generated code was for from-scratch projects that didn't need the framework, that would have been fine. The framework in question was LGPL-licensed. The legal team asked if the maintainer would dual-license under Apache-2.0 (the maintainer straight up changed the license for new versions, instead).

Yes the from-scratch generation is probably a safe bet. However I wanted to create some library template combining aspects of practicalli's dev features with the pom and clojars features of deps-new. I can certainly do that on my computer but as things stand I cannot publish/contribute the resulting template. I can only use that template personally from scratch.

Yeah, I've been talking to Lee Read on and off for ages about support of git deps in cljdoc... That would be the ideal solution here I think. At this point, I think deps-new is ready for an 0.11.1 release. I just need to add a changelog entry for this PR.

@fmjrey Even tho' I've merged this and the original addition of Codox, can you give me a good explanation of why it's useful in this situation? It feels like it's only applicable to folks who clone the repo locally and generate the docs, for local viewing.

Yes it's mainly for contributors, I wanted to see locally what the doc+docstrings would look like. I realize now you're not considering using anything else than github for doc viewing. That being said markdown in docstrings is not always well supported and not at all by github. I'm using spacemacs which does not parse markdown syntax in docstring. codox seems like a good way to preview them before committing. But I agree, it's more useful if you publish elsewhere like cljdoc.

BTW with more and more projects and dependencies using git coordinates, I imagine the clojure ecosystem could slowly be diluted into a myriad of separate solutions for doc and artifact publishing. clojars+cljdoc assumptions have become brittle since deps cli. I'm wondering if it's not time for a properly supported/funded review of clojars+cljdoc, especially the latter which I believe could become a central place for ecosystem discovery (the lisp curse etc.).