subject:"Re\: apache binary distributions"

Please read all the emails in a thread before responding. Nuff said.

Sent from my iPhone

 On Aug 28, 2015, at 6:19 PM, Dennis E. Hamilton dennis.hamil...@acm.org 
 wrote:
 
 Dave, please bring specific, concrete details of alleged ASF Trademark abuse 
 by The Document Foundation to the AOO PMC private list.  Alternatively, take 
 them privately to the trademarks@ a.o list and also get clarification on what 
 qualifies as trademark abuse.
 
 Please.
 
 This is not the place for such allegations.
 
 
 -Original Message-
 From: Dave Fisher [mailto:dave2w...@comcast.net] 
 Sent: Friday, August 28, 2015 16:21
 To: general@incubator.apache.org
 Subject: Re: apache binary distributions
 
 Our trademark is abused by LibreOffice. How do we find a policy where can get 
 Linux distributions near compliance.
 
 [ ... ]
 
 
 -
 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

2015-08-28 Thread David Nalley

/me notes the mixed public and private lists


 I.e. assume you're a developer or sysadmin who is *not* an Apache
 committer.  You know you need to get a software project management tool
 for the linux machines you maintain, and you've heard of something
 called Maven.

 - What is the actual process by which you'd find out how to get this
 software (i.e. you'd search for it), and how you'd actually install it?


If I wanted to install maven, I'd do:

yum install maven3

or

apt-get install maven



 - How would you normally detect if you're getting the original Maven
 software, versus some different software - either a different vendor's
 version, or perhaps a bogus version with adware in it, or perhaps some
 non-standard version that is apparently popular, but is *not* the
 default version used on your platform?

So some of this is choice.
By default your distribution is going to have package repositories
enabled for software the distribution packages.

So if the distribution packages the software, you presumably trust the
distribution to provide you with legitimate software. (if you can't
trust your kernel and things like binutils, why bother worrying about
anything else) The distributions sign their packages, and the package
management system verifies that signature prior to installation.

Third parties (to the distribution) may also provide package
repositories. Cassandra, for instance, does this. They have a debian
package repository for the various versions of Cassandra. You can
manually configure your system to access that package repository,
configure it to trust the published signing key, and then things like
'apt-get install cassandra' work, and you get cassandra from a third
party repository (in this case from the project itself)

Of course, anyone could setup a package repository - Shapeblue for
instance has done that for CloudStack - they run a package repository
and ship RPM and deb packages from it of Apache CloudStack.
http://www.shapeblue.com/packages/   How do you know they haven't
tampered with it or modified it heavily? You don't - they aren't
providing the source packages, so know way of knowing how they are
built.

--David



 * Separately: does anyone have links to any trademark/branding policy
 pages that common package managers have out there?  I'm wondering what
 policy or best practices that are *clearly documented* is already out
 there for the actual linux distros or package management systems is.


The only folks that I know of that have a policy explicitly dealing
with this is Mozilla. Their is a lot of drama within the distributions
about how this is/was handled.
https://www.mozilla.org/en-US/foundation/trademarks/policy/   (read
down to the software distribution section)

Essentially, Mozilla says that you may distribute your own compiled
version of their software, using their marks, only if it is built from
unaltered source. In practice this is a bit more difficult. Having
packaged software for Fedora and a few other distributions, it's not
uncommon to need to patch something. Sometimes it's environment
related (your stuff won't build with the latest glibc), sometimes it's
related to how things gets built. In Mozilla's case, they require
approval of any patches applied to source, before it's distributed.
Debian decided it was too much, and not free enough, and thus we have
Iceweasel and Icedove instead of Firefox and Thunderbird.

--David

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

Our trademark is abused by LibreOffice. How do we find a policy where can get 
Linux distributions near compliance.

Since LO rebased and declared a new license we can impute how much of that is 
really AL 2 via a diff. If the LO code is a nominal percent Apache OO then we 
say it is sufficient to be based on Apache. If they move below that percent 
then they are no longer compliant.

To stay compliant they can contribute upstream and help us have a source 
release that they can remain compliant against.

Essentially we use the trademark as a honey trap to stay relevant.

Purity will never happen.

Anyone that has a distro that is sufficiently close can then get a powered by 
use of the mark. If we can't do a binary for a platform then we can point users 
to all of the powered by binaries. The SVN model.

Sent from my iPhone

 On Aug 28, 2015, at 3:10 PM, Dennis E. Hamilton dennis.hamil...@acm.org 
 wrote:
 
 [Not cross-posting to a private list.]
 
 Dave,
 
 I don't exactly understand what it is expected that trademarks@ would be 
 doing or clarifying with regard to your specific Foo Manchu case.
 
 Please explain what you mean by a percentage.
 
 - Dennis
 
 PS: How do you see a case where the Manchu project makes nothing more than 
 nominative mentions of Foo and Foo is not used at all in the naming of the 
 Manchu product?  Are specific instances of the use of Foo in a manner that 
 would confuse Manchu with Foo what you have in mind for bringing to an Apache 
 Foo PMC?
 
 PPS: I assume we are talking about something other than how third parties use 
 and attribute ALv2 licensed code one way or another.  I'm not certain how 
 trademark enters there.  There is related discussion on legal-discuss, 
 however.
 
 -Original Message-
 From: Dave Fisher [mailto:dave2w...@comcast.net] 
 Sent: Friday, August 28, 2015 14:35
 To: general@incubator.apache.org
 Cc: tradema...@apache.org; stephen.alan.conno...@gmail.com
 Subject: Re: apache binary distributions
 
 Again mixed. Let's substitute a real case.
 
 Sent from my iPhone
 
 On Aug 28, 2015, at 6:21 AM, Shane Curcuru a...@shanecurcuru.org wrote:
 
 (Please note mixed private/public lists)
 
 On 8/25/15 5:17 PM, Stephen Connolly wrote:
 [ ... ]
 
 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.
 
 Foo = OpenOffice
 Manchu = LibreOffice
 
 This is the reality in Linuxland without the attribution. This has been going 
 on for sometime. I think since prior to Oracle's grant.
 
 Rolling that back should be a goal for the PMC.
 
 Maybe we diff the codebases and accept a percentage. This standard might the 
 encourage upstream contribution.
 
 I would like to formulate this idea for the AOO dev list. The above has 
 really helped me crystallize what I've been kicking around in my mind for 
 months and months.
 
 Thoughts before I take it there?
 
 I know I'm not following Shane's thoughts below. OpenOffice is uniquely 
 problematic.
 
 Regards,
 Dave
 
 [ ... ]
 
 
 -
 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

2015-08-28 Thread Dennis E. Hamilton

[Not cross-posting to a private list.]

Dave,

I don't exactly understand what it is expected that trademarks@ would be doing 
or clarifying with regard to your specific Foo Manchu case.

Please explain what you mean by a percentage.

 - Dennis

PS: How do you see a case where the Manchu project makes nothing more than 
nominative mentions of Foo and Foo is not used at all in the naming of the 
Manchu product?  Are specific instances of the use of Foo in a manner that 
would confuse Manchu with Foo what you have in mind for bringing to an Apache 
Foo PMC?

PPS: I assume we are talking about something other than how third parties use 
and attribute ALv2 licensed code one way or another.  I'm not certain how 
trademark enters there.  There is related discussion on legal-discuss, however.

-Original Message-
From: Dave Fisher [mailto:dave2w...@comcast.net] 
Sent: Friday, August 28, 2015 14:35
To: general@incubator.apache.org
Cc: tradema...@apache.org; stephen.alan.conno...@gmail.com
Subject: Re: apache binary distributions

Again mixed. Let's substitute a real case.

Sent from my iPhone

 On Aug 28, 2015, at 6:21 AM, Shane Curcuru a...@shanecurcuru.org wrote:
 
 (Please note mixed private/public lists)
 
 On 8/25/15 5:17 PM, Stephen Connolly wrote:
[ ... ]
 
 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.

Foo = OpenOffice
Manchu = LibreOffice

This is the reality in Linuxland without the attribution. This has been going 
on for sometime. I think since prior to Oracle's grant.

Rolling that back should be a goal for the PMC.

Maybe we diff the codebases and accept a percentage. This standard might the 
encourage upstream contribution.

I would like to formulate this idea for the AOO dev list. The above has really 
helped me crystallize what I've been kicking around in my mind for months and 
months.

Thoughts before I take it there?

I know I'm not following Shane's thoughts below. OpenOffice is uniquely 
problematic.

Regards,
Dave

[ ... ]


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

Again mixed. Let's substitute a real case.

Sent from my iPhone

 On Aug 28, 2015, at 6:21 AM, Shane Curcuru a...@shanecurcuru.org wrote:
 
 (Please note mixed private/public lists)
 
 On 8/25/15 5:17 PM, Stephen Connolly wrote:
 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.

Foo = OpenOffice
Manchu = LibreOffice

This is the reality in Linuxland without the attribution. This has been going 
on for sometime. I think since prior to Oracle's grant.

Rolling that back should be a goal for the PMC.

Maybe we diff the codebases and accept a percentage. This standard might the 
encourage upstream contribution.

I would like to formulate this idea for the AOO dev list. The above has really 
helped me crystallize what I've been kicking around in my mind for months and 
months.

Thoughts before I take it there?

I know I'm not following Shane's thoughts below. OpenOffice is uniquely 
problematic.

Regards,
Dave

 
 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)
 
 Correct.  For the ASF's purposes, if it is essentially unmodified
 software - or only modified in the normal and well-understood way to
 fit into that particular platform or distro - then we want the packager
 to use our actual product names.
 
 We definitely should ask for trademark attributions in descriptions or
 other well-known places.  The actual implementation and enforcement of
 that is a question that depends on the situation.  In many cases, if
 it's simple packaging that truly is just doing the right thing from our
 perspective, legal attribution probably isn't that big a deal.
 
 In particular, a lot of the importance depends on what a well-informed
 consumer would expect from that particular well-known packaging system.
 I.e. if the packager is doing what is normal and expected - even if
 that changes some of the software from our product - it's probably fine.
 
 
 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?
 
 Thanks for the excellent distillation of the technical aspects.  This is
 definitely a question we need to draft a clear policy for, so that we
 can have a consistent way we ask packagers to do things.
 
 Trademark law is well established for consumer products, but less so for
 highly technical software products and different ways that the products
 are offered to the public.  So I need a clear question to bring to
 counsel to get their perspective on what we should cover.
 
 The easiest way to see the applicability of trademarks is to provide a
 description of an end-users view of the process.  Could someone here
 come up with a description of the process that an end-user would go
 through when they're trying to get a specific Apache product using one
 of these methods?
 
 I.e. assume you're a developer or sysadmin who is *not* an Apache
 committer.  You know you need to get a software project management tool
 for the linux machines you maintain, and you've heard of something
 called Maven.
 
 - What is the actual process by which you'd find out how to get this
 software (i.e. you'd search for it), and how you'd actually install it?
 
 - How would you normally detect if you're getting the original Maven
 software, versus some different software - either a different vendor's
 version, or perhaps a bogus version with adware in it, or perhaps some
 non-standard version that is apparently popular, but is *not* the
 default version used on your platform?
 
 * Separately: does anyone have links to any trademark/branding policy
 pages that common package managers have out there?  I'm wondering what
 policy or best practices that are *clearly documented* is already

Re: apache binary distributions

Dennis this is now triple posted including one private list. I request you no 
longer contact me directly as I thought I was replying privately to our prior 
conversation and would have moderated some of my language. BTW what I wrote has 
NOTHING to do with the Incubator. I am sure the IPMC has zero interest in 
re-incubating OpenOffice.org.

Trademarks, legal-discuss tell me if the following idea is crazy. You can split 
the thread. Just say which you are replying on.

I'll note that this should go to the AOO dev list soon with an appropriate 
formulation as a proposal.

Regards,
Dave

Sent from my iPhone

 On Aug 28, 2015, at 4:21 PM, Dave Fisher dave2w...@comcast.net wrote:
 
 Our trademark is abused by LibreOffice.

Change this to misused in Linux distributions.

 How do we find a policy where can get Linux distributions near compliance.
 
 Since LO rebased and declared a new license we can impute how much of that is 
 really AL 2 via a diff. If the LO code is a nominal percent Apache OO then we 
 say it is sufficient to be based on Apache. If they move below that percent 
 then they are no longer compliant.
 
 To stay compliant they can contribute upstream and help us have a source 
 release that they can remain compliant against.
 
 Essentially we use the trademark as a honey trap to stay relevant.
 
 Purity will never happen.
 
 Anyone that has a distro that is sufficiently close can then get a powered 
 by use of the mark. If we can't do a binary for a platform then we can point 
 users to all of the powered by binaries. The SVN model.
 
 Sent from my iPhone
 
 On Aug 28, 2015, at 3:10 PM, Dennis E. Hamilton dennis.hamil...@acm.org 
 wrote:
 
 [Not cross-posting to a private list.]
 
 Dave,
 
 I don't exactly understand what it is expected that trademarks@ would be 
 doing or clarifying with regard to your specific Foo Manchu case.
 
 Please explain what you mean by a percentage.
 
 - Dennis
 
 PS: How do you see a case where the Manchu project makes nothing more than 
 nominative mentions of Foo and Foo is not used at all in the naming of the 
 Manchu product?  Are specific instances of the use of Foo in a manner that 
 would confuse Manchu with Foo what you have in mind for bringing to an 
 Apache Foo PMC?
 
 PPS: I assume we are talking about something other than how third parties 
 use and attribute ALv2 licensed code one way or another.  I'm not certain 
 how trademark enters there.  There is related discussion on legal-discuss, 
 however.
 
 -Original Message-
 From: Dave Fisher [mailto:dave2w...@comcast.net] 
 Sent: Friday, August 28, 2015 14:35
 To: general@incubator.apache.org
 Cc: tradema...@apache.org; stephen.alan.conno...@gmail.com
 Subject: Re: apache binary distributions
 
 Again mixed. Let's substitute a real case.
 
 Sent from my iPhone
 
 On Aug 28, 2015, at 6:21 AM, Shane Curcuru a...@shanecurcuru.org wrote:
 
 (Please note mixed private/public lists)
 
 On 8/25/15 5:17 PM, Stephen Connolly wrote:
 [ ... ]
 
 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.
 
 Foo = OpenOffice
 Manchu = LibreOffice
 
 This is the reality in Linuxland without the attribution. This has been 
 going on for sometime. I think since prior to Oracle's grant.
 
 Rolling that back should be a goal for the PMC.
 
 Maybe we diff the codebases and accept a percentage. This standard might the 
 encourage upstream contribution.
 
 I would like to formulate this idea for the AOO dev list. The above has 
 really helped me crystallize what I've been kicking around in my mind for 
 months and months.
 
 Thoughts before I take it there?
 
 I know I'm not following Shane's thoughts below. OpenOffice is uniquely 
 problematic.
 
 Regards,
 Dave
 
 [ ... ]
 
 
 -
 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
 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: apache binary distributions

2015-08-26 Thread Ross Gardler

Probably best to ask the specific question about brand on the trademarks@ list.

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Tuesday, August 25, 2015 11:52 AM
To: general@incubator.apache.org
Cc: Dennis Hamilton dennis.hamil...@acm.org
Subject: 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

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-25 Thread Roman Shaposhnik

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

2015-08-25 Thread Roman Shaposhnik

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: apache binary distributions

2015-08-25 Thread Stephen Connolly

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

Re: apache binary distributions

2015-08-22 Thread Mark Thomas

On 22/08/2015 04:37, Niclas Hedhman wrote:
Cool.
I can't find info on how much it costs ASF, any pointers before embarking
on 100+ artifact signing spree... ;-)

