search

OpenRefine / openrefine.org

Source website for openrefine.org
https://openrefine.org
Other
133 stars 119 forks source link

Add two extensions developed by RefinePro #260

Open wetneb opened 10 months ago

wetneb commented 10 months ago

I wasn't aware of them but @magdmartin pointed me to them in a call. I think they are worth listing even though they are targeting a fairly old version.

netlify[bot] commented 10 months ago

Deploy Preview for openrefine-website ready!

Name Link
Latest commit 09afcb58d8ad7d9b09e2531e43fbd22caf862247
Latest deploy log https://app.netlify.com/sites/openrefine-website/deploys/6542b664898698000879c713
Deploy Preview https://deploy-preview-260--openrefine-website.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

tfmorris commented 10 months ago

Should the attribution be to the RefinePro forks or the original FAIRplus repos (e.g. https://github.com/FAIRplus/OpenRefine_Authenticator)? They appear to have been contributed by Novartis (NIBR).

magdmartin commented 10 months ago

Thanks for adding them @wetneb .

RefinePro was contracted by NIBR to develop extensions, which were then released via FAIRplus. RefinePro added more details to the readme and ported open issues when forking the FAIRplus repositories. It is more likely that any new tickets or pull requests will receive attention on the RefinePro repositories.

wetneb commented 10 months ago

It is more likely that any new tickets or pull requests will receive attention on the RefinePro repositories.

Personally, I would say that the most actively maintained GitHub repository of a project should not be marked as a fork of another one, but as an independent one. You can convert a fork into a non-fork repository by making a request to GitHub's support.

wetneb commented 10 months ago

It's a valid point, but I would assume good faith here and avoid to scare away the extension author from interacting with the OpenRefine project. I am glad they wrote an extension for OpenRefine and want to encourage them to do more of that.

Looking at the HttpClient.java file, they did make its provenance clear with a comment, so they probably thought they were correctly crediting the original authors by doing that:

/*
    Custom code from original OpenRefine project main/src/com/google/refine/util/HttpClient.java
*/

So I would suspect it's just a lack of familiarity with the concept of license header and the importance to retain them. I think it should be easy to fix.