Migrating: weaver-test

[rossabaker]

Migration Checklist

Project Submission Issue: #112

For Organization Projects:

• Create a team for the repo with maintainer as team member
• After repo transfer, add repo with write permissions to the created team

For All Projects:

• Add project to the site by adding an entry to the projects.yml file

Announcements

These steps are optional but encouraged.

• Write a blog post announcing the change
• Post to our social channels (Mastodon)

[Baccata]

Regarding the fact that I'm gonna have to fork instead of transferring ownership, should I create an "orphan" fork ? (Namely push the sources to the new repo without using the "fork" button)

[armanbilge]

What are the pros/cons?

I initially created http4s/hpack as a fork of twitter/hpack but then recently asked GitHub to decouple it. Seems to have worked fine.

https://github.com/http4s/hpack

[Baccata]

Oh, didn't know you could decouple after a fork. coolsies

[zainab-ali]

In the original issue #112, we state that the license is Apache 2.0. It's current license is Apache 2.0, but with the following custom clause:

 6. Trademarks. This License does not grant permission to use the trade
    names, trademarks, service marks, or product names of the Licensor
    and its affiliates, except as required to comply with Section 4(c) of
    the License and to reproduce the content of the NOTICE file.

For context, the original Apache 2.0 clause is:

6. Trademarks. This License does not grant permission to use the trade
  names, trademarks, service marks, or product names of the Licensor,
  except as required for reasonable and customary use in describing the
  origin of the Work and reproducing the content of the NOTICE file.

and Section 4(c) is:

  (c) You must retain, in the Source form of any Derivative Works
      that You distribute, all copyright, patent, trademark, and
      attribution notices from the Source form of the Work,
      excluding those notices that do not pertain to any part of
      the Derivative Works; and

The weaver codebase no longer contains any trademarks or references to Disney. Ideally, it would be relicensed under standard Apache 2.0. However, this requires approval from Disney's legal team.

The custom clause is apparently known as TOST (@Baccata can comment more on this term). It isn't listed under OSI, as required by Typelevel project governance unless otherwise approved.

Is it viable to approve this license?

[Baccata]

TOST stands for TOMORROW OPEN SOURCE TECHNOLOGY, and was a name that Disney's Open-Source Council came up with after Weaver became open-source.

Smithy4s (which was released a few years after weaver) uses that denomination : https://github.com/disneystreaming/smithy4s/blob/series/0.18/LICENSE

[valencik]

I wonder if it would be possible to submit the TOST licence to the OSI for review?
https://opensource.org/licenses/review-process

[rossabaker]

The TOST is a non-starter in many workplaces, and does not fold cleanly into an established license for derivative works – as you're experiencing now! I have deep reservations about OSI, but their list is our bulwark against license proliferation that impedes both publishers and consumers in FOSS.

On the other hand, weaver-test is a good product, with kind and reputable people behind it, and many happy users. It's is a success story that Typelevel ought to celebrate and support, not turn away on a technicality.

I propose:

• Continue to pursue relicensing to Apache 2.0. This is the healthiest outcome for the project.
• Typelevel waives the OSI requirement. The authors show good faith, and corporate licensing is a marathon, not a sprint.
• Some sort of callout of the non-OSI license would be helpful in the docs so it doesn't catch anyone by surprise.

To the last point, I noticed the POM is Apache-2.0 while the source is TOST. That should be reconciled in one direction or the other.

[jducoeur]

Seems like a reasonable compromise plan to me.

…

On Thu, Nov 14, 2024 at 1:03 AM Ross A. Baker ***@***.***> wrote: The TOST is a non-starter in many workplaces, and does not fold cleanly into an established license for derivative works – as you're experiencing now! I have deep reservations about OSI, but their list is our bulwark against license proliferation that impedes both publishers and consumers in FOSS. On the other hand, weaver-test is a good product, with kind and reputable people behind it, and many happy users. It's is a success story that Typelevel ought to celebrate and support, not turn away on a technicality. I propose: - Continue to pursue relicensing to Apache 2.0. This is the healthiest outcome for the project. - Typelevel waives the OSI requirement. The authors show good faith, and corporate licensing is a marathon, not a sprint. - Some sort of callout of the non-OSI license would be helpful in the docs so it doesn't catch anyone by surprise. To the last point, I noticed the POM is Apache-2.0 <https://repo1.maven.org/maven2/com/disneystreaming/weaver-core_3/0.8.4/weaver-core_3-0.8.4.pom> while the source is TOST <https://github.com/disneystreaming/weaver-test/blob/5a61ebed194578a8b741ace1c96f89744edc271f/LICENSE>. That should be reconciled in one direction or the other. — Reply to this email directly, view it on GitHub <#114 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQVNYLEKJUB6YTBH5D77S32AQ4KJAVCNFSM6AAAAABRWVK7X2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZVGQ4DMNZSGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>