Re: Complicated re-distribution of pgjdbc the "open source way" - Mailing list pgsql-jdbc

From Pavel Raiskup
Subject Re: Complicated re-distribution of pgjdbc the "open source way"
Date
Msg-id 7863565.PlBjy2zgnd@nb.usersys.redhat.com
Whole thread Raw
In response to Re: Complicated re-distribution of pgjdbc the "open source way"  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Responses Re: Complicated re-distribution of pgjdbc the "open source way"  (Dave Cramer <pg@fastcrypt.com>)
Re: Complicated re-distribution of pgjdbc the "open sourceway"  (Árpád Magosányi <mag@magwas.rulez.org>)
List pgsql-jdbc
On Monday 07 of March 2016 18:31:41 Vladimir Sitnikov wrote:
> Pavel>what is more important we could do the job _consistently_
> Pavel>with a lot _less_ packagers effort.
>
> I think "testing" is the key answer here to get consistent results.

I am talking about the downstream patching effort -- that should be done
consistently in all distributions.

> Pavel>* the build would be 1-step process
> Pavel> Any thoughts?
>
> This all reminds me the 14 competing standards (see [1])
> Do you mean "1-step" as in "1-cpu-instruction"?
> Is "./build.sh" a "1-step"?

By one step I mean something like './build.sh' in terms of package
building.  That is -- no need to build parent-poms (one-file) package
before (or build stub package first, add this to repository and then build
again the full package).

> Pavel> even patches from us to support pure open source build are not wanted
>
> I'm afraid this ^^ is misleading.
>
> Patches are welcome provided they include tests to cover the change.
> No tests -> no acceptance. It is in line with typical development
> model, isn't it?

This is *your* easy excuse to not incorporate change ;).  100% coverage is
a sci-fi, as anybody must agree.  What am I going to test on Fedora if I
patch osgi out?  Am I going to test that it does not work?  If yes, I'm
fine to write the patch.

You refused attempts to post patches which would make some code optional,
at which point it is not useful to think about testing something.

Other than that, not everything is easily testable in your actual CI.

> Pavel>_Open_ distribution¹
> Pavel> By FOSS source I mean software which
> Pavel>  _anybody_ can read, study, copy, modify, distribute
>
> Can you tell us if org.osgi.enterprise complies with your definition
> of "open distribution"?

The license refuses you to modify the code, it is *clear vendor lock-in*
and:

  """
  anybody who cares a bit about open source principles should at least
  be aware of its consequences
  """

Also, your build system should allow us to build without this support.
That is how everything else works.  Can we submit patches for this?

> Just in case you say "no", see [2] (download jar and note that sources
> are in OSGI-OPT folder) for complete source code that is available
> under Apache 2.0 license -> you can read, copy, modify and distribute
> it with no problem.

But as far as I understand, those jars are not original sources -- those
are products of some build (which automatically adds some license file
there? or what is automatized?  Is it easily re-build-able?).

You are allowed to download original sources, but you can't modify them.
I stopped the observation here as that is simply not acceptable -- this
has been discussed in mentioned threads, direct reference is [1]
(reference by Vitalii).

> Taking that into account, why do you think "org.osgi.enterprise" is
> not "open distribution"?
>
> 1: thttps://xkcd.com/927/
> 2: http://mvnrepository.com/artifact/org.osgi/org.osgi.enterprise/5.0.0

:) no, this is different.  If you produce API that needs to be protected
by license, it is either wrong design, or you have bad intentions.

[1] https://lists.fedoraproject.org/pipermail/legal/2012-July/001930.html

Pavel



pgsql-jdbc by date:

Previous
From: Árpád Magosányi
Date:
Subject: Re: Complicated re-distribution of pgjdbc the "open source way"
Next
From: Pavel Raiskup
Date:
Subject: Re: Complicated re-distribution of pgjdbc the "open source way"