[Bioc-devel] Policies regarding forked packages

Henrik Bengtsson henr|k@bengt@@on @end|ng |rom gm@||@com
Fri Nov 1 19:26:51 CET 2024


FWIW, the CRAN Repository Policies
(https://cran.r-project.org/web/packages/policies.html) has the below
regarding "takeovers". Maybe Bioconductor can borrow from this.

"Packages should be named in a way that does not conflict
(irrespective of case) with any current or past CRAN package (the
Archive area can be consulted), nor any current Bioconductor package.
Package maintainers give the right to use that package name to CRAN
when they submit, so the CRAN team may orphan a package and allow
another maintainer to take it over. Package names on CRAN are
persistent and in general it is not permitted to change a package’s
name.

When a new maintainer wishes to take over a package, this should be
accompanied by the written agreement of the previous maintainer
(unless the package has been formally orphaned)."

This covers takeover of a package that has been orphaned.  CRAN uses:

Maintainer: ORPHANED

to formally mark a package orphaned, e.g.
https://github.com/search?q=org%3Acran+Maintainer%3A+ORPHANED&type=code

R CMD check with _R_CHECK_ORPHANED_=true gives an alert (NOTE or
WARNING?) package that directly or indirectly depend on an orphaned
package.

The CRAN Policies doesn't say how and when CRAN decides to orphan a
package.  My guess is that they might do it when they noticed that the
maintainer does not respond to their requests, or the maintainer's
email address bounces. OTH, we
(https://www.cranhaven.org/dashboard-live.html) also see that they end
up archiving all-OK packages when the maintainer does not respond,
e.g. https://cran.r-project.org/package=SACCR.

Although not explicitly stated, CRAN has the power to orphan a
package, and *orphaned* packages can be taken over per the above
policies. They don't write anything explicit about taking over
*archived*, non-orphaned packages, but I guess that can declare a
package that has been archived for a "long time" to be orphaned, and
thereby allow someone to take it over.

/Henrik

On Fri, Nov 1, 2024 at 9:46 AM Alexey Sergushichev <alsergbox using gmail.com> wrote:
>
> Hi,
>
> I also would add that it could make sense to rename your fork. I understand
> this is a normal practice in open source software, that you start a new
> project by forking an old one, but unless you have an explicit permission
> to use the original package name, I'm not sure using it is ethically or
> legally correct. When you have your own package name, the MIT licence
> allows you to use the old code.
>
> Best,
> Aexey
>
> On Fri, Nov 1, 2024 at 11:06 AM Leonardo Collado Torres <
> lcolladotor using gmail.com> wrote:
>
> > Hi,
> >
> > I'm not from Bioconductor core. Just a heads up that they've been busy
> > with the BioC 3.20 release that was just recently completed
> > https://bioconductor.org/news/bioc_3_20_release/.
> >
> > From the sideline, it seems that you are doing a great service to the
> > community by keeping your fork in working conditions. From
> > https://github.com/Bioconductor/Contributions/issues/new I don't see
> > any specific info about your question. Searching "fork" at
> > https://contributions.bioconductor.org/index.html also didn't lead me
> > to any relevant results.
> >
> > Best,
> > Leo
> >
> > Leonardo Collado Torres, Ph. D.
> > Investigator, LIEBER INSTITUTE for BRAIN DEVELOPMENT
> > Assistant Professor, Department of Biostatistics
> > Johns Hopkins Bloomberg School of Public Health
> > 855 N. Wolfe St., Room 382
> > Baltimore, MD 21205
> > lcolladotor.github.io
> > lcolladotor using gmail.com
> >
> > Leonardo Collado Torres, Ph. D.
> > Investigator, LIEBER INSTITUTE for BRAIN DEVELOPMENT
> > Assistant Professor, Department of Biostatistics
> > Johns Hopkins Bloomberg School of Public Health
> > 855 N. Wolfe St., Room 382
> > Baltimore, MD 21205
> > lcolladotor.github.io
> > lcolladotor using gmail.com
> >
> >
> >
> > On Mon, Oct 28, 2024 at 9:39 AM Ali Sajid Imami
> > <ali.sajid.imami using gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I have a question about your policies regarding forked packages. There
> > is a package that some of our other packages depend on and is of interest
> > to the Bioconductor community that our lab did not create. However, the
> > package was never submitted to CRAN or BioConductor, and the original
> > authors are not reachable. It has not been updated in over 7 years, and
> > consequently, it does not build. It is, however, licensed under the MIT
> > license. To ensure our build systems and analysis pipelines keep working,
> > we forked this package a while back and have been maintaining that fork.
> > What is the policy regarding submitting this package to Bioconductor? Our
> > lab is well-versed in the package’s codebase, and we would be able to both
> > maintain it indefinitely and be able to address any comments from the
> > BioConductor community.
> > >
> > >
> > >
> > >
> > >
> > > ------------------------
> > > Regards,
> > > Dr. Ali Sajid Imami
> > > LinkedIn <https://pk.linkedin.com/pub/ali-sajid-imami/50/956/2a6>
> > >
> > > Out of the night that covers me,
> > >       Black as the pit from pole to pole,
> > > I thank whatever gods may be
> > >       For my unconquerable soul.
> > >
> > > It matters not how strait the gate,
> > >       How charged with punishments the scroll,
> > > I am the master of my fate,
> > >       I am the captain of my soul.”
> > >
> > > Invictus by William Ernest Henley
> > >
> > >
> > >         [[alternative HTML version deleted]]
> > >
> > > _______________________________________________
> > > Bioc-devel using r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> > _______________________________________________
> > Bioc-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



More information about the Bioc-devel mailing list