If the binary release is not the official releases, we need to let
people know about it. Adding the DISCLAIMER could help us with that.
For the other binary release such as Maven release, Docker release
how can we introduce the DISCLAIMER for it?
Willem Jiang
Twitter: willemjiang
Weibo:
Sure, I'm OK with that.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Thu, Nov 8, 2018 at 3:12 AM Dave Fisher wrote:
>
> Hi Willem,
>
> I’ve added the following to the proposal:
>
> === External Dependencies ===
>
> brpc has the following external dependencies.
>
> * Google gflags
I used to use and also see some other projects use the following structure to
maintain the third-party license:
Create a folder licenses under root to hold the licenses of the dependencies,
like lib1.txt with the content of lib1 license, and lib2.txt with the license
content of lib2.
In your
+1 (binding)
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Hi,
> we need to include licenses of all components shipped in an artifact. The
> example just appends all licenses to the LICENSE file including the
> copyrights. Is the copyright required?
If the license include it and the terms of the license say so then yes. This
applied to common
Hi Willem,
I’ve added the following to the proposal:
=== External Dependencies ===
brpc has the following external dependencies.
* Google gflags (BSD)
* Google protobuf (BSD)
* Google leveldb (BSD)
brpc also includes third party code in the source tree.
*
+1 binding.
would be interested to participate as a mentor
thanks
On Wed, Nov 7, 2018, 12:53 PM Matt Sicker +1 (binding)
>
> On Wed, 7 Nov 2018 at 08:03, Kevin A. McGrail wrote:
>
> > +1 (binding)
> >
> > On 11/7/2018 2:46 AM, hxd wrote:
> > > Hi,
> > > Sorry for the previous mail with bad
Hi -
>> ...I propose this:
>>
>> If someone has done several of the following:
>> - has been involved in an incubating project from start to finish
>> - has been a release manager
>> - has assembled LICENSE and NOTICE files
>> - has reviewed and voted on releases
>> - has proposed or accepted
+1 (binding)
On Wed, 7 Nov 2018 at 08:03, Kevin A. McGrail wrote:
> +1 (binding)
>
> On 11/7/2018 2:46 AM, hxd wrote:
> > Hi,
> > Sorry for the previous mail with bad format.
> > I'd like to call a VOTE to accept IoTDB project, a database for managing
> large amounts of time series data from
+1 (Non Binding)
On Wed 7 Nov, 2018, 11:02 vintagewang +1 (non-binding)
>
> XIAORUI Wang
>
> zhangli...@apache.org 于2018年11月7日 周三09:30写道：
>
> > +1 (non-binding)
> >
> > Thanks,
> > John(Zhang Liang) from Sharding-Sphere
> >
> > Bruno Mahé 于2018年11月7日周三 上午1:37写道：
> >
> > > +1 (non-binding)
> >
What Alex is saying makes sense. Whether you like it or not, you are creating a
derived work (or something - I am not a lawyer), and that needs its own L
> On Nov 7, 2018, at 9:03 AM, Alex Harui wrote:
>
> IIRC, we use the food allergy analogy for these situations. AIUI, the goal
> is for
IIRC, we use the food allergy analogy for these situations. AIUI, the goal is
for the top-level LICENSE to make it convenient for someone to see what the
ingredients are, because some folks are "allergic" to certain licenses. I
think you can still use "pointers" instead of copying full texts
Hi Vincent,
At least right now we have the source code part covered since we do not ship
any third party code/jars etc. with it. However, as you pointed it is a
concern for the binary release. We just want this to be easy to manage. At
the moment we have 80+ jars that we ship as
IMO, that was (and in many cases) still IS a Good Thing... the issue is that it
must be made clear that what the ASF releases are source code artifacts. Any
binary releases that are done are not official releases of the foundation nor
the PMC, but are community provided conveniences.
> On Nov
Hi Jonas,
I totally understand your situation right now, because I have just gone through
the release process for my project Apache OpenWhisk as well.
Regarding whether you should add the copyright, to me, it depends on the source
code release or the binary release.
If you only care about the
Another example: for some projects, the most important distribution is via
Maven Central. We can distribute source and binary there, of course, but my
guess would be that the vast majority of consumers are pulling the binaries and
linking directly against them, using source distributions only
Hi -
There are some projects where the binary is all the users want. For example,
Apache OpenOffice. In that case these binaries are an exception and while on
dist they are not mirrored and instead we distribute through SourceForge.
I think if binaries are kept in a separate folder from source
+1 (binding)
On 11/7/2018 2:46 AM, hxd wrote:
> Hi,
> Sorry for the previous mail with bad format.
> I'd like to call a VOTE to accept IoTDB project, a database for managing
> large amounts of time series data from IoT sensors in industrial
> applications, into the Apache Incubator.
> The
Hi,
On Wed, Nov 7, 2018 at 1:35 PM Jonas Pfefferle wrote:
> ...Shouldn't the copyright be appended
> to the NOTICE file instead?...
Probably not - the NOTICE must be minimal as per
http://www.apache.org/dev/licensing-howto.html we must only add "any
*mandatory* legal notifications specific to
Jim
What do you think now?
Was that a good or bad thing?
TLDR; I’m in favor of convenient binaries is just the how they are handled.
Sorry for my brevity, what I meant is that binaries should not be beside next
to the source release seating on the same server and giving the same guarantees
Hi all
I think this is a good idea. Rather than copying all licenses and
then ship both, the original license in each jar and the copied
one, I would prefer to list the jars in the NOTICE file and point
to the licenses already included in the listed jars.
The advantages are that (1) the
Since we are only shipping jars and jars already include the licenses e.g.
in META-INF or the pom file, we could refer to them in the NOTICE file
instead of replicating them.
Jonas
On Wed, 07 Nov 2018 13:35:04 +0100
"Jonas Pfefferle" wrote:
Hi all,
We are just preparing a new release
Hi all,
We are just preparing a new release and are wondering how and what is
required for licenses and copyrights of components shipped with an artifact.
According to the release
policy http://www.apache.org/legal/release-policy.html#distribute-other-artifacts
we need to include licenses
Just a FYI that in the early days of the ASF (and the httpd project), community
binaries were a common offering...
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
ASF should only distribute source
Having binaries/compiled along side of the source is not a good signal and
confusing.
- Carlos Santana
@csantanapr
> On Nov 7, 2018, at 4:24 AM, Bertrand Delacretaz
> wrote:
>
> Hi,
>
>> On Tue, Nov 6, 2018 at 11:07 PM David Nalley wrote:
>> ... To my
+1 (binding) from my side.
This will be a good addition to all of the pretty new IoT projects at apache.
Chris
Am 07.11.18, 10:02 schrieb "Gosling Von" :
+1
Good luck ~
Von Gosling
> 在 2018年11月7日，下午3:46，hxd 写道：
>
> Hi,
> Sorry for the
+1 cool project
On Wed, Nov 7, 2018 at 1:02 AM Gosling Von wrote:
> +1
>
> Good luck ~
>
> Von Gosling
>
>
> > 在 2018年11月7日，下午3:46，hxd 写道：
> >
> > Hi,
> > Sorry for the previous mail with bad format.
> > I'd like to call a VOTE to accept IoTDB project, a database for managing
> large amounts
On Tue, Nov 6, 2018 at 12:34 PM wrote:
> ...For instance [1] which states:
> "For committership, that is typical. Most PMCs allow a veto for adding new
> members to the PMC.” ...
Interesting, I missed that indeed, I'll start a discussion on our
members@ list to see what people think.
Thanks
Hi,
On Tue, Nov 6, 2018 at 9:20 AM Justin Mclean wrote:
> ...I propose this:
>
> If someone has done several of the following:
> - has been involved in an incubating project from start to finish
> - has been a release manager
> - has assembled LICENSE and NOTICE files
> - has reviewed and voted
Hi,
On Tue, Nov 6, 2018 at 11:07 PM David Nalley wrote:
>... To my mind, allowing projects to distribute 'convenience binaries'
> from our hardware, in a place we say contains releases, and which is
> occasionally consumed in such a way as to dwarf what we call official
> releases[1], makes them
+1
Good luck ~
Von Gosling
> 在 2018年11月7日，下午3:46，hxd 写道：
>
> Hi,
> Sorry for the previous mail with bad format.
> I'd like to call a VOTE to accept IoTDB project, a database for managing
> large amounts of time series data from IoT sensors in industrial
> applications, into the Apache
Hi,
> but I just wanted to highlight that we don't have to restrict our reviews to
> what is legally needed.
Which is the same for source releases i.e. to vote +1 on a release it just has
to compile, but tests could still be failing and/or it could not work. With
most of the incubator release
+1.
I get asked to mentor projects too, but have this restriction of not being
able to join the IPMC
On Tue, 6 Nov 2018 at 3:13 PM, Sheng Wu wrote:
> Hi Justin
>
> Very interesting proposal. And I like it, also willing to request for that
> :)
>
> From my experience, several projects have
While officially binaries are only convenience, it happened several times
with Groovy that we downvote a release _because_ of broken binaries. So we
integrate them as part of our review process. Basically, we do the usual
checks on sources (checksums, signatures, build, ...), but we _also_ check
+1 no binding
Welcome new IoT project
Sheng Wu
Apache SkyWalking
On 2018/11/07 07:46:59, hxd wrote:
> Hi,
> Sorry for the previous mail with bad format.
> I'd like to call a VOTE to accept IoTDB project, a database for managing
> large amounts of time series data from IoT sensors in
35 matches
Mail list logo
