-
Notifications
You must be signed in to change notification settings - Fork 380
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
[ RFC ] Process for moving modules out of the contrib
package.
#2866
Comments
Thanks a lot for your suggestions @mattpolzin . Just a small note from my side: Every time we drop stuff from contrib we potentially break a lot of packages. I therefore suggest that we check the pack collection for the impact these changes will have and try to inform package maintainers beforehand. I can try and help with this. |
@stefan-hoeck yeah, you're right that these changes are very likely to break packages. Do you suggest that something new be slotted into the process or are you aiming for an informal awareness that packages included in I know it was previously decided that we shouldn't run |
I was aiming for informal awareness and hinting at the possibility that we/I could at least test the pack collection manually in case of deletions from contrib that don't go to base. On the other hand, I still think it would be useful to run certain PRs against the pack collection in general. Perhaps something triggered by a label as you suggest? If I understand correctly, labels can only be set by the project maintainers, right? At least, I never figured out how I could set labels for my own PRs myself. |
That's my understanding as well. I've always found it confusing, but I suppose there is some logic in protecting the labeling system -- maybe all the more so if a label triggers something in CI. |
Isn't the code in I guess I'm proposing to remove the text about licenses above. It should be implicit that if you're copying the code you need to either keep the same license, or make it clear that your new choice of license only applies to new code added after the move.
What's the purpose of this requirement? An alternative would be for the person who proposes to maintain it to simply decide where they want it; e.g. they might put it with their other git repos. |
I think you’re right, that was an oversight. We should either require the same copyright or ask Edwin for permission to re-license the redistributed code. I’ll modify the above text to say it must use the same license (or include it’s text prior to a statement that new or heavily modified portions are under a different license, because that is allowed).
This allows the community to pick new maintainers for these projects over time even if the original author moves on without time or foresight to find a new maintainer themselves. I’ve been privy to numerous projects where the original maintainer moves on; that should be ok, but I don’t want it to make it hard for the community to continue using and maintaining this work. Also, offering ones time to help extract a portion of the contrib package should not imply that person is offering their time beyond extraction. |
IANAL, but BSD license allows arbitrary re-licensing preserving the original copyright notice (with no restrictions to adding new notices). So, these options are not exclusive, we can (and, actually, must) preserve existing copyright, and we can add new lines to notice mentioning re-licenser, covering years after movement from the original repository. Surely, Edwin can cease his copyright and allow to mention only new copyright holder (say, the Idris community), but why bother, if new lines just can be added, since it's allowed by the current license? By the way, the existing copyright notice is very old, I think it should be extended to the present year. |
That sounds right, except I'm pretty sure you need to keep around not just the copyright line but the whole original license text:
I don't think that's an obstacle to switching licenses, so long as the old license text is kept around to satisfy that condition. I don't know if the new license would apply to the old code or just the code added after the license changed. I think the copyright holder(s) can agree to a new license if that helps. I don't know if it's just Edwin who holds the copyright, though; I see many contributers in the git log. Here's an example of a project maintainer asking all contributers to agree to a license change. |
@buzden @falsifian Please let me know if I have captured this (more correct) understanding of the license requirements:
I am pretty sure that although some or most of code in the new repository may be the same as the code that originated in the Idris 2 project, the new repository itself is a derivative work (a new package, after all) and therefore there is no distinction needed between old code & new code within the new license as long as the Idris 2 license text is included. |
I have a small quibble, but at this point I'm far enough out of my depth that you shouldn't let it block you, and I have seen contradictory claims by others (presumably also not lawyers) on the Internet; see e.g. this post and follow-up comments which disagree. My quibble's only about how the new repo ought to to describe the licensing situation, not about whether or not things can be distributed. (BTW, my vague sense is that it's a bit rude when forking a project to change licences, but I don't really know if that's true, and in any case this isn't forking. Still, I would default to not changing licences, for simplicity.) My understanding is that if I fork someone else's (BSD-licensed, for example) project under a different licences (GPL, for example), my own licence only applies to stuff I wrote after the fork. Say the original project had just one file, Here is some possible replacement text:
|
UPDATES (not part of proposal text):
Summary / Motivation
A while back, it was decided that the
contrib
package should be disbanded (via general consensus, conversation at an Idris Developer Meeting, and perhaps at least as importantly by Edwin). I won't get into the details of why in this document, but suffice to say thatcontrib
represents a mix of modules that are (a) important enough to eventually land inbase
or (b) niche enough to not be worth maintaining as part of the core project. The second category does not make a module less useful (qualitatively) but it makes it less frequently of-use and possibly leaves it with fewer core project contributors who are knowledgable enough or motivated enough to maintain it.Therefore, we can begin the process of moving modules out of
contrib
at will.The rest of this proposal represents my personal thoughts and intuitions on a process for moving things out of
contrib
and I would love feedback from anyone interested in shaping that process.The following wiki page will be a final repository for this information once some semblance of agreement has been reached: [TBD].
The proposal
Criteria & Destination
First, we know that all of the
contrib
package is intended to be disbanded. Some of it may end up in thebase
library, other parts of it may end up in packages hosted by the community. @eayus put a lot of work into mapping out proposed destinations (base
vs. third party) in the wiki. Although much of that document is not worded very strongly (i.e. "I think..." rather than "it is decided..."), it is the closest thing we have to consensus on destinations for modules at this point in time. The document was aired in Discord and as part of an Idris Developer Meeting -- I don't know personally if it was posted to the mailing list, but I hope it was. At any rate, I propose that this document be a strong indication of preference given the time others have had to voice opinions. I also think it is important that any contributor feels welcome to argue the opposite of what the document currently indicates in public channels (GitHub Isuee, Discord, Mailing List) -- the document is not set in stone.The document leaves some things more up in the air than others, and I propose that anyone who wants to relocate one or more modules but feels uncertain at all about where to put those modules or how to structure a new package to contain those modules should feel free and encouraged to engage the community in further strategizing.
TLDR; If you agree with the wiki about a module you would like to relocate, proceed with your own interpretation of the best relocation and feel free and encouraged to engage the community in further strategizing via GitHub Issues, Discord, or the Mailing List.
Process
For all
contrib
module extractions, it is highly recommended that you open a GitHub ticket on the Idris2 compiler project explaining what you are about to do; this adds visibility into your efforts and reduces the likelihood that more than one person is working on the same thing!base
Relocation ProcessI propose that for modules being moved into the
base
package, a single Pull Request implements the following:contrib
.contrib
.ipkg
file.base
. The code is either nearly identical to the code fromcontrib
or the PR description explains the reasoning behind differences. Differences with good motivation are perfectly within bounds.base
.ipkg
file.Example: Data.List.HasLength.
Third-Party Relocation Process
First of all, I propose it be required that the relevant module(s) is/are ported to a new repository hosted under the GitHub organization https://github.com/idris-community. This requires reaching out to one of the organization maintainers to create the repository, but you (the person writing the new package) will be given administrative permission over the repository you are creating. Repositories can also be moved to the community group after creation. This allows the community to pick new maintainers for these projects over time even if the original author moves on without time or foresight to find a new maintainer themselves.
It is important to also say that anyone is free to create their own repositories that reproduce portions of the
contrib
package under their own control and with that there are no rules guiding where the repository is located; this process only applies when a person chooses to submit a PR that removes the relevant module(s) from thecontrib
package.I propose that for modules being moved into third-party packages, the following process is followed:
contrib
..ipkg
file.pack
andsirdi
have both been actively developed recently, howeverpack
is currently getting more use and active maintenance to the best of my knowledge).contrib
package. This includes both the module(s) source code and any references from thecontrib.ipkg
file.Acquiring an
idris-community
GitHub RepositoryIf you do not have the ability to create repositories under the
idris-community
organization, reach out to Matt Polzin via Discord (matt.polzin#2289) or email ([email protected]) to request membership in the community.The text was updated successfully, but these errors were encountered: