diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 87d16058..cad16c2c 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -14,7 +14,13 @@ The TSC will be responsible for identifying, agreeing and implementing the gover 3. Create space to grow the community 4. Provide a framework to set project direction and facilitate technical decision making -## Phase 1: Setup Period (now) +## Current Status + +TAMS will become a Community Project under the Linux Foundation, as discussed in detail by [ADR0051](./docs/adr/0051-host-organisation-for-tams.md). +This was decided by a [vote of the TSC](https://github.com/bbc/tams/wiki/TSC-Meetings-2026#2026-09-04) and is now in the process of being implemented (phase 2, below). +As part of that implementation, this document will be updated. + +## Phase 1: Setup Period (completed) Initially the TSC will be formed from several of the team at BBC R&D and AWS who were involved in TAMS becoming an industry initiative, balanced out by other organisations. In the Setup Period, the TSC is charged with setting up an open governance process and identifying a suitable organisation to take control of the project. @@ -25,7 +31,7 @@ However the BBC commits this will end and a decision will be made and published After the TSC has agreed on the governance approach, this document will be updated to describe it, and the community will be informed. In the meantime, suggestions and comments are greatly appreciated. -## Phase 2: Transition Period +## Phase 2: Transition Period (now) Immediately after the completion of the Setup Period, the TSC will work to implement the approach that was decided. This will involve any relevant project setup process with the organisation selected, and moving the TAMS repository out of the BBC’s GitHub Organisation. diff --git a/docs/README.md b/docs/README.md index c9e1d925..f1b8eea3 100644 --- a/docs/README.md +++ b/docs/README.md @@ -91,6 +91,7 @@ For more information on how we use ADRs, see [here](./adr/README.md). | [0047](./adr/0047-flow-profiles.md) | Adding Flow Profiles to TAMS | | [0048](./adr/0048-media-integrity.md) | Integrity model for media in TAMS, and when interacting with other systems | | [0049](./adr/0049-source-collected_by-query-parameter.md) | Ability to query for Sources without a collected_by value | +| [0051](./adr/0051-host-organisation-for-tams.md) | Host Organisation for TAMS | | [0052](./adr/0052-specifying-the-sorting-of-listings.md) | Options for specifying the sorting of listings | | [0053](./adr/0053-editorial-purpose-tag.md) | Editorial Purpose Tag | | [0054](./adr/0054-selectable-presigned-storage-urls.md) | Support for selectable presigned storage PUT URLs | diff --git a/docs/adr/0051-host-organisation-for-tams.md b/docs/adr/0051-host-organisation-for-tams.md new file mode 100644 index 00000000..82c4d25f --- /dev/null +++ b/docs/adr/0051-host-organisation-for-tams.md @@ -0,0 +1,414 @@ +--- +status: "accepted" +--- +# Host Organisation for TAMS + +## Context and Problem Statement + +[ADR0046](./0046-governance.md) considered options for the future governance of TAMS, and concluded that it should move to an organisation such as the Linux Foundation. +At that time a process was set out (described in [GOVERNANCE.md](https://github.com/bbc/tams/blob/2190650f824b86bc6e53320538427cf0446d34e0/GOVERNANCE.md#phase-1-setup-period-now)) to form a TSC, identify a suitable organisation and move TAMS under it. +This ADR documents possible organisations and the associated decision. + +## Decision Drivers + +The TSC [identified](https://github.com/bbc/tams/wiki/TSC-Meetings-2026#next-steps-on-governance) a number of aspects to consider when selecting an organisation: + +- How does governance work for projects? + What is involved? +- What is the underlying legal structure? +- What is the funding model? + Is it a paid membership organisation? + Can non-members be involved? +- Is there a stated Intellectual Property Rights (IPR) policy/position? +- If there is a community, where is it? + Can we join? +- Are they being talked about/engaged by organisations we’re working with in the TAMS Community? + Can we see any evidence of that happening? + +## Considered Options + +Several possible organisations were identified, from discussions and suggestions by the TSC, their colleagues and others at the meetings. +Note that these options are in no particular order, except as to make the rest of the document flow better. + +- Option 1: Linux Foundation (LF) +- Option 1a: Linux Foundation, with funding +- Option 2: Academy Software Foundation (ASWF) +- Option 3: Cloud Native Computing Foundation (CNCF) +- Option 4: Joint Development Foundation (JDF) +- Option 5: Alliance for Open Media (AOM) + +These options are all related, as illustrated by the following diagram (where boxes are organisations, and hexagons are example projects): +![Relationship between the organisations under the Linux Foundation umbrella](../images/ADR0051-LinuxFoundationFamilyTree.drawio.png) + +## Decision Outcome + +**Chosen option: Option 1 — Linux Foundation**, because it best preserves TAMS's breadth of applicability, minimises friction, and keeps the most options open for the future. + +### Reasons + +#### 1. Applicability beyond Media & Entertainment + +TAMS is fundamentally a standard for managing time-addressable content — video, audio and data on a timeline. +While adoption today is concentrated in broadcast, news and sports, there is no technical reason this model could not serve workloads in other domains where live or near-live content is produced and stored. +Aligning TAMS with an industry-specific organisation risks signalling — intentionally or otherwise — that the standard is scoped only to that industry. +The Linux Foundation's sector-neutral positioning avoids constraining the project's long-term reach. + +#### 2. Community and cultural fit + +The Academy Software Foundation provides a ready-made community, but that community is primarily oriented around film, VFX and post-production tooling. +The typical TAMS adopter — a broadcast, news or sports organisation — sits in a different part of the media landscape with different workflows, timelines and concerns. +There is a risk that TAMS would occupy a niche position within a community whose focus lies elsewhere, making it harder to attract engagement from the organisations most likely to benefit from it. +Conversely, broadcast organisations looking at TAMS might perceive it as part of a VFX-oriented ecosystem that does not reflect their world. +Joint events and activities would be a hard sell where the VFX and broadcast audiences are only partially aligned. + +#### 3. Friction and operational overhead + +ASWF comes with more process around managing a project: a formal submission and approval process, a lifecycle from Sandbox through Incubation to Graduation, annual reviews, and a requirement to move the existing community into ASWF infrastructure. +By contrast, the Linux Foundation approach is the closest to TAMS's existing operating model — the TSC, community Slack and current contribution processes can continue with minimal disruption. +LF is "light-touch overall with considerable freedom", which is a strength the TSC values. + +#### 4. Flexibility and reversibility + +The SWOT analysis identified "keeps the most options open in future" as a strength of the Linux Foundation path, and "could move to another sub-foundation or switch to funded later" as an opportunity. +Should circumstances change — for example, should ASWF broaden its positioning to encompass broadcast-oriented projects — TAMS could move at that point. +The reverse journey, moving out of a more structured organisation, would involve greater overhead and disruption. + +#### Acknowledged trade-offs + +There is a recognised weakness: TAMS will need to continue building its own community rather than inheriting one, and an unfunded project may face some limitations in the support available. +However, the TSC judged that community fit, long-term flexibility and minimal friction outweigh the short-term benefit of a pre-existing audience whose interests are not well aligned with TAMS's direction. +MXL provides a recent precedent for a media-adjacent project successfully taking this route within the Linux Foundation. + +#### The Future + +While **Option 1 - Linux Foundation** is the right choice for TAMS at present due to the reasons outlined, it may not be the final form, and the flexibility to change in the future is part of what makes this option appealing. +To that end, the TSC will keep this under consideration and commits to beginning a review of this position and whether our surrounding context has changed around September 2027 (12 months hence) and updating this document with the outcome of that review. + +### Detailed SWOT Analysis of Options + +To aid making this decision, an analysis of Strengths, Weaknesses, Opportunities and Threats (SWOT) was conducted to provide another lens for analysing the options, as captured in the table below. +In this context a Strength is akin to a "Good" in the ADR options, a Weakness akin to a "Bad", an Opportunity is something positive that could come to pass with some work (or some good luck) as a result, and a Threat is the opposite - something negative that could come to pass, but that is less certain than a Weakness. + +Alliance for Open Media (Option 5) has been removed from the scope of this analysis as it is unlikely to be a good fit based on the heavy focus on AV1, which TAMS is related to, but not closely. +Similarly Cloud Native Computing Foundation (Option 3) has also been removed from the scope, since it seems to consider projects which exist at another layer of the stack to TAMS and is otherwise very similar to the Academy Software Foundation (Option 2). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OptionStrengthsWeaknessesOpportunitiesThreats
Linux Foundation (Option 1)Closest to existing modelHave to form/grow/run own communityMay be able to move beyond media & entertainmentMay face some limitations/restrictions by being unfunded
Light-touch overall with considerable freedomCould move to another sub-foundation/switch to funded later
Keeps the most options open in future
Linux Foundation, funded
(Option 1a)		Similar to existing modelHave to form/grow/run own communityMay be able to move beyond media & entertainmentUnlikely to be able to switch back to unfunded later
Light-touch overall with considerable freedomSignificant upfront and ongoing costs for our communityMay be complex for the BBC to be involved (likely on a special Associate tier)
Clear approach to how we manage funding
Academy Software Foundation (Option 2)Ready-made communityMore process around managing the projectMaking a common home for open source media software and unifying with fellow travellers (e.g. OpenTimelineIO)Positions TAMS initially within Media & Entertainment: limits multi-use applicability
Existing funding and structureHarder to join and set up: more process and structure involvedGrowing towards the film/VFX industry as a broader TAMS marketFilm/VFX prominence overshadows the more broadcast/news positioning of TAMS
Need to move existing communityMay help push into poorly served regions: e.g. US marketLots of work involved for us in broadening ASWF beyond film/VFX
Some effort from Premier tier members, who provide 1x FTESome cultural mismatch due to different sectors/industries/geographies: may be high-friction
Joint Development Foundation (Option 4)More rigourous handling of IPRDiffers from how TAMS works today, which is much more like a software projectPossible path to formal standardisation, if that's a route we want to take
Not aimed at developing/owning software directly
Form a sub-foundation (ADR0046 Option 5)Provides a common space for open source broadcast software to growLots of work for us to set it up, and high overhead to runPotentially fills a gap in our sectorThere are many other organisations that partially cover this need, and adding a "competitor" is challenging and risky
Considerable freedom to set direction and approachLikely to require some kind of funding plan for e.g. legal support and admin costsMay be able to join forces with comparable open source broadcast technology under and common framework
Retain the status quo (ADR0046 Option 1)No effort requiredNo legal entity or trademark protectionProject could stall if the BBC re-prioritise away from it
TSC already functioningPerceived as BBC-owned — limits adoptionNone: this is the baseline we're trying to improve onSingle-org perception limits vendor adoption and contributions
Working so far...Contributors and TSC members lack any formal governance rights or statusSubject to BBC enterprise controls: org is not really set up for this!
BBC Charter renewal means long-term outlook remains unknown
+ + +### Implementation + +{Once the proposal has been implemented, add a link to the relevant PRs here} + +## Pros and Cons of the Options + +Note that in keeping with the other TAMS ADRs, options are characterised as “Good”, “Bad” or “Neutral”. +For the avoidance of doubt, that should be read as “a good/bad fit for the TAMS project at this time” rather than a value judgement on the organisations in question, and the wording exists as a very simple way to express strengths and weaknesses. + +### Option 1: Linux Foundation + +Become a project directly under the Linux Foundation, like [Media eXchange Layer (MXL)](https://github.com/dmf-mxl/mxl/). + +At a basic level, Linux Foundation projects are required to use an open source licence, have a documented charter that separates their technical governance from the business needs of the organisations involved and allows anyone to participate in the technical community, and transfer ownership of their assets (repositories, domains, etc.) to a neutral party. + +In terms of that neutral party, Linux Foundation projects are a “series” of LF Projects, LLC, a “series limited liability company” under Delaware law. +This effectively allows each project to be a distinct legal entity under the parent organisation, with separate obligations, assets and liabilities, without the overhead of managing a large number of companies (_note that this is the author's layperson's understanding, and not a qualified legal opinion_). +This option specifically considers the "Community Project" [style of project](https://www.linuxfoundation.org/projects/hosting). + +On IPR, it seems to rely on Apache 2.0 and similar licences containing a patent grant and then [Developer Certificate of Origin (DCO)](https://wiki.linuxfoundation.org/dco) sign-off indicating you were able to licence that contribution under Apache 2.0. +There is some cross-LF activity to defend members from Non-practicing Entities (also known as "patent trolls") depending on membership tier. + +Linux Foundation projects have considerable freedom to operate as they see fit and build a community where they’d like. +To set up a project requires the support of at least one Linux Foundation member (both the BBC and AWS are members) and five sponsoring organisations (although it isn’t clear what that means). + +- Good, because it offers us considerable freedom in how to operate TAMS +- Good, because it allows our existing community and process to remain, only changing the underlying ownership +- Good, because it is the lightest-touch of the options +- Good, because it creates space for TAMS applications outside of the Media & Entertainment sector, where it may find broader adoption +- Good, because it has proven templates for setting up the legal and IP framework around the TAMS specification +- Neutral, because while it is not a direct fit for TAMS, the Linux Foundation overall is very broad +- Neutral, because there would be additional steps to operate as a funded project, however this is no different to the existing model +- Bad, because we have to form, grow and run our own community (rather than being participants in an existing one) + +### Option 1a: Linux Foundation, with funding + +As Option 1, but use the "Community Project + Funding" form of [Linux Foundation project](https://www.linuxfoundation.org/projects/hosting), like the [Yocto Project](https://www.yoctoproject.org/). + +In this model organisations become members of the project in exchange for an annual membership fee, which is put towards infrastructure, events and similar (with the Linux Foundation taking 8%). +They are a Directed Fund where paying members at an appropriate level receive some control over how the project is run and the funds are spent (e.g. through seats and votes on the Governing Board) and other benefits, however technical participation is open to all. + +- Good, because it offers us considerable freedom in how to operate TAMS +- Good, because it allows our existing community and process to remain, only changing the underlying ownership +- Good, because it is the lightest-touch of the options +- Good, because it creates space for TAMS applications outside of the Media & Entertainment sector, where it may find broader adoption +- Good, because it has proven templates for setting up the legal and IP framework around the TAMS specification +- Neutral, because while it is not a direct fit for TAMS, the Linux Foundation overall is very broad +- Neutral, because there would be additional steps to operate as a funded project, however this is no different to the existing model +- Bad, because we have to form, grow and run our own community (rather than being participants in an existing one) +- Bad, because several of our community would need to put in substantial funding (both to join our project, and if necessary the Linux Foundation) to get set up + +### Option 2: Academy Software Foundation (AWSF) + +Join the Academy Software Foundation (ASWF) as a project, like [OpenTimelineIO](https://github.com/AcademySoftwareFoundation/OpenTimelineIO). + +ASWF is a subsidiary of the Linux Foundation, and shares many of the same aspects, for example the legal structure and requirements around licences, participation and ownership. +Its [charter](https://cdn.platform.linuxfoundation.org/agreements/aswf.pdf) describes its scope as: + +> open source or open specification projects supporting the motion picture industry + +The Foundation itself reads this fairly broadly, listing among its [goals](https://www.aswf.io/about/) to "share resources across the motion picture and broader media industries", however in practice many of the projects and members are active in the animation and visual effects space. + +It is a membership organisation (a "Directed Fund" of the Linux Foundation), applying the overall principle of separating technical governance from business direction, while providing a way to collect funds and spend them to further its goals based on the direction of [member organisations](https://www.aswf.io/members/). +For example, the ASWF funds its use of Slack and has a Working Group managing (and where necessary funding) some [CI infrastructure](https://www.aswf.io/ci-infrastructure/). + +It also comes with more requirements in initial submission, including considering the potential "universe of participants" and presenting for approval to the [Technical Advisory Council (TAC)](https://tac.aswf.io/). +There is also a project lifecycle process into which projects are slotted: Sandbox, Incubation, Graduated, Archived. +Projects aim to move up from Sandbox to Incubation (or at least make demonstrable progress) within one year. +Moving to Incubation requires some more complete documentation and pass a growth assessment. +Annual Reviews take place to re-assess lifecycle stage and look over current activity, stage match and feedback. + +#### Slack and Community + +One of our considerations is around what happens to the existing TAMS community, which is currently centred around a few core spaces (e.g. the CNAP Slack) and events (TAMSCon, the Community Call, etc.) + +It seems the [ASWF Slack](https://slack.aswf.io/) is viewed as an enabler for the community it serves: providing a space for the groups involved to come together around a shared goal. +Members and participants have deep expertise is a wide variety of topics, and it serves the variety of projects under the ASWF umbrella well. +A few of the TSC members are also members of the ASWF Slack and can see the variety of technical discussions that take place, of a similar character to those in the CNAP Slack (however there are a number of useful private channels within the CNAP workspace: it is not clear to what extent this is possible in the ASWF community). + +The ASWF Slack community is geared around a channel-per-project, e.g. there is a `#opentimelineio` channel, plus a handful of working group channels (e.g. `#opentimelineio-examples`). +In theory it is possible to merge workspaces together, exporting data from our existing workspace and then importing it to the new one, which would reduce (but not entirely mitigate) the impact of moving spaces. +One of the aspects the ASWF funds is a Slack Pro licence for their workspace, enabling retention of the message history beyond the 3-month limit of Slack Free. + +#### Events + +Typically ASWF has a set of events that run across the Foundation: broadly the Open Source Forum, Open Source Days and Dev Days. +Of these the Open Source Forum and Open Source Days a in-person presentation sessions about software, open source and best practices (in Los Angeles) open to Foundation members, or members plus individuals for a registration fee. +Dev Days is a "hackathon" day where participants give a day of their time to work on a task from an Academy Software Foundation project. + +In addition to this the various projects and Working Groups have their TSC and other meetings on a regular cadence, along with the fortnightly TAC meeting. + +Currently the in-person events are in Los Angeles, although the Foundation have expressed that growing into Europe would have some appeal. + +#### Pros and Cons + +- Good, because it is well aligned with the sector TAMS works in +- Good, because it provides a ready-made community to join an grow +- Good, because it provides a ready structure to manage funding and spending on resources +- Neutral/bad, because it is currently VFX/film focused (but seems keen to grow wider than that) +- Neutral/bad, because it introduces more process around managing the project +- Neutral/bad, because current events are all in the US (California) and the TAMS community is currently much more focused in Europe: many existing participants would be unable to attend in-person +- Bad, because it positions TAMS firmly within Media & Entertainment, when the technology may be more widely useful +- Bad, because it likely forces us to move our existing community, which may come at a cost of engagement and participation +- Bad, because we'd lose some of the freedom we enjoy to run and manage events within our community +- Bad, because very few of the existing TAMS community are Members of ASWF: in principle this isn't a barrier to technical participation, but limits event access + +### Option 3: Cloud Native Computing Foundation (CNCF) + +Join the Cloud Native Computing Foundation as a project, like [Helm](https://github.com/helm/helm). + +CNCF is another subsidiary of the Linux Foundation, and shares many of the same aspects much like ASWF. +It is intended for projects that contribute to cloud-native ecosystem and provides a vendor-neutral home for open-source cloud-native projects. + +Broadly a similar project lifecycle approach applies as with ASWF: there is an acceptance process for new projects, which then move through the stages. +On community, there are individual communities around projects (such as the Kubernetes community) but the broader cloud-native ecosystem means one community (e.g. a single Slack) is less likely to be practical. + +- Bad, because most of the CNCF projects exist at a lower level that TAMS, providing underlying compute and platform capabilities to support a wide variety of applications, such as Kubernetes and Helm +- Bad, because we have to form, grow and run our own community (rather than being participants in an existing one) + +### Option 4: Joint Development Foundation (JDF) + +Form a Joint Development Foundation under the Linux Foundation, like the [Coalition for Content Provenance and Authenticity (C2PA)](https://github.com/c2pa-org). + +JDF projects are a specific Linux Foundation structure intended for standards and specification projects, with a potential path to more formal standardisation. +JDF projects can also be funded or unfunded, and member organisations can be Steering Members, General Members and Contributor Members. +They are operated by a Steering Technical Committee (STC), which can run either "designated by consensus" (the model on which the TAMS TSC operates) or "designated by steering member", where Steering Member organisations provide a representative. +There’s also two operational modes: either “Community specification” (like TAMS, work is conducted asynchronously in public repos) with licences built for spec work, or “Traditional specification” as a more conventional specification process (C2PA is understood to use the latter). + +JDF projects come with a more rigorous handling of IPR (especially in “Traditional” mode) requiring it to be considered explicitly, rather than the more general implicit grant in other projects through licences like Apache 2.0. + +- Good, because it is intended for building specifications +- Good, because it has a more rigorous handling of IPR +- Neutral/bad because it is not aimed at building software directly, which increases friction should the TAMS community wish to own any software (e.g. store implementations). +- Bad, because the approach seems to differ somewhat from how TAMS is currently running as an open source project + +### Option 5: Alliance for Open Media (AOM) + +Become a project under the Alliance for Open Media, like [AV1](https://aomedia.org/specifications/av1/). + +AOM is a JDF predominantly concerned with the developmnt and promotion of the AV1 codec. +While there is a working group considering [Storage and Transport Formats](https://aomedia.org/about/organization/#storage-and-transport-formats-working-group) the primary concern seems to be the codec itself. + +- Bad, because of the significant focus on AV1 + +## Appendix: Detailed Organisation Research + +Based on the [questions laid out above](#decision-drivers), research was carried out into each candidate organisation. +This was used as the basis of each Option, the Pros and Cons and the SWOT analysis above, and is reproduced here for completeness. + +### How does governance work? + + +| | How does governance work? | +| -- | -- | +| Academy Software Foundation | The principles of the ASWF include open licence, separation of technical concerns, open participation and neutral ownership. TAMS being framed as a broadcast technology falls outside of the organisation scope of motion picture and special effects.
There is a clear application, approval and project governance process that seeks to facilitate a universe of participants and encourage phased progression and growth. | +| Alliance for Open Media | With foundations in the AV1 codec the scope of the organisation has expanded to include working groups, each with a select focus.
There appears to be alignment with TAMS and the objectives of the Storage and Formats working group. Steering group governance stems from a hierarchy of steering committees from member organisations. | +| Cloud-native Computing Foundation | The principles of the CNCF are for projects to contribute to the cloud-native echo system and to be a vendor neutral home.
Organisations are self-governed and supported by an oversight committee which can provide support when called upon, supported by standard templates that can be adjusted to meet project needs and criteria to encourage project progress. | +| Joint Development Foundation | The organisation is focused on the fast initialisation of projects moving to longer-term standards and specifications (including source code and data). A clear process of execution of the membership agreement and the establishment of a project charter with a capability to include project sponsorship. | +| Linux Foundation | The foundation requires projects to use an approved open source licensing model supported by a clear strategy for Intellectual Property ownership and for all assets to be neutrally owned.
Oversight is minimal, with a focus on the separation of business and technical governance to be documented in a charter. | + + +| | What is the legal structure? | +| -- | -- | +| Academy Software Foundation | US Law, 501c6 Series LLC (Limited Liability Company). | +| Alliance for Open Media | The organisation has adopted a number of patent, software and contributor licence agreements that are aligned with the objectives of the organisation and that contributors must comply. Operates within the organisation of the Joint Development Foundation. | +| Cloud-native Computing Foundation | US Law, 501c6 Series LLC (Limited Liability Company). | +| Joint Development Foundation | US Law, operates as a subsidiary of the Joint Development Foundation Projects (501 non-profit). | +| Linux Foundation | US Law,. 501c6 LLC (Limited Liability Company), each project is ‘series’ which is a subset of the LLC. | + +| | What evidence is there of existing unfunded projects, would it be compatible with TAMS? | +| -- | -- | +| Academy Software Foundation | The foundation is formed to manage the curation of a community, a number of projects (approximately ten) supported by funding to be used by all projects. | +| Alliance for Open Media | Unclear. | +| Cloud-native Computing Foundation | The foundation is formed to manage the curation of a community, a number of projects (approximately ten) supported by funding to be used by all projects. | +| Joint Development Foundation | Participation is accepted with no fee or sponsorship. | +| Linux Foundation | Participation is feasible under both community and funding models, and additional scope for combinations. Models without funding receive less support than those with funding, the Linux foundation receives a percentage of the funding to aid support and organisation. | + +| | How are Intellectual Property Rights managed and addressed? | +| -- | -- | +| Academy Software Foundation | It is dependent on the software licence that the project adopts, TAMS uses Apache 2.0 which grants permission to use the code and contributors own their own copyright. | +| Alliance for Open Media | The organisation has a set of patent licences that govern how IPR is managed. | +| Cloud-native Computing Foundation | The organisation charter clearly defines how IPR is to be managed and which specific licences are to be adopted and used. | +| Joint Development Foundation | A flexible approach with a series of well-defined policies being offered to projects to adopt that are aligned with established copyright licences and options. | +| Linux Foundation |It is dependent on the software licence that the project adopts, TAMS uses Apache 2.0 which grants permission to use the code and contributors own their own copyright. | + +| | How is the community managed? | +| -- | -- | +| Academy Software Foundation | In addition to annual events, the organisation leverages an establish digital community and has discovered that this is enabling a wider community of ideas and knowledge sharing alongside membership projects. | +| Alliance for Open Media | This is a project of the Joint Development Foundation and it is likely that communities are out of scope. | +| Cloud-native Computing Foundation | An established large community around the cloud-native ecosystem which would require integration from the existing TAMS community. | +| Joint Development Foundation | The organisation is focused on the principles of establishing work and communities are out of scope. | +| Linux Foundation | The foundation provides a set of tools to support project management and community integration; projects are expected to manage communities independently. | diff --git a/docs/images/ADR0051-LinuxFoundationFamilyTree.drawio.png b/docs/images/ADR0051-LinuxFoundationFamilyTree.drawio.png new file mode 100644 index 00000000..3d1fe49b Binary files /dev/null and b/docs/images/ADR0051-LinuxFoundationFamilyTree.drawio.png differ