Jump to content

Source Code & Intellectual Property Policy


- Alex -

Recommended Posts

  • Community Leader

  • Member ID:  1
  • Group:  Community Leader
  • Followers:  11
  • Topic Count:  211
  • Topics Per Day:  0.06
  • Content Count:  508
  • Content Per Day:  0.15
  • Reputation:   36
  • Achievement Points:  4808
  • Solved Content:  0
  • Days Won:  36
  • Joined:  07/11/17
  • Status:  Online
  • Last Seen:  
  • Device:  Windows

Source Code & Intellectual Property Policy
Ownership, Licensing & Project Stewardship
Public GGU policy — subject to revision as systems, responsibilities, and operational practices change.

Public Transparency:
This policy is intentionally published so the community can understand GGU's standards and accountability. Credentials, recovery material, private personnel records, and active security-sensitive details remain restricted.

This policy defines how GGU-developed source code, configuration, documentation, designs, and related technical work should be owned, licensed, stored, reused, and maintained.

 

Purpose

Source-control workflow and intellectual-property ownership are separate concerns. This policy exists so ownership, licensing, and stewardship are handled explicitly rather than being buried inside repository-usage rules.

 

Scope

This policy applies to source code, scripts, configuration, templates, documentation, build systems, automation, infrastructure definitions, graphics, technical assets, and other work created for GGU projects.

 

Project Stewardship

  • Operational projects should live in approved GGU-controlled repositories or other approved shared storage.
  • Projects should identify maintainers or responsible Teams.
  • Deployment and recovery information should not exist only on one person's computer.
  • Repositories should contain enough documentation for another authorized maintainer to understand the project.

 

Ownership Must Be Explicit

GGU should not rely on vague assumptions about ownership. Projects with special contributor, licensing, commissioned-work, partnership, or external ownership arrangements should document those terms explicitly.

 

Work Created for GGU

Where a contributor creates work specifically as part of an assigned GGU role or approved GGU project, the intended ownership or license should be defined by the project or contributor arrangement. If no special terms exist, Leadership should resolve ownership before publication, commercial use, relicensing, or transfer.

 

Existing Personal Projects

A contributor may bring pre-existing code, assets, or tools into a GGU project only when they have the right to do so. Pre-existing ownership should be identified rather than silently treated as newly created GGU work.

 

Third-Party Code & Assets

  • Respect software and asset licenses.
  • Preserve attribution and notices where required.
  • Do not copy proprietary source or assets without permission.
  • Do not use dependencies whose licensing conflicts with the intended project distribution without review.
  • Track important third-party dependencies where practical.

 

Open Source

Before publishing a GGU project as open source, verify that it contains no secrets, private member data, restricted infrastructure details, or third-party material that cannot legally be redistributed. The chosen license should be deliberate.

 

Closed Source

Closed-source GGU repositories remain restricted to authorized users. Private status does not eliminate the need to define contributor rights, third-party licensing obligations, or project ownership.

 

Contributor Rights & Credit

GGU should reasonably preserve contributor credit where appropriate. Credit does not automatically grant ongoing administrative access, ownership of unrelated project components, or a right to prevent operational maintenance after the contributor leaves.

 

Departure or Role Change

  • Operational source and documentation must remain accessible to GGU.
  • Departing contributors should transfer project knowledge and ownership of deployment processes.
  • Personal credentials should be removed or replaced.
  • Shared secrets known to departing users should be rotated when appropriate.
  • A departing contributor must not intentionally withhold required operational code, configuration, or documentation.

 

Forking & Reuse

Reuse of GGU code or assets outside GGU depends on the applicable license, ownership, project agreement, or explicit approval. Public availability alone does not automatically grant unrestricted reuse unless the published license permits it.

 

AI-Assisted Contributions

AI-assisted code or content is still subject to the same ownership, licensing, security, review, and third-party provenance requirements as human-created work.

 

Disputes

Ownership or licensing disputes should be escalated to Community Leadership or the Owner before code is published, relicensed, sold, transferred, or removed from GGU control.

 

Documentation

Projects with non-standard ownership or licensing terms should document those terms in an appropriate repository or organizational record.

 

Related Policy

  • Git / Gitea Repository Usage Policy
  • AI-Assisted Development & Content Policy
  • Third-Party & Partner Access Policy

 

Make ownership explicit before it becomes a dispute.

Alex Thunderhunter

Alex — Founder & Systems Architect

Building the community, one server at a time.

Community Leader
Link to comment
Share on other sites


  • Replies 0
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.