Re: third party tooling.
On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: ...you can call yourself open source software all you want, but unless you get an exception from Fedora Packaging Committee you are not open enough for the distribution to consider your work... But that's doesn't make your project invalid or useless. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: third party tooling.
On Thu, Aug 6, 2015 at 2:25 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: ...you can call yourself open source software all you want, but unless you get an exception from Fedora Packaging Committee you are not open enough for the distribution to consider your work... But that's doesn't make your project invalid or useless. Right. I don't know where you're coming from Roman, but the Foundation doesn't require our projects to be built via bootsrappable [sic] from source using *only* open source software binaries as the input. Never has, never will. So to Jan's original question: totally fine, no issues with compiler dependencies for certain platforms. Our software is defined by ALv2 and the Category licenses for dependencies. We are Open Source by the OSI definition, and any reasonable person's definition. If Fedora believes otherwise, then they better pony up a reason why. I can't believe they think ASF software is not Open Source, so I don't know where you're going with that. -g
Re: apache binary distributions
On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: I honestly see no problem with that, again provided that the artifact can NOT be confused with the one coming from Apache project. I think the problem lies in Trademarks. Debian's Tomcat7 is labeled Servlet and JSP engine and its Tomcat8 is labeled Apache Tomcat 8 - Servlet and JSP engine, yet I don't see Apache Tomcat project creating/maintaining a Debian dist. Now, is Debian allowed to call it Tomcat? Is it allowed to call Tomcat8 to BE Apache Tomcat8, when in fact(!) there are changes to the source, such as the start script in Debian Tomcat is not original of Apache Tomcat, but instead follows a Debian template for how those scripts should be written. I am not sure what all the changes are, feel free to check; http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches IF (like Mozilla) Apache decides to strike down on Debian and not allowing it to use the same names, _I_ think it is a disservice to the users (IceWeasel browser), but as it stands, Apache trademark licensing seems to not really be followed (Perhaps Debian has some permission that was granted long in the past... I may have missed that). Cheers -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
RE: apache binary distributions
I think there is a bright-line distinction between Apache binary distributions and distributions made by third parties. In particular, I don't think that taking builds off of a buildbot or any other developer or overnight builds will count, although release candidates come close. I think it has to do with authenticity. (I am agreeing with Roman, but include verifiable provenance here.) When an Apache Project makes convenience binaries from a specific source code release and declares them authentic via release-manager control (even though not a source code release), via code signing via Apache committer signatures, including the release manager's, using and arranging publication of appropriately named files for download in some manner while housing the integrity hashes and signatures on secure Apache infrastructure, I would say that is an Apache [Convenience] Binary Distribution. Any release notes and support information about those identified binary distributions are about those and not anything else. There is clear provenance that such distributions are specifically provided for public use by the Apache Project and that the Apache Project will stand behind them in an appropriate manner. (Take bug reports against the binaries, deal with security vulnerabilities, no matter their origin in the Apache source code, etc.) - Dennis -Original Message- From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman Shaposhnik Sent: Thursday, August 6, 2015 17:51 To: general@incubator.apache.org Subject: Re: apache binary distributions On Thu, Aug 6, 2015 at 1:15 AM, Jochen Theodorou blackd...@gmx.org wrote: [ ... ] if PMC produced a release then binary convenience artifacts are easy: anything that corresponds to that release *could* be considered an official binary convenience artifact for the release (see my point above on 3d part vs. PMCs actually producing these binaries). IOW, what makes a binary convenience artifact an official ASF artifact is not whether it got designated as such, but whether it corresponds to an official source release produced by the PMC. Same for links for example to docker image distribution servers... or let's say a link to an ubuntu package. On the other hand you can put disclaimers on the pages stating they are not official... But they are. If they correspond to an official release. Then again nightly builds should be ok, if they will have the same disclaimer? No. Nightly builds are special precisely because they don't correspond to an official source release. Or is it ok if the nightly build comes from non-apache? It is ok, but at that point it becomes 3d party artifact and as such can't be promoted as part of ASF project. If that is ok, then why does the release document not say this and is instead very strict about not promoting anything even beyond the dev-list? It does not make sense for me and I am going in circles here. Perhaps the source of confusion is that ironically PMCs are *more* constrained in what they can do compared to 3dparty. They do get the Apache Branding rights in return for those constraints, though. Of course a third person would be someone unrelated to the project. Or related. Could even be one of the PMC members. The point is: it is NOT PMC. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: apache binary distributions
Then throw in an extra special case, Apache ABC making a release of Apache XYZ ;-) Not common, but AFAIK, nothing but convention (go over and do it in the name of XYZ instead) stopping that... But say XYZ has lost its PMC and is destined for Attic, and ABC is in desperate need... On Fri, Aug 7, 2015 at 8:50 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Thu, Aug 6, 2015 at 1:15 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 06.08.2015 02:43, schrieb Roman Shaposhnik: [...] As you probably remember we've discussed this issue not that long time ago: http://thread.gmane.org/gmane.comp.apache.incubator.general/49852 The consensus there is that as long as you're communicating intent clearly you can let downstream developers test/develop against your development artifacts. IOW, the definition of developers starts including downstream developers integrating with your project. yes, I remember that discussion, but for me the outcome is not as clear as it is for you it seems. Especially with regards to communicating that intend and if it has to go through the release voting cycle. You usually don't do that for SNAPSHOTS or nightly builds and for the nightly builds the release guide is quit clear that it must not be communicated beyond the dev-list. I read that as: a link on the websites of the project is forbidden. Well, all I can share is this (personal ;-)) bit of wisdom: Apache really is about *rough* consensus. And I've come to appreciate that it is a *good* thing. So no -- not every discussion will end in full 100% consensus, but rough consensus is good enough for most situations. But anyway... le tme phrase some scenarios and question: Let us assume httpd makes the release 2.4.10, a linux distributor takes the source, adapts them (for example security patches), compiles packages out of it and releases it as http://packages.ubuntu.com/vivid-updates/apache2-bin in source and binary form. Then it means they took a release and made their own release out of it, while using the apache name. Correct. At that point it constitutes a derived work. The Apache License is very permissive that way, but it is considered a good practice to distinguish the derived work by at leas a version ID. That is also, how all of the Hadoop ecosystem vendors are creating dervived works when they distribute Apache Hadoop as part of their products. E.g. the version string of Cloudera's Hadoop is: ASF_VERSION-CDH_VERSION. This is in line with most of the Linux packaging guidelines as well. the difference is that in Ubuntu I do for example: sudo apt-get install apache2 that's it. No mentioning of a derived version in this at all. apache2 is the package name, something like 2.4.10-9ubuntu1.1 only a version string, which is maybe not looked at by the user. Well, long time ago most Linux distributions seems to have agreed that it is good enough of a differentiator. In fact, I remember at around '98 there was a big outcry from the GCC community around the fact that some patches added by RH broke it in subtle ways AND the user feedback flowed to the GCC MLs not the RH MLs. IIRC that triggered quite a bit of discussion, but in the end -- the package is still called gcc. This, by the way, raises a very important question: for an open *source* foundation what artifacts can reasonably be considered covered by the brand? Obviously the source release: you can't change the source and still call it the same name without the consent of the PMC. Obviously logos and marks: you can't take a Hadoop elephant and use it for your ElephantFS project (although my understanding is that you *can* actually use it as a logo for your zoo). Both of these are clear cut, because the artifacts themselves are clear cut: source is a source and logo is a logo. But what is a Binary? The only hint at what it is defined as comes courtesy of how ALv2 defines an Object: ||| Object form shall mean any form resulting from mechanical ||| transformation or translation of a Source form, including but ||| not limited to compiled object code, generated documentation, ||| and conversions to other media types. And with that 'but not limited to' things get *really* murky. Consider, for example, you taking the C source of httpd and feeding it to emscripten LLVM compiler. You get an 'executable' which happens to be a bunch of Java Script (it runs just fine in your browser AND if you're really masochistic you can even read it as a source). Is this a object or a derivate work? I'd argue it is an object/binary, but I'm not sure. My only point is this: while it is easy to understand what source is, we kind of have to accept the fact that object/binary is literally *anything* that resulted from a mechanical transformation. The potential set of artifacts that would qualify as a binary is, literally, infinite.
Re: What is the legal basis for enforcing release policies at ASF?
On Thu, Aug 6, 2015 at 7:50 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: Hi! while answering a question on release policies and ALv2 I've suddenly realized that I really don't know what is the legal basis for enforcing release policies we've got documented over here: http://www.apache.org/dev/release.html For example, what would be the legal basis for stopping a 3d party from releasing a snapshot of ASF's project source tree and claim it to be a release X.Y.Z of said project? Nothing other than the Trademarks. If someone wants to call httpd trunk 3.0.1-GA, they cannot do this as Apache httpd 3.0.1-GA or Apache HTTP Server 3.0.1-GA. They can certainly release trunk under the AL license and call it Kindred Http Server 3.0.1-GA, based on Apache HTTP Server. That is a statement of fact and not an abuse of the mark, IMHO. (If it was not actually based on Apache HTTP Server, then that would similarly be a Trademark infringement as it is a false use of the mark.) There are no less than two marks, one is the name of the foundation itself in conjunction with Open Source Software, and the other is the specific project name.
Re: apache binary distributions
On Thu, Aug 6, 2015 at 1:15 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 06.08.2015 02:43, schrieb Roman Shaposhnik: [...] As you probably remember we've discussed this issue not that long time ago: http://thread.gmane.org/gmane.comp.apache.incubator.general/49852 The consensus there is that as long as you're communicating intent clearly you can let downstream developers test/develop against your development artifacts. IOW, the definition of developers starts including downstream developers integrating with your project. yes, I remember that discussion, but for me the outcome is not as clear as it is for you it seems. Especially with regards to communicating that intend and if it has to go through the release voting cycle. You usually don't do that for SNAPSHOTS or nightly builds and for the nightly builds the release guide is quit clear that it must not be communicated beyond the dev-list. I read that as: a link on the websites of the project is forbidden. Well, all I can share is this (personal ;-)) bit of wisdom: Apache really is about *rough* consensus. And I've come to appreciate that it is a *good* thing. So no -- not every discussion will end in full 100% consensus, but rough consensus is good enough for most situations. But anyway... le tme phrase some scenarios and question: Let us assume httpd makes the release 2.4.10, a linux distributor takes the source, adapts them (for example security patches), compiles packages out of it and releases it as http://packages.ubuntu.com/vivid-updates/apache2-bin in source and binary form. Then it means they took a release and made their own release out of it, while using the apache name. Correct. At that point it constitutes a derived work. The Apache License is very permissive that way, but it is considered a good practice to distinguish the derived work by at leas a version ID. That is also, how all of the Hadoop ecosystem vendors are creating dervived works when they distribute Apache Hadoop as part of their products. E.g. the version string of Cloudera's Hadoop is: ASF_VERSION-CDH_VERSION. This is in line with most of the Linux packaging guidelines as well. the difference is that in Ubuntu I do for example: sudo apt-get install apache2 that's it. No mentioning of a derived version in this at all. apache2 is the package name, something like 2.4.10-9ubuntu1.1 only a version string, which is maybe not looked at by the user. Well, long time ago most Linux distributions seems to have agreed that it is good enough of a differentiator. In fact, I remember at around '98 there was a big outcry from the GCC community around the fact that some patches added by RH broke it in subtle ways AND the user feedback flowed to the GCC MLs not the RH MLs. IIRC that triggered quite a bit of discussion, but in the end -- the package is still called gcc. This, by the way, raises a very important question: for an open *source* foundation what artifacts can reasonably be considered covered by the brand? Obviously the source release: you can't change the source and still call it the same name without the consent of the PMC. Obviously logos and marks: you can't take a Hadoop elephant and use it for your ElephantFS project (although my understanding is that you *can* actually use it as a logo for your zoo). Both of these are clear cut, because the artifacts themselves are clear cut: source is a source and logo is a logo. But what is a Binary? The only hint at what it is defined as comes courtesy of how ALv2 defines an Object: ||| Object form shall mean any form resulting from mechanical ||| transformation or translation of a Source form, including but ||| not limited to compiled object code, generated documentation, ||| and conversions to other media types. And with that 'but not limited to' things get *really* murky. Consider, for example, you taking the C source of httpd and feeding it to emscripten LLVM compiler. You get an 'executable' which happens to be a bunch of Java Script (it runs just fine in your browser AND if you're really masochistic you can even read it as a source). Is this a object or a derivate work? I'd argue it is an object/binary, but I'm not sure. My only point is this: while it is easy to understand what source is, we kind of have to accept the fact that object/binary is literally *anything* that resulted from a mechanical transformation. The potential set of artifacts that would qualify as a binary is, literally, infinite. So now, we come to the real question at hand: is Apache Brand meant to protect *any* possible object/binary artifact or only those that PMC actually care about? IOW, to be protected, does the artifact have to be produced by the PMC first (and then it gets protection) or this protection extends to a [potentially unlimited] number of hypothetical artifacts that could be produced when a 'mechanical translation' is applied to the source? I don't know the
What is the legal basis for enforcing release policies at ASF?
Hi! while answering a question on release policies and ALv2 I've suddenly realized that I really don't know what is the legal basis for enforcing release policies we've got documented over here: http://www.apache.org/dev/release.html For example, what would be the legal basis for stopping a 3d party from releasing a snapshot of ASF's project source tree and claim it to be a release X.Y.Z of said project? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings and the ASF maturity model (was: Reform of Incubator...)
Of course there are... CD40 - podlings may not have this prior to coming ASF, hence the full history might not be available. RE40 - interesting clause in itself, both the can be and the caveat in it no guarantee. IMHO, shouldn't be there at all. QU20 - Highly subjective as noted in footnote 7, and every project would need to examine a reasonable level of security awareness and response strategy, and often there will be varying opinions on what is appropriate. QU40 - That is mostly a function of how popular a project is, and how the project's code is intended to be used. QU50 - How do you check list-ticking the strive to qualifier? CO70 - another strive to... CS50 - a funny one, actually two... Mailing lists are not spelled out, and in theory YouTube videos and response videos could serve as asynchronous channel. Also, it doesn't mention that such channel needs to be provided by ASF infrastructure. IN10/IN20 - I claim that many projects would fail if all companies decided to pull their man-power support away. I happen to think it is relatively good, as that provides use-cases and requirements, but the agendas are there under the surface, and it should be recognized as a fact, rather than pretending it isn't. So, the maturity model shouldn't be a set of gating criteria, but that the podling should self-assess its position and to what degree, as well as how, each point is handled. Yes, many of the points are non-negotiable, but don't claim that all are... And if it is gating criteria for becoming a TLP, then likewise it should be a reversed gating criteria for going to Attic. Cheers Niclas On Thu, Aug 6, 2015 at 8:01 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Wed, Aug 5, 2015 at 12:43 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Wed, Aug 5, 2015 at 12:24 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: ...I understand the maturity model to be something to aspire to and that Apache Projects will always be working toward it. I mean TLPs, not podlings, although podlings should be aware of it and also aspire to it... I don't see why podlings should be different here, once they are about to graduate. Why can't we define our incubation process as a way for podlings to learn to operate according to that maturity model [1]? This would allow us to use the maturity model [1] as a checklist for graduating podlings - do you see anything in there that shouldn't be required from a podling that's about to graduate? I see it as a useful checklist that may uncover interesting issues within the graduating podling. I don't see anything in there that would qualify as an unambiguous gating criteria. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
Re: Welcome Heath Alexander Mattmann!
Hello, Jochen, my exuberant friend... On Thu, Aug 6, 2015 at 4:47 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: Forwarding to general@incubator, where it is obviously on-topic. You're drunk and shouting from the rooftops, dude! I'm thrilled for Chris (a past Incubator Mentor of mine, too) and family, but general@incubator is a high-traffic list with a large subcribership... no baby announcements here please! Come on, let's go back inside and party... Marvin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Fwd: Welcome Heath Alexander Mattmann!
Forwarding to general@incubator, where it is obviously on-topic. -- Forwarded message -- From: Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov Date: Wed, Aug 5, 2015 at 8:30 PM Subject: Welcome Heath Alexander Mattmann! To: memb...@apache.org memb...@apache.org Hi Everyone, Heath Alexander Mattmann (HAM) was born July 24, 2015 at 4:22am 7lbs 2 oz! Mommy and son are doing great, as are daddy and brother CJ :) Here are a few pics: http://min.us/mn5DX6JkUmGAv Cheers, Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ -- Any world that can produce the Taj Mahal, William Shakespeare, and Stripe toothpaste can't be all bad. (C.R. MacNamara, One Two Three) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings and the ASF maturity model (was: Reform of Incubator...)
On Thursday, August 6, 2015, Dennis E. Hamilton dennis.hamil...@acm.org wrote: +1 with the understanding that there is the usual flexibility between policies and practices, consistent with the spirit and principles of the ASF for Apache Projects. And, to be fair, I think TLPs should also self-assess on a periodic basis as an accountability of the PMC, nudged as necessary by the Chair (not to do it as much as to direct the PMCs eyes to the ball). I do not understand why the initative should come from the Chair, the chair is just an ordinary PMC member with a added responsibility to the board. The Chair cannot and should not be able to nudge more than any other PMC. rgds jan i. I can also imagine the maturity model items being used on an exception basis, only reporting maturity-model deviations and how they are being addressed as part of a report to the Board. - Dennis -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org javascript:;] Sent: Thursday, August 6, 2015 00:28 To: Incubator General general@incubator.apache.org javascript:; Subject: Re: Podlings and the ASF maturity model (was: Reform of Incubator...) On Thu, Aug 6, 2015 at 8:46 AM, Niclas Hedhman nic...@hedhman.org javascript:; wrote: ...the maturity model shouldn't be a set of gating criteria, but that the podling should self-assess its position and to what degree, as well as how, each point is handled. Yes, many of the points are non-negotiable, but don't claim that all are... So you would see the maturity model as one element of the Incubation graduating checklist, with self-assessment from the podling and its mentors? I like the idea. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org javascript:; For additional commands, e-mail: general-h...@incubator.apache.org javascript:; -- Sent from My iPad, sorry for any misspellings.
Re: apache binary distributions
On Wed, Aug 5, 2015 at 11:14 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Wed, Aug 5, 2015 at 5:44 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: Let us put that last part a step up... Let us assume someone takes one of the released sources of one of the java projects out there, makes maven artifacts out of it and publishes them at maven central. Is that ok? I mean that is very near the distributor case, so it should be ok, or not? That is fine. Just make sure that the published org is NOT org.apache.foo What do you mean by publishing org in the context of the Maven Central? Group id is what I meant. This and Ralph's comment make perfect sense. Thanks for clarifying! Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: third party tooling.
On Thu, Aug 6, 2015 at 2:12 AM, Greg Stein gst...@gmail.com wrote: On Thu, Aug 6, 2015 at 2:25 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: ...you can call yourself open source software all you want, but unless you get an exception from Fedora Packaging Committee you are not open enough for the distribution to consider your work... But that's doesn't make your project invalid or useless. Right. I don't know where you're coming from Roman, but the Foundation doesn't require our projects to be built via bootsrappable [sic] from source using *only* open source software binaries as the input. Never has, never will. So to Jan's original question: totally fine, no issues with compiler dependencies for certain platforms. We're in total agreement. I was just articulating a principle that increases downstream consumption of our projects, but in no way was trying to position that principle as part of the policy. Our software is defined by ALv2 and the Category licenses for dependencies. We are Open Source by the OSI definition, and any reasonable person's definition. If Fedora believes otherwise, then they better pony up a reason why. I can't believe they think ASF software is not Open Source, so I don't know where you're going with that. Lets not get ahead of ourselves, shall we? ;-) Everything I said in this thread is *my* opinion on what an ultimate definition of open source project must include (or at least recommend). Fedora has a set of principles around what they include in a distro. These are different. What I was saying is that their packaging principle actually makes sense to me as part of the OSI definition. As to the reason why I feel this is a fundamental feature of a true open source project -- we can discuss that in a different thread. I do feel pretty strongly about that. 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 Thu, Aug 6, 2015 at 1:29 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 06.08.2015 08:22, schrieb Niclas Hedhman: On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: I honestly see no problem with that, again provided that the artifact can NOT be confused with the one coming from Apache project. I think the problem lies in Trademarks. Debian's Tomcat7 is labeled Servlet and JSP engine and its Tomcat8 is labeled Apache Tomcat 8 - Servlet and JSP engine, yet I don't see Apache Tomcat project creating/maintaining a Debian dist. Now, is Debian allowed to call it Tomcat? Is it allowed to call Tomcat8 to BE Apache Tomcat8, when in fact(!) there are changes to the source, such as the start script in Debian Tomcat is not original of Apache Tomcat, but instead follows a Debian template for how those scripts should be written. I am not sure what all the changes are, feel free to check; http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches IF (like Mozilla) Apache decides to strike down on Debian and not allowing it to use the same names, _I_ think it is a disservice to the users (IceWeasel browser), but as it stands, Apache trademark licensing seems to not really be followed (Perhaps Debian has some permission that was granted long in the past... I may have missed that). I think there is nothing in the apache license 2 forbidding the usage of the project name or even apache (version 1.1 and 1 have been different and did indeed require a permission). The trademark weapon is more one of last resort. For example to go against false releases with malicious code added and the distributor not willing to take it of the web. At least I hope no-one has some crazy idea as that ;) Once again: this has *nothing* to do with the code (and only code is covered by ALv2) and everything to do with brand management policy. You can take Groovy source code and build Jochenoovy without any problem whatsoever, the issue is when *you* not the PMC want to build Groovy and start distributing it in parallel with the actual artifact. Thanks, Roman. P.S. As a tangent, I must point out that this dichotomy is precisely why I've always been skeptical about our collective ability to meaningfully manage binary artifacts. With binaries branding considerations become super important and I haven't seen much success around OSS foundations with striking that perfect balance between not diluting the brand AND considering the needs of downstream packagers. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: third party tooling.
On Thu, Aug 6, 2015 at 12:25 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: ...you can call yourself open source software all you want, but unless you get an exception from Fedora Packaging Committee you are not open enough for the distribution to consider your work... But that's doesn't make your project invalid or useless. Let me put it this way: it makes it *less* useful. Take being part of a Linux distro -- if your project can't be delivered via that channel it is by definition reaches less people, hence it is less useful. But to Greg's point -- this is a tangent to this discussion of ASF policies. I was putting forward a principle that, in general, increases the downstream consumption of the projects coming from the foundation. It is a good principle, but in no way it is part of the policy. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: third party tooling.
I want to come back to the question about the dependency of a source release on third-party tooling to be built. There is some sort of principle involved when it comes to how others can build the source easily, even if only to confirm that it builds and operates. I would not want to see an Apache release that provides building on a significant explicitly-targeted platform exclusively via expensive commercial tools as the only means for directly confirming builds by an user of the release, a volunteer tester, some-one verifying the build, etc. I don't believe that is necessary for any project that I am aware of. In the odd case of Visual Studio, mentioned in the original question, I think the danger is that the developers will use a Professional or more-expensive version and not confirm that a free version is readily available and can be sufficient to accomplish all of the builds by limiting their development to use of the free version or at least confirming that the free version will build it. I would think that this is in the spirit of maturity-model clause CD30's widely available standard tools. I would question any unnecessary dependence on tools that are a barrier to use by casual users and volunteer developers. - Dennis MUSINGS I see no reason that a podling with a small, new initial code base could rely on freely available tools, providing portable source code that can be easily built on and for different platforms by including platform-abstraction layers that suit that project's purposes and that otherwise satisfy requirements for Apache releases. TLPs, such as Apache OpenOffice, where Microsoft Windows is a crucial target platform, have greater difficulty when the project-specified versions of the Visual C++ compiler and essential platform libraries (including redistributable run-time) predate the current comprehensive, freely-available versions. This is a different challenge with historical origins in a legacy code base. -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Thursday, August 6, 2015 02:13 To: general@incubator.apache.org; ro...@shaposhnik.org Subject: Re: third party tooling. On Thu, Aug 6, 2015 at 2:25 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: ...you can call yourself open source software all you want, but unless you get an exception from Fedora Packaging Committee you are not open enough for the distribution to consider your work... But that's doesn't make your project invalid or useless. Right. I don't know where you're coming from Roman, but the Foundation doesn't require our projects to be built via bootsrappable [sic] from source using *only* open source software binaries as the input. Never has, never will. So to Jan's original question: totally fine, no issues with compiler dependencies for certain platforms. Our software is defined by ALv2 and the Category licenses for dependencies. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Podlings and the ASF maturity model (was: Reform of Incubator...)
+1 with the understanding that there is the usual flexibility between policies and practices, consistent with the spirit and principles of the ASF for Apache Projects. And, to be fair, I think TLPs should also self-assess on a periodic basis as an accountability of the PMC, nudged as necessary by the Chair (not to do it as much as to direct the PMCs eyes to the ball). I can also imagine the maturity model items being used on an exception basis, only reporting maturity-model deviations and how they are being addressed as part of a report to the Board. - Dennis -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Thursday, August 6, 2015 00:28 To: Incubator General general@incubator.apache.org Subject: Re: Podlings and the ASF maturity model (was: Reform of Incubator...) On Thu, Aug 6, 2015 at 8:46 AM, Niclas Hedhman nic...@hedhman.org wrote: ...the maturity model shouldn't be a set of gating criteria, but that the podling should self-assess its position and to what degree, as well as how, each point is handled. Yes, many of the points are non-negotiable, but don't claim that all are... So you would see the maturity model as one element of the Incubation graduating checklist, with self-assessment from the podling and its mentors? I like the idea. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - 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 5, 2015 at 11:22 PM, Niclas Hedhman nic...@hedhman.org wrote: On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: I honestly see no problem with that, again provided that the artifact can NOT be confused with the one coming from Apache project. I think the problem lies in Trademarks. As always ;-) This is actually the subtle point that Jochen seems to be missing: the ALv2 allows a lot of things that do not necessarily translate into how ASF manages brands of its projects. The two are separate. Debian's Tomcat7 is labeled Servlet and JSP engine and its Tomcat8 is labeled Apache Tomcat 8 - Servlet and JSP engine, yet I don't see Apache Tomcat project creating/maintaining a Debian dist. Correct. And with Linux distros the very notion of the artifact gets blurry so much so that pretty much everything they do starts looking like a derived work. That's why I like to focus on Maven artifacts since they are much easier to discuss in the context of not infringing on ASF brands. Now, is Debian allowed to call it Tomcat? Is it allowed to call Tomcat8 to BE Apache Tomcat8, when in fact(!) there are changes to the source, such as the start script in Debian Tomcat is not original of Apache Tomcat, but instead follows a Debian template for how those scripts should be written. I am not sure what all the changes are, feel free to check; http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches *I* think it should be allowed to as long as the version ID is different. To me, the full handle for any software artifact always is NAME-VERSION. Linux distros take the same point of view and have this: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning IF (like Mozilla) Apache decides to strike down on Debian and not allowing it to use the same names, _I_ think it is a disservice to the users (IceWeasel browser), but as it stands, Apache trademark licensing seems to not really be followed (Perhaps Debian has some permission that was granted long in the past... I may have missed that). 100% agreeing with the above paragraph. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings and the ASF maturity model (was: Reform of Incubator...)
On Thu, Aug 6, 2015 at 12:28 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Aug 6, 2015 at 8:46 AM, Niclas Hedhman nic...@hedhman.org wrote: ...the maturity model shouldn't be a set of gating criteria, but that the podling should self-assess its position and to what degree, as well as how, each point is handled. Yes, many of the points are non-negotiable, but don't claim that all are... So you would see the maturity model as one element of the Incubation graduating checklist, with self-assessment from the podling and its mentors? I like the idea. +1. Would love to see it being practiced starting from the next podling who's about to graduate. 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
Am 06.08.2015 02:43, schrieb Roman Shaposhnik: [...] As you probably remember we've discussed this issue not that long time ago: http://thread.gmane.org/gmane.comp.apache.incubator.general/49852 The consensus there is that as long as you're communicating intent clearly you can let downstream developers test/develop against your development artifacts. IOW, the definition of developers starts including downstream developers integrating with your project. yes, I remember that discussion, but for me the outcome is not as clear as it is for you it seems. Especially with regards to communicating that intend and if it has to go through the release voting cycle. You usually don't do that for SNAPSHOTS or nightly builds and for the nightly builds the release guide is quit clear that it must not be communicated beyond the dev-list. I read that as: a link on the websites of the project is forbidden. But anyway... le tme phrase some scenarios and question: Let us assume httpd makes the release 2.4.10, a linux distributor takes the source, adapts them (for example security patches), compiles packages out of it and releases it as http://packages.ubuntu.com/vivid-updates/apache2-bin in source and binary form. Then it means they took a release and made their own release out of it, while using the apache name. Correct. At that point it constitutes a derived work. The Apache License is very permissive that way, but it is considered a good practice to distinguish the derived work by at leas a version ID. That is also, how all of the Hadoop ecosystem vendors are creating dervived works when they distribute Apache Hadoop as part of their products. E.g. the version string of Cloudera's Hadoop is: ASF_VERSION-CDH_VERSION. This is in line with most of the Linux packaging guidelines as well. the difference is that in Ubuntu I do for example: sudo apt-get install apache2 that's it. No mentioning of a derived version in this at all. apache2 is the package name, something like 2.4.10-9ubuntu1.1 only a version string, which is maybe not looked at by the user. The point being here, for the end-user this will be the official release, not what is found on the apache servers. Why is this ok? Because technically it is an artifact that is a derived work. Of course that makes a difference, but every version from version control is a derivative work. It was also mentioned here, that for example publishing snapshot builds to maven central is not allowed. This is where it gets tricky with our current policy. Personally I see absolutely no reason to NOT publish Maven artifacts as widely as possible provide that the version ID or name communicates the intent. It seems, however, that I'm in a minority here (although truth be told nobody has been able to communicate a convincing enough argument for why my approach may be dangerous to the foundation and/or Projects). Currently I read this thread as following... if a third party publishes a snapshot to bintray or wherever, there is not really a problem. But if the project does it, then it is. And if the third party is actually not a third party, but a contributor things get very very unclear. What would happen if a third party would do this? Is the project/apache required to do something about this? I mean if you read this: http://mail-archives.apache.org/mod_mbox/incubator-general/201506.mbox/%3CD1B01671.4EE90%25rvesse%40dotnetrdf.org%3E some even see nightly builds, not communicated beyond the dev-list on non-apache servers already as a problem. Third party is at complete liberty of doing so. Provide the artifact is marked in such a way that is can NOT be confused with an official ASF artifact (IOW it can be called a derived work). not to be confused with an official ASF artifact... that's the part I am trying to extend my understanding. For me it is an official ASF artifact, if I download it from an ASF server. But then I have to include mirrors. And hat simplified version is already a problem... if I give a maven version information on an ASF page, does this make the maven package automatically an official ASF artifact, even though the download itself is not from ASF infrastructure? Same for links for example to docker image distribution servers... or let's say a link to an ubuntu package. On the other hand you can put disclaimers on the pages stating they are not official... Then again nightly builds should be ok, if they will have the same disclaimer? Or is it ok if the nightly build comes from non-apache? If that is ok, then why does the release document not say this and is instead very strict about not promoting anything even beyond the dev-list? It does not make sense for me and I am going in circles here. Of course a third person would be someone unrelated to the project. So what they do is of lesser concern, unless they misuse things. But what if the person is ASF member, or contributor to that project, maybe even in the
Re: apache binary distributions
Am 06.08.2015 08:22, schrieb Niclas Hedhman: On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik ro...@shaposhnik.org wrote: I honestly see no problem with that, again provided that the artifact can NOT be confused with the one coming from Apache project. I think the problem lies in Trademarks. Debian's Tomcat7 is labeled Servlet and JSP engine and its Tomcat8 is labeled Apache Tomcat 8 - Servlet and JSP engine, yet I don't see Apache Tomcat project creating/maintaining a Debian dist. Now, is Debian allowed to call it Tomcat? Is it allowed to call Tomcat8 to BE Apache Tomcat8, when in fact(!) there are changes to the source, such as the start script in Debian Tomcat is not original of Apache Tomcat, but instead follows a Debian template for how those scripts should be written. I am not sure what all the changes are, feel free to check; http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches IF (like Mozilla) Apache decides to strike down on Debian and not allowing it to use the same names, _I_ think it is a disservice to the users (IceWeasel browser), but as it stands, Apache trademark licensing seems to not really be followed (Perhaps Debian has some permission that was granted long in the past... I may have missed that). I think there is nothing in the apache license 2 forbidding the usage of the project name or even apache (version 1.1 and 1 have been different and did indeed require a permission). The trademark weapon is more one of last resort. For example to go against false releases with malicious code added and the distributor not willing to take it of the web. At least I hope no-one has some crazy idea as that ;) bye blackdrag -- Jochen blackdrag Theodorou blog: http://blackdragsview.blogspot.com/ - 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 5, 2015 at 5:44 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: Let us put that last part a step up... Let us assume someone takes one of the released sources of one of the java projects out there, makes maven artifacts out of it and publishes them at maven central. Is that ok? I mean that is very near the distributor case, so it should be ok, or not? That is fine. Just make sure that the published org is NOT org.apache.foo What do you mean by publishing org in the context of the Maven Central? Group id is what I meant.
Re: Podlings and the ASF maturity model (was: Reform of Incubator...)
On Thu, Aug 6, 2015 at 8:46 AM, Niclas Hedhman nic...@hedhman.org wrote: ...the maturity model shouldn't be a set of gating criteria, but that the podling should self-assess its position and to what degree, as well as how, each point is handled. Yes, many of the points are non-negotiable, but don't claim that all are... So you would see the maturity model as one element of the Incubation graduating checklist, with self-assessment from the podling and its mentors? I like the idea. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
