As far as Firefox on Android is concerned (and assuming I'm not misinformed),
we don't ship stuff from third-party jars.
Sync's third-party dependencies, for example, are in our tree as source. We do
build a "sync-thirdparty.jar" as an intermediate build step, but it's built
from source:
jars/sync-thirdparty.jar: $(addprefix $(srcdir)/,$(SYNC_THIRDPARTY_JAVA_FILES))
jars
@echo "JAR sync-thirdparty.jar"
$(NSINSTALL) -D classes/sync-thirdparty
$(JAVAC) $(JAVAC_FLAGS) -d classes/sync-thirdparty $(addprefix
$(srcdir)/,$(SYNC_THIRDPARTY_JAVA_FILES))
$(JAR) cMf jars/sync-thirdparty.jar -C classes/sync-thirdparty .
sutagent apparently bundles commons-net and jmdns from jars, and we bundle a
Robotium jar for test running, but neither of those are "shipping" things.
That doesn't completely answer your questions, but it does make me feel that
this is less of a concern than if we were dumping something from maven-central
into Firefox.
mfinkle or Brad might have more insight on why things are the way they are;
chaps?
-R
On 30 Sep 2013, at 5:40 PM, Mike Hommey <[email protected]> wrote:
> Hi,
>
> It has just come to my attention that we're using some third party java
> libraries. At the very least, jmdns, commons-net, and robotium. There
> are two things that I'm concerned with.
>
> While their license (Apache License 2.0) allow binary redistribution
> without the corresponding source (although there is a source jar for
> commons-net), shouldn't Mozilla redistribute the sources as well?
>
> Independently of this kind of ethical problem, how do we ensure those
> pre-built java classes actually match the source they're supposed to be
> built from? Shouldn't we actually build them instead?
>
> I'm not sure this is the right list to discuss these, as, while it's
> an issue specific to mobile firefox, it's also a problem of policy.
>
> Mike
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
