river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE NOTICE build.xml
Date Fri, 12 Feb 2016 16:03:39 GMT
One other small issue - the 2.2.3 release currently being voted on doesn’t include the INRIA
license in its LICENSE file.

One could argue that we should cancel that vote and spin another release candidate.  However,
I’ll argue that we can leave the fix until the next release…

- The INRIA license itself is embedded into the source file for ‘AbstractDependencyVisitor’.
 Hence it is technically distributed with the source distribution (as opposed to the normal
source files that simply reference the Apache License contained in LICENSE)
- http://www.apache.org/legal/resolved.html says “...Apache releases should contain a copy
of each license, usually contained in the LICENSE document….”.  Not ‘should’ and not
‘must’.
- The likelihood of any issue arising from our use of an example file for its intended purpose
seems pretty remote.

Cheers,

Greg Trasuk

> On Feb 12, 2016, at 10:51 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
> 
> It’s a little bigger job than I want to take on just now, so I went ahead and put the
INRIA license back into the LICENSE file.  
> 
> Longer term, there are a few options
> 1 - Leave it as-is, with the INRIA license in our LICENSE file.  This ends up encumbering
downstream users (like Rio, Harvester, StartNow, BlazeGraph, etc) with the requirement to
include the INRIA license, even if they’re not actually using ‘classdep’.
> 2 - Re-implement ‘classdep’ such that the one source file doesn’t need the INRIA
license
> 3 - Move the build tools out to a separate project deliverable, which could include the
INRIA license, but then wouldn’t encumber downstream users of the JTSK deliverables.
> 
> Since we’ve already talked about (and decided) to strip out the build tools and service
starter packages into separate deliverables, that’s probably the idea we should stick with.
 One more thing for the next release.
> 
> Cheers,
> 
> Greg Trasuk
>> On Feb 11, 2016, at 5:37 PM, Peter <jini@zeus.net.au> wrote:
>> 
>> I think so, I've no objection to someone reimplementing it.
>> 
>> Sent from my Samsung device.
>> 
>>  Include original message
>> ---- Original message ----
>> From: Greg Trasuk <trasukg@stratuscom.com>
>> Sent: 12/02/2016 07:53:31 am
>> To: dev@river.apache.org
>> Subject: Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE NOTICE build.xml
>> 
>> Is there anything other than org.apache.river.tool.classdepend.AbstractDependencyVisitor?
 I don’t like the idea of the River code being encumbered with INRIA’s license, so I wonder
if we could simply re-implement that class. 
>> 
>> Cheers, 
>> 
>> Greg Trasuk 
>> 
>>> On Feb 11, 2016, at 4:20 PM, Peter <jini@zeus.netau> wrote: 
>>> 
>>> Yes thanks for fixing dep-libs. 
>>> 
>>> You may have misunderstood; River contains sources that are copyright  of INRIA,
which are not AL2 licensed. 
>>> 
>>> Regards, 
>>> 
>>> Peter. 
>>> 
>>> Sent from my Samsung device. 
>>> 
>>>   Include original message 
>>> ---- Original message ---- 
>>> From: Greg Trasuk <trasukg@stratuscom.com> 
>>> Sent: 12/02/2016 05:36:04 am 
>>> To: dev@riverapache.org 
>>> Subject: Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE NOTICE buildxml

>>> 
>>> 
>>> One more data point -   
>>> 
>>> - Many Apache projects do not ship binaries.  Check out httpd.apache.org and
subversion.apache.org.  Both say they do not officially endorse any binaries (although they
do point to committer-created binaries)  
>>> 
>>> Cheers,  
>>> 
>>> Greg Trasuk  
>>> 
>>>>  On Feb 11, 2016, at 2:31 PM, Greg Trasuk <trasukg@stratuscom.com>
wrote:  
>>>> 
>>>> 
>>>>  A little while ago I asked a question - “Does it make sense to release
a binary package”?    
>>>> 
>>>>  I don’t think we need to.  Here are a few reasons:  
>>>> 
>>>>  - Apache’s products are source distributions.  Officially, if we build
a binary package, it’s a “convenience binary”, and not a released product.  i.e. Apache
doesn’t really recognize a binary package, but will insist that if we distribute a binary,
the LICENSE and NOTICE files need to correctly reflect the other libraries that are included
in that binary.  
>>>>  - The build.xml has been modified so it uses Ivy to download the build-time
dependencies when you go to build.  That saves us from having to manage a “build-deps”
library and distribute it separately.  This means that _we_ are not distributing those dependencies,
so we don’t have to reference them in the NOTICE and LICENSE files.  Which is good, because
it doesn’t impose any requirements on downstream users of River who don’t use ‘asm’.
  
>>>>      (I asked about this on the list - you asked me to go ahead and fix the
issue with distributing jars in the source package).  
>>>> 
>>>>  -  ‘classdep’ is built as part of the build process.  Prior to that,
‘build.xml’ calls ‘Ivy’ to download ‘asm’.  We don’t distribute ‘classdep’
through Maven Central.  We don’t even recommend using it, why would we distribute it?  
>>>>  - As I explained before, the JTSK binary on its own doesn’t do anything.
 You can’t run “reggie” out of it, for example (this is one reason people find it so
confusing to startup using Jini).  All you can do with the JTSK distribution is run the tests.
 If you run the integration tests, it starts by recompiling, hence there’s no need for a
binary to run the integration tests.    
>>>>  - We _do_ ship the generated jar files as artifacts in Maven Central, which
is realistically how developers will be using the jar files. For example, you can build the
examples project without downloading or building the main River distribution  Harvester gets
its jars from Maven Central.  I’m pretty sure that Rio does too (not sure if Rio uses Maven
or Gradle for its build, but either one uses Maven Central as the artifact repo).  The pom
files include the transitive dependency references.  
>>>> 
>>>>  I left my question as “how about if I comment out the bits that make the
binary release, and if anyone wants it badly enough they can do the work to build the binary
properly”.  That’s what I did.  There’s a note next to the commented-out part telling
what work needs to be done.  As it stands now, the ‘release’ target does not generate
a binary release artifact, just the source and doc artifacts.  As I’ve explained above,
that makes sense as far as I can tell..  
>>>> 
>>>>  On a practical level, if you desperately want the binary release, somebody
who is not me has to do the work to generate it properly and then manage the ‘3.0’ release.
 If we’re good to go without the binary artifact, I’ll be happy to spin the ‘3.0’
release as soon as the vote on ‘2.2.3’ is finished.  
>>>> 
>>>>  Cheers,  
>>>> 
>>>>  Greg Trasuk  
>>>> 
>>>>>  On Feb 11, 2016, at 1:35 PM, Peter <jini@zeus.net.au> wrote: 

>>>>> 
>>>>> 
>>>>>  Greg,  
>>>>> 
>>>>>  Please revert this.  
>>>>> 
>>>>>  ASM licensed code exists in classdepend, which classdep uses, in the
tools package.  
>>>>> 
>>>>>  As far as I'm aware were still releasing a binary for River 3, but you've
found an issue with how we currently do that?  
>>>>> 
>>>>>  Regards,  
>>>>> 
>>>>>  Peter.  
>>>>> 
>>>>>  Sent from my Samsung device.  
>>>>> 
>>>>>   Include original message  
>>>>>  ---- Original message ----  
>>>>>  From: Greg Trasuk <trasukg@stratuscom.com>  
>>>>>  Sent: 11/02/2016 02:57:35 am  
>>>>>  To: dev@river.apache.org  
>>>>>  Subject: Re: svn commit: r1729654 - in /river/jtsk/trunk: LICENSE NOTICE
build.xml  
>>>>> 
>>>>> 
>>>>>  Just note - this change is on the trunk branch - anyone know if it’s
possible to change the commit message retroactively?   
>>>>> 
>>>>>  Cheers,   
>>>>> 
>>>>>  Greg   
>>>>> 
>>>>>>  On Feb 10, 2016, at 11:55 AM, gtrasuk@apache.org wrote:   
>>>>>> 
>>>>>>  Author: gtrasuk   
>>>>>>  Date: Wed Feb 10 16:55:24 2016   
>>>>>>  New Revision: 1729654   
>>>>>> 
>>>>>>  URL: http://svn.apache.org/viewvc?rev=1729654&view=rev   
>>>>>>  Log:   
>>>>>>  The generated release artifacts for the 2.2 branch are now only
the source and documentation artifacts, and do not include the release tooling like 'roll_release.sh'.
 Those files are only used by the release manager, so shouldn't be in the source distribution
   
>>>>>> 
>>>>>>  The LICENSE and NOTICE files also are no longer duplicated to 'LICENSE.TXT'
and 'NOTICE.txt', as per Apache release recommendations.     
>>>>>> 
>>>>>>  LICENSE and NOTICE files have been modified to reflect the fact
that 'asm' and 'animal-sniffer' are no longer distributed with the source, but are downloaded
at build time.   
>>>>>> 
>>>>>>  Modified:   
>>>>>>     river/jtsk/trunk/LICENSE   
>>>>>>     river/jtsk/trunk/NOTICE   
>>>>>>     river/jtsk/trunk/build.xml   
>>>>>> 
>>>>>>  Modified: river/jtsk/trunk/LICENSE   
>>>>>>  URL: http://svn.apache.org/viewvc/river/jtsk/trunk/LICENSE?rev=1729654&r1=1729653&r2=1729654&view=diff
  
>>>>>>  ==============================================================================
  
>>>>>>  --- river/jtsk/trunk/LICENSE (original)   
>>>>>>  +++ river/jtsk/trunk/LICENSE Wed Feb 10 16:55:24 2016   
>>>>>>  @@ -199,39 +199,3 @@   
>>>>>>     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied.   
>>>>>>     See the License for the specific language governing permissions
and   
>>>>>>     limitations under the License.   
>>>>>>  -   
>>>>>>  -   
>>>>>>  -APACHE RIVER SUBCOMPONENTS:   
>>>>>>  -   
>>>>>>  -Apache River includes some external software components. Your use
of these   
>>>>>>  -components is subject to the terms and conditions of the following
licenses:   
>>>>>>  -   
>>>>>>  -ASM libraries (tools/asm-5.0.1.jar and tools/asm-commons-5.0.1.jar)
  
>>>>>>  -   
>>>>>>  -   ASM: a very small and fast Java bytecode manipulation framework
  
>>>>>>  -   Copyright (c) 2000-20011 INRIA, France Telecom   
>>>>>>  -   All rights reserved.   
>>>>>>  -   
>>>>>>  -   Redistribution and use in source and binary forms, with or without
  
>>>>>>  -   modification, are permitted provided that the following conditions
  
>>>>>>  -   are met:   
>>>>>>  -   1. Redistributions of source code must retain the above copyright
  
>>>>>>  -      notice, this list of conditions and the following disclaimer.
  
>>>>>>  -   2. Redistributions in binary form must reproduce the above copyright
  
>>>>>>  -      notice, this list of conditions and the following disclaimer
in the   
>>>>>>  -      documentation and/or other materials provided with the distribution.
  
>>>>>>  -   3. Neither the name of the copyright holders nor the names of
its   
>>>>>>  -      contributors may be used to endorse or promote products derived
from   
>>>>>>  -      this software without specific prior written permission.
  