With my infra hat on...

The short answer is 'Don't worry about it and get signing.'

The longer answer is that if a project wants to use the signing service
then providing and paying for that service is infra's problem. As it
happens, the solution we have is such that we are confident we can
afford to sign every release of every project if necessary.

The cost to the ASF is not per artefact but per 'signing event'. A
signing event can consist of any number of artefacts.

Note that it is a signing event that gets a unique certificate and a
signing event is the smallest thing we can revoke.

Typically, it is one signing event per release but there cases where a
release needs 2 or 3 signing events. For example, Tomcat signs its
Windows installer and uninstaller. Th uninstaller is packaged in the
installer so we need one event to sign the uninstaller and then a second
to sign the installer package that contains the (now signed)
uninstaller. If Tomcat wanted to sign all the JARs we could sign them at
the same time we sign the uninstaller (with a little jigging about of
the build script) at no extra cost.

If a project thought it needed 10s of signing events per release then I
suspect there would need to be a conversation to see if that was really
the case or if the number could be reduced.

For more details see this:
http://people.apache.org/~markt/presentations/2015-04-15-Code%20Signing%20at%20the%20ASF.pdf

The exact costs are confidential but any ASF Member can look at the
quotes (we accepted the second one dated 19-08-2014) in the private
foundation repo (look under correspondence then Symantec).

I'll be at ApacheCon Core in Budapest if anyone wants to talk face to
face about this.

Mark

On Fri, Aug 21, 2015 at 12:35 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

On Thu, Aug 20, 2015 at 8:09 AM, Niclas Hedhman nic...@hedhman.org
wrote:

On Thu, Aug 20, 2015 at 1: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?

Good idea, but to be practical to users, the certificate for the signing
needs to be part of the certificate chain of the JVM (otherwise those
would
be needed to be installed on every host). I don't know how willing infra
would be to support PKI at ASF for this, otherwise many projects will be
limited due to cost (I could be wrong by now and that there are totally
free CAs)

That infrastructure now exists through code signing service by Symantec.
One PMC member (or more) gets their own unique log in, pushes the artifact
(.jar, in this example) to the service and is returned a signed artifact
reflecting the ASF providence.

The interesting thing is the actual cert is unique to the object, so if it
is discovered that it was compromised, the signature can be revoked (good
luck having sig revocations active at boot time, but otherwise this is
quite useful.) And because there is a history, we know who precisely
requested each object signing.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-21 Thread Niclas Hedhman

Cool.
I can't find info on how much it costs ASF, any pointers before embarking
on 100+ artifact signing spree... ;-)

On Fri, Aug 21, 2015 at 12:35 AM, William A Rowe Jr wr...@rowe-clan.net
wrote:

 On Thu, Aug 20, 2015 at 8:09 AM, Niclas Hedhman nic...@hedhman.org
 wrote:

  On Thu, Aug 20, 2015 at 1: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?
 
  Good idea, but to be practical to users, the certificate for the signing
  needs to be part of the certificate chain of the JVM (otherwise those
 would
  be needed to be installed on every host). I don't know how willing infra
  would be to support PKI at ASF for this, otherwise many projects will be
  limited due to cost (I could be wrong by now and that there are totally
  free CAs)
 

 That infrastructure now exists through code signing service by Symantec.
 One PMC member (or more) gets their own unique log in, pushes the artifact
 (.jar, in this example) to the service and is returned a signed artifact
 reflecting the ASF providence.

 The interesting thing is the actual cert is unique to the object, so if it
 is discovered that it was compromised, the signature can be revoked (good
 luck having sig revocations active at boot time, but otherwise this is
 quite useful.) And because there is a history, we know who precisely
 requested each object signing.




-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache binary distributions

2015-08-20 Thread Niclas Hedhman

On Thu, Aug 20, 2015 at 1: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?


Good idea, but to be practical to users, the certificate for the signing
needs to be part of the certificate chain of the JVM (otherwise those would
be needed to be installed on every host). I don't know how willing infra
would be to support PKI at ASF for this, otherwise many projects will be
limited due to cost (I could be wrong by now and that there are totally
free CAs)

Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: apache binary distributions

2015-08-20 Thread William A Rowe Jr

On Thu, Aug 20, 2015 at 8:09 AM, Niclas Hedhman nic...@hedhman.org wrote:

 On Thu, Aug 20, 2015 at 1: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?

 Good idea, but to be practical to users, the certificate for the signing
 needs to be part of the certificate chain of the JVM (otherwise those would
 be needed to be installed on every host). I don't know how willing infra
 would be to support PKI at ASF for this, otherwise many projects will be
 limited due to cost (I could be wrong by now and that there are totally
 free CAs)


That infrastructure now exists through code signing service by Symantec.
One PMC member (or more) gets their own unique log in, pushes the artifact
(.jar, in this example) to the service and is returned a signed artifact
reflecting the ASF providence.

The interesting thing is the actual cert is unique to the object, so if it
is discovered that it was compromised, the signature can be revoked (good
luck having sig revocations active at boot time, but otherwise this is
quite useful.) And because there is a history, we know who precisely
requested each object signing.

Re: apache binary distributions

2015-08-19 Thread Bertrand Delacretaz

On Wed, Aug 19, 2015 at 10:46 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 ...Well I actually have concerns about the maven that debian is publishing.
 There are some quite significant - in my view - deviations from our Maven.

 For me, the majority of the concerns could be addressed if they fix the
 *Description* to clarify that it is a modified distribution of Apache Maven
 *and* they add an ACK to the trademarks in the description of the package...

I agree that this would be a reasonable request.

OTOH I'm not sure about requesting a package name change, if I'm
getting maven from a Debian package library it's reasonable to
expect that that package has been built and assembled by Debian, as
it's their core business. But that would be a question for our
trademarks folks.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-19 Thread Jochen Theodorou


Am 18.08.2015 18:46, schrieb Marvin Humphrey:

On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen


So what if a project (members) does not vote but unofficially
releases binary executable packages, perhaps along with source to some
other location than /dist/? Clearly, it's not an official release by Apache
policy but there the bits are in the wild anyway.


At Apache, software that is published beyond the group that develops it must
be assembled, vetted and voted in accordance with Release Policy and
distributed in accordance with Release Distribution Policy.

   http://www.apache.org/dev/release
   http://www.apache.org/dev/release-distribution


does this extend to convenience binaries and binaries not produced by 
the project itself?... let's say for example a windows installer



Apache is deliberately decentralized in that technical decisions are
officially delegated to a PMC, but projects are still obligated to follow
Foundation policy with regards to project governance, IP diligence, etc.  A
primary function of the Incubator is to prepare projects to self-govern in
accordance with Apache policy and traditions.


And a project could choose to just tolerate this such binaries, right?
[...]

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

2015-08-19 Thread Ted Dunning



Sent from my iPhone

On Aug 19, 2015, at 1:46, Stephen Connolly stephen.alan.conno...@gmail.com 
wrote:

 
 Well I actually have concerns about the maven that debian is publishing.
 There are some quite significant - in my view - deviations from our Maven

