On Fri, 2009-03-27 at 11:24 +0000, MJ Ray wrote: > Chow Loong Jin <hyperair@gmail.com> wrote: [...] > > For the Python part, the sources are completely distributed, and no > > binaries are in the tarball. However, for the Java part, only the .jar > > is distributed in the tarball. I have contacted the upstream developer > > about this issue, and he will be releasing another tarball with the > > sources for the Java portion. > > I think this is a problem at the moment: DFSG 2 requires source code. That's fine, upstream will provide the source code in the next release, in addition to the bundled binary .jar > > > The problem begins here: The Java portion has a build-dependency on Sun > > Microsystem's WTK[1], and it is not free[2]. However, this is just a > > build dependency, and not a runtime dependency. In fact, the .jar isn't > > even supposed to run on the target machine, it's supposed to be uploaded > > to the mobile device. > > So this would be a practical problem, Fails To Build From Source, but > only for the mobile device component? I think the Java portion would > need to be in contrib at least due to the non-free build-dependency, > and probably non-free because presumably some bit of WTK ends up in > the jar file, but that may depend on the precise terms and I got a > "General Error" page when trying to view > [2] https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewLicense-Start It wouldn't really FTBFS, if the mobile component isn't built, but instead shipped verbatim as a data file. > > Hence, my question: Is it okay (within DFSG) for upstream to distribute > > the said .jar file, together with the sources for this .jar file, and > > for this said .jar file to be copied straight into a .deb and > > distributed as-is? > > I feel that it isn't, because it fails DFSG 2 at the moment and maybe > others once the WTK-dependent sources are available. There are > several bits in http://ftp-master.debian.org/REJECT-FAQ.html > which look like they'd apply, like "Source missing" and "Non-Main". "Source missing" would apply if the source is really missing, but this is a case of source + binary, but the binary is not rebuilt, and instead distributed as is. "Non-main" would apply if the .jar needs to be rebuilt from the provided sources instead of just distributed as is. > > I suspect it's probably not certain until we have some general > resolution to the wider firmware question, though. > http://www.debian.org/vote/2008/vote_003#texte > is a bit kernel-case-specific to be reliable here. But that's about sourceless firmware. This is a binary _with_ sources. To summarize: Upstream will ship sources for the .jar as well as the .jar itself, but the .jar cannot be built from the sources without WTK, which is non-free, and cannot be distributed by Debian. So, I'd like to distribute the .jar as-is, without removing it from the upstream tarball, or rebuilding this .jar before distributing it. Is this permitted? Also, as mentioned in debian-mentors, there is one such binary (not .jar, but .sis) which is distributed within the "gammu" package which is in main. Considering gammu's currently sitting in main, surely shipping the .jar similarly in remuco (the package I'm working on) wouldn't be a problem? -- Chow Loong Jin
Attachment:
signature.asc
Description: This is a digitally signed message part