On 2012-04-20 15:58:21 (+0200), Ludwig Nussel
Angelos Tzotsos wrote:
On 04/20/2012 01:58 PM, Ludwig Nussel wrote:
[...] - how likely is it that we are going to patch an upstream java library or application ourselves, rather than updating it to an upstream release that fixes the issue ? * very few in this project are fluent with java * is it an issue to push a newer version to fix rather than backporting changes/patches for those packages ? Well, just recently we had the case where a fix was only a few lines but the package couldn't be rebuilt from java source and upstream only offered a major version update. That sucks. It's embarrassing if a package is flagged as free software but you can't actually fix it. If at all exceptions should be granted only on a case by case basis after thorough review. Also such packages should not be put in
Pascal Bleser wrote: the oss tree.
How about if we create a new tree for those Java applications? I think we should not use NonFree since this would confuse users, that they use non free software.
There is no usable source, you can't fix bugs in the code yourself
Of course there is usable source. You can build it with Ant, Maven, Gradle, or quite often even with just a one line javac invocation. There are different approaches on handling and facilitating this. The essential problems are: 1) to bootstrap the build environments, i.e. get Maven built (and patched in order to lookup jars in /usr/share/java/blah too) 2) package the many hundreds of often used libraries and frameworks and such (oh yes, surprise surprise, java is very widely used (that's even an understatement), and there are huge amounts of open source pieces of software in java) I made a proposal a while ago to have a "lesser evil" mechanism to have packages from binary distributions at least as a short or mid term solution until we have a chance of catching up with those dependencies. It would also be a very sorry initiative if we did that on our own. Oh there is jpackage but, I don't know, seems a bit dormant.
and you probably don't even know what license that random dump of bundled jars has.
That is indeed quite a task but from more than 10 years of day to day experience of coding with java (and lots of open source java libraries and bits), I can say that the set is large (as said, there is a huge amount of open source software in java, and a high degree of reuse of libraries), but it's not totally random. What I mean to say, I guess, is that you keep running into mostly the same jars. I'll grant you definitely one thing here: unfortunately, the idea of Maven style repositories (which are by now a de-facto standard and used by almost all dependency management tools, obviously Maven itself, but also Gradle or Ivy) is quite good and sound, and also includes metadata about the component and its dependencies (obviously) is a missed opportunity in terms of license information: most POM files (which are component descriptors with all sorts of metadata, in XML format) lack licensing information. Then again, it wouldn't really be reliable either. The same accounts for non-java stuff too though, you can run into libraries written in C that say "GPL" on freshmeat (or freshcode, as it's called now) but effectively has different copyrights in individual source code files in its archive.
Calling it non-free is the closest match.
Sorry, are you saying the Apache Software License or the GPL/LGPL is not considered "oss" any more? Surely you're not. cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf