Licencing for incubating/affiliated/related projects using sbt-typelevel-site

[TimWSpence]

By default, sbt-typelevel-site uses typelevel assets like the typelevel logo and generates a footer "XXX is a project distributed under the XXX license.". We probably need to decide on what it should generate for incubating/affiliate/not officially endorsed projects.

As a side note, I'm in the process of adopting sbt-typelevel-site for cats STM and not sure what status to assign to it. It's not officially affiliated or incubating but happy to put it forward for either of those if there's any interest

[armanbilge]

Since I am responsible for making this into a problem 😅 a couple thoughts from me:

1. Non-Typelevel(-affiliated) projects are expected to override the default Typelevel-oriented theme included in sbt-typelevel-site. We can probably enforce this better by de-activating the Typelevel theme if the project group id is not org.typelevel.

2. Once the appropriate branding for affiliates is determined, we can add a setting to sbt-typelevel-site that activates affiliate mode. E.g. it can keep the logo but use "XXX is a Typelevel Affiliate project..." as the footer instead.

3. Tangential: the charter says that affiliate projects must be approved by the Steering Committee. IMHO if affiliates are encouraged, seems reasonable that a current Typelevel maintainer/member should be able to create an affiliate project simply by providing written notice. Of course, the committee could still veto, but this would avoid being bogged down on affiliation requests.

[rossabaker]

You can see the difference in the charter between Typelevel projects and affiliate projects. I'd say pick the one you think betters fit for your vision for the project, and open an issue here. Here's a sample issue for a project I contributed under the charter.

Speaking for myself, I'd welcome it as a Typelevel Project. You've been working on it for a while, you're known to be a good maintainer, and cats-stm is complementary to other Typelevel projects.

As for streamlining the affiliation process, we haven't delayed any yet, but we also haven't received any requests yet. So it's hard to say whether the process is fine, or whether it's so onerous it scared off anyone who might have tried. I'd be happy to revisit it: it's mostly boilerplate from the MVG.

[TimWSpence]

You can see the difference in the charter between Typelevel projects and affiliate projects. I'd say pick the one you think betters fit for your vision for the project, and open an issue here. Here's a sample issue for a project I contributed under the charter.

Speaking for myself, I'd welcome it as a Typelevel Project. You've been working on it for a while, you're known to be a good maintainer, and cats-stm is complementary to other Typelevel projects.

As for streamlining the affiliation process, we haven't delayed any yet, but we also haven't received any requests yet. So it's hard to say whether the process is fine, or whether it's so onerous it scared off anyone who might have tried. I'd be happy to revisit it: it's mostly boilerplate from the MVG.

Thanks Ross! That's very kind of you to say 😊 And thanks for the link! I actually had no idea what the process was before

[valencik]

I think there are perhaps three groups of projects that might use sbt-typelevel:

1. A Typelevel organization project
2. A Typelevel affiliate project
3. An independent project that is Typelevel ecosystem friendly, or an aspiring Typelevel project

Purely for the sake of wider usage and adoption of sbt-typelevel I think the default should optimize for case 3, independent projects that want to follow our best practices, as long as it doesn't come at a large cost to projects in cases 1 or 2.

For example I think things like:

de-activating the Typelevel theme if the project group id is not org.typelevel

are a fantastic idea.

Similarly for:

we can add a setting to sbt-typelevel-site that activates affiliate mode.

So perhaps my proposal would be a setting for each of these three cases with the default being the third case with no branding.

[armanbilge]

Polite bump on this :) we're in the process of updating the sbt-typelevel-site plugin and are adding a tlSiteIsTypelevelProject setting. Should this distinguish between org and affiliate projects?

[jducoeur]

I can't say that I've thought about this deeply yet, but my gut reaction is that we should distinguish, but it doesn't have to be terribly dramatic -- different wording in the footer would be adequate, IMO. More glanceable difference would be fine (and maybe a bit better), but I don't think it's critical.

[rossabaker]

is sounds a boolean, but there are three states, no?

[armanbilge]

Right, that's exactly my question :) is it a boolean, or are there a meaningful three states here, in which case how should we be treating them differently?

[rossabaker]

There are three meaningful states of Typelevel projecthood. Organization, affiliate, null. What the plugin does, I don't have a strong opinion, but if we want to grab that metadata and be able to do the right thing with it now and later, a ternary field makes sense.

[jducoeur]

Sounds like, eg, a typelevelRelationship enumeration is the way to go here...

[armanbilge]

Yes, thanks all, makes sense: collect the info now, maybe tweak the site footer, and more importantly have it available for the future