Can you be specific?  Should you perhaps take this up with the maven pmc? Who 
should then contact Debian with concrete suggestions?
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-19 Thread Ted Dunning


There is a reason that these distributions are not called hadoop in the product 
name. There is no cloudera hadoop.  Nor MapR hadoop.  

It is a fine line to acknowledge provenance and give proper credit but not 
claim to be identical. 

On the other hand, hive and pig and zookeeper in the distributions are 
typically just repackaged apache releases.  I say generally, since there are 
exceptions in products competitive to MapR's (I work for MapR) which I am not 
fully knowledgable about. 

Sent from my iPhone

 On Aug 19, 2015, at 1:42, Niclas Hedhman nic...@hedhman.org wrote:
 
 That said, I think/suspect that if Cloudera Hadoop or Hortonworks
 Hadopo is published in this manner (official releases with minor changes
 to fit their bigger picture), there might be quite a lot of noise... Just
 asking... I have no strong opinion in either way, other than I would like
 to see consistency.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: apache binary distributions

2015-08-19 Thread Dennis E. Hamilton

A side matter that has not been raised here.

One reason for protecting a mark is to avoid losing it.

I have worked at two corporations that were necessarily aggressive in 
protecting the use of their marks: Univac in various incarnations and Xerox 
Corporation.

While Google might be happy to see the verbing of its mark, other trademark 
holders worry about the inappropriate use of their mark by others.  This is 
related to the confusion issue but it is about the mark *becoming* generic and 
no longer protected.

The famous case of this is apparently aspirin.  I suspect the makers of 
Kleenex tissues have similar concerns but can't do much about what the general 
public does.  

There are some hyper-active approaches that we know of, especially if your 
surname is McDonald, but nevertheless there are two reasons for careful use of 
a mark and requiring others to use it carefully: protecting the distinctiveness 
and protecting against confusion.

I have no information on recent cases and how the US Patent and Trademark folk 
rule on these things nowadays.

I suspect the guidelines that go with protecting an ASF-held mark to this 
degree is over the line on the fussiness side.  At the OSCON Apache Software 
Foundation booth, I repeatedly heard that I use Apache or I love Apache and 
it is easy to confirm that they mean the Apache HTTPD software (or whatever the 
fussy designation would be).  I don't see any guidance on how Apache project 
participants should employ the marks in their writing and speaking. 

The matter of harmful confusion, as gone into at length on this thread, is of 
course a judgment call as it would be if a claim of confusion were put before a 
judge [;), and it is all grey in the wide middle.

I think an useful case here would be whether users of Joe's Maven found that 
the Apache Maven project would not accept their incident reports and there no 
other recourse, users being led to believe that the Apache Maven project is 
responsible for the code that they are using.  If that is a pattern, that seems 
like a good trigger for having a heart-to-heart with the producer of Joe's 
Maven about clearing up the confusion.

 - Dennis


-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Wednesday, August 19, 2015 06:27
To: Incubator General general@incubator.apache.org
Subject: Re: apache binary distributions

On Wed, Aug 19, 2015 at 10:46 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 ...Well I actually have concerns about the maven that debian is publishing.
 There are some quite significant - in my view - deviations from our Maven.

 For me, the majority of the concerns could be addressed if they fix the
 *Description* to clarify that it is a modified distribution of Apache Maven
 *and* they add an ACK to the trademarks in the description of the package...

I agree that this would be a reasonable request.

OTOH I'm not sure about requesting a package name change, if I'm
getting maven from a Debian package library it's reasonable to
expect that that package has been built and assembled by Debian, as
it's their core business. But that would be a question for our
trademarks folks.

-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

2015-08-19 Thread William A Rowe Jr

On Wed, Aug 19, 2015 at 4:39 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 We could define a hierarchy of right to use the mark: pmc has ultimate
 right, if the pmc are not producing a packaging for that system then the
 developers of the packaging system have the right to define who can use the
 mark in relation to their packaging system only.


FWIW, the Foundation (board level) has the legal final authority, they
delegate this to the VP Trademarks, who shares that delegation with the
individual PMCs to adapt to each of their own unique circumstances.

At no time do we state that others creating a binary from our released
tarball/source is infringing our mark, if the result of what they built is
limited to ASF sources - not extended or patched in a 'significant way'.
PMC's must determine what is significant in this context... if someone
patched httpd for 128 bit int sizes, that PMC would probably shrug (and
work out the right patch upstream.) Any PMC distributing sources for a .jar
are likely to flip out over modifying the public API's, and rightfully so.
And we've noted here, many ASF project builds allow various things to be
toggled-in/toggled-out. Clear labeling is a good way to avoid a PMC
objecting to the use of the mark.

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? Because only the ASF committers sign code as the ASF under the
authority of the PMC, there is no concern about that .jar being a
third-party component. Users could still build that .jar, because we give
them the sources, on purpose, to deliberately do that.

With few exceptions, downstream is very easy to work with when the PMC
addresses their concerns clearly and politely.


 The aim here would be to make our software available easily in different
 packaging systems. The pmc may want to take ownership of popular packaging
 systems, so we'd need to be able to trump others


Keep in mind, every package distributor has their own policy for who gets
naming priority. It can be helpful to point out that the ASF owns the mark,
and should generally have priority, but the politics of the thing is that
individual contributors to each package distributor have to earn their
karma, just as we require here at the ASF. A signed vs. and unsigned build
may also carry weight in those discussions.

Re: apache binary distributions

We could define a hierarchy of right to use the mark: pmc has ultimate
right, if the pmc are not producing a packaging for that system then the
developers of the packaging system have the right to define who can use the
mark in relation to their packaging system only.

The aim here would be to make our software available easily in different
packaging systems. The pmc may want to take ownership of popular packaging
systems, so we'd need to be able to trump others
On Wed 19 Aug 2015 at 10:27, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 I might add also that our integration tests should pass for patched
 releases (if you want to call the package maven)

 Let's take this straw man out for a walk:

 Microsoft produce a maven.msi and it is available for download on a page
 called how to get maven on the Microsoft website. The installer's first
 screen says clearly that this is microsoft's build of Apache maven and
 our marks are ack on the first screen.

 Is that ok?
 On Wed 19 Aug 2015 at 10:03, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 Perhaps, the maven pmc could decree: if you are making a convenience
 installer of maven for an OS where the maven pmc does not create a
 convenience installer, you may use maven as the packaging name provided
 the description clarifies it is a custom build and provides an ack of our
 marks. Also the version number is different if patches have been applied.

 Would that be an acceptable defence of our mark?

 On Wed 19 Aug 2015 at 09:46, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest
 of the
  PMC, I may not call it Maven. If I did call it Maven then the
 remainder of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


 Well I actually have concerns about the maven that debian is
 publishing. There are some quite significant - in my view - deviations from
 our Maven.

 For me, the majority of the concerns could be addressed if they fix the
 *Description* to clarify that it is a modified distribution of Apache Maven
 *and* they add an ACK to the trademarks in the description of the package.

 The open question remains, is the *Package Name* a name that could be
 viewed as use of the trademark?

 Do the end users - i.e. developers - expect that `apt-get install maven`
 is installing Apache Maven? If they are junior developers my experience
 suggest they may think so...

 So if `apt-get install maven` causes confusion with our brand, we may
 have to ask Debian what they suggest they could do to remove the confusion.

 There are simple solutions, e.g. change the package name to mvn; stop
 making such large sweeping changes to our product; etc

 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.

 This gets even more confusing with some of their packaged maven plugins,
 which for interop need to use maven:
 http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
  (more
 obvious with Fedora:
 http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
 Thankfully in these cases I believe the source code is not patched, but it
 is binaries rebuilt from source not pulled down from Maven Central... which
 can cause issues for users.

 Fun Fun Fun




 Niclas

Re: apache binary distributions

2015-08-19 Thread Niclas Hedhman

I was indeed talking of publishing the original material, released properly
from Apache but with some minor changes to fit into the SteveNick
Platform (whatever that might be). I think that is analogous...

So, if we agree that is all the same... minor alterations of official
releases

That said, I think/suspect that if Cloudera Hadoop or Hortonworks
Hadopo is published in this manner (official releases with minor changes
to fit their bigger picture), there might be quite a lot of noise... Just
asking... I have no strong opinion in either way, other than I would like
to see consistency.

Cheers
Niclas


On Wed, Aug 19, 2015 at 1:15 PM, Marvin Humphrey mar...@rectangular.com
wrote:

 On Tue, Aug 18, 2015 at 6:46 PM, Niclas Hedhman nic...@hedhman.org
 wrote:

  Well, if  Debian can publish their built Apache Maven as maven and
  SteveNick can't publish their built Apache Maven as maven, then the
  inescapable question is; On what non-arbitrary grounds is one acceptable
  and the other is not? It can't be we like Debian, but not SteveNick,
  that is morally weak.

 We need to distinguish between two situations:

 *   Redistributor starts from official Apache release.
 *   Redistributor starts from unreleased code.

 Debian consumes official Apache releases, and they make changes that are
 often very small.  Whether we should be aggressive in enforcing our
 trademarks
 under those circumstances is a judgment call.  Should SteveNick also
 start
 from an official release and make changes of similar scope to those made by
 Debian, I would agree that the case for enforcing our trademarks would be
 roughly analogous.

 However, if SteveNick are Apache project contributors publishing
 unreleased
 code and making an end run around Apache release policy, there's greater
 cause
 for concern.

 *   Are other PMC members being denied their right to participate in
 release
 decision making?
 *   To what extent does the privileged position afforded SteveNick
 undermine project independence?
 *   While our communities strive to maintain codebases in compliance with
 Apache legal and release policies, we accept that raw repository code
 may
 be imperfect between releases.  Just how far out of compliance is the
 unreleased code SteveNick are publishing under our trademark?
 *   To what extent is the 501(c)(3) status of the Foundation put at
 increased risk by the actions of this project?  What if the practices
 spread to other projects?

 If Debian were to systematically consume unreleased code from us (aside
 from
 patches they've contributed themselves), I imagine we would have similar
 concerns.  But that seems like a weird theoretical.

 Marvin Humphrey

 -
 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: apache binary distributions

I might add also that our integration tests should pass for patched
releases (if you want to call the package maven)

Let's take this straw man out for a walk:

Microsoft produce a maven.msi and it is available for download on a page
called how to get maven on the Microsoft website. The installer's first
screen says clearly that this is microsoft's build of Apache maven and
our marks are ack on the first screen.

Is that ok?
On Wed 19 Aug 2015 at 10:03, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Perhaps, the maven pmc could decree: if you are making a convenience
 installer of maven for an OS where the maven pmc does not create a
 convenience installer, you may use maven as the packaging name provided
 the description clarifies it is a custom build and provides an ack of our
 marks. Also the version number is different if patches have been applied.

 Would that be an acceptable defence of our mark?

 On Wed 19 Aug 2015 at 09:46, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest of
 the
  PMC, I may not call it Maven. If I did call it Maven then the
 remainder of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


 Well I actually have concerns about the maven that debian is
 publishing. There are some quite significant - in my view - deviations from
 our Maven.

 For me, the majority of the concerns could be addressed if they fix the
 *Description* to clarify that it is a modified distribution of Apache Maven
 *and* they add an ACK to the trademarks in the description of the package.

 The open question remains, is the *Package Name* a name that could be
 viewed as use of the trademark?

 Do the end users - i.e. developers - expect that `apt-get install maven`
 is installing Apache Maven? If they are junior developers my experience
 suggest they may think so...

 So if `apt-get install maven` causes confusion with our brand, we may
 have to ask Debian what they suggest they could do to remove the confusion.

 There are simple solutions, e.g. change the package name to mvn; stop
 making such large sweeping changes to our product; etc

 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.

 This gets even more confusing with some of their packaged maven plugins,
 which for interop need to use maven:
 http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
  (more
 obvious with Fedora:
 http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
 Thankfully in these cases I believe the source code is not patched, but it
 is binaries rebuilt from source not pulled down from Maven Central... which
 can cause issues for users.

 Fun Fun Fun




 Niclas

Re: apache binary distributions

Perhaps, the maven pmc could decree: if you are making a convenience
installer of maven for an OS where the maven pmc does not create a
convenience installer, you may use maven as the packaging name provided
the description clarifies it is a custom build and provides an ack of our
marks. Also the version number is different if patches have been applied.

Would that be an acceptable defence of our mark?

On Wed 19 Aug 2015 at 09:46, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest of
 the
  PMC, I may not call it Maven. If I did call it Maven then the remainder
 of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


 Well I actually have concerns about the maven that debian is publishing.
 There are some quite significant - in my view - deviations from our Maven.

 For me, the majority of the concerns could be addressed if they fix the
 *Description* to clarify that it is a modified distribution of Apache Maven
 *and* they add an ACK to the trademarks in the description of the package.

 The open question remains, is the *Package Name* a name that could be
 viewed as use of the trademark?

 Do the end users - i.e. developers - expect that `apt-get install maven`
 is installing Apache Maven? If they are junior developers my experience
 suggest they may think so...

 So if `apt-get install maven` causes confusion with our brand, we may have
 to ask Debian what they suggest they could do to remove the confusion.

 There are simple solutions, e.g. change the package name to mvn; stop
 making such large sweeping changes to our product; etc

 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.

 This gets even more confusing with some of their packaged maven plugins,
 which for interop need to use maven:
 http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
  (more
 obvious with Fedora:
 http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
 Thankfully in these cases I believe the source code is not patched, but it
 is binaries rebuilt from source not pulled down from Maven Central... which
 can cause issues for users.

 Fun Fun Fun




 Niclas

Re: apache binary distributions

On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest of
 the
  PMC, I may not call it Maven. If I did call it Maven then the remainder
 of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


Well I actually have concerns about the maven that debian is publishing.
There are some quite significant - in my view - deviations from our Maven.

For me, the majority of the concerns could be addressed if they fix the
*Description* to clarify that it is a modified distribution of Apache Maven
*and* they add an ACK to the trademarks in the description of the package.

The open question remains, is the *Package Name* a name that could be
viewed as use of the trademark?

Do the end users - i.e. developers - expect that `apt-get install maven` is
installing Apache Maven? If they are junior developers my experience
suggest they may think so...

So if `apt-get install maven` causes confusion with our brand, we may have
to ask Debian what they suggest they could do to remove the confusion.

There are simple solutions, e.g. change the package name to mvn; stop
making such large sweeping changes to our product; etc

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.

This gets even more confusing with some of their packaged maven plugins,
which for interop need to use maven:
http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
(more
obvious with Fedora:
http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
Thankfully in these cases I believe the source code is not patched, but it
is binaries rebuilt from source not pulled down from Maven Central... which
can cause issues for users.

Fun Fun Fun




 Niclas

Re: apache binary distributions

2015-08-18 Thread Kalle Korhonen

On Thu, Aug 13, 2015 at 8:58 PM, Marvin Humphrey mar...@rectangular.com
wrote:

 On Thu, Aug 13, 2015 at 8:35 PM, Luke Han luke...@gmail.com wrote:
  There's one discussion in Kylin community about to add binary
  package in release, people are really would like to have one:
 
 http://mail-archives.apache.org/mod_mbox/incubator-kylin-dev/201508.mbox/%3CCAKmQrOZ_MFUyF_y7HXE7iVMCfJHuuOFuU4T8ibsPWfnw0z2Opw%40mail.gmail.com%3E
 
  For some reason, people (especially in China) is not easy
  to build from source, since there are many library hosted on
  some services which can't be access directly.
 
  Beyond that, the first impression of a project is how to setup
  correctly and successfully, it not make sense to have everyone to
  build from source. And the reality is many projects already DO binary
  package for convenience purpose.
 
  After read so long mail thread here, I have a little bit confusion:-(
  there are too many messages...should we have some clear
  guide or practices for such binary release ?

 Apache produces open source software, and official Apache releases consist
 of
 source code.  Alongside such official releases, projects may offer binary
 packages supplied by volunteers which meet certain criteria:
   http://www.apache.org/dev/release#what
   In some cases, binary/bytecode packages are also produced as a
 convenience
   to users that might not have the appropriate tools to build a compiled
   version of the source. In all such cases, the binary/bytecode package
 must
   have the same version number as the source release and may only add
   binary/bytecode files that are the result of compiling that version of
 the
   source code release.

 I've always wondered about the official Apache releases consist of source
code. So what if a project (members) does not vote but unofficially
releases binary executable packages, perhaps along with source to some
other location than /dist/? Clearly, it's not an official release by Apache
policy but there the bits are in the wild anyway. I'm asking since at least
for many of the Java/Maven based projects it's very easy and inexpensive to
distribute software through Maven Central. NPM also happily uses Github as
their central repository so you could technically make lots and lots of
convenience artifacts available without ever officially releasing
anything.

Kalle

RE: apache binary distributions

2015-08-18 Thread Dennis E. Hamilton

Marvin's comprehensive response is very helpful.

However, the first described case is about a third-party distribution of 
binaries, even though some or all of the third parties are participants on the 
project.  (I assume the executable was not produced by the project in a manner 
that constitutes distribution and it is not authenticated by the project, 
especially a release manager.)

Off the top of my head, the trademark policy comes into play, because these are 
not folks acting with their Apache Project hats on.  It seems that the first 
responsibility about this is for the PMC of the (hypothetical) project.

 - Dennis

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Tuesday, August 18, 2015 09:46
To: general@incubator.apache.org
Subject: Re: apache binary distributions

On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen

 So what if a project (members) does not vote but unofficially
 releases binary executable packages, perhaps along with source to some
 other location than /dist/? Clearly, it's not an official release by Apache
 policy but there the bits are in the wild anyway.

At Apache, software that is published beyond the group that develops it must
be assembled, vetted and voted in accordance with Release Policy and
distributed in accordance with Release Distribution Policy.

  http://www.apache.org/dev/release
  http://www.apache.org/dev/release-distribution

Apache is deliberately decentralized in that technical decisions are
officially delegated to a PMC, but projects are still obligated to follow
Foundation policy with regards to project governance, IP diligence, etc.  A
primary function of the Incubator is to prepare projects to self-govern in
accordance with Apache policy and traditions.

As a last resort, policy violations eventually escalate to the Board of
Directors, which has the authority to take actions including termination of
the project.  But a healthy project self-governs and does not require Board
intervention -- individual contributors on the ground like you and me are
expected to address problems before they become severe.

 I'm asking since at least
 for many of the Java/Maven based projects it's very easy and inexpensive to
 distribute software through Maven Central. NPM also happily uses Github as
 their central repository so you could technically make lots and lots of
 convenience artifacts available without ever officially releasing
 anything.

Apache software does get (re)published to Maven Central, NPM, and any number
of other downstream distribution channels -- it just has to be released in
accordance with Apache release policy first.

Apache's release policy is deeply enmeshed with our governance institutions,
our IP controls, and the legal structure of the Foundation.  For example,
holding release votes helps ensure that small contributors are not run over
and that power is not consolidated in the hands of the few, jeopardizing
project independence.  It also helps to ensure that our projects actually make
pure open source releases, something that is really worth fighting for in this
era of privacy violations and aggressive three-letter agencies.

I've focused more on how policy is administered than the why policy is the
way it is in this email, because we're deep in a thread and this email is
long enough.  For those who are interested, I suggest reading the the Release
Policy page, as it captures some of the rationales, sometimes eloquently.

HTH,

Marvin Humphrey

-
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

2015-08-18 Thread Stephen Connolly

On 18 August 2015 at 18:35, Dennis E. Hamilton dennis.hamil...@acm.org
wrote:

 Marvin's comprehensive response is very helpful.

 However, the first described case is about a third-party distribution of
 binaries, even though some or all of the third parties are participants on
 the project.  (I assume the executable was not produced by the project in a
 manner that constitutes distribution and it is not authenticated by the
 project, especially a release manager.)

 Off the top of my head, the trademark policy comes into play, because
 these are not folks acting with their Apache Project hats on.  It seems
 that the first responsibility about this is for the PMC of the
 (hypothetical) project.


Yes that was my analysis of the question: If I decide to produce an
unofficial binary release of Maven without the approval of the rest of the
PMC, I may not call it Maven. If I did call it Maven then the remainder of
the PMC would be responsible for sending me a CD.



  - Dennis

 -Original Message-
 From: Marvin Humphrey [mailto:mar...@rectangular.com]
 Sent: Tuesday, August 18, 2015 09:46
 To: general@incubator.apache.org
 Subject: Re: apache binary distributions

 On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen

  So what if a project (members) does not vote but unofficially
  releases binary executable packages, perhaps along with source to some
  other location than /dist/? Clearly, it's not an official release by
 Apache
  policy but there the bits are in the wild anyway.

 At Apache, software that is published beyond the group that develops it
 must
 be assembled, vetted and voted in accordance with Release Policy and
 distributed in accordance with Release Distribution Policy.

   http://www.apache.org/dev/release
   http://www.apache.org/dev/release-distribution

 Apache is deliberately decentralized in that technical decisions are
 officially delegated to a PMC, but projects are still obligated to follow
 Foundation policy with regards to project governance, IP diligence, etc.  A
 primary function of the Incubator is to prepare projects to self-govern in
 accordance with Apache policy and traditions.

 As a last resort, policy violations eventually escalate to the Board of
 Directors, which has the authority to take actions including termination of
 the project.  But a healthy project self-governs and does not require Board
 intervention -- individual contributors on the ground like you and me are
 expected to address problems before they become severe.

  I'm asking since at least
  for many of the Java/Maven based projects it's very easy and inexpensive
 to
  distribute software through Maven Central. NPM also happily uses Github
 as
  their central repository so you could technically make lots and lots of
  convenience artifacts available without ever officially releasing
  anything.

 Apache software does get (re)published to Maven Central, NPM, and any
 number
 of other downstream distribution channels -- it just has to be released in
 accordance with Apache release policy first.

 Apache's release policy is deeply enmeshed with our governance
 institutions,
 our IP controls, and the legal structure of the Foundation.  For example,
 holding release votes helps ensure that small contributors are not run over
 and that power is not consolidated in the hands of the few, jeopardizing
 project independence.  It also helps to ensure that our projects actually
 make
 pure open source releases, something that is really worth fighting for in
 this
 era of privacy violations and aggressive three-letter agencies.

 I've focused more on how policy is administered than the why policy is
 the
 way it is in this email, because we're deep in a thread and this email is
 long enough.  For those who are interested, I suggest reading the the
 Release
 Policy page, as it captures some of the rationales, sometimes eloquently.

 HTH,

 Marvin Humphrey

 -
 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

2015-08-18 Thread Marvin Humphrey

On Tue, Aug 18, 2015 at 6:46 PM, Niclas Hedhman nic...@hedhman.org wrote:

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.

We need to distinguish between two situations:

*   Redistributor starts from official Apache release.
*   Redistributor starts from unreleased code.

Debian consumes official Apache releases, and they make changes that are
often very small.  Whether we should be aggressive in enforcing our trademarks
under those circumstances is a judgment call.  Should SteveNick also start
from an official release and make changes of similar scope to those made by
Debian, I would agree that the case for enforcing our trademarks would be
roughly analogous.

However, if SteveNick are Apache project contributors publishing unreleased
code and making an end run around Apache release policy, there's greater cause
for concern.

*   Are other PMC members being denied their right to participate in release
decision making?
*   To what extent does the privileged position afforded SteveNick
undermine project independence?
*   While our communities strive to maintain codebases in compliance with
Apache legal and release policies, we accept that raw repository code may
be imperfect between releases.  Just how far out of compliance is the
unreleased code SteveNick are publishing under our trademark?
*   To what extent is the 501(c)(3) status of the Foundation put at
increased risk by the actions of this project?  What if the practices
spread to other projects?

If Debian were to systematically consume unreleased code from us (aside from
patches they've contributed themselves), I imagine we would have similar
concerns.  But that seems like a weird theoretical.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-18 Thread Ted Dunning

On Tue, Aug 18, 2015 at 10:15 PM, Marvin Humphrey mar...@rectangular.com
wrote:

 However, if SteveNick are Apache project contributors publishing
 unreleased
 code and making an end run around Apache release policy, there's greater
 cause
 for concern.


On the other hand, if SteveNick are contributors publishing unreleased
code with VERY LARGE WARNINGS that it is their NON-APACHE APPROVED RELEASE,
then the use of the trademark is probably just fine.  Indeed, the PMC may
view it as a service for, say, testing purposes.

The problem comes from the level of confusion.  If the Debian package were
not a repackaging of a real release from Apache, I would find it very
misleading and confusing. As it is, I prefer it because of the packaging
convenience and the knowledge that Debian does a nice job of moving the
released Apache bits to me in an understandable and manageable way.

Re: apache binary distributions

2015-08-18 Thread Marvin Humphrey

On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen

 So what if a project (members) does not vote but unofficially
 releases binary executable packages, perhaps along with source to some
 other location than /dist/? Clearly, it's not an official release by Apache
 policy but there the bits are in the wild anyway.

At Apache, software that is published beyond the group that develops it must
be assembled, vetted and voted in accordance with Release Policy and
distributed in accordance with Release Distribution Policy.

  http://www.apache.org/dev/release
  http://www.apache.org/dev/release-distribution

Apache is deliberately decentralized in that technical decisions are
officially delegated to a PMC, but projects are still obligated to follow
Foundation policy with regards to project governance, IP diligence, etc.  A
primary function of the Incubator is to prepare projects to self-govern in
accordance with Apache policy and traditions.

As a last resort, policy violations eventually escalate to the Board of
Directors, which has the authority to take actions including termination of
the project.  But a healthy project self-governs and does not require Board
intervention -- individual contributors on the ground like you and me are
expected to address problems before they become severe.

 I'm asking since at least
 for many of the Java/Maven based projects it's very easy and inexpensive to
 distribute software through Maven Central. NPM also happily uses Github as
 their central repository so you could technically make lots and lots of
 convenience artifacts available without ever officially releasing
 anything.

Apache software does get (re)published to Maven Central, NPM, and any number
of other downstream distribution channels -- it just has to be released in
accordance with Apache release policy first.

Apache's release policy is deeply enmeshed with our governance institutions,
our IP controls, and the legal structure of the Foundation.  For example,
holding release votes helps ensure that small contributors are not run over
and that power is not consolidated in the hands of the few, jeopardizing
project independence.  It also helps to ensure that our projects actually make
pure open source releases, something that is really worth fighting for in this
era of privacy violations and aggressive three-letter agencies.

I've focused more on how policy is administered than the why policy is the
way it is in this email, because we're deep in a thread and this email is
long enough.  For those who are interested, I suggest reading the the Release
Policy page, as it captures some of the rationales, sometimes eloquently.

HTH,

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-17 Thread Jochen Theodorou


Am 17.08.2015 10:45, schrieb Branko Čibej:
[...]

So wait ... If the Subversion PMC releases source, and, say, Debian
creates a binary package called 'subversion-x.y.z' ... you're saying
that's trademark infringement and we should be telling all the people
who produce binary packages to stop using our registered trademark? Really?

Producing binaries is different from creating a derived work. Even if
packagers change the sources (which they often do, in minor ways, to
tune the build to their platform), it's less than sane to tell them they
should rename the packages because of that.

It would be different if their changes resulted in changed
functionality, but that's not what's happening.


My take so far is: The PMC decides upon if they want to allow for that 
or not. So the Subversion PMC could forbid the redistribution of 
packages named subversion-x.y.z... But that does not mean they have to. 
Where the PMC should get active in such matters is if something claims 
to be subversion, but really is not. But again the PMC is responsible 
for 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

2015-08-17 Thread Bertrand Delacretaz

On Mon, Aug 17, 2015 at 10:53 AM, Jochen Theodorou blackd...@gmx.org wrote:
 ...My take so far is: The PMC decides upon if they want to allow for that or
 not. So the Subversion PMC could forbid the redistribution of packages named
 subversion-x.y.z... But that does not mean they have to...

That's my understanding as well, but the best practice is to always
ask for people to use Apache FOO instead of just FOO when referring
to our projects.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-17 Thread Stephen Connolly

On 17 August 2015 at 09:53, Jochen Theodorou blackd...@gmx.org wrote:

Am 17.08.2015 10:45, schrieb Branko Čibej:
[...]

So wait ... If the Subversion PMC releases source, and, say, Debian
creates a binary package called 'subversion-x.y.z' ... you're saying
that's trademark infringement and we should be telling all the people
who produce binary packages to stop using our registered trademark?
Really?

Producing binaries is different from creating a derived work. Even if
packagers change the sources (which they often do, in minor ways, to
tune the build to their platform), it's less than sane to tell them they
should rename the packages because of that.

It would be different if their changes resulted in changed
functionality, but that's not what's happening.

My take so far is: The PMC decides upon if they want to allow for that or
not. So the Subversion PMC could forbid the redistribution of packages
named subversion-x.y.z... But that does not mean they have to. Where the
PMC should get active in such matters is if something claims to be
subversion, but really is not. But again the PMC is responsible for that.

I don't know what Debian is doing to subversion... they are certainly
making - to my mind at least - significant changes to Maven:
http://anonscm.debian.org/cgit/pkg-java/maven.git/tree/debian/patches/plugins_version.diff?id=2628fdf44618983f3c714b6c0a9c320f68ab2ad2

On the other hand, Subversion and Maven both at least have an out for the
distros... we can ask them to use our short-name

I think it is acceptable for our users to

apt-get install mvn

That seems acceptable to me, and would not put into question the usage of
our mark.

For something like

brew install maven

Which really does this:

https://github.com/Homebrew/homebrew/blob/master/Library/Formula/maven.rb

I have a hard time arguing a case that homebrew is abusing our mark...
homebrew goes and grabs our convenience binary, removes some excess files
(windows batch files) and creates symlinks...

In short, my personal opinion is that `brew install maven` is installing
maven as provided by the Apache Maven PMC.

On the other hand, when I look at the description of Debian's maven package:

http://anonscm.debian.org/cgit/pkg-java/maven.git/tree/debian/control?id=2628fdf44618983f3c714b6c0a9c320f68ab2ad2#n47

Description: Java software project management and comprehension tool
Maven is a software project management and comprehension tool. Based on
the
concept of a project object model (POM), Maven can manage a project's
build,
reporting and documentation from a central piece of information.
.
Maven's primary goal is to allow a developer to comprehend the complete
state of a development effort in the shortest period of time. In order to
attain this goal there are several areas of concern that Maven attempts
to deal with:
.
* Making the build process easy
* Providing a uniform build system
* Providing quality project information
* Providing guidelines for best practices development
* Allowing transparent migration to new features

I see a potential abuse of our mark which I have raised with the rest of
the Apache Maven PMC. It's not a major abuse, for example I believe some
simple changes to this description would suffice:

e.g. by changing it with the following diff

Description: Java software project management and comprehension tool
- Maven is a software project management and comprehension tool. Based on
the

+ Debian's redistribution of Apache Maven.

+ .

+ Apache Maven is a software project management and comprehension tool.
Based on the
concept of a project object model (POM), Maven can manage a project's
build,
reporting and documentation from a central piece of information.
.
Maven's primary goal is to allow a developer to comprehend the complete
state of a development effort in the shortest period of time. In order to
attain this goal there are several areas of concern that Maven attempts
to deal with:
.
* Making the build process easy
* Providing a uniform build system
* Providing quality project information
* Providing guidelines for best practices development
* Allowing transparent migration to new features
+ .
+ Apache, Apache Maven and Maven are trademarks of the Apache Software
Foundation.

The critical question that does concern me, however, is the package name
`maven`... is the package name an abuse of our mark?

I really would appreciate guidance from brand management on the package
name thing.

Users of a distribution expect when they

yum install apache subversion maven

that they have installed Apache HTTPD, Apache Subversion and Apache
Maven... but really they have installed Fedora's httpd service based on
Apache HTTPD, Fedora's svn based on Apache Subversion and Fedora's mvn
based on Apache Maven.

So:

Is Debian calling a package `maven` that is a clearly different thing[1]
from Apache

Re: apache binary distributions

2015-08-17 Thread Roman Shaposhnik

On Sun, Aug 16, 2015 at 1:02 PM, Marvin Humphrey mar...@rectangular.com wrote:
 On Sun, Aug 16, 2015 at 12:43 PM, Roman Shaposhnik ro...@shaposhnik.org 
 wrote:

 Now that takeaway from this thread for me so far is this: in order for the
 trademark enforcement to be invoked there has to be a legitimate concern
 from the PMC. The foundation is not in a business of blatant brand policing
 (otherwise quite a few CD should've been sent already to various Linux
 distros).

 It doesn't follow that if there have been instances where the
 trademark policy may have been applied flexibly that it is anything
 other than what is documented.

The documentation is subject to quite a bit of interpretation
as I read it. See bellow:

 This thread is long and bendy. What is it that you want to achieve?

Three things:
1. Have a reference point for future questions like the one that
started this very thread (it is long -- but there actually *was*
a podling question that started it ;-).

2. Clarify some of the more subtle points of the policy

3. Have Shane (as VP of Brand) and a few active PMC members
(like Stephen Connolly) express their view points on how ASF
brands are being used by downstream Linux packagers, since this
is the prototypical relationship between the Foundation and *any*
downstream.

Based on #3 I feel like I might have a few potential suggestions to clarify
our written policy, but I'd like to see the feedback first.

Thanks,
Roman.

P.S. Thanks to all who chimed in with very good feedback!

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: apache binary distributions

2015-08-17 Thread Dennis E. Hamilton

On dev-community, you mentioned something that caught my eye.  Although it is a 
bit OT, maybe not, Roman's observation on this thread (abridged below).

Indulge me in borrowing the key bit for me:

I get so worked up when 'general public'
in our release policy gets [mis]interpreted 
as mostly related to 'end users'.
But that's a pet peeve for a different thread ;-)

I think that the general public becomes involved in multiple ways.  

First and foremost has to do with the next-in-line adopter of an Apache Project 
release.  That can be two-fold when there are convenience binaries that have 
quite different next-in-line adopters, as for Apache OpenOffice.

Although take-up of the AOO source for packaging in Linux distributions is not 
a significant factor (LibreOffice having that distribution case pretty well 
nailed down), there are next-in-line integrators and customizers.

For AOO a key consideration is that the software is for end-user purposes and 
somewhere end-users and the general public touch it massively.  And that 
software and those users come back to the project with their Bugzilla issues, 
mailing list reports, forum searches, etc.  They are certainly and clearly in 
the cycle of learning-and-improvement and their adoption of the software, 
however binaries reach them, is a big deal.  

This may be an aberration with respect to the ASF prototypical case, but it is 
not so much with respect to open-source itself.  And authenticity and 
protection of the brand/trade-mark are serious.  I suspect similar 
considerations arise for software that has end-user importance, whether for 
productivity, web browsing, social connections, or tools for media and image 
creation.  

The key point is that knowing the *variety* of next-in-line adopters is 
important, including is the ultimate end-points where usability, reliability, 
and other continuation-influencing factors feed back to the project very 
directly.  

Just sayin'

 - Dennis


-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Monday, August 17, 2015 21:11
To: general@incubator.apache.org
Subject: Re: apache binary distributions

On Sun, Aug 16, 2015 at 1:02 PM, Marvin Humphrey mar...@rectangular.com wrote:
[ ... ]
 This thread is long and bendy. What is it that you want to achieve?

Three things:
[ ... ]

3. Have Shane (as VP of Brand) and a few active PMC members
(like Stephen Connolly) express their view points on how ASF
brands are being used by downstream Linux packagers, since this
is the prototypical relationship between the Foundation and *any*
downstream.

Based on #3 I feel like I might have a few potential suggestions to clarify
our written policy, but I'd like to see the feedback first.

Thanks,
Roman.

P.S. Thanks to all who chimed in with very good feedback!

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---BeginMessage---
On Mon, Aug 17, 2015 at 8:48 AM, Shane Curcuru a...@shanecurcuru.org wrote:
 On 8/16/15 4:25 PM, Roman Shaposhnik wrote:
 On Fri, Aug 14, 2015 at 3:59 PM, Shane Curcuru a...@shanecurcuru.org wrote:
 On 8/7/15 7:53 AM, Niclas Hedhman wrote:
 Bill,
 So I can release Niclas Hadoop platform, based on Apache Hadoop ?? I
 thought the discussion a few years ago was that this was misleading...

 No, you cannot.  See our actual trademark policy:

   https://www.apache.org/foundation/marks/faq/#products

 Our release policy, as Roman originally asked about, applies only to ASF
 projects, and has no bearing on third parties.  However our trademark
 policy, and trademark law, prevents third parties from publicly
 providing software using our trademarks.

 Our operational policies only apply to our projects, just like any other
 corporation.  Some policies, like our license itself and our formal
 trademark policy, inform the rest of the world how they are allowed to
 use our websites, software code, and brands.

 Make sense?

 It does, but our relationships with downstream Linux vendors
 (just to take the most obvious example) set a very confusing
 precedent.

 Shane, if would be super helpful if you took a look at:
http://pkgs.org/search/hadoop
http://pkgs.org/search/maven
http://pkgs.org/search/subversion
 and pubished your narrative of how the ASF branding
 policies apply in both cases.

 The 3 projects I'm picking represent a pretty diverse
 set of cases of how PMCs are conducting themselves.

 OK, that will take some time.  It would help if we can setup a call or
 get someone to writeup a description of what those pages mean from the
 larger perspective:

Understood. And perhaps this could be considered
important enough so that we start a dedicated thread.

Let me know if you'd also suggest moving to a more appropriate
mailing list

Re: apache binary distributions

2015-08-17 Thread Shane Curcuru

On 8/16/15 9:05 PM, David Nalley wrote:
 On Sun, Aug 16, 2015 at 3:43 PM, Roman Shaposhnik ro...@shaposhnik.org 
 wrote:
 On Sun, Aug 16, 2015 at 12:33 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 On Sun, Aug 16, 2015 at 12:29 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

 The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
 that corresponds to an Apache Hadoop release.  Having project Foo
 produce a
 release of Bar, Baz and Pigdog is pretty far off the reservation,
 however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?


 The downstream shouldn't be calling their artifacts Hadoop if they aren't
 the Hadoop PMC in any case.

 But they do. And not just hadoop -- go do searches on pkgs.org and see
 for yourself.

 Now that takeaway from this thread for me so far is this: in order for the
 trademark enforcement to be invoked there has to be a legitimate concern
 from the PMC. The foundation is not in a business of blatant brand policing
 (otherwise quite a few CD should've been sent already to various Linux
 distros).

 
 It is the PMC's reponsibility to police their brand. [1] Some projects
 police it very loosely, others much more rigidly. If a project were to
 wish to go the Mozilla route, I am sure they could.  The foundation
 provides projects with nice, generic scaffolding that gives some
 flexibility, but generally just works. The foundation itself rarely
 engages in trademark policing without the PMC requesting help.

That being said, let's be clear since we're on a publicly archived list
here: The ASF owns all Apache trademarks on behalf of our projects.  We
certainly hope - and often only have the volunteer energy for - having
the PMCs take the lead in reporting and attempting to police misuse of
their project's marks.  But if a PMC is truly falling down on the job -
or if a PMC is unfairly allowing one/some companies to take advantage of
their project brand - the ASF can and will enforce our polices at the
Foundation level.

This really is a rare case, but we do need to be clear from the policy
side.  I'm not particularly concerned about less-active projects that
might just let things slide (or not be aware of) or slide into
obscurity.  I am concerned that some PMCs might not take policing
seriously enough when it comes to vendors specifically pushing the
boundaries in ways that harm our Apache wide reputation for project
independence:
  https://community.apache.org/projectIndependence.html

- Shane

 
 
 [1] http://apache.org/foundation/marks/responsibility#responsible
 
 -
 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

2015-08-17 Thread Branko Čibej

On 16.08.2015 21:33, Ted Dunning wrote:
 On Sun, Aug 16, 2015 at 12:29 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

 The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
 that corresponds to an Apache Hadoop release.  Having project Foo
 produce a
 release of Bar, Baz and Pigdog is pretty far off the reservation,
 however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?

 The downstream shouldn't be calling their artifacts Hadoop if they aren't
 the Hadoop PMC in any case.


So wait ... If the Subversion PMC releases source, and, say, Debian
creates a binary package called 'subversion-x.y.z' ... you're saying
that's trademark infringement and we should be telling all the people
who produce binary packages to stop using our registered trademark? Really?

Producing binaries is different from creating a derived work. Even if
packagers change the sources (which they often do, in minor ways, to
tune the build to their platform), it's less than sane to tell them they
should rename the packages because of that.

It would be different if their changes resulted in changed
functionality, but that's not what's happening.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-16 Thread David Nalley

On Sun, Aug 16, 2015 at 3:43 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 On Sun, Aug 16, 2015 at 12:33 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 On Sun, Aug 16, 2015 at 12:29 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

  The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
  that corresponds to an Apache Hadoop release.  Having project Foo
 produce a
  release of Bar, Baz and Pigdog is pretty far off the reservation,
 however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?


 The downstream shouldn't be calling their artifacts Hadoop if they aren't
 the Hadoop PMC in any case.

 But they do. And not just hadoop -- go do searches on pkgs.org and see
 for yourself.

 Now that takeaway from this thread for me so far is this: in order for the
 trademark enforcement to be invoked there has to be a legitimate concern
 from the PMC. The foundation is not in a business of blatant brand policing
 (otherwise quite a few CD should've been sent already to various Linux
 distros).


It is the PMC's reponsibility to police their brand. [1] Some projects
police it very loosely, others much more rigidly. If a project were to
wish to go the Mozilla route, I am sure they could.  The foundation
provides projects with nice, generic scaffolding that gives some
flexibility, but generally just works. The foundation itself rarely
engages in trademark policing without the PMC requesting help.


[1] http://apache.org/foundation/marks/responsibility#responsible

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-16 Thread David Nalley

On Sun, Aug 16, 2015 at 3:29 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 Seems like for the past two weeks I only have weekends to respond :-(
 Apologies for the delay on this thread.

 On Sun, Aug 9, 2015 at 7:30 PM, Ted Dunning ted.dunn...@gmail.com wrote:
  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.

 The question is: do we have ASF-wide trademark guidelines or do
 we allow each PMC to make those as they go.


 Yes. We do have ASF-wide trademark guidelines and we also allow PMC's to
 have pretty broad latitude within those boundaries.  The PMC definitely
 should not be making things up, but they do have a lot of responsibility
 for deciding what they don't like.

 I don't think I was clear: I understand that ASF has foundation-wide
 trademark guidelines, what I was asking is: are we allowing PMCs
 to put additional constraints on top of those.

Yes, off hand I know of two PMCs that have additional, or more rigid
trademark guidelines in place.




 How is the release policy not clear (
 http://www.apache.org/dev/release.html#distribute-other-artifacts) when it
 says:

All releases are in the form of the source materials needed to make changes
  to the software



And then it says

In all such cases, the binary/bytecode package must have the same version
 number as the source release and may only add binary/bytecode files that
 are the result of compiling that version of the source code release.

 Right. So what happens to at least 4 different (and I do mean different) ways
 of building Hadoop? Are these all different distributions? Do ALL of them
 need to be blessed by PMC?

 The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
 that corresponds to an Apache Hadoop release.  Having project Foo produce a
 release of Bar, Baz and Pigdog is pretty far off the reservation, however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?

 Remember -- we're still talking producing binary packages from exact same
 source release that PMC blessed -- just using different build and packaging
 mechanics.

 Thanks,
 Roman.

 -
 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

2015-08-16 Thread Ted Dunning

On Sun, Aug 16, 2015 at 12:29 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

  The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
  that corresponds to an Apache Hadoop release.  Having project Foo
 produce a
  release of Bar, Baz and Pigdog is pretty far off the reservation,
 however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?


The downstream shouldn't be calling their artifacts Hadoop if they aren't
the Hadoop PMC in any case.



 Remember -- we're still talking producing binary packages from exact same
 source release that PMC blessed -- just using different build and packaging
 mechanics.


And a different project.

Re: apache binary distributions

2015-08-16 Thread Roman Shaposhnik

Seems like for the past two weeks I only have weekends to respond :-(
Apologies for the delay on this thread.

On Sun, Aug 9, 2015 at 7:30 PM, Ted Dunning ted.dunn...@gmail.com wrote:
  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.

 The question is: do we have ASF-wide trademark guidelines or do
 we allow each PMC to make those as they go.


 Yes. We do have ASF-wide trademark guidelines and we also allow PMC's to
 have pretty broad latitude within those boundaries.  The PMC definitely
 should not be making things up, but they do have a lot of responsibility
 for deciding what they don't like.

I don't think I was clear: I understand that ASF has foundation-wide
trademark guidelines, what I was asking is: are we allowing PMCs
to put additional constraints on top of those.

 How is the release policy not clear (
 http://www.apache.org/dev/release.html#distribute-other-artifacts) when it
 says:

All releases are in the form of the source materials needed to make changes
  to the software



And then it says

In all such cases, the binary/bytecode package must have the same version
 number as the source release and may only add binary/bytecode files that
 are the result of compiling that version of the source code release.

Right. So what happens to at least 4 different (and I do mean different) ways
of building Hadoop? Are these all different distributions? Do ALL of them
need to be blessed by PMC?

 The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
 that corresponds to an Apache Hadoop release.  Having project Foo produce a
 release of Bar, Baz and Pigdog is pretty far off the reservation, however.

It is. But if they screw up packaging guidelines inadvertently and the
downstream
want to take matters in their own hands -- how is it off the reservation?

Remember -- we're still talking producing binary packages from exact same
source release that PMC blessed -- just using different build and packaging
mechanics.

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

2015-08-16 Thread Roman Shaposhnik

On Sun, Aug 16, 2015 at 12:33 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 On Sun, Aug 16, 2015 at 12:29 PM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

  The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
  that corresponds to an Apache Hadoop release.  Having project Foo
 produce a
  release of Bar, Baz and Pigdog is pretty far off the reservation,
 however.

 It is. But if they screw up packaging guidelines inadvertently and the
 downstream
 want to take matters in their own hands -- how is it off the reservation?


 The downstream shouldn't be calling their artifacts Hadoop if they aren't
 the Hadoop PMC in any case.

But they do. And not just hadoop -- go do searches on pkgs.org and see
for yourself.

Now that takeaway from this thread for me so far is this: in order for the
trademark enforcement to be invoked there has to be a legitimate concern
from the PMC. The foundation is not in a business of blatant brand policing
(otherwise quite a few CD should've been sent already to various Linux
distros).


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

2015-08-16 Thread Marvin Humphrey

On Sun, Aug 16, 2015 at 12:43 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 Now that takeaway from this thread for me so far is this: in order for the
 trademark enforcement to be invoked there has to be a legitimate concern
 from the PMC. The foundation is not in a business of blatant brand policing
 (otherwise quite a few CD should've been sent already to various Linux
 distros).

It doesn't follow that if there have been instances where the
trademark policy may have been applied flexibly that it is anything
other than what is documented.

This thread is long and bendy. What is it that you want to achieve?

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-16 Thread Roman Shaposhnik

On Mon, Aug 10, 2015 at 6:30 AM, William A Rowe Jr wr...@rowe-clan.net wrote:
 On Aug 9, 2015 8:33 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Fri, Aug 7, 2015 at 12:46 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
  On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  ...is Apache Brand meant to protect *any* possible object/binary
  artifact or only those that PMC actually care about?...
 
  IMO any object/binary created from our source code has to be clearly
  identified as not coming from the ASF

 As a reminder, based on the foundation core purpose, the ASF releases open
 source code for consumption by the general public at no charge.

 While convenience binaries are shipped by many projects, others pointedly
 refuse (subversion is one example where all binary builds are thirdparty).
 The complexity of the number of potential build is one driving factor...
 Compile once-and-done for Java is much different than a cross platform
 machine code result.

FWIW: this is exactly the position I subscribe to.

 Well, the real question is: do we aspire to have a monopoly on certain
 binary convenience artifacts? IOW, if a Hadoop PMC blessed and RPM
 as one of those artifacts, does it mean that only that RPM (however
 potentially screwed up it is from the standpoint of Fedora packaging
 guidelines) is the RPM that can be called Hadoop?

  If Kermit distributes a compiled version of httpd for example I would
  expect that to be labeled as Kermit's distribution of the Apache HTTP
  Server.
 
  And if that's done properly I would expect filenames to reflect this
  where possible, so Kermit's binary package should be named like
  kermit-httpd-2.4.16.tgz to help prevent confusion.

 Well, this is not what's happening: http://pkgs.org/search/httpd

 A couple things here.  Our claim to Apache HTTP Server or Apache httpd
 marks are strong.  But HTTP alone is a protocol name, while httpd was the
 name of the binary of earlier (and other later) unix server daemons.

Sure. This was just an example. I could've as easily used Subversion:
   http://pkgs.org/search/subversion
or Maven:
http://pkgs.org/search/maven
or dozen other examples.

My point is -- very few of them would say Apache FOO. They all seem
to say FOO. They also seem to correspond rather neatly to the official
source releases produced by the PMC.

Now, to complicate things even further: Maven actually does produce
binary convenience artifacts, where Subversion doesn't. Thus in case
of Maven what gets published by the downstream is *different* from
what gets published by Maven's PMC.

All I saying -- if I were to look at the branding downstream from ASF
PMC producing source releases thing get confusing pretty quickly.

I just honestly don't see how what Fedora does to Apache Maven would
be different from what Jochen was suggesting for Apache Groovy.

 If a vendor who hated the AL 2.0 (some did/still do?) decided to ship their
 improved Apache httpd 2.0 based on their patches to 1.3 (under the AL
 1.1) we would have had words, and likely a CD letter to them eventually.

Understood. For the sake of keeping this thread even remotely manageable
lets just not even consider adulterated source. After all, there's quite a bit
of adulteration that can be done during build time anyway.

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

2015-08-14 Thread Shane Curcuru

On 8/6/15 4:29 AM, Jochen Theodorou 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.

Have folks here read the license recently?

6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.

  https://www.apache.org/licenses/LICENSE-2.0.html#trademarks

So our license explicitly excludes any Apache trademarks (i.e. APACHE
and the names of all of our projects, among other things) from any of
the other grants the license makes.  Beyond that, trademark law (which
varies in different countries) applies when anyone is using one of our
trademarks in association with a software product or other related
product or service that they provide *publicly*.

Employees in a $BigCo could call an internal release Best Apache Foo,
and we likely couldn't legally do anything about it (although we'd
certainly not be happy about it, and if we found out should ask them to
change it).  But when some other company or individual releases
Something Apache Foo publicly that we can - and should! - complain and
ensure that they're following our published trademark policy:

  https://www.apache.org/foundation/marks/faq/#products

Having specific examples to discuss is a much better idea.  It's very
important both 1) what, specifically, the thing is that's being provided
(download, maven repo, whatever), 2) what an end user would perceive the
branding of that thing to be, and 3) who - what specific person or
organization - is providing that thing.

- Shane





 
 At least I hope no-one has some crazy idea as that ;)
 
 bye blackdrag
 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions - Apache policies

2015-08-14 Thread Shane Curcuru

On 8/9/15 9:37 PM, Roman Shaposhnik wrote:
 On Fri, Aug 7, 2015 at 1:52 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 The question is: do we have ASF-wide trademark guidelines or do
 we allow each PMC to make those as they go.

Um, yes, we do:

  https://www.apache.org/foundation/marks/

Question: raise your hand here (or in a private email to me) if you are
on the IPMC and have never read that page before.  If so, please go read
it.  I'll wait.

.
.
.

Thanks.

Separately: the ASF is a corporation, which has a board and a number of
corporate officers who are empowered by the board to set specific kinds
of ASF-wide policies, which are *required* (if so marked; many are best
practices) of all Apache projects.  If you haven't read the minimal list
of these requirements, I highly recommend it - it's a much simpler read
than the trademark policy [1]:

  https://www.apache.org/dev/project-requirements

These ASF policies are required for our projects (and podlings, so they
can graduate), but obviously we don't have the authority to require
third parties (other companies or people) to follow them.  We can,
however, insist legally that third parties follow our Apache license and
our trademark policy.

- Shane

[1] Apologies for the long-windedness of the trademark policies.  It's
on my I'd really love to list to break it up into simpler chunks.



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-13 Thread Marvin Humphrey

On Thu, Aug 13, 2015 at 8:35 PM, Luke Han luke...@gmail.com wrote:
 There's one discussion in Kylin community about to add binary
 package in release, people are really would like to have one:
 http://mail-archives.apache.org/mod_mbox/incubator-kylin-dev/201508.mbox/%3CCAKmQrOZ_MFUyF_y7HXE7iVMCfJHuuOFuU4T8ibsPWfnw0z2Opw%40mail.gmail.com%3E

 For some reason, people (especially in China) is not easy
 to build from source, since there are many library hosted on
 some services which can't be access directly.

 Beyond that, the first impression of a project is how to setup
 correctly and successfully, it not make sense to have everyone to
 build from source. And the reality is many projects already DO binary
 package for convenience purpose.

 After read so long mail thread here, I have a little bit confusion:-(
 there are too many messages...should we have some clear
 guide or practices for such binary release ?

Apache produces open source software, and official Apache releases consist of
source code.  Alongside such official releases, projects may offer binary
packages supplied by volunteers which meet certain criteria:

  http://www.apache.org/dev/release#what

  In some cases, binary/bytecode packages are also produced as a convenience
  to users that might not have the appropriate tools to build a compiled
  version of the source. In all such cases, the binary/bytecode package must
  have the same version number as the source release and may only add
  binary/bytecode files that are the result of compiling that version of the
  source code release.

That's not quite what you asked for in the thread on dev@kylin (embedding a
binary inside a source release) but is it good enough?

Embedding executable binary code inside an official source release is not
OK.  Binary files, though they may be derived from open source, are not open
source themselves and cannot be audited by a PMC.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-13 Thread Luke Han

There's one discussion in Kylin community about to add binary
package in release, people are really would like to have one:
http://mail-archives.apache.org/mod_mbox/incubator-kylin-dev/201508.mbox/%3CCAKmQrOZ_MFUyF_y7HXE7iVMCfJHuuOFuU4T8ibsPWfnw0z2Opw%40mail.gmail.com%3E

For some reason, people (especially in China) is not easy
to build from source, since there are many library hosted on
some services which can't be access directly.

Beyond that, the first impression of a project is how to setup
correctly and successfully, it not make sense to have everyone to
build from source. And the reality is many projects already DO binary
package for convenience purpose.

After read so long mail thread here, I have a little bit confusion:-(
there are too many messages...should we have some clear
guide or practices for such binary release ?

Thanks.

Best Regards!
-

Luke Han

On Mon, Aug 10, 2015 at 10:50 PM, David Nalley da...@gnsa.us wrote:

On Sun, Aug 9, 2015 at 9:33 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
On Fri, Aug 7, 2015 at 12:46 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
...is Apache Brand meant to protect *any* possible object/binary
artifact or only those that PMC actually care about?...

IMO any object/binary created from our source code has to be clearly
identified as not coming from the ASF.

Well, the real question is: do we aspire to have a monopoly on certain
binary convenience artifacts? IOW, if a Hadoop PMC blessed and RPM
as one of those artifacts, does it mean that only that RPM (however
potentially screwed up it is from the standpoint of Fedora packaging
guidelines) is the RPM that can be called Hadoop?

That depends.
And what it largely depends on is the product, the PMC producing it,
and the user base.
Some projects have problems with abuse of their marks. People bundling
additional (occasionally malicious) software with the ASF-produced
software. Some of those projects enforce (rightly IMO) trademark to
the benefit of the project and its users.

Other projects are much more lax with trademarks, yet remain very vibrant.

Mozilla had similar problems to those that GCC had, which were
described earlier. Linux distributions were patching the 'official'
release, and inadvertently causing problems which ended up giving
Mozilla products an undeserved (at least for those specific issues)
bad reputation. So they rectified this by enforcing their trademarks,
and declaring that any patches had to be approved by Mozilla if you
were to retain the Mozilla brands on the software. Is that overkill
for most of the products that call the ASF home? Probably. But for
some projects, it makes sense.

(This is completely separate from a discussion about a third-party
using ASF marks for their own gain and confusing folks about the
origin of the software they are using)

--David

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-10 Thread David Nalley

On Sun, Aug 9, 2015 at 9:33 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 On Fri, Aug 7, 2015 at 12:46 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org 
 wrote:
 ...is Apache Brand meant to protect *any* possible object/binary
 artifact or only those that PMC actually care about?...

 IMO any object/binary created from our source code has to be clearly
 identified as not coming from the ASF.

 Well, the real question is: do we aspire to have a monopoly on certain
 binary convenience artifacts? IOW, if a Hadoop PMC blessed and RPM
 as one of those artifacts, does it mean that only that RPM (however
 potentially screwed up it is from the standpoint of Fedora packaging
 guidelines) is the RPM that can be called Hadoop?


That depends.
And what it largely depends on is the product, the PMC producing it,
and the user base.
Some projects have problems with abuse of their marks. People bundling
additional (occasionally malicious) software with the ASF-produced
software. Some of those projects enforce (rightly IMO) trademark to
the benefit of the project and its users.

Other projects are much more lax with trademarks, yet remain very vibrant.

Mozilla had similar problems to those that GCC had, which were
described earlier. Linux distributions were patching the 'official'
release, and inadvertently causing problems which ended up giving
Mozilla products an undeserved (at least for those specific issues)
bad reputation. So they rectified this by enforcing their trademarks,
and declaring that any patches had to be approved by Mozilla if you
were to retain the Mozilla brands on the software. Is that overkill
for most of the products that call the ASF home? Probably. But for
some projects, it makes sense.

(This is completely separate from a discussion about a third-party
using ASF marks for their own gain and confusing folks about the
origin of the software they are using)

--David

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-10 Thread William A Rowe Jr

On Aug 9, 2015 8:33 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Fri, Aug 7, 2015 at 12:46 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
  On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
  ...is Apache Brand meant to protect *any* possible object/binary
  artifact or only those that PMC actually care about?...
 
  IMO any object/binary created from our source code has to be clearly
  identified as not coming from the ASF

As a reminder, based on the foundation core purpose, the ASF releases open
source code for consumption by the general public at no charge.

While convenience binaries are shipped by many projects, others pointedly
refuse (subversion is one example where all binary builds are thirdparty).
The complexity of the number of potential build is one driving factor...
Compile once-and-done for Java is much different than a cross platform
machine code result.

 Well, the real question is: do we aspire to have a monopoly on certain
 binary convenience artifacts? IOW, if a Hadoop PMC blessed and RPM
 as one of those artifacts, does it mean that only that RPM (however
 potentially screwed up it is from the standpoint of Fedora packaging
 guidelines) is the RPM that can be called Hadoop?

  If Kermit distributes a compiled version of httpd for example I would
  expect that to be labeled as Kermit's distribution of the Apache HTTP
  Server.
 
  And if that's done properly I would expect filenames to reflect this
  where possible, so Kermit's binary package should be named like
  kermit-httpd-2.4.16.tgz to help prevent confusion.

 Well, this is not what's happening: http://pkgs.org/search/httpd

A couple things here.  Our claim to Apache HTTP Server or Apache httpd
marks are strong.  But HTTP alone is a protocol name, while httpd was the
name of the binary of earlier (and other later) unix server daemons.

The next is that many vendors compile httpd.  They are encouraged to do
so.  If they label it apache-httpd, it aught to consist of ASF sources.  If
they label it kermits-httpd, it is likely a portmanteau of Kermit's modules
and patches with ASF sources combined.

If a vendor who hated the AL 2.0 (some did/still do?) decided to ship their
improved Apache httpd 2.0 based on their patches to 1.3 (under the AL
1.1) we would have had words, and likely a CD letter to them eventually.

Finally Apache HTTP Server was a very early mark, early abuse was not as
effectively policed.  So the approach to correcting abuse has been a strong
emphasis on polite requests to avoid community confusion.  Where that
fails, only then do we escalate.

Covalent/Springsource/VMW/Pivotal have a long history of renaming where
confusion would result.  RavenSSL was Apache httpd+mod_ssl, build upon
RSA not OpenSSL for US domestic users looking for patent licensing.
tcServer is Apache Tomcat combined with many enterprise extensions.  The
guidelines and Trademark usage constraints are rather straightforward.
Where vendors have built-upon httpd, it is often as an extension to an ASF
base package.  RH GPL-licensed mod_cluster is but one example of this.

Re: apache binary distributions

2015-08-10 Thread Bertrand Delacretaz

On Mon, Aug 10, 2015 at 3:33 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 ...do we aspire to have a monopoly on certain
 binary convenience artifacts? IOW, if a Hadoop PMC blessed and RPM
 as one of those artifacts, does it mean that only that RPM (however
 potentially screwed up it is from the standpoint of Fedora packaging
 guidelines) is the RPM that can be called Hadoop?...

IMO what's important is for users to be informed of the provenance of
any binaries that they use. Exactly how they are named does not really
matter, if a binary package is named just Hadoop-x.y.z but clearly
belongs to Fedora I suppose that's fine, even though
Fedora-Hadoop.x.y.z would be better IMO, but not always practical
probably.

 Kermit's binary package should be named like
 kermit-httpd-2.4.16.tgz to help prevent confusion.

 Well, this is not what's happening: http://pkgs.org/search/httpd ...

As Bill says, httpd's name and long history which might explain a lot
of this, but we can do better now.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-09 Thread Roman Shaposhnik

On Fri, Aug 7, 2015 at 12:46 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 ...is Apache Brand meant to protect *any* possible object/binary
 artifact or only those that PMC actually care about?...

 IMO any object/binary created from our source code has to be clearly
 identified as not coming from the ASF.

Well, the real question is: do we aspire to have a monopoly on certain
binary convenience artifacts? IOW, if a Hadoop PMC blessed and RPM
as one of those artifacts, does it mean that only that RPM (however
potentially screwed up it is from the standpoint of Fedora packaging
guidelines) is the RPM that can be called Hadoop?

 If Kermit distributes a compiled version of httpd for example I would
 expect that to be labeled as Kermit's distribution of the Apache HTTP
 Server.

 And if that's done properly I would expect filenames to reflect this
 where possible, so Kermit's binary package should be named like
 kermit-httpd-2.4.16.tgz to help prevent confusion.

Well, this is not what's happening: http://pkgs.org/search/httpd

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

2015-08-09 Thread Roman Shaposhnik

On Fri, Aug 7, 2015 at 1:52 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 Roman,

 That was a *really* long email.

Well, I do those from time to time ;-)

 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.

The question is: do we have ASF-wide trademark guidelines or do
we allow each PMC to make those as they go.

 2) Apache Approved releases are approved collections of software.

That's way too vague for me. I'm not really sure what 'software' means.

 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

The devil, as usual, is in the details. When I look at something like:

http://pkgs.org/centos-7/centos-x86_64/httpd-2.4.6-31.el7.centos.x86_64.rpm.html
it is very tempting to assume it was a release of ASF software.

 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.

I disagree. ASF owns the trademarks, but then it is up to the foundaiton
to define clear guidelines.

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

2015-08-09 Thread Ted Dunning

On Sun, Aug 9, 2015 at 6:33 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 On Fri, Aug 7, 2015 at 12:46 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
  On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  ...is Apache Brand meant to protect *any* possible object/binary
  artifact or only those that PMC actually care about?...
 
  IMO any object/binary created from our source code has to be clearly
  identified as not coming from the ASF.

 Well, the real question is: do we aspire to have a monopoly on certain
 binary convenience artifacts?


?!

No.  The mission of the ASF is to *facilitate* the use and adaptation of
software.



 IOW, if a Hadoop PMC blessed and RPM
 as one of those artifacts, does it mean that only that RPM (however
 potentially screwed up it is from the standpoint of Fedora packaging
 guidelines) is the RPM that can be called Hadoop?


How is the release policy not clear (
http://www.apache.org/dev/release.html#distribute-other-artifacts) when it
says:

All releases are in the form of the source materials needed to make changes
 to the software


And then it says

In all such cases, the binary/bytecode package must have the same version
 number as the source release and may only add binary/bytecode files that
 are the result of compiling that version of the source code release.


The Hadoop PMC is utterly free to produce a Hadoop RPM with Hadoop in it
that corresponds to an Apache Hadoop release.  Having project Foo produce a
release of Bar, Baz and Pigdog is pretty far off the reservation, however.

Re: apache binary distributions

2015-08-09 Thread Ted Dunning

On Sun, Aug 9, 2015 at 6:37 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 On Fri, Aug 7, 2015 at 1:52 PM, Ted Dunning ted.dunn...@gmail.com wrote:
  Roman,
 
  That was a *really* long email.

 Well, I do those from time to time ;-)

  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.

 The question is: do we have ASF-wide trademark guidelines or do
 we allow each PMC to make those as they go.


Yes. We do have ASF-wide trademark guidelines and we also allow PMC's to
have pretty broad latitude within those boundaries.  The PMC definitely
should not be making things up, but they do have a lot of responsibility
for deciding what they don't like.

 2) Apache Approved releases are approved collections of software.

 That's way too vague for me. I'm not really sure what 'software' means.


That is going to be hard for me to help you with.


  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

 The devil, as usual, is in the details. When I look at something like:

 http://pkgs.org/centos-7/centos-x86_64/httpd-2.4.6-31.el7.centos.x86_64.rpm.html
 it is very tempting to assume it was a release of ASF software.


And you might take that to the Apache httpd PMC.


 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.

 I disagree. ASF owns the trademarks, but then it is up to the foundaiton
 to define clear guidelines.


I am not clear what you disagree with.  I didn't say that the ASF didn't
own the trademarks so that can hardly be the problem.  The fact that
trademarks are only protected insofar as confusing usage is trademarks 101
(see http://www.uspto.gov/trademarks-getting-started/trademark-basics)

Re: apache binary distributions

2015-08-07 Thread Ted Dunning

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

Re: apache binary distributions

2015-08-07 Thread Bertrand Delacretaz

On Fri, Aug 7, 2015 at 2:50 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 ...is Apache Brand meant to protect *any* possible object/binary
 artifact or only those that PMC actually care about?...

IMO any object/binary created from our source code has to be clearly
identified as not coming from the ASF.

If Kermit distributes a compiled version of httpd for example I would
expect that to be labeled as Kermit's distribution of the Apache HTTP
Server.

And if that's done properly I would expect filenames to reflect this
where possible, so Kermit's binary package should be named like
kermit-httpd-2.4.16.tgz to help prevent confusion.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

2015-08-07 Thread Jochen Theodorou


Am 07.08.2015 02:50, schrieb Roman Shaposhnik:

On Thu, Aug 6, 2015 at 1:15 AM, Jochen Theodorou blackd...@gmx.org wrote:

[...]

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.


Official releases are released releases in the apache sense, meaning 
there has been a voting and in that the PMC votes are binding. For me 
that authorizes the PMC to produce official releases of apache projects. 
Of course unreleased releases can in theory be made by everyone.


[...]

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.


ok, noted

[...]

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.


understood


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.


can't be promoted means no link or description on the web page? Not even 
with disclaimer?


[...]

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.


ok, as long as this is general opinion.

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

2015-08-06 Thread 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).


Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

RE: apache binary distributions

2015-08-06 Thread Dennis E. Hamilton

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

2015-08-06 Thread Niclas Hedhman

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: 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

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: 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: apache binary distributions