Possible idea:

An edit button that takes you to the add package form with everything filled out. An additional option to remove the older version from the project, pre-selected. This would allow for editing usage data, by nature.

Title -- some data consistency issues appearing otherwise.

On bigger projects, oss-a-b can be a bit slow since the JSON payload for packages_used is sync'd for each edit. This can result in a sluggish UI and apparent timeouts, resulting in duplicated packages submitted. Then, when removing a duplicate, both packages get removed since they'd have the same package ID. (This doesn't affect multiple revisions of packages, since those would result in new IDs for modifications.)

These turned out to be a rather large maintenance pain. More practical to use an existing solution (say, Passport) and cookies instead of trying to manage session data in the browser.

General tracking task to update everything that is old in package.json.

For packages with GitHub/Bitbucket/etc URLs, there's a high chance we can automatically discover and import a package's license text.

For example, if an admin wants to call out a few common licenses in the dropdown, or provide additional links/references/documentation.

ACLs currently only use the 'owner' permission level, and even then the support is rather poor. This is an artifact of removing a permission system that was married to Amazon-internal systems, and it now needs some fixing up.

The function transformCopyright() may be provided by TAGS attached to a license to modify the text to be produced for the copyright statement.

For Apache-2.0 license the tag notice is defined which should strip off the copyright notice at the beginning of the attribution text and append it as 'see following NOTICE:' at the end.

This does not seem to work as expected, as the following steps show:

• Create a new project
• Define a new package using 'Apache-2.0' license.
• Build attribution document.

The document generated contains the copyright notice TWICE, one occurence at the beginning of the text and one at the end.

The expected behavior is that the copyright NOTICE only appears ONCE at the end of the text.

Hi, testing the attribution builder, I ran into the following issue: the builder is only accessible at port 8000 instead of 2424. Could it be that the README/quickstart guide needs to be updated?

Provide a way to archive a project to hide it from view. Somewhat like deleting a project, but non-destructive.

We've collected information about many components from other sources and would like to be able to add them programmatically. We'd need an API for getting, adding, and updating components.

Things are broken on Node versions newer than 6.

• Migrate to Gulp 4?
• Drop Gulp entirely and use something else? npm scripts, makefiles, etc?

Once a project has been created, it's not possible to edit the ACL, or even the owner, via the UI. The API is (mostly) there.

We've been considering the ability to mark license/copyright information as having been validated/confirmed/curated if an "approved" person has looked at it (or the information has come from a trusted source).

I'm considering a couple of changes and wanted to get your input on them:

• Add an attribute to components to flag that the information has been validated (probably a date and some kind of field to track who did the validation)
• Add a page that lists components and allows them to be edited (specifically to allow marking a component as validated)
• In the component selector when you're editing a product's attribution provide some kind of indicator against validated components

The UI was recently migrated from Bootstrap 3 to 4 (alpha 6). Some components may have been missed. Scan through and clean these up -- it's possible for there to be nothing left to do.

Right now, the attribution builder assumes that a person is using the website. This is reflected in audit logs, access checks, etc. It's possible to implement a custom auth backend that allows for programmatic access, but that gets a little hacky and doesn't play nice with traditional authentication.

To solve issues like #14, I'm thinking of building in support for programmatic clients that access the site via API keys. These keys will map to user accounts and will be stored in a new database table (or perhaps Redis, since it's in the firing line of a request). These could then be configured to access resources via the usual configuration system. API clients could then present an Authorization header with said key.

I'd imagine the format of that table would look something like this:

I'm not sure there will be any kind of UI for this; at most there'd be a CLI tool to create an API service user. Still thinking of specifics, but there's a rough overview.

The storage mechanism for contacts is flexible, but the UI currently only allows for one contact to be listed: a legal contact. There's no reason to not allow for arbitrary types, possibly specified via configuration.

These should ideally work in Docker.

Due to our own shifting needs we have decided to stop building or supporting oss-attribution-builder. We will be archiving it in place as others might find value in the content and I hope some do.

While this package is no longer being supported you can still hop on over to the TODO Group Slack channel to discuss/discover tooling that is pertinent to this domain.

Thanks for adding this! :) Going through the API I noticed that "attach a package to the project" requires a "packageId" (which apparently can be any number<=total amount of packages in database)
Attaching this new package then returns the actual "packageId" of the new package created in the attribution-builder database.
I don't understand yet, why "packageId" is required at all, and new packages are never checked for duplicates.
Let's say my project already has:
"packageId": "1"
"name": "Pkg1"
"version": "1.0.0"
and
"packageId":"2"
"name":"Pkg2"
"version":"1.0.0"

Attaching
"packageId":"1"
"name":"Pkg2"
"version":"1.0.0"
simply attaches a duplicate of "Pgk2" to my project (which I can't delete via the API) and returns "packageId":"3"

This might be obvious for someone else, but I don't see the reason for this yet.

At the moment, for text to be available for a license, it has to be manually entered into the licenses/known directory. SPDX publishes texts in a standard manner and it should be easier to use these from within the attribution builder.

There is another Issue I ran into. When I first used the API to create a new Project, I would use an input structure as follows:
data class NewProject( val title: String, val version: String, val description: String, val plannedRelease: String, val contacts: Contacts, val acl: ACL, val metadata: ObjectNode )

data class ACL( val everyone: String )

This would work perfectly fine, as long as val everyone = "owner"
Now, going through the code again, I changed it to:
enum class ACL(private val permission: String) { OWNER("owner"), EDITOR("editor"), VIEWER("viewer"); @JsonValue override fun toString() = permission }
And the same request returns: "error":"You cannot remove yourself as an owner." for ACL.OWNER

I can't really see, where/ why/ how that happens :(
Weirdly, the same error occurs when I change it back to the first implementation, but replace the value name by anything else but "everyone". For example:

data class ACL( val role: String )

Could anyone ;) clarify this for me?

Being able to clone an existing project for a new version or major release would be useful. Otherwise digging out old attribution documents can be a pain.

For example, a "linkage" tag could be used to activate the "Dynamic or static" linking question.