Roman, That was a *really* long email.
Some general responses. 1) The concept of a brand covering some artifact doesn't come into play at all. Instead, there are two things that happen. The first is that the PMC approves releases which defines each such release as an Apache release. The second process is that the ASF controls the use of its trademarks. 2) Apache Approved releases are approved collections of software. The PMC approves artifacts containing known as releases and validates their contents with signatures so that consumers can verify this. Only approved releases should be referred to as Apache releases, but anybody else can make their own releases under any level of diligence that they would like to apply. This is well covered in the release policy: http://www.apache.org/dev/release.html#what 3) The control of the abstract concept of the brand is done via trademarks which is all about how the trademarked words and logos are used and has nothing much to do with content of releases and everything to do with control and possibility of confusion. 4) Inferentially, nobody should be saying that something is Apache Hadoop version 9915.3 because no release (see 2 above) has been approved by the PMC and thus that name (see 3 above) cannot be applied without confusing the consumer. Conversely, anybody can copy the bits comprising Zookeeper 3.4.5 source release anywhere they like and they can call those bits Zookeeper 3.4.5 precisely because the trademark owner (Apache) has said that this is permissible use of the trademark by approving the release. 5) Nominative uses as part of product names such as "X powered by Apache Y", "X based on Apache Y" and "X for Apache Y" have very long standing as permissible uses of the trademark "Apache Y". Happily, Apache policy roughly accords with this and you can likely get your IP lawyer to describe it in more detail. There really isn't much more that needs to be said about this since 2 and 3 are pretty much independent. On Thu, Aug 6, 2015 at 5:50 PM, 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. > > 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 answer to that question, but my bias is this: if we > assume the later position then we're behaving similar to what > patent trolls do. We're essentially saying: even though PMC is not > producing all those possible artifacts we will forbid such production > under the brand name (remember you can still produce an artifact > and call it something else). > > With that in mind, the only honest position on binaries that I could > see is this: any 3d party producing artifacts that qualify as an object > under the ALv2 terminology has the right to use the ASF brand > to refer to those artifacts (as a corollary, I really feel like ASF needs > to get out of the business of taking *any* official position on binary > convenience artifacts and start treating them as though they always > come from a 3d party). > > All of the above, of course, is just my opinion. Not an ASF policy. > > >>> 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. > > This is yet another area where things get blurry. The way I see it is > this: between > official source releases the source code base exists in a bit of a > weird state. On > one hand, from an ALv2 license perspective a source is: > > ||| "Source" form shall mean the preferred form for making modifications, > ||| including but not limited to software source code, documentation > ||| source, and configuration files. > > which makes me believe that the license treats Source as a means to > an end of defining one type of work: > > ||| "Work" shall mean the work of authorship, whether in Source or > ||| Object form, made available under the License, as indicated by a > ||| copyright notice that is included in or attached to the work > ||| (an example is provided in the Appendix below). > > The part that says 'made available under the License' makes me think > that source becomes work when it is 'made available'. Surprisingly > I can't find anything in the license that would clarify who's authorized > to make work available. We all assume it must be a PMC, but the > licensed doesn't seem to support that view. > > The assumption that you're making is a reasonable one: only PMC is > authorized to make work available (which will mean that everything > else is derived work). That said, I'd appreciate if somebody can > point out to me the basis on which we make an assertion that > only PMC is authorized to produce releases of apache projects. > > >>> 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... > > Sure, but I think the relationship is the other way around. It is true that > ASF servers that distribute source releases are reliable providers > of official ASF artifacts. However, there are other sources as well. > Anything > that matches a hash taken from a release constitutes an official artifact > regardless of whether it came from. IOW, PMCs are in business of > designating certain source artifact (typically via hashes) as official. > > > 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? > > PMCs have an ability to designate certain binary convenience artifacts > as corresponding to a particular source release. That includes Maven. > I see no problem with following the same guidelines as for source > and using hashes to designate what constitutes and official binary > release. > > Once again -- 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. > > > 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 PMC? For example... assuming I would provide > > snapshot of Groovy on an external server and the web page > > mentions how to get this with a disclaimer, would that be ok? > > Even if it is a nightly build? > > As I said -- that person(*) (even a PMC member of the project) as > a person has even more rights than a PMC does, except in one > crucial area -- that person can NOT speak on behalf of the project > (and that includes linking to that person's artifacts from the PMC > managed assets: website, wiki, etc.). > > Other than that, that person is absolutely free to: > #1 produce maven binaries based on, really anything, > including but not limited to snapshot of source tree > #2 distribute those binaries however he/she sees fit > provided they can't be confused with project's binaries. > Modifying versionID while leaving everything else > as-is is considered acceptable. > > #2 of course may be subject to constraints of distribution > channel. An example is a recently cited Maven Central > policy where they are NOT allowing to publish SNAPSHOTs > AND they only allow owners of the groupID to publish. > Those constraints, of course, have nothing to do with > ASF or the project -- those are Maven Central constraints. > > Thanks, > Roman. > > (*) as all of us living in US know: corporations are people too. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
