Skip to content

Instantly share code, notes, and snippets.

@bearlike
Last active May 27, 2023 21:35
Show Gist options
  • Save bearlike/45367689b142fe54ebfd7baacfd8f9f4 to your computer and use it in GitHub Desktop.
Save bearlike/45367689b142fe54ebfd7baacfd8f9f4 to your computer and use it in GitHub Desktop.
Understanding License types and GitHub CICD

Krishna's 2-cents:

My understanding of GitHub Action Workflow files

As far as I know (and in my opinion), focusing on these below potential inputs should be a good starting point for engineering language models for generating workflow files, not exclusive to GitHub Actions [CI/CD]:

  • Workflow Name: A name for the workflow file, eg., "CI", "test", "deploy".
  • On Events: What (kind of) events trigger the workflow. This could be any events such as 'push', 'pull_request', or a on complex structures, it could be an API call with payloads. But for now, focusing on simpler events, should get the job done.
  • Environment Variables: Any environment variables that the workflow needs.
  • Jobs: A list of jobs that the workflow should run. Imagine, complete a serives of sub-tasks to compete a bigger task. Each job is roughly an object should atleast contain the below:
    • Job Name
    • Running Environment: (runs-on, usually a docker image. eg., Ubuntu-1804, etc.)
    • Steps: Series of steps to complete a subtask. This could be a list of steps, where each step is an object that should atleast includes:
      • Name of the step
      • The action to use (uses. this is specific to GitHub CICD)
      • With parameters for the action
      • Run command (if any., bash, python, etc.)
      • Env variables specific to the step
  • Workflow-level 'needs': Any dependencies between jobs, specified at the workflow level. This is to maintian the order of tasks and prevent them from running simultaneously. Like, installing dependencies before testing a script.
  • Secrets: Information about any secrets (like passwords) that need to be used in the workflow.
  • Branches: The branches (master, main, feature/new-feat, etc.) on which the workflow should run. This could be a list of branch names.
  • Job timeout: TLE for jobs. The maximum time that the workflow should be allowed to run before it is forced to stops.
  • Matrix strategy: If you are running jobs in parallel with different configurations, you would need to specify the matrix of configurations.
  • Container: If your jobs run in a container, you would need to specify the container image to use.
  • Services: If your jobs depend on services like databases, you would need to specify those.
  • Concurrency: If you want to limit the number of concurrent runs for a workflow, you would need to specify a concurrency group. Otherwise, your EC2 bill from a job spawning container after container could bankrupt you lol.

Workflow YAML Basic Structure Explanation

name: Github action workflow name

on:
  push: # Run this workflow every time a new commit pushed to the repository
  pull_request:  # Run this workflow every time a new pull request is opened to the repository
  scheduled: # Run this workflow as a cron job
    - cron: "0 0 * * MON-FRI"
  workflow_dispatch: # Run this workflow on demand (manually)

jobs: # All workflows need at list one job

  job-key: #First job
    name: Job Name
    runs-on: ubuntu-latest # Set the type of machine the workflow will run on
    steps: # Each job can be divided in many steps

      - name: Checkout code # Step name
        uses: actions/checkout@v2 # Action used on the step

      - name: Run Super-Linter # Another step name
        uses: github/super-linter@v3  # Action used on the step
        env:  # Environment variables used on the step
          DEFAULT_BRANCH: main
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Run specific commands # Another step name
        run: |
          ls -lha
          echo "This is a shell command"

Understanding License types

I have only considered commonly used licenses from Github documentation. They should cover most reposities. Any custom licenses would appear as others in repos.license.key so we can safely ignore them.

