[License-discuss] [Non-DoD Source] Re: Discussion: AGPL and Open Source Definition conflict

[Thorsten Glaser]

Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss dixit:

>If it were to be done seriously, then a great deal more thought would
>need to go into it. In one of the messages I sent out (see

What I’m doing at $dayjob (which is involved in Java™ mostly) is to,
at build time, do…

1. check if the source tree is clean (git status)
2. create, in a temp subdirectory, a clean copy of the source tree
   (git archive HEAD | tar xf, basically) with no files added/removed
3. create a tarball from that
4. ask Maven to download me the source JARs¹ of all dependencies
   (recursively) into another directory hierarchy
5. create a PKZIP archive from that
6. place the two archvies so that they will be included in the WAR
   file (basically Java Web executable, which the application server
   serves as HTTP file tree) and thus shipped inside the binary
7. at the end of build, check the committed list of dependencies
   against the current list and update² if necessary

The web code already has links to the two archives and the global
LICENCE.txt file (see below) plus extra licence files (things like
the LGPL, Apache licence, CPL, CC-BY, etc. get kept separate). See
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=veraweb/veraweb.git;a=tree
if you wish to see it in action.

① source JARs is the best we can get from Maven; they normally
  only contain a copy of the .java files that are direct source
  for the .class files in the binary JAR, plus some minor metadata;
  some projects don’t even have that, so I recently amended this
  mechanism to account for those and placed manually downloaded
  distfiles into the tree that are copied there as well; so,
  source JARs are *not* Complete Corresponding Source, but we
  don’t deal with GPL/AGPL in the Java™ world (too much CDDL/EPL),
  and there’s often no (automatable) way to get the distfiles

  Torsten Werner had this idea of rebootstrapping a new Maven
  repository with explicit source requirements, it never went
  anywhere though.

  Oh, and don’t ever trust metadata like <license/> tags in the
  POMs (or, worse, package.json in the JavaScript world which is
  even more wild-west), they lie. Inspect every single file… or
  at least do some overall grepping plus some random sampling.

② by changing the file, showing a diff, telling the user to
  commit the changed file, and breaking the build (since this
  list is used in the earlier step), plus the dependencies in
  the list have a flag whether licence review has been done,
  which of course must be re-done each time a dependency ver‐
  sion changes (I painstakingly copy all licence grants and
  Apache NOTICE files into a central LICENCE.txt file also in
  the webroot of the project)

This is not perfect for multiple reasons, mostly the inadequate
source JAR mechanism (but if I get the binary JARs from an in‐
termediate, the Maven Central repository, and source JARs are
all I get, I’d argue that I couldn’t have done better if some‐
one complains and send them to the Maven Central operators).
Our software also creates source JARs for the individual com‐
ponents, nothing better, as there’s no standardised mechanism
in the Maven world; we could³ do better, but at least naming
would have to be agreed on. The JAR is like a library (even
if these can sometimes be executable, which ELF DLLs also can
be), the WAR is more like a finished binary, with some JARs
embedded and others expected to be provided by the runtime
environment, but we produce source on the WAR level.

③ https://repo1.maven.org/maven2/org/evolvis/tartools/maven-parent/1.17/
  I can build a -source.tgz in these projects and upload that,
  but as I said, naming is not standardised.

Worse, the source code is on project level, not library level.
Look at the output of (on Debian)
	apt-cache showsrc libxcb | fgrep ' deb libs '
which counts 24 packages shipping a library currently; there
is but one source tree for all of them combined.

I’d argue that the -source.tgz should be built by the parent
project or global Makefile and shipped under the name of the
source package, not of those libraries built, but then we’d,
in addition to naming, need a discovery mechanism.

This also applies to ELF (and other) binaries:

$ dpkg -L coreutils | fgrep bin/ | wc -l
105

I doubt I’d want 105 copies of the same source, or of the
contents of coreutils-8.30/lib/, or even of the GPL.

I’d argue that, in the presence of a packaging system, the
complete corresponding source should be an artefact, named
like the source package, with its own dependencies… and in
Debian we could just make source packages installable and
able to be depended on (there’s an open issue about that
somewhere); that plus a mechanism to install them all would
suffice.

For the Java™ world, we have a (bad) packaging system, but
keeping source JARs around (they are used for the benefit
of the IDE, not to provide actual buildable sources, so they
have a different scope anyway) but add discoverable source
archives (could even be JAR, to not break the ecosystem) as
a new requirement. That, plus code (which I already have ☻)
to download them all and embed into the finished web contai‐
ners, or create a bundle otherwise… most Java™ projects are
comprised of more than just one WAR (multiple WARs or EARs,
a tarball with files needed to install it or documentation
perhaps) so I tend to create a “shipment” archive which
could just bundle all sources as well if it’s not needed
inside the webroot. (I used to have that but moved to web.)

And then there’s this project where I was lazy; all depen‐
dencies are Apache/BSD/similar, so all I *needed* to bundle
were the licence notices. The system-inherent problems plus
the ever-small budget indicated so. Sure, I could bundle the
dependencies’ sources, but nobody’s going to look at it as
that project is not web but executable fat JAR.

tl;dr: Mechanisms are there, many even, but agreement is
       lacking.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg