Comments (7)
The Dash License Tool uses the standard GitLab API to create issues. If you make an issue in the correct form, it will "just work".
Theoretically, we could extend the scanner to look at the staging repo for sources. We can easily add new Nexus repositories if we know the base artifacts URL. The problem with this is that the content in the staging repository isn't necessarily stable. In fact, it disappears by design.
It occurs to me that the source stability problem actually extends to any content for which we pull sources from a staging server: whether the corresponding issues are automatically created or created via some API or automation.
Pointing to staged artifacts that are inevitably removed is actually an antipattern.
from dash-licenses.
I understand where you are coming from, together with the issue you see.
My main issue, that I want to make the acceptance by the Dash Tool a quality gate. Right now I have to release something and then I will find out if you are happy. Additionally anyone who uses our new Version for an Eclipse Porject will need to do a more or less manual step, before their project is accepted by Eclipse process for release.
Just for my understanding: After an artifact is checked and deemed acceptable, I guess you will identify it later via its coordinates in a stable Repository (like Maven Central)?
My main issue is, with an artifact I deploy to Maven Central:
- I build and release it to sonartype staging (automated).
- Then I already have to manually go to the sonartype repo.
- Close it.
- Wait till the checks are green.
- Mark it for release.
- Pray and wait (as sometimes it does not publish it, even if all the checks are green).
Now I would need to add another manual step, which is only possible after the Artifact is really synced to maven central and trigger the dash process.
Right now, I don't have a good idea how an acceptable solution could look like. :-(
Ideas?
from dash-licenses.
Just for my understanding: After an artifact is checked and deemed acceptable, I guess you will identify it later via its coordinates in a stable Repository (like Maven Central)?
Yes.
Random idea...
If you were to create an issue that points to a commit on a GitHub repository, it will scan a snapshot based on that.
e.g., git/github/eclipse/dash-licenses/65decbd4f82198acd764737166f11edc3ecbe60d
IPLab will grab a ZIP of the github.com/eclipse/dash-licenses
repository at the specified commit and scan that.
The coordinates that we stuff into our database would be correct, but not useful enough to be reused.
from dash-licenses.
I'll note that the problem that we're trying to solve here is not "make the Dash License Tool happy", but to more generally improve the odds that any attempts to automate license scanning will be successful. Anything that you can do to make your project's license intention more consistently discoverable via automation will be a net benefit for every adopter.
The IPLab scanner uses Scancode Toolkit. Scancode identifies licenses, it doesn't make any decisions. Our scanner interprets the results produced by Scancode, but doesn't do anything particularly magical or complicated. The one big optimisation that we do is take a license declaration made with an SPDX-License-Identifier
in the header at face value and ignore any other license information that it finds in the file.
So... if you put the SPDX-License-Identifier
header in every file, then you'd be good-to-go. Alternatively, if you at least put that header in the files that make references to other licenses, most of the problem would be addressed (BND, for example, has a bunch of files that make solid references to all manner of licenses).
from dash-licenses.
If, for example, you added a license header with an SPDX-License-Identifier
tag to the top of the license
files in bndtools/bnd (e.g., GPL_2_0.java), then automated tools would have a fighting chance of understanding the license of the file.
I believe that Scancode is getting fetched up on the GPL reference in this comment:
/**
* An annotation to indicate that the type depends on the GNU General Public
* License v2.0. Applying this annotation will add a Bundle-License clause.
*
* @deprecated Replaced by {@link GPL_2_0_only} or {@link GPL_2_0_or_later}.
*/
While this file does represent the GPL, it is not itself distributed under the GPL. If you express your intention unambiguously with an SPDX-License-Identifier
then Scancode, Fossology, FOSSA, ... will have a fighting chance of making sense of it without human intervention.
FYI, I've added a rule to the IPLab scanner to ignore that directory. Making good resilient rules is actually pretty hard in the general case, so this is something that we do very carefully.
from dash-licenses.
Returning back to the original request...
You can create an IPLab issue with an attachment.
from dash-licenses.
Any thoughts on any of the above, @juergen-albert?
from dash-licenses.
Related Issues (20)
- lpg.generator HOT 5
- Add OSGi Metadata
- Problem parsing `yarn.lock` modified by `npm install`? HOT 5
- Don't shade the base artifact HOT 1
- Wrong example package detected in package-lock.json HOT 3
- Remapping of package name is not detected in package-lock.json HOT 3
- mavenLicenseCheck GH workflow is triggered (and immediately skipped) on every issue comment HOT 1
- Correctly parse crates version names HOT 2
- Reduce calls to clearlydefined HOT 2
- Move this repository to to the eclipse-dash organisation HOT 6
- The tool has built-in support for go.sum files
- Cyclic error reported for a bundle with fragment HOT 1
- Source bundles are present in dependencies after upgrading to Tycho 4.0.5. HOT 1
- Too many dependencies are present after upgrading to Tycho 4.0.5. HOT 3
- Download of latest dash-licenses jar is currently not working HOT 1
- Support the Conan C/C++ Package Manager
- dash-licenses does not understand npm Workspaces
- dotnet instructions feedback
- "Plugin not found in any plugin repository" HOT 2
- False positive on call-mvn-license-check github workflow HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dash-licenses.