Bug#828970: ITP: singularity -- application containerization platform
Hi Dave,
NB CCing upstream (Gregory) since discussion is public anyways
Thanks for following up, Dave! I haven't realized that you are
maintaining your own fork on github with adjusted debian packaging
and just kept plowing through the upstream's debian/ and submitting them
upstream (minor ones so far).
Before commenting on your points: Do you have intent to maintain
singularity within Debian? should we then join the forces? (I am DD so can
upload)
> [I saw this late as I didn't get a reply to the question about whether
> this was being packaged for Debian.]
> > * License : BSD
> The licence is actually BSD-3-Clause-LBNL in SPDX terms. I think its
> default licensing clause is a potential trap which Debian might
> consider. I've asked for an opinion from Fedora legal about including
> language to nullify that in a "separate written license agreement".
well -- for completeness -- it is "without imposing a separate written license
agreement" and overall paragraph in question is
You are under no obligation whatsoever to provide any bug fixes, patches, or
upgrades to the features, functionality or performance of the source code
("Enhancements") to anyone; however, if you choose to make your Enhancements
available either publicly, or directly to Lawrence Berkeley National
Laboratory, without imposing a separate written license agreement for such
Enhancements, then you hereby grant the following license: a non-exclusive,
royalty-free perpetual license to install, use, modify, prepare derivative
works, incorporate into other computer software, distribute, and sublicense
such enhancements or derivative works thereof, in binary and source code form.
which I (IANAL) do not see a problem with. To me it reads as an additional
clause providing copyleft like license mandating making contributions available
back publicly or directly to the lab under permissive terms. But indeed,
it makes the license not quite just a BSD-3 ;)
> The claim on the web site that it is simply BSD3 is wrong
yes
> but the issue that included that was closed without resolution. See also below.
just a note: problems with information on the website do not directly
relate to the problems with the source code/packaging, and there all the terms
are described, right?
> > Programming Lang: C
> It's compiled C used by a set of Bourne shell scripts.
yeap
> > Package name (singularity) conflicts with a game package last released in
> > 2011 with notable popcon of 300... so I guess I would need to come up with an
> > alternative name, e.g.
> > singularity-containers
> > Alternative recommendations are welcome!
> It probably doesn't matter much, but the bundled packaging I contributed
> used the singular.
I thought to just stick to the one you chose:
$> git log -p debian/control | grep -e Package -e Author
...
Author: Gregory M. Kurtzer <gmkurtzer@lbl.gov>
+Package: singularity-container
> Debian might want to be circumspect about copyright issues surrounding
> this. The unresolved issue mentioned above concerned the claim on the
> project web site that copyright doesn't apply at least to "patches" and
oh, where on the website? can't find
(git)hopa:~/deb/perspect/singularity[remotes/origin/gh-pages]git
$> git grep -l patch | grep -v '\.js' | xargs grep patch
content/faq.html:<li>Requires root to run (there is however a submitted patch to allow non-root, but it has not been accepted at this point)</li>
content/faq.html:<li>Even with the proposed patch, no mitigation of user escalation within the container</li>
content/faq.html:are leveraging any kernel version specific or external patches/module
content/home.html:a standing unimplemented patch to RunC (already daemon-less) which allows for
content/install.html:Packages for singularity (2.0 plus some patches) have now hit the Fedora
content/license.html:You are under no obligation whatsoever to provide any bug fixes, patches, or
> I was subsequently told "You cannot “own” copyright in something you
> contribute to a 3-clause BSD project." (despite the project licence
> requiring you to grant a licence...). I find it difficult to believe
> that's what LBNL lawyers actually say, but there you are.
> <https://github.com/gmkurtzer/singularity/issues/117>
I guess you are talking about rhc54 AKA Ralph Castain ? But he is not a
lawyer [1] and not a major contributor to singularity anyways (although
with sufficiently high privileges apparently on the upstream github repo).
I am really not sure what kind of bad mood (or grappa) could make him say "You
cannot own" phrase... so I must say, I would just ignore that portion of the
discussion, and provide concrete pull request suggesting adjustment of the
wording and make that issue close with that:
https://github.com/gmkurtzer/singularity/pull/137/files
and by the time I have finished writing this email Gregory has already
merged it! ;)
ut again -- that is not directly related to
packaging/redistribution in Debian or Fedora.
[1] https://github.com/gmkurtzer/singularity/issues/117#issuecomment-231357131
> This should be added to the post v2.0 upstream copyright file (if you're
> using that and update from 2.0) since obviously Debian doesn't subscribe
> to the LBNL copyright theory (see also
> <https://github.com/loveshack/singularity>):
> Files: libexec/docker-import.sh
> Copyright: 2016 Dave Love, University of Liverpool
> License: BSD-3-Clause-LBNL
> There are potential security issues in the setuid program, with patches
> for v2.0 under
> <https://pkgs.fedoraproject.org/cgit/rpms/singularity.git>, but it looks
> as if more are needed.
oh -- thanks for the pointer. So, if I get it right, you aren't feeling
like contributing those patches to upstream yourself ATM? and you would
reconsider whenever a clarification is made on you retaining the
copyright to those patches? or what exactly? (I usually do not really
care much enough to sweat for claiming my ownership on every line I have
ever changed.... git log keeps the record of the truth! ;) )
So, now we (I or you? or both?) should absorb the changes you have
accumulated in your clone and/or fedora packaging, within Debian
package:
$> git diff --stat master...gh-loveshack/master
COPYING | 7 ++++++-
debian/copyright | 76 +++++++++++++++++++++++++++++++++++++++++-----------------------------------
src/file.c | 2 +-
src/image-bind.c | 2 +-
src/image-mount.c | 2 +-
src/image.c | 13 ++++++++++---
src/loop-control.c | 2 +-
src/message.c | 4 ++--
src/message.h | 3 ++-
src/mounts.c | 4 ++--
src/sexec.c | 8 +++++++-
some of those specific to debian/packaging (e.g. COPYING) should
then in case of debian pkging go under debian/patches due to
$> cat debian/source/format
3.0 (quilt)
anyways....
I can do all of that (absorb some within debian/patches, create a
separate clone etc) but wondered what you Dave and Gregory would
decide upon -- majority of those patches look like changes desirable in
upstream codebase, and not under a growing collection of patches in each
distribution.
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: