BatchEE Report - why are they monthly
All, I believe the BatchEE podling is incorrectly set to monthly reports. If I look at the schedule, they should have reported in June, but were late and reported in July. I believe they should have been taken off monthly but weren't and as a result were expected to report in August (and now September). Unless there are objections I'm going to remove them from the report and fix their monthly attribute. John
Re: What is the legal basis for enforcing release policies at ASF?
On Fri, Aug 21, 2015 at 11:00 AM, Jim Jagielski j...@jagunet.com wrote: On Aug 20, 2015, at 10:23 AM, Benson Margulies bimargul...@gmail.com wrote: On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski j...@jagunet.com wrote: Coming in late. A snapshot is not a release. Licenses kick in at distribution/ release. Are you sure? When you have a public source control repo, with a LICENSE file at the top, I would think that this counts as a legal 'publication' under the terms of the license. if not, just what is the legal status of source code snipped from our repositories? A file that exists on a public source repo, with an associated license is, of course, covered under that license. The issue is what is the combined, derivative work under? I can, for example, take a handful of ALv2 files, combine them as-is and license the WORK as GPLv3 for example. Furthermore, a release should have such things as a NOTICE file, etc, as required. Again, no idea if that is included in a snap-shot or not. A release is such that the release artifact is verified as compliant w/ the ALv2, and is an official action of the foundation; A snapshot may or not be verified but for sure is not an official action and the person providing the snapshot does so at their own risk. I was working from some significant miss-assumptions which I won't go into here, to avoid confusing other readers, not unless I understand things thoroughly. On Fri, Aug 21, 2015 at 10:51 AM, Jim Jagielski j...@jagunet.com wrote: I did NOT SAY that... holy moley. I said that licenses kick in at a release, but I not not say that they don't kick-in at other times; also, a release is guaranteed to be under ALv2 (it is our work) and there is no guarantee on said snapshot, depending on how it is created. Yes, I should have given your statement the benefit of the doubt. Whether your statement had been incomplete, outright wrong, or absolutely on point, my venting was inexcusable. On Fri, Aug 21, 2015 at 11:04 AM, Jim Jagielski j...@jagunet.com wrote: Cut it out. I apologize to you for my antagonistic tone. It was a combination of being several days deep into a head cold, and fundamentally misunderstanding the provenance of svn.
Re: apache binary distributions
On Wed, Aug 19, 2015 at 1:46 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: But I am still awaiting guidance from brand on whether a technical name usage - e.g. installer package name - is a use of the mark. Makes two of us. I see a log of good consensus on this thread which helps me get a gut feel on what is the right way to go about enforcing the use of the mark. That said, I still would love to read Shane's meditation on the matter ;-) Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: apache binary distributions
On Wed, Aug 19, 2015 at 10:06 AM, William A Rowe Jr wr...@rowe-clan.net wrote: There are some special things here we do have absolute control over. If a project wants to provide the 'official' build, why not start signing the .jar? This! This is such a great idea. Would love this to be weaved into our policy (at least as part of what is suggested, not required) somehow. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is the legal basis for enforcing release policies at ASF?
Roman Shaposhnik wrote: On the other hand, somebody taking said snapshot and releasing it under the name Project BOO, licensed under the ALv2. Is something that both the ALv2 license AND our trademark policy are totally fine with. What if (not a fictional example; a real case) the code is taken from a branch that comes from a recent code donation and source headers are still in the process of being updated to comply with the donation? Waiting for that code to be included in a formal release for sure solves the problem. But if one doesn't want to wait, I wouldn't know what to suggest. Regards, Andrea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is the legal basis for enforcing release policies at ASF?
On Fri, Aug 21, 2015 at 11:37 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: [Failing at dealing with this cross-posted and variously-branched discussion on two lists, so I am doing it too. Also OT with respect to Ross's declaration, but it has to do with the fact that release is not so well distinguished as one might hope.] Minor nit? #1: Generally, because of what is seen in the repository in terms of LICENSE and NOTICE placement, it appears to apply to everything at and below that point in the repository. A casual observer cannot tell that there is an important ceremonial distinction with regard to using the archived packaging of an approved Apache Release. I was thinking exactly that while reading the thread. Now, to be fair, most of the time statements made by both of these are correct. I actually haven't seen that much licensing issues with TLP during release cycles. Not-so-minor nit? #2: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file **distributed** with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the 'License') at the very top of many individual files in typical ASF Project repositories. Yup. That goes back to the clarification I've just requested from Ross. 'cuz I agree -- I can see it being interpreted in more than one way. Techno-legal nit? #3: From http://www.apache.org/licenses/icla.txt: You hereby grant to the Foundation and to recipients of software **distributed** by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. ** emphasis mine in both places Great point. I haven't connected the dots with ICLAs myself, but it totally makes sense to talk about ICLA since it is the document that governs the ingest point of new contributions. Avoiding the nit-pickers by picking more nit? #4 A while back, because I was concerned that some user of a contribution of mine might be trapped in a hair splitting between distribution, non-distribution, and released I made a supplemental declaration. I provided a copy to the Secretary of the Foundation on 2013-03-08. This broader statement grants to **all parties obtaining** any past or future ASF **contribution** of mine effectively the same copyright license granted under the iCLA without the condition that it be distributed by the Foundation. You can see it in all of its glory at http://mail-archives.apache.org/mod_mbox/openoffice-dev/201303.mbox/%3c008801ce1c21$0deb3560$29c1a020$@apache.org%3e. This is not the same as an ALv2 license, but it basically gives to all of those parties the same terms as provided to the ASF under the iCLA (technically not an ALv2 license either). I have made a comparable declaration by any contribution I might make to LibreOffice. I have *not* provided LibreOffice with the dual MPL-LGPL license declaration they tend to request. (The receipt of that declaration has not been acknowledged, but I stand behind it.) Interesting! Thanks for the pointer. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What is the legal basis for enforcing release policies at ASF?
Fascinating discussion, who started this thread? ;-) On a more serious note (actually, very serious one): On Fri, Aug 21, 2015 at 9:13 AM, Ross Gardler ross.gard...@microsoft.com wrote: Our policy is that the combined works are RELEASED under ALv2. That combined work is only licensed as such when the foundation formally approves it. So let me spell one thing explicitly here and see if we all agree. Here's what it is: even though from a purely licensing standpoint a content of a source code repo (a snapshot but NOT in a Maven sense) most of the time happens to be licensed under ALv2 (verification at the point of contribution) we, as a foundation, refuse the right to ANYBODY to call it a release of Apache FOO. We use our trademark power for that. It has nothing to do with the license itself. On the other hand, somebody taking said snapshot and releasing it under the name Project BOO, licensed under the ALv2. Is something that both the ALv2 license AND our trademark policy are totally fine with. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: apache binary distributions
So there is - to my mind - the obvious stuff: 1. The package description should ACK our marks. End of Story there. 2. The package description should call out those cases where there are significant deviations from the official distributions. Significant deviations will be determined by the individual PMCs as they know what is significant and what is not. That leaves the technical package name. Is using our mark in the technical package name (which cannot have space to ACK the mark, but assuming there is an ACK of the mark in the description) an issue? So if we have: package-name: foo description: The Manchu team's packaging based on Apache Foo. Apache Foo is a framework for doing bar. Apache, Apache Foo and Foo are trademarks of the Apache Software Foundation. is the Manchu packaging of Foo ok to use foo as the package name? It would seem to be a disservice to users to force Manchu to pick a different name for Foo (i.e. the firefox vs iceweasel issue) On the other hand, packaging up Apache Foo for the Manchu installer framework may require significant patching of Apache Foo such that it is necessary to declare that it is *based on Apache Foo* Compare and contrast with homebrew's packaging of Apache Maven where they just download the convenience binary published by the Apache Maven team... that seems reasonable to be called `maven` because it is actually installing exactly what the Apache Maven team released without modifications. Shane, do you need further clarifications? On 25 August 2015 at 11:52, Roman Shaposhnik ro...@shaposhnik.org wrote: On Wed, Aug 19, 2015 at 1:46 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: But I am still awaiting guidance from brand on whether a technical name usage - e.g. installer package name - is a use of the mark. Makes two of us. I see a log of good consensus on this thread which helps me get a gut feel on what is the right way to go about enforcing the use of the mark. That said, I still would love to read Shane's meditation on the matter ;-) Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