License License keyword Commercial Use Attribution Necessary Reason Can we use it?
Academic Free License v3.0 afl-3.0 Yes Yes Allows commercial use, distribution, modification, patent use, and private use. Yes
Apache license 2.0 apache-2.0 Yes Yes Permits commercial use, distribution, modification, patent use, and private use. Yes
Artistic license 2.0 artistic-2.0 Yes Yes Allows commercial use, distribution, modification, and private use. Yes
Boost Software License 1.0 bsl-1.0 Yes No Permits commercial use, distribution, modification, and private use. Yes
BSD 2-clause "Simplified" license bsd-2-clause Yes Yes Permits commercial use, distribution, modification, and private use. Yes
BSD 3-clause "New" or "Revised" license bsd-3-clause Yes Yes Permits commercial use, distribution, modification, and private use. Yes
BSD 3-clause Clear license bsd-3-clause-clear Yes Yes Allows commercial use, distribution, modification, and private use. Yes
BSD Zero-Clause license 0bsd Yes No Allows commercial use, distribution, modification, and private use. Yes
Creative Commons Zero v1.0 Universal cc0-1.0 Yes No Allows all uses including commercial use. Yes
Creative Commons Attribution 4.0 cc-by-4.0 Yes Yes Permits commercial use but requires attribution. Yes
Creative Commons Attribution Share Alike 4.0 cc-by-sa-4.0 Yes Yes Allows commercial use but requires attribution and share-alike. Yes
Do What The F*ck You Want To Public License wtfpl Yes No This license is very permissive and essentially allows for any use. Yes
Educational Community License v2.0 ecl-2.0 Yes Yes Permits commercial use, distribution, modification, patent use, and private use. Yes
Eclipse Public License 1.0 epl-1.0 Yes Yes Permits commercial use, distribution, modification, patent use, and private use. Yes
Eclipse Public License 2.0 epl-2.0 Yes Yes Permits commercial use, distribution, modification, patent use, and private use. Yes
European Union Public License 1.1 eupl-1.1 Yes Yes Allows commercial use, distribution, modification, and private use. Yes
GNU Affero General Public License v3.0 agpl-3.0 Yes Yes Permits commercial use, but you must disclose source and network use is also considered distribution. Yes
GNU Lesser General Public License family lgpl Depends Yes Depends on the specific version of the LGPL. All versions permit commercial use, but have some restrictions. Yes
ISC isc Yes Yes Allows commercial use, distribution, modification, and private use. Yes
LaTeX Project Public License v1.3c lppl-1.3c Yes Yes Allows commercial use, distribution, modification, and private use. Yes
Microsoft Public License ms-pl Yes Yes Permits commercial use, distribution, modification, and private use. Yes
MIT mit Yes Yes Permits commercial use, distribution, modification, and private use. Yes
Mozilla Public License 2.0 mpl-2.0 Yes Yes Allows commercial use, distribution, modification, patent use, and private use. Yes
Open Software License 3.0 osl-3.0 Yes Yes Allows commercial use, but any distribution must make the source available. Yes
PostgreSQL License postgresql Yes No Permits commercial use, distribution, modification, and private use. Yes
SIL Open Font License 1.1 ofl-1.1 Yes Yes Allows commercial use, distribution, and modification, but there are restrictions on selling the font by itself. Specific for fonts and not for our purpose. Yes
University of Illinois/NCSA Open Source License ncsa Yes Yes Allows commercial use, distribution, modification, and private use. Yes
The Unlicense unlicense Yes No This license releases the work into the public domain, allowing all uses. Yes
zLib License zlib Yes Yes Allows commercial use, distribution, and modification. Yes
Creative Commons license family cc Depends Depends Depends on the specific type of Creative Commons license. Some allow commercial use, others do not. No
GNU General Public License family gpl Depends Yes Depends on the specific version of the GPL. All versions permit commercial use, but have restrictions on distribution and modification. No
GNU General Public License v2.0 gpl-2.0 Yes Yes Allows commercial use, but any modifications must also be released under the GPL. No
GNU General Public License v3.0 gpl-3.0 Yes Yes Allows commercial use, but any modifications must also be released under the GPL. No
GNU Lesser General Public License v2.1 lgpl-2.1 Yes Yes Allows commercial use, but any modifications or linked code must also be released under the LGPL. No
GNU Lesser General Public License v3.0 lgpl-3.0 Yes Yes Allows commercial use, but any modifications or linked code must also be released under the LGPL. No
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment