这是indexloc提供的服务,不要输入任何密码
Skip to content

chore(LICENSE): clarify license for build scripts #25026

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jul 23, 2025

Conversation

thunder-coding
Copy link
Member

@thunder-coding thunder-coding commented Jun 12, 2025

This should have been obvious but let's just make it clear

Copy link
Member

@TomJo2000 TomJo2000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good suggestion.

But if we're going to be pedentatic we should probably also specify the license for build.sh files.
Since the document is specifically describing the licenses for

  • Patches
  • And non-build files.

But the license for build.sh files (and auxiliary build files like default configs or occasions build stubs/shims) is left unspecified.

There's 3 main ways we can approach this.

  • 1.) Use Apache 2.0 for the build scripts and miscellanea, since that's what the build system uses
    This may be undesirable as it may impose or preclude some rights and freedoms that we do or do not wish to grant in regards to build scripts.
    So we can lump in "Use <FOO License> to permit/preclude <X>, <Y>, <Z>" into this point.
    e.g licensing the build scripts under GPLv3 or MIT.
  • 2.) Copy the licensing approach used for patches.
    This would in effect be Fedora's build script licensing model,
    whereby the build for any given packaged is under the same license terms as that project.
    I don't think this is a good idea as it turns the licensing situation into a messy patchwork.
  • 3.) Be maximally permissive.
    This would in effect be Arch's build script licensing model,
    using a maximally permissive license for build scripts imposes minimal restrictions on the use of our build scripts giving users the greatest amount of flexibility when it comes to using our build scripts.
    The BSD0 or MIT-0 licenses would be good candidates for this purpose as they are maximally permissive versions of common and well defined/understood licenses.
    I would urge against using The Unlicense, as it is less commonly used and thus less well defined.
    It also has issues regarding what rights it can disavow under certain jurisdictions.
    Notably employees of Google, and the US Federal government are not allowed to contribute to projects using The Unlicense due to these concerns.

Edit: Apparently I was misremembering the Fedora thing, and their packaging specs are MIT or MIT-0 licensed.
https://docs.fedoraproject.org/en-US/legal/misc/#_license_of_fedora_spec_files

This should have been obvious but let's just make it clear
@thunder-coding thunder-coding force-pushed the license-clarification branch from cdafc34 to a772e92 Compare July 23, 2025 02:32
@thunder-coding thunder-coding merged commit a772e92 into master Jul 23, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants