Note also that this issue is not yet resolved. So I would wait a decision 
before taking action, that's the decision we took in OFBiz PMC.

Even if there are high probabilities that it will not eventually be allowed (time are changing), AFAIK there are currently no bylaws preventing to release jars in a product.

Jacques


Le 26/04/2017 à 14:43, Daniel Dekany a écrit :
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



Reply via email to