Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages without current source of licenses #83879

Open
aviks opened this issue May 19, 2023 · 19 comments
Open

Packages without current source of licenses #83879

aviks opened this issue May 19, 2023 · 19 comments

Comments

@aviks
Copy link
Contributor

aviks commented May 19, 2023

The following packages do not seem to have publicly available sources, and the latest release (cached on the package servers) do not have any associated license file in them. I believe therefore that there is no permission for anyone to use that code, or even cache it on the package servers. I think these packages should be removed from the registry.

BigG
Estapir
GAPTypes
InfrastructureSensing
MeshFinder
MirroredArrayViews

(PS: there are quite a few other packages in the registry without licenses, but since they have associated github repos, I will ping their authors first. If there is no response, we will have to take a similar call about those. But that's for later)

@nilshg
Copy link
Contributor

nilshg commented May 19, 2023

I just checked InfrastructureSensing on JuliaHub to see how much usage it got which yielded nothing but intererstingly on JuliaHub the package is credited to @rbalexan. I'm not sure where JuliaHub gets that info but assuming this is correct maybe you could find other authors in this way?

@ericphanson
Copy link
Member

@ericphanson
Copy link
Member

Ah, #19033 (comment) has a bunch of authors: @Moelf for BigG, @PetrKryslUCSD for MeshFinder, @lucianolorenti for Estapir, and @slmcbane for MirroredArrayViews

@nilshg
Copy link
Contributor

nilshg commented May 19, 2023

Great detective work, looks like all packages can go into the "ping author" pile (and looks like at least some of the authors are still active in the community so that's helpful).

Thanks Avik for looking at this, it's one of those things that potential enterprise users might (rightly!) freak out over.

@fingolfin
Copy link
Contributor

GAPTypes could be deleted / yanked from my POV. Of course you then may wish to yank old versions of GAP.jl that depend on it.

@StefanKarpinski
Copy link
Contributor

While I don't disagree that we should remove these, I think that we should probably add terms of service to the registry, stating that by registering a package, you give at least some right to use the code. It's a little hard to pick terms; we may need to talk to a lawyer about this. I do also think that there's a pretty decent legal case to be made that by publishing and registering code, you obviously intended for people to use it, so that seems like some kind of implicit permission, but obviously we'd rather have explicit permission with clear terms.

@Moelf
Copy link

Moelf commented May 19, 2023

in my case it was superseded by https://github.com/tlienart/Franklin.jl so can we just delete it? I'm sure nobody ever used it

@PetrKryslUCSD
Copy link

@nilshg
Copy link
Contributor

nilshg commented May 19, 2023

Wouldn't the easiest way forward here for the authors to just retrospectively slap an MIT license on this and then there's no need to yank anything?

@ericphanson
Copy link
Member

I believe these particular repos have all been deleted, so they would need to be reconstituted

@lucianolorenti
Copy link

In my case the repository was deleted, I guess it can be removed from the registry

@fingolfin
Copy link
Contributor

If the repository is gone (as in the GAPTypes case), where do we "slap" that license to?

@nilshg
Copy link
Contributor

nilshg commented May 19, 2023

I thought the issue was that these packages are still installable from package servers, so presumably the repos are mirrored there? If that's not the case then yanking is by definition fine.

@Moelf
Copy link

Moelf commented May 19, 2023

Julia's pkg server is designed so that even if author deleted original repo, packages are still installable -- this is a good design.

deleting stuff from pkg server is a separate item, need manual review for sure

@nilshg
Copy link
Contributor

nilshg commented May 19, 2023

That's what I understood, and I apologise if I'm just confusing the issue here but I thought the problem was exactly that

(i) there are packages that are installable from General,
(ii) but don't have a license and therefore expose users to litigation risk, and
(iii) as a point of principle we don't want to yank things from General due to the promises we make on reproducibility.

It seemed to me that to the extent that authors are still contactable it might be feasible to get their permission to just retroactively add an MIT license to wherever these package now exist and General is getting them from, solving the litigation risk issue without yanking.

I might be misunderstanding though and again sorry if I'm just adding noise here.

@ericphanson
Copy link
Member

ericphanson commented May 19, 2023

from Slack, it sounds like from the copyright point of view, it might be OK if the authors just write something in this issue like "I waive copyright to the code in package XYZ", since that is a thing they have the right to do, and it would alleviate users from issues. It wouldn't solve the problem of there are packages without OSI-approved licenses (which is against General's policy in general) but it would mean that in such cases those problems aren't very impactful, and my opinion would be it's fine to leave the packages there without yanking them or such, in that case.

@PetrKryslUCSD
Copy link

I regret but I have already deleted all of those packages!

https://github.com/PetrKryslUCSD/MeshPorter.jl https://github.com/PetrKryslUCSD/MeshKeeper.jl https://github.com/PetrKryslUCSD/MeshMaker.jl https://github.com/PetrKryslUCSD/MeshFinder.jl

As suggested above, I wish to state for the record that I waive the copyright to the above four packages.

@fingolfin
Copy link
Contributor

In many jurisdictions you can not just "waive copyright". Certainly not in Germany.

at the same time, let's not blow things out of proportion. "expose users to litigation risk" is not very plausible. Yes, a hypothetical risk exists, but there are many hurdles against that (like: you must actually use that package AND it's copyright holders must decide to sue AND they must have standing (package non-trivial -- difficult to argue for eg GAPTypes) and a bunch more. The argument given above that registering a package indicates intent to enable others to use your code also has legal weight. So it's not as black and white as some expressed it here. IANAL though (but I was involved centrally in legal proceedings against companies violating the GPL on code I hold
copyright on, which involved talking to lawyers about this quite a bit)

oh and indeed: conversely, even if there is a license attached you are not free of risk... eg you might VIOLATE that license. And get sued for that ;-)

@DilumAluthge
Copy link
Member

@aviks What is the list of remaining packages that are still missing licenses?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants