DFSG NEW review for osgi-compendium7 version 7.0.0-3

Summary

• Licensing is DFSG-compliant and debian/copyright is accurate: Yes
• Packaging is of good quality: Yes
• Issues: 0 blocker, 1 important, 1 minor
• debian/watch: version 5
• debian/copyright: machine-readable, without the current Format URL
• Scan before the review: nothing found

Licensing

The tree is 485 OSGi Alliance .java files plus a stub META-INF/MANIFEST.MF; every file carries the standard Apache-2.0 header (verified by grep: all 485 files match 'Licensed under the Apache License, Version 2.0', and zero non-OSGi copyright lines exist). No non-free terms, no built/ minified/binary files (the tree is pure Java sources), no embedded third-party code, no fonts/images/data of unclear provenance, and no licence-less file. debian/copyright is DEP-5 (exact copyright-format 1.0 URL), with Files: * and Files: debian/* stanzas and a stand-alone Apache-2.0 paragraph pointing at /usr/share/common-licenses/Apache-2.0. The only inaccuracy is that Files: * states the years as 2012-2013 while the file headers span 2000-2018 - holders and licence are correct, so this is minor.

Packaging

Solid Java-team packaging: dh with javahelper and maven_repo_helper at compat 13, headless JDK, --release 8, salsa Vcs-, Standards-Version 4.7.4 (current Policy 4.7.4.1). All Build/run dependencies exist in the archive and the binary runtime deps correctly limit to osgi-core/osgi-annotation, leaving servlet/JPA/JAX-RS/J2ME as provided APIs (imports of javax. appear only in the spec API classes, same model as the old osgi-compendium). The 01-backward-compatibility patch has proper DEP-3 headers with Forwarded: not-needed. The execute_after_mh_install removal of the maven-repo 7.0.0 version directory matches the -3 changelog intent ('org.osgi:osgi.cmpn:7.x only') and is consistent with the actual maven-repo-helper layout (version dir plus mapped 7.x dir, as seen under /usr/share/maven-repo). Changelog is coherent. Absence of autopkgtests/javadoc is not a fault.

Issues

1. [important] [licensing] debian/copyright does not declare the current copyright-format 1.0 URL

• Files: debian/copyright:1
• Basis: found by the review tooling's own checks
• Evidence: Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0
• Problem: The first field must be exactly Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ (copyright-format 1.0, "Format" field). Anything else, including the http:// form and the URLs of the drafts that preceded 1.0, does not declare the file to be in the current format, and a file written to a draft may also use field names and licence short names that 1.0 changed.
• Fix: Replace the line as shown under Proposed changes, then check the rest of the file against copyright-format 1.0 (for example Upstream-Name, Upstream-Contact and Source in the header, not Name or Maintainer).

2. [minor] [licensing] Files: * copyright years understated (2012-2013 vs actual 2000-2018)

• Files: debian/copyright:8
• Basis: checked, in the package or with a reference tool
• Evidence: Files: * stanza says Copyright: 2012-2013, OSGi Alliance, but file headers span earlier and later years, e.g. org/osgi/service/log/LogEntry.java Copyright (c) OSGi Alliance (2000, 2017) and org/osgi/util/xml/XMLParserActivator.java (2002, 2017); the newest files reach 2018.
• Problem: The Copyright field of the catch-all stanza misdescribes the copyright of every upstream file: holders and licence are correct (OSGi Alliance, Apache-2.0), but the year range omits all work before 2012 and after 2013.
• Fix: Broaden the range, e.g. Copyright: 2000-2018, OSGi Alliance (or list the actual spans).

Verified

• All 485 upstream .java files were found by grep to carry the Apache-2.0 header text, and a grep for Copyright (c) (?!OSGi) matched nothing - OSGi Alliance is the only holder; coverage is exact (prescan scanned 487 files including the two .pc copies; every holder was named in debian/copyright).
• Tree contains only Java sources plus META-INF/MANIFEST.MF (stub, Manifest-Version: 1.0); globs for non-.java files under org/ and for LICENSE/COPYING/NOTICE found only the former empty - no built, minified or binary files, so no DFSG form-modification concern.
• The prescan's licence scan reported no non-free wording (no non-commercial/no-modification/CC-NC/ND terms) and no disallowed licence.
• debian/copyright is machine-readable with the exact copyright-format 1.0 URL; Files: debian/* covers subdirectories because * matches slashes (copyright-format 6.9).
• All Build-Depends exist in the archive (checked: libosgi-core-java 8.0.0-2, libosgi-annotation-java 8.1.0-1, libosgi-foundation-ee-java, libjaxrs-api-java 2.1.2-2, libgeronimo-jpa-2.0-spec-java).
• Binary runtime Depends (libosgi-annotation-java, libosgi-core-java only) are intentional: javax.servlet/javax.ws.rs/javax.persistence/javax.microedition imports occur only in the spec API classes (23 javax-importing files) and are provided at runtime by consumers - the same model the old osgi-compendium adopted when it dropped those as provided deps (changelog 5.0.0-4).
• execute_after_mh_install removes only the maven-repo org/osgi/osgi.cmpn/7.0.0 dir, keeping the 7.x mapped-version dir; confirmed against the addon (maven_repo_helper inserts mh_install after dh_install) and the real layout under /usr/share/maven-repo (e.g. junit has both 4.13.2/ and 4.x/), matching the -3 entry 'Install the Maven artifact as org.osgi:osgi.cmpn:7.x only'.
• 01-backward-compatibility.patch has DEP-3 Description/Author/Forwarded: not-needed; as a Debian-specific source-compat change (new abstract methods turned into throwing default methods), not forwarding is appropriate.
• Standards-Version 4.7.4 satisfies the current Policy 4.7.4.1 (first two components match).
• Changelog is well-formed with proper bug closures; recent entries to unstable are dated consistently.
• uscan found the packaged version as the newest upstream release (upstream 7.0.0, packaged 7.0.0).
• Every pointer of debian/copyright to /usr/share/common-licenses names a file that is there (Apache-2.0).

Not confirmed

• Could not verify the --javacopts option of jh_build (no jh_build(1) or javahelper docs installed on the reviewing system); --release 8 is valid javac syntax and the package has shipped with this rules file, so no build failure is inferred from it.