Re: Step towards being able to build on Linux (Pull request #435)

On Wednesday 20 of January 2016 18:18:16 Vladimir Sitnikov wrote:
> >I'm asking you - as Java hacker - how this is
> >_normally_ done.
>
> Maven profile. See [1].

Thanks.

> >That is unlucky .. who should I ask?  At least adding new dependency is
> >big issue every committer should take into account.  I'm not sure about
> >licensing too -- and thats why we can't provide jdbc with osgi support.
>
> Frankly speaking, I've no idea how that is usually managed.
> It looks like pgjdbc does not force to sign CLAs when accepting patches.
>
> I'm not sure why you pay so much attention to osgi while completely
> ignore the fact that pgjdbc includes lots of contributions (from
> random people) itself.

Contributing to project with "PostgreSQL" license is clear;  using it is
clear either.  As a user, I can trust you (== software provider) that the
code you provide is really "PostgreSQL" licensed -- on distribution
level we must properly check/review that this is truth, but that is fine.

(hard) dependency on randomly licenced project OTOH can make otherwise
perfectly well licenced open source project unusable for me as open-source
user.  What would be worse:  Two dependencies on two proprietary licenses
might make the project (legally) unusable.  At least as far as I
understand.

That is why the licensing is important from user's perspective, and why SW
providers should be aware of that POV.

> The osgi jars in question are licensed under Apache 2.0.
> jcp is Apache 2.0 as well.

IANAL, but Apache 2.0 is fine license if we *have* the right source code
(which is not guaranteed by Apache 2.0 itself, neither osgi, afaik), but
again - IANAL.  Do we have source?

But to other point -- if I understand it right, only some kind of API for
"jar-file" propagation in osgi-capable system is used.
Is this too candidate for opt-out in maven profile?  That would simplify
things.

> >Yes, we do manual reviews.  By "software binary blob" I meant code
> >(which can be executed) which may, e.g., infect my machine.
>
> I do not want to stretch that, but I wonder if you call "sql statement
> inside a java code" a "software binary blob" "which can be executed in
> backend" and "infect the machine via integer overflow or whatever".

It is source code;  thus (if not obfuscated) nobody is blocked from
looking at the code and decide whether that "is"/"is not" malicious
software.  Or whether it has compatible license.  Pre-compiled software is
not human readable usually, similarly obfuscated code -- so that I meant
by "binary".

> I mean: what if I convert osgi.jar into a java file into a form of some
> select statements? Would it heal your case?

That sounds like obfuscation.

If you converted the osgi.jar file into properly licensed SQL source code,
that it would be probably fine :).

> > Pavel sent you an approach.  Except the testsuite issue?
>
> Yes. Without a testcase I cannot understand what that commit is trying
> to accomplish.

We try to move one dependency from 'hard' => 'optional', because that is
hard-to-get-into-linux (the right way).  But sounds fair, as I understand
it right -- in Travis is something like Ubuntu environment, right?  There
should be easy to remove '*.jar' (which is redundant anyway) file to make
such test.

Thanks Vladimir for the answer,
Pavel