Tracking Package Contacts - License

[confused-Techie]

Alright, as anyone that's been around on our Discord knows, we recently had to consider the legal implications of redistributing packages, possibly against the license within the package.

This means we needed any one of the following to legal host our packages:

• Express Consent from the Package Author (This is done by uploading to the registry, or confirming we are allowed to host the package)
• A License that allows Redistribution

So to start this process I began looking through every unique license that was pulled from Atoms registry, this included 149 unique licenses types being defined throughout every package. This included many saying "License in License" and so on.

So with a lot of help from the rest of the Pulsar Team, we manually combed through every license, and studied the license itself to verify if redistribution was allowed.

Many packages we had to visit the repo itself to verify the license within the repo and confirm we were able to redistribute.

From there that still left many many packages who had no license specified, or a license of a type that does not exist.

For those following packages we then went ahead to the repo of each one, and opened an issue to confirm if we were allowed to redistribute their content.

Although many of the repos have since been archived (Many stating this was because the sunset of Atom), and many additionally may have had their "Issues" disabled for the repo. In either previous case we will go ahead and delete the package from our registry.

But for those that remain we were able to create Issues asking about this, of which many package authors have already responded. But for the ones that haven't I will go ahead and list them here, for ease of access and checking back in later.

The deadline for these remaining package authors to respond is 3 weeks. At which time the package will be removed.

---

• latex-online
• language-wex5
• hotdog-tabs
• bemhtml
• github-user-datatip
• atom-arma-language
• language-dm
• egg
• next-dark
• language-multiverse
• autoclose-editors
• scheme-syntax
• language-bgscript
• quilt-completions
• atom-selenium-autocomplete
• atom-monokai-one-dark
• linter-flexible-survival
• single-ut
• language-tree-test
• gpp-compiler
• mura-snippets
• haskell-tools
• language-todotxt-plus
• autocomplete-webgl
• emp-frontend-devtool
• language-nagios
• language-t8-assembly
• language-topas
• itunes
• execute-command
• language-antimony
• smilebin
• sandstorm-syntax
• swinsian
• language-maxlang
• export-project-html
• language-spf
• goproof
• find-dependencies
• aural-coding
• language-epic
• neolao
• insert-require
• mdfld
• snippr-io-editors-atom
• atom-grok-highlighter
• atom-expressionengine
• cga-4bit-syntax
• darker-one-dark-syntax
• language-cwl-atom
• language-structured-text
• atom-nonmem
• hello-world
• language-fhem
• cwl-solarized-dark
• thedaniel-test-package-2
• kobble
• irene-emojify
• devfactory-language-client
• language-category-compiler
• language-gpp
• language-tesp
• continuum-atom
• cut-line
• nitrogen
• luser-inerface-ui
• made-of-code-atom
• keystrokes
• language-jsil
• lang-gdscript
• language-ivan
• monokai-soft
• oblivion-contrast-syntax

[Digitalone1]

@confused-Techie To retain the names after the package deletion you would have to make pointer column of names table nullable (we set NOT NULL on creation).

https://github.com/pulsar-edit/package-backend/blob/main/scripts/database/create_names_table.sql#L7

In PostgreSQL the default action for foreign keys is ON DELETE SET NULL, so you can set the field nullable to change it to null when the package is deleted. This way the names of deleted packages will remain with null pointer.

[confused-Techie]

@Digitalone1 great news! Thanks, so if we just set names to be nullable, then the existing code should work just fine for not deleting it?

[Digitalone1]

@Digitalone1 great news! Thanks, so if we just set names to be nullable, then the existing code should work just fine for not deleting it?

No, we should remove the query for names deletion. At the moment, if you need to remove a package, collect all queries in deletePackageByName and strip only the part related to the names table.

[confused-Techie]

@Digitalone1 great news! Thanks, so if we just set names to be nullable, then the existing code should work just fine for not deleting it?

No, we should remove the query for names deletion. At the moment, if you need to remove a package, collect all queries in deletePackageByName and strip only the part related to the names table.

Thanks for the info, we could handle this on a PR here soon, but sounds good to me

[Digitalone1]

In PostgreSQL the default action for foreign keys is ON DELETE SET NULL, so you can set the field nullable to change it to null when the package is deleted. This way the names of deleted packages will remain with null pointer.

Unfortunately, I'm wrong. We have to drop the existing constraint and make a new one. In #62 there's an easy step by step guide to do this.

[confused-Techie]

Alright, it's been 3 weeks. Time to start going through this list and closing the issues, marking which packages should be removed.

[confused-Techie]

Alright, all issues here are closed and have responded to properly.

All that leaves is for the actual deletion to occur.

Some quick stats about the last step here.

Out of 105 packages marked as having invalid licenses, that is no license key in the package.json and no LICENSE.md within the repo:

• 21 Community Packages had responses from the maintainers to keep them
• 83 Packages either were archived after creating the issue, or received no response within 3 weeks and must be removed.
• 1 Atom Package was mistakenly marked

So this means 83 packages will have to be removed from the Pulsar Package Registry. These packages will be added to our Admin Actions log, and hopefully in the future if someone wants, they can recreate the functionality within said package.