年7月5日周五 07:06写道：
>>
>> Hi,
>>
>> I would ask legal-disc...@apache.org, but it would not be allowed unless it
>> is an optional dependency. However, it depends on the exact details.
>>
>> Kind Regards,
>> Justin
>>
>>> On 5 Jul 2024
t;
> > > > Hi,
> > > >
> > > > I would ask legal-disc...@apache.org, but it would not be allowed
> > > unless it is an optional dependency. However, it depends on the exact
> > > details.
> > > >
> > > > Kind Regards,
> >
it depends on the exact
> > details.
> > >
> > > Kind Regards,
> > > Justin
> > >
> > > > On 5 Jul 2024, at 6:45 pm, Michele Sciabarra <
> > openserverl...@nuvolaris.io> wrote:
> > > >
> > > > If this is not
tional dependency. However, it depends on the exact
> details.
> >
> > Kind Regards,
> > Justin
> >
> > > On 5 Jul 2024, at 6:45 pm, Michele Sciabarra <
> openserverl...@nuvolaris.io> wrote:
> > >
> > > If this is not the right place to
ds on the exact details.
>
> Kind Regards,
> Justin
>
> > On 5 Jul 2024, at 6:45 pm, Michele Sciabarra
> > wrote:
> >
> > If this is not the right place to ask this question please ignore it and
> > let me know where I should ask.
> >
>
nal dependency. However, it depends on the exact details.
>
> Kind Regards,
> Justin
>
> > On 5 Jul 2024, at 6:45 pm, Michele Sciabarra
> > wrote:
> >
> > If this is not the right place to ask this question please ignore it and
> > let me know where I shou
Hi,
I would ask legal-disc...@apache.org, but it would not be allowed unless it is
an optional dependency. However, it depends on the exact details.
Kind Regards,
Justin
> On 5 Jul 2024, at 6:45 pm, Michele Sciabarra
> wrote:
>
> If this is not the right place to ask this que
If this is not the right place to ask this question please ignore it and
let me know where I should ask.
We are starting the OpenServerless project and checking licenses.
We have one component in our project, Minio, which is AGPL Licensed.
We know AGPL is not to be used in Apache Code but here
packages to apache-xxx before releasing. The packages released
> > before
> > > >>>> should be on to left intact.
> > > >>>>
> > > >>>> I came across same issue when we release apache fury. In your case,
> > most
> > > >>>> pack
>> downstreams. So fury just skipped release binary packages for fury
> > >>>> JavaScript.
> > >>>>
> > >>>> I was wondering whether the incubator release policy remove such
> name
> > >>>> rules. It does introduce ex
>>>> the naming needs to be consise and be as short as possible. We barely
> >>> see a
> >>>> wheel in a organization name wheel as $orgname-xxx.
> >>>>
> >>>>
> >>>>
> >>>> On Wednesday, May 15, 2024, Ti
t;>>>
>>>>> The distribution guidelines [1] say packages published to NPM should
>>>>> be named `apache-`, however, at KIE, we have a somewhat big
>>>>> set of packages that are published under these scopes:
>>>>> - @kie-tools/*
>
also some VS Code Extensions (which can't have a scope):
> > > > - yard-vscode-extension
> > > > - swf-vscode-extension
> > > > - pmml-vscode-extension
> > > > - dmn-vscode-extension
> > > > - bpmn-vscode-extension
> > >
extension-kogito-bundle
> > > - vscode-extension-kie-ba-bundle
> > > - vscode-extension-dashbuilder-editor
> > >
> > > And a one-off package that is later then transformed into a Maven
> > > WebJar [2] (which can't have a scope either)
> > >
kogito-bundle
> > - vscode-extension-kie-ba-bundle
> > - vscode-extension-dashbuilder-editor
> >
> > And a one-off package that is later then transformed into a Maven
> > WebJar [2] (which can't have a scope either)
> > - sonataflow-deployment-webapp
> >
bundle
> - vscode-extension-dashbuilder-editor
>
> And a one-off package that is later then transformed into a Maven
> WebJar [2] (which can't have a scope either)
> - sonataflow-deployment-webapp
>
> Those do not conform with the guidelines, but have been published
> under
n transformed into a Maven
> WebJar [2] (which can't have a scope either)
> - sonataflow-deployment-webapp
>
> Those do not conform with the guidelines, but have been published
> under these scopes/names for quite some time now, before KIE became a
> podling.
>
> My questio
then transformed into a Maven
WebJar [2] (which can't have a scope either)
- sonataflow-deployment-webapp
Those do not conform with the guidelines, but have been published
under these scopes/names for quite some time now, before KIE became a
podling.
My question is: Are we required to rename
Hi,
> Thank you all for the inputs, but we still seeking clarity on NPM.
>
> We - Apache KIE podling - are trying to get a single release procedure for
> all binaries, but with lack of NPM infra for staging makes it really
> complex.
>
> I notice that OpenDAL publishes to NPM, is there anyone in
le build the PMC will
> > never
> > > > be able to verify that the binaries match the sources.
> > > >
> > > >
> > > > > The KIE project has three main types of consumable artifacts: Maven
> > > > > modules, Container ima
; >
> > >
> > > > The KIE project has three main types of consumable artifacts: Maven
> > > > modules, Container images, and NPM packages; and we also maintain
> some
> > > > live web pages like https://sandbox.kie.org, and extensions for
> Chrome
> >
Chrome
> > > [3] and VS Code [4].
> > >
> > > For the release to be voted, we understand we have to provide a .zip
> > > file containing the source code along with instructions on how to
> > > build it. Once/if approved, our understanding is that the exact sa
ing is that the exact same
> > approved source code could be used to build and publish
> > binaries/artifacts of any sort to public registries/repositories.
> >
> > I’m laying out all the information I could gather so someone can
> > correct me if somehow I got the wrong
ion I could gather so someone can
> correct me if somehow I got the wrong idea of any part of the process.
>
> I guess the main question I have at the moment is: Are we able to pass
> the release vote only with the sources (without any published
> artifacts) so that once/if approve
registries/repositories.
I’m laying out all the information I could gather so someone can
correct me if somehow I got the wrong idea of any part of the process.
I guess the main question I have at the moment is: Are we able to pass
the release vote only with the sources (without any published
Daniel,
That’s exactly the reason. There’s also this link referencing the
requirement [1].
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=287607354#content/view/287607354
Regards,
_
Alex Porcelli
http://porcelli.me
On Tue, Jan 23, 2024 at 9:58 AM Daniel Gruno
On 1/23/24 15:49, PJ Fanning wrote:
Hi Alex,
While reproducible builds are a great idea, the Incubator PMC does not
require them. Plugging away at improving things so that reproducible
builds can be produced in future is a useful thing to do.
This may be related to https://issues.apache.org/ji
Fanning
Datum: Dienstag, 23. Januar 2024 um 15:50
An: general@incubator.apache.org
Betreff: Re: [QUESTION] Reproducible build for container images
Hi Alex,
While reproducible builds are a great idea, the Incubator PMC does not
require them. Plugging away at improving things so that reproducible
builds
Hi Alex,
While reproducible builds are a great idea, the Incubator PMC does not
require them. Plugging away at improving things so that reproducible
builds can be produced in future is a useful thing to do.
Regards,
PJ
On Tue, 23 Jan 2024 at 14:58, Alex Porcelli wrote:
>
> In the KIE podling, w
In the KIE podling, we regularly publish container images as part of
our releases. We've achieved semantically identical images, verified
using the 'diffoci' tool. However, due to current Docker/OCI engine
limitations, we can't eliminate variations in file metadata caused by
automatically appended
Thank you all for the valuable inputs... to play safe I opened a
ticket [1] with legal for better clarity.
[1] https://issues.apache.org/jira/browse/LEGAL-663
On Wed, Jan 10, 2024 at 8:30 PM Justin Mclean wrote:
>
> Hi,
>
> > In your source release anything in Category A is fair game. Things in
Hi,
> In your source release anything in Category A is fair game. Things in
> Category B are not. Things in Category X never are.
While correct, that’s not the full story; you also can’t have anything as a
dependency whose license is a category X one.
Kind Regards,
Justin
Hello
In general with all such things ASF and licensing a great place to start
for information is here [1]. It lays out the different categories and how
ASF Legal has designated a given license.
The way to really consider this largely comes down to whether you package
that binary in a release yo
Hi!
I'd say the situation has changed a bit, as those jars are available at
central since version 19.3, IIRC ([#1]).
They are published under Oracle Free Use Term and Conditions (FUCT) license
([#2]), so I'd check again with legal to see if this license is allowed or
not.
HTH,
juan pablo
[#1]
In KIE podling we have reference for the Oracle JDBC driver being used
only for tests [1], however based on this ticket [2], it's not clear
if we can continue to use it or this dependency has to be removed.
Guidance on this topic would be highly appreciated!
Regards,
Alex
[1]
https://github.com
gt; Von: Justin Mclean
> Datum: Mittwoch, 10. Januar 2024 um 01:26
> An: incubator general apache
> Betreff: Re: [QUESTION] Handling of licensing issues for dependencies of
> dependencies
> HI,
>
> > I was performing a more thorough check of our dependencies in preparatio
also GPL (I hope that’s correct)
Chris
Von: Justin Mclean
Datum: Mittwoch, 10. Januar 2024 um 01:26
An: incubator general apache
Betreff: Re: [QUESTION] Handling of licensing issues for dependencies of
dependencies
HI,
> I was performing a more thorough check of our dependencies in preparat
HI,
> I was performing a more thorough check of our dependencies in preparation of
> opening graduation discussions with the Incubator PMC and found at least one
> package that, while not directly used in the code, is installed as a
> dependency of multiple top-level dependencies that is LGPL l
I was performing a more thorough check of our dependencies in preparation of
opening graduation discussions with the Incubator PMC and found at least one
package that, while not directly used in the code, is installed as a dependency
of multiple top-level dependencies that is LGPL licensed. The
the same as download JDK
> > and
> > > > > > place them under JAVA_HOME.
> > > > >
> > > >
> > > > Except that's not how these libraries are listed within your pom
> > file. If
> > > > there was a step where you
was a step where you required a developer to download these
> files,
> > > what you're describing would be accurate, but they're downloaded in an
> > > automated fashion. Keep in mind, this isn't the JMH that's distributed
> > > with the
e files,
> > > what you're describing would be accurate, but they're downloaded in an
> > > automated fashion. Keep in mind, this isn't the JMH that's distributed
> > > with the JDK that you're using here, it's an add-on library you'r
istributed
> > with the JDK that you're using here, it's an add-on library you're using.
> >
> >
> > > >
> > > > > you can't use org.openjdk.jmh:* as a compile/test compile
> > > > > dependency in your project
> > &g
gt; >
> > > > you can't use org.openjdk.jmh:* as a compile/test compile
> > > > dependency in your project
> > >
> > > fury-benchmark is not released in binary form. But we can of course
> > > make it an optional dependency (or the entire modul
s an add-on library you're using.
> >
> > > you can't use org.openjdk.jmh:* as a compile/test compile
> > > dependency in your project
> >
> > fury-benchmark is not released in binary form. But we can of course
> > make it an optional dependency (or
ION.
> > >
> > > Or, we can exclude the benchmark code from the release like [4] but
> > > still hold it in the VCS.
> > >
> >
> > There's a difference between the GPL+CPE Cat X ruling we list on our
> > license website and how you're using
t in the VCS.
> >
>
> There's a difference between the GPL+CPE Cat X ruling we list on our
> license website and how you're using JMH. When it comes to a Java
> application, a developer has preinstalled the JDK (or using a manager of
> some kind to install it - so n
m). In
the case of JMH, the repository I linked above forces the user to download
the additional dependency from maven central (or similar repository) rather
than relying on the system preinstalled library.
It's probably worth a question to legal, but I'm inclined to believe the
answer is no
Hi,
As listed in that document, a GPL license with a classpath exception is
category X, so everything that applies to other category X licenses applies to
that license. System dependencies that users or developers typically have
installed that don't impact the license of the compiled package ar
Justin>GPL files with classpath exceptions are not allowed [1]
Justin, could you please elaborate?
The link in [1] you mention reads "Special exceptions to the GNU GPL (e.g.
GNU Classpath)"
If "GPL with classpath exception" is not allowed, then **all** ASF
Java-based projects violate the policy a
Thanks for your feedback!
I interpret the response as we don't distribute JMH files in source or
binary form, and it's optionally included in test scope. So we can
depend on its classes like we depend on "java.lang.String".
Again, no GPL files are distributed with Fury in source or binary form.
Hi,
GPL files with classpath exceptions are not allowed [1]. Any files with that
license cannot be in an ASF distribution [2] in source or binary form. They
cannot be a non-optional dependency. [3]
Kind Regards,
Justin
1. https://www.apache.org/legal/resolved.html#category-x
2. https://www.apa
Most JMH source files (e.g. see [1]) have the same license as
java.lang.String.
Do you exclude files that use `java.lang.String` from the release? I doubt
so.
The same goes for the benchmarks.
>Or, we can exclude the benchmark code from the release like [4] but
>still hold it in the VCS.
There's
I think once it stays in the test scope, it should be good.
The release policy is about compiling sources to get the binary, which
means the final version could work without GPLx is the most important
part.
Sheng Wu 吴晟
Twitter, wusheng1108
tison 于2023年12月27日周三 09:09写道：
>
> Hi,
>
> The new podlin
Hi,
The new podling Fury depends on jmh[1] which is licensed under GPLv2
with "CLASSPATH" EXCEPTION.
IIRC Flink ever factored out its benchmark code into a separate repo
[2] to comply with ASF's license policy [3].
But since Fury doesn't modify jmh's code, just refers to some
"org.openjdk.jmh."
Hi,
My understanding is that is all come across, but it would be best to ask infra.
Kind Regards,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.a
Brian hope you don’t mind if I share additional details for the members of
the mailing list.
Some of the repositories have several stars, followers, historical list of
Pull Request and several other relevant metadata associated with them.
If a transfer between existing kiegroup and Apache organiz
Hey all,
I was reading the Initial Code Import document[1] and while it says
Infra needs the code attached to a JIRA ticket (after the SGA or CCLA
has been completed), it also seems to say that you can pull all of it
in via a GitHub export-> import operation[2].
So, my questions:
1) Is a direct
an existing codebase. Any code that was
>>>> developed outside of the ASF SVN repository and our public mailing lists
>>>> must be processed like this, even if the external developer is already
>> an
>>>> ASF committer.
>>>>
>>>>
gt;>
> >> "Incubating projects should follow the procedure described in the
> incubator
> >> mentor guide and report status via STATUS tracking."
> >>
> >> Okay, cool, so I follow the link to the incubator mentor guide[2] and
> >> there'
external developer is already an
> > ASF committer.
> >
> > "Incubating projects should follow the procedure described in the
> incubator
> > mentor guide and report status via STATUS tracking."
> >
> > Okay, cool, so I follow the link to the incubator
;Incubating projects should follow the procedure described in the incubator
>> mentor guide and report status via STATUS tracking."
>>
>> Okay, cool, so I follow the link to the incubator mentor guide[2] and
>> there's only a self-referencing anchor link about &qu
gt; Okay, cool, so I follow the link to the incubator mentor guide[2] and
> there's only a self-referencing anchor link about "Start IP clearance"
>
> The question: what is the procedure I need to follow?
>
> Thanks!
> BKP
>
> [1] https://incubator.apache.org/i
status via STATUS tracking."
Okay, cool, so I follow the link to the incubator mentor guide[2] and
there's only a self-referencing anchor link about "Start IP clearance"
The question: what is the procedure I need to follow?
Thanks!
BKP
[1] https://incubator.apache.org/ip-
Thanks, this is helpful!
BKP
Brian Proffitt
VP, Marketing & Publicity
Co-organizer, Community Over Code
Member, Apache Software Foundation
Member, Apache Community Development & Incubator PMCs
Red Hat Open Source Program Office
On Mon, Jul 24, 2023 at 11:50 AM Ayush Saxena wrote:
> Hi Brian,
Hi Brian,
I tried to look in Apache Incubator docs, there isn't any explicit
mention about that, or at least not in the one I looked at. But in the
generic Adding PMC doc, it does mention [1]
```
Be sure to send a separate [NOTICE] email for each individual you are
nominating.
```
So, it should b
We have a number of KIE contributors we need to add to the PPMC membership.
As a matter of process, should I present those to the list en masse or one
at a time?
BKP
Brian Proffitt
VP, Marketing & Publicity
Co-organizer, Community Over Code
Member, Apache Software Foundation
Member, Apache Commu
On Jun 27, 2023, at 6:33 AM, Brian Proffitt wrote:
The KIE podling has a question that I don't know the answer to. They
are
wondering if they are required to mirror their source into the Apache
GitHib organization? They will be hosting their code in their own GH
repo,
but they want to k
transfer their repositories to the ASF.
> >
> > Best,
> > Dave
> >
> > Sent from my iPhone
> >
> > > On Jun 27, 2023, at 6:33 AM, Brian Proffitt wrote:
> > >
> > > The KIE podling has a question that I don't know the answer to. They
SF.
>
> Best,
> Dave
>
> Sent from my iPhone
>
> > On Jun 27, 2023, at 6:33 AM, Brian Proffitt wrote:
> >
> > The KIE podling has a question that I don't know the answer to. They are
> > wondering if they are required to mirror their source into the Apach
my iPhone
> On Jun 27, 2023, at 6:33 AM, Brian Proffitt wrote:
>
> The KIE podling has a question that I don't know the answer to. They are
> wondering if they are required to mirror their source into the Apache
> GitHib organization? They will be hosting their code in thei
The KIE podling has a question that I don't know the answer to. They are
wondering if they are required to mirror their source into the Apache
GitHib organization? They will be hosting their code in their own GH repo,
but they want to know if the mirror is necessary as well.
BKP
Brian Pro
thoug.
>
> Chris
>
>
> Von: Alexander Alten-Lorenz
> Datum: Dienstag, 2. Mai 2023 um 16:05
> An: general@incubator.apache.org
> Betreff: Re: License question when including other ASF projects
> Can anyone give us a tip regarding this one?
>
> Thanks,
> —alex
resolve false-positives ... might have a look at it thoug.
Chris
Von: Alexander Alten-Lorenz
Datum: Dienstag, 2. Mai 2023 um 16:05
An: general@incubator.apache.org
Betreff: Re: License question when including other ASF projects
Can anyone give us a tip regarding this one?
Thanks,
—alex
> On
included in binary-only form (see
>>> Category B under [1]).
>>>
>>> Cheers
>>> Dominik
>>>
>>>
>>> [1] https://www.apache.org/legal/resolved.html
>>>
>>>
>>> -Original Message-
>>> From: Alexander Al
.0 should be fine in case it is included in binary-only form (see
>> Category B under [1]).
>>
>> Cheers
>> Dominik
>>
>>
>> [1] https://www.apache.org/legal/resolved.html
>>
>>
>> -Original Message-
>> From: Alexander A
ers
> Dominik
>
>
> [1] https://www.apache.org/legal/resolved.html
>
>
> -Original Message-
> From: Alexander Alten-Lorenz
> Sent: Saturday, April 29, 2023 11:29 AM
> To: general@incubator.apache.org
> Subject: License question when including other ASF
@incubator.apache.org
Subject: License question when including other ASF projects
Hi,
We use Apache Calcite, dependabot suggests a bump, but the automation failed
since Calcite uses a non-compatible license (if I’m right)
https://github.com/apache/incubator-wayang/actions/runs/4751917613/jobs/8441627979?pr=302
Hi,
We use Apache Calcite, dependabot suggests a bump, but the automation failed
since Calcite uses a non-compatible license (if I’m right)
https://github.com/apache/incubator-wayang/actions/runs/4751917613/jobs/8441627979?pr=302#step:6:1117
How can we solve this, except not to update ;) Or is
Thank you. Here is the PR to fix that.
https://github.com/apache/spark/pull/40249
[SPARK-42649][CORE] Remove the standard Apache License header from the top
of third-party source files
Dongjoon.
On Wed, Mar 1, 2023 at 11:53 PM wrote:
> Hi,
>
> See https://www.apache.org/legal/src-headers.html
Hi,
See https://www.apache.org/legal/src-headers.html#3party - "Do not add the
standard Apache License header to the top of third-party source files.” and
"Minor modifications/additions to third-party source files should typically be
licensed under the same terms as the rest of the third-party
Thanks Josh!
On Wed, Mar 1, 2023, at 16:12, Josh Fischer wrote:
> done:
> https://github.com/apache/incubator-heron/commit/1c5779dcdf19eed888412f3d87b31ebb4b00e07e
>
> On Wed, Mar 1, 2023 at 9:02 AM Josh Fischer wrote:
>
>> Sure, I'll get it done today.
>>
>> On Wed, Mar 1, 2023 at 8:49 AM Christ
done:
https://github.com/apache/incubator-heron/commit/1c5779dcdf19eed888412f3d87b31ebb4b00e07e
On Wed, Mar 1, 2023 at 9:02 AM Josh Fischer wrote:
> Sure, I'll get it done today.
>
> On Wed, Mar 1, 2023 at 8:49 AM Christian Grobmeier
> wrote:
>
>> Josh,
>>
>> On Wed, Mar 1, 2023, at 14:38, Josh
Sure, I'll get it done today.
On Wed, Mar 1, 2023 at 8:49 AM Christian Grobmeier
wrote:
> Josh,
>
> On Wed, Mar 1, 2023, at 14:38, Josh Fischer wrote:
> > Thanks for this, Christian. I was looking at this list [1] and had quite
> > a few questions. The list you sent seems to have more informat
Josh,
On Wed, Mar 1, 2023, at 14:38, Josh Fischer wrote:
> Thanks for this, Christian. I was looking at this list [1] and had quite
> a few questions. The list you sent seems to have more information.
> 1. https://cwiki.apache.org/confluence/display/incubator/RetiringPodlings
great you are stil
Thanks for this, Christian. I was looking at this list [1] and had quite
a few questions. The list you sent seems to have more information.
1. https://cwiki.apache.org/confluence/display/incubator/RetiringPodlings
On Wed, Mar 1, 2023 at 3:58 AM Christian Grobmeier
wrote:
> Hi,
>
> I completed
Right, it contains ALv2 licensed code attributed to two authors - some is
from Guava, some is from Apache Spark contributors.
I thought this is how we should handle this. It's not feasible to go line
by line and say what came from where.
On Wed, Mar 1, 2023 at 1:33 AM Dongjoon Hyun
wrote:
> May
Hi,
I completed most of the retirement actions described here:
https://incubator.apache.org/guides/retirement.html
The copyright item is not checked. Do we have any tooling to check whether we
remove the source code?
It was also hard to dig out all the requested resources. If anybody knows any
May I ask why do you thinkn in that way? Could you elaborate a little more
about your concerns if you mean it from a legal perspective?
> The ASF header states "Licensed to the Apache Software Foundation (ASF)
under one or more contributor license agreements.”
> I ‘m not sure this is true with thi
Hi,
The issue is not the original header it is the addition of the ASF header. The
ASF header states "Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.” I ‘m not sure this is true with this
file even though both Spark and this file are under the
+CC @Justin Mclean, and @Willem Jiang since you left the concerns
It looks like Spark may have incorrectly added that header. You could ask
> them why it was added perhaps or just leave it as is.
>
Kind Regards,
>
Justin
>
I have the same question as Justin asked, do we need to
Thank you Gordon for the +1 , and Rich for the comment and opportunity to
clarify.
I want to ask for an ASF incubator mentor for this, to move it forward.
We are reaching out to key companies in the quantum computing industry with
this proposal - to have a vendor neutral project at Apache - and h
+1 for this idea.
On Fri, Feb 10, 2023 at 11:58 AM James Dailey
wrote:
> Thanks Rich.
>
> "The Open Quantum Safe (OQS) project is an open-source project that
> aims to support the development and prototyping of quantum-resistant
> cryptography."
>
> So, their concept is very different - it's att
Thanks Rich.
"The Open Quantum Safe (OQS) project is an open-source project that
aims to support the development and prototyping of quantum-resistant
cryptography."
So, their concept is very different - it's attempting to provide a
"counter" to quantum computing which may render existing encrypti
Have you seen https://openquantumsafe.org/ ? The team is impressive.
Work is done on GitHub, MIT license, and has integrations with OpenSSL and
others.
Hello
I'm seeking additional input and interest in this idea. AFAIK, there
are no existing projects of this type in the attic, active, or
incubating.
At ApacheCON North America (october 2022), we heard from the CEO of
Strangeworks, Whurley!.
He presented the idea of an open source project that co
HI,
> I'm struggling to find any examples of ASF jars pushed to maven
> central that have anything other than the standard boilerplate Apache
> LICENSE and NOTICE. Having a transitive dependency on another jar
> doesn't appear to be mentioned in any jar LICENSE/NOTICE that I
> checked.
See [1]. I
Hi Justin,
I'm struggling to find any examples of ASF jars pushed to maven
central that have anything other than the standard boilerplate Apache
LICENSE and NOTICE. Having a transitive dependency on another jar
doesn't appear to be mentioned in any jar LICENSE/NOTICE that I
checked.
Having code fr
Hi,
Those jars are likely to have different LICENSE and NOTICE files so I would
suggest you vote on both at the same time.
Kind Regards,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional co
Thanks Hans. That would be the general plan with the Maven jar part of
our releases.
* as part of the RC where we stage a source release for people to vote
on, we will also push jars to repository.apache.org staging repo
* if the vote on the source release passes, we will release the source
release
1 - 100 of 645 matches
Mail list logo
