[
https://issues.apache.org/jira/browse/FREEMARKER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170435#comment-17170435
]
Dániel Dékány commented on FREEMARKER-153:
------------------------------------------
My understanding is lightly different, and I'm pretty certain the outcome would
be OK legally this way.
It's true that each individual jar-s deployed to Maven Central must have
{{LICENSE}} and {{NOTICE}} under {{META-INF}}. But those files are added to
{{META-INF}} by the {{org.apache:apache}} parent POM, as they are always the
same for all Apache projects, and so they are not part of our source code.
On source code level, we only have a single "package", which encloses all the
Maven modules. That's a single big unit, as we release all of that at once, in
a single source package, under a single version number. Therefore, the *source
code* of individual Maven modules needs no separate {{LICENSE}} and {{NOTICE}}
file. We only need them in the project root directory. And those only apply to
the source code, so we don't talk about the dependencies there, as they are not
included in the source code. (First I said we might get away with single
LICENSE in the root, that says that a binary release package might bundles this
and that, but since then, I have realized that's wrong.)
For binary release we need that complicated LICENSE and all. But that's not the
same as the license of the source code. In FreeMarker, we have a src/dist/bin
directory that contains the binary distribution license. It passed several
incubation releases like that (checked by some keen eyes from outside the
FreeMarker project), so I assume it's at least an acceptable solution.
> FreeMarker Generator release preparations
> ------------------------------------------
>
> Key: FREEMARKER-153
> URL: https://issues.apache.org/jira/browse/FREEMARKER-153
> Project: Apache Freemarker
> Issue Type: Task
> Reporter: Siegfried Goeschl
> Assignee: Siegfried Goeschl
> Priority: Major
>
> From [[email protected]]
> {noformat}
> I said I will help in the Apache release process, so only focusing on that,
> so some points:
> - We are required to have a so-called source release (every other
> artifact is optional in the policy). As we are using the org.apache:apache
> parent, that should generate that automatically, with .asc and sha512 and
> all. But currently it doesn't, because maven-release-plugin config/argument
> is overwritten with this: <arguments>-Dmaven.javadoc.skip=true</arguments>.
> We should keep configuring release at minimum, to avoid such accidents.
> Maybe as in
> https://github.com/apache/freemarker-docgen/blob/master/pom.xml#L70.
> - I assume we also want a binary release, for the CLI only, and
> freemarker-generator-cli-x.y.z-*app*.zip (note the "-app") will be our
> binary release artifact. Then:
> - It bundles some dependency binaries that are not under ASL2 license.
> Unfortunately, the licenses of those must be included in the
> distribution.
> See the LICENSE at
> https://github.com/apache/freemarker-docgen/blob/master/LICENSE. At
> the bottom, it lists the licenses, then it refers to the actual license
> files. As we will have many licenses, let's create a "licenses" directory
> for them. (In the future, the dependencies have to be checked
> for changes.
> Even version upgrades my pull in sneaky transient dependencies. Some
> licenses are not even allowed, so anything but ASL2, MIT,
> BSD-without-advertisement-clause, will need closer attention.)
> - I noticed that the documentation is not included in the binary
> distribution. But because of the extra legal burden including it would
> bring (we have fonts and icons under CC-SA and SIL OFL in the Docgen
> output), I actually prefer that to stay like that.
> - .sha512 file is not yet generated
> - freemarker-generator-cli/src/site: If you agree, instead of this I
> will create freemarker-generator*-site*/src/docgen, and convert the
> Markdown to XDocBook. For now this will be only the CLI documentation, and
> the JavaDoc, as the freemarker-generator-maven-plugin is not ready. One
> annoyance I realized is that we should have Docgen in Maven Central for the
> builds to work reliably in the future, which means that Docgen has to be
> officially released (it never was, it's an internal tool). That would be a
> minimalistic release, means, no announcement, no web site, just the bare
> minimum (i.e., source release, and deployment to Maven Central). I have
> some backlog there (Google keeps nagging me about mobile issues), but I
> hope I can fix that in the coming days, then go through the official
> release process (takes 1-2 weeks).
> - Some smaller things:
> -
> - Having a "release" profile is also hopefully unnecessary, because
> org.apache:apache takes care of signing.
> - We should also remove most plugin version management, as many of
> those versions are set in org.apache:apache.
> - freemarker-generator-cli/templates should be inside
> freemarker-generator-cli/src/main/templates, I guess.
> P.s.: Siegfired asked our opinions in another thread. I did my part, even
> too much (;, so, would be good if others participate in that as well.
> --
> Best regards,
> Daniel Dekany
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
