That's a good point. So then it can remain as is for now. We only have to remember this if it ever produce a release (because all we need is deploying the service, an no release is needed for that).
And then I guess then we don't have to include gradlew.jar in the LICENSE either. Wednesday, April 26, 2017, 2:24:25 PM, Taher Alkhateeb wrote: > We are facing the same issue in OFBiz. However! What I understood is that > you cannot include the binary in the release, but you can include it in > trunk/development branch which is where you need it mostly. > > On Apr 26, 2017 3:21 PM, "Daniel Dekany" <[email protected]> wrote: > >> As it turns out, we aren't supposed to commit gradlew.jar (or any >> binary except images and such): >> https://issues.apache.org/jira/browse/LEGAL-288 >> >> Furthermore, if it the tester has releases (it might won't have), we >> clearly aren't allowed to include that jar. >> >> So, we have to describe how to install Gradle manually instead. >> >> >> Thursday, April 6, 2017, 12:52:48 PM, Pradeep Murugesan wrote: >> >> > Hi Daniel, >> > >> > >> > Thanks for merging it. >> > >> > >> > I have opened another pull request(#4). which contains >> > >> > >> > 1. additional files with license headers >> > >> > 2. removed the "created by" signature from the source code >> > >> > >> > >> > Also I am not sure about the license information for gradle wrapper >> > binary located at >> > incubator-freemarker-online-tester/gradle/wrapper/gradle-wrapper.jar. >> > I have looked in another apache project >> > https://github.com/apache/aurora. They have not mentioned the wrapper >> jar in any files. >> > >> > >> > Kindly let me know if we need to add it. I also see no license >> > information associated with the binary, but the gradle source is >> > bearing the apache license >> > (https://github.com/gradle/gradle/blob/master/subprojects/wrapper/src/ >> integTest/groovy/org/gradle/integtests/AbstractWrapperIntegrationSpec >> .groovy). >> > >> > >> > As a next step, I would change the package names and the cdn for the >> javascript files. >> > >> > >> > Thank you. >> > >> > Pradeep. >> > >> > >> > >> > ________________________________ >> > From: Daniel Dekany <[email protected]> >> > Sent: Wednesday, April 5, 2017 10:52:59 PM >> > To: Pradeep Murugesan >> > Subject: Re: >> > https://github.com/apache/incubator-freemarker-online-tester/pull/3 >> > >> > Wednesday, April 5, 2017, 10:13:50 PM, Pradeep Murugesan wrote: >> > >> >> Hi Daniel, >> >> >> >> changed the license headers for all the files. There were few files >> >> which I thought the license header is not necessary as they are the >> >> external libraries used by the project. Have issued a pull request for >> these. >> > >> > Thanks, I will look into it promptly. >> > >> >> Files that doesn't have a license now >> >> >> >> DISCLAIMER >> >> gradlew >> >> gradlew.bat >> >> >> >> gradle/wrapper >> >> >> >> * gradle-wrapper.jar >> >> * gradle-wrapper.properties >> >> >> >> src/main/resources/assets/js >> >> >> >> * autosize.min.js >> >> * jquery.autosize.min.js >> >> * jquery.blockUI.js >> >> >> >> Kindly let me know if any of the above files need the license >> information. >> > >> > Yes, all files must have license information somewhere, except >> > DISCLAIMER, LICENSE and NOTICE. While it's preferable, the license >> > header is not mandatory (and for binary files we can't have it >> > anyway), except for non-binary files that are covered by the usual ASF >> > ASLv2 license. Regardless, the LICENSE file in the root should give an >> > overview of all the licenses used, and for the non-ASF licenses show >> > which files/directories are covered by that license. (Also, ASF >> > licensed binary files, if we have any, has to be mentioned explicitly, >> > because they can't have a header.) You can see these in action in the >> > FreeMarker distros (note that the source and binary distribution has >> > different LICENSE). >> > >> > As of the jquery files, we should not store those. We should use a >> > googleapis.com URL or wherever CDN people use nowadays to load JQuery. >> > Then they won't complicate the LICENSE anymore (and won't burden our >> > web server). >> > >> >> Will do the package renaming as part of the next pull request. It would >> be easier to track. >> > >> > Right. >> > >> >> >> >> >> >> Pradeep. >> > >> > -- >> > Thanks, >> > Daniel Dekany >> > >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