>>>>>>  -   
>>>>>>  -   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS"   
>>>>>>  -   AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE   
>>>>>>  -   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE   
>>>>>>  -   ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
BE   
>>>>>>  -   LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR   
>>>>>>  -   CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF   
>>>>>>  -   SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS   
>>>>>>  -   INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN   
>>>>>>  -   CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE)   
>>>>>>  -   ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF   
>>>>>>  -   THE POSSIBILITY OF SUCH DAMAGE.   
>>>>>> 
>>>>>>  Modified: river/jtsk/trunk/NOTICE   
>>>>>>  URL: http://svn.apache.org/viewvc/river/jtsk/trunk/NOTICE?rev=1729654&r1=1729653&r2=1729654&view=diff
  
>>>>>>  ==============================================================================
  
>>>>>>  --- river/jtsk/trunk/NOTICE (original)   
>>>>>>  +++ river/jtsk/trunk/NOTICE Wed Feb 10 16:55:24 2016   
>>>>>>  @@ -23,11 +23,3 @@ The original two releases of the Service   
>>>>>>  and code, are available from:   
>>>>>> 
>>>>>>      http://www.artima.com/jini/serviceui/index.html   
>>>>>>  -   
>>>>>>  -Copyright (c) 2000-2005 INRIA, France Telecom   
>>>>>>  -This product includes the ASM library (http://asm.ow2.org/)   
>>>>>>  -   
>>>>>>  -This product includes the animal-sniffer library from codehaus.org.
  
>>>>>>  -The original software is available from http://mojo.codehaus.org/animal-sniffer/
  
>>>>>>  -Licensed under the MIT license.   
>>>>>>  -   
>>>>>> 
>>>>>>  Modified: river/jtsk/trunk/build.xml   
>>>>>>  URL: http://svn.apache.org/viewvc/river/jtsk/trunk/build.xml?rev=1729654&r1=1729653&r2=1729654&view=diff
  
>>>>>>  ==============================================================================
  
>>>>>>  --- river/jtsk/trunk/build.xml (original)   
>>>>>>  +++ river/jtsk/trunk/build.xml Wed Feb 10 16:55:24 2016   
>>>>>>  @@ -87,7 +87,7 @@   
>>>>>>      </target>   
>>>>>> 
>>>>>>      <target name="release" description="Create source and binary
release packages"   
>>>>>>  -        depends="clean, all.build, release-src, release-bin, release-doc">
  
>>>>>>  +        depends="clean, all.build, release-src, release-doc">
  
>>>>>>      </target>   
>>>>>> 
>>>>>>      <fileset id="river.bin.files" dir="${basedir}">   
>>>>>>  @@ -117,7 +117,13 @@   
>>>>>>          <include name="README*"/>   
>>>>>>      </fileset>-->   
>>>>>> 
>>>>>>  -    <target name="release-bin" description="Create a binary
release" depends="all.build">   
>>>>>>  +    <!-- This target is unused - the distribution doesn't have
functionality on its   
>>>>>>  +    own, so there's no point in having a binary distribution. 
If someone wants to   
>>>>>>  +    reactivate the binary distribution, they will also need to
create the appropriate    
>>>>>>  +    license and notice files that cover the binaries (no other
products are    
>>>>>>  +    distributed with the source distribution).   
>>>>>>  +    -->   
>>>>>>  +    <target name="unused-release-bin" description="Create a
binary release" depends="all.build">   
>>>>>>          <!-- TODO: add depends: javadoc-internals and remove
from ci-build -->   
>>>>>> 
>>>>>>          <mkdir dir="${dist.dir}"/>   
>>>>>>  @@ -149,6 +155,8 @@   
>>>>>>          <exclude name="nbproject/**"/>   
>>>>>>          <exclude name="build.properties"/>   
>>>>>>          <exclude name="tar_release_test/**"/>   
>>>>>>  +        <exclude name="roll_release.sh"/>   
>>>>>>  +        <exclude name="release.xml"/>   
>>>>>>          <!--   
>>>>>>          TODO: why were these excluded from the source archive? 
 
>>>>>>          <exclude name="${doc}/release-notes/new.html"/>  



Mime
View raw message