RE: [PROPOSAL] Silk as new Incubator project

[Dennis E. Hamilton]

 below

-Original Message-
From: dwhyt...@gmail.com [mailto:dwhyt...@gmail.com] On Behalf Of Donald Whytock
Sent: Friday, September 19, 2014 13:52
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Silk as new Incubator project

On Fri, Sep 19, 2014 at 12:57 PM, Roman Shaposhnik 
wrote:

> On Fri, Sep 19, 2014 at 8:36 AM, Christian Grobmeier
>  wrote:
> > Not saying anything on the proposal itself, I would be concerned because
> > of the name Silk.
> > There is this:
> > http://lucidworks.com/product/integrations/silk/
[ ... ]
> >> >  * Apache Silk (preferable name)
> >> >  * Apache Sylk
> >> >  * Apache Memstor
> >> >  * Apache Ignite
>
> It would be very useful if we can get feedback on
> the most/least pref. ones from that list.
>
[ ... ]

I'd think Ignite is a standard-enough English word that no one could
reasonably claim exclusivity (but IANAL).

Don


Ignite is used within software names, as in "AIR Music Technology Ignite."  The 
splash screen says "Ignite by air".  I have no idea whether "Apache Ignite" is 
enough for non-confusion.  Too bad about Sylk.



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

RE: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Dennis E. Hamilton]

I suggest that the release manager and anyone else in the KEYS file should 
have added key fingerprints to their Apache profiles at 
<https://id.apache.org/>.

This will have their PGP keys refreshed regularly under their Apache ID at 
<https://people.apache.org/keys/committer/>.

With regard to an identifiable association of the key, presence in this 
manner connects the PGP key to The Apache ID by demonstration of control 
over the committer's Apache profile.

One can go farther by adding the user...@apache.org to an User-ID on the key.
Verifying that one has control over that e-mail address (and all User-IDs)
Is done by registering the public key at the PGP Global Directory service at 
<https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event> and completing the
ceremony specified there.  After the ceremony is completed, you can retrieve
your counter-signed PGP key from that service and synchronize it to a public
PGP key server.  The ASF will pick it up on a future refresh.

Use of the key from the Apache ID list has certain valuable properties.  It is
not fixed, as in the key files in the project and in distributions.  That means
any additional (web-of-trust) certifications of the keys association with a 
committer are updated automatically.  That includes any revocations.


 -- Dennis E. Hamilton
dennis.hamil...@acm.org+1-206-779-9430
https://keybase.io/orcmid  PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail



-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com] 
Sent: Sunday, October 12, 2014 22:29
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

Hi,

> First, the signing key is present in SVN, but has not been uploaded to the
> standard key-servers, nor has it been signed by anyone.

I found it here:
https://pgp.mit.edu/pks/lookup?search=Julian+Hyde&op=index

Even if the key is part of a web trust it may not be part of everyone's web of 
trust. I'd see that as a hard requirement to meet.

Thanks,
Justin
-
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: Convenience Binary Policy

[Dennis E. Hamilton]

 in-line.
-Original Message-
From: br...@apache.org [mailto:br...@apache.org] 
Sent: Thursday, October 23, 2014 01:47
To: general@incubator.apache.org
Subject: Re: Convenience Binary Policy

On 22.10.2014 03:02, Justin Mclean wrote:
> Hi,
>
>> Binary dependencies are, by definition, not released by the ASF; because
>> we release source code. Also, software that has dependencies that are
>> only available in binary form is not open-source, in my book.
> You may possibly be forgetting about Category B licensed dependancies. These 
> may only be included in binary form in an Apache product. [1] They would be 
> still be consider open source by most people :-) The source does exist it's 
> just not able to be included in a Apache product due to the weak copy left 
> provision the licences include.

I have trouble visualising how any ASF project could have /mandatory/
dependencies on anything from the B-list.


For an indication of the kinds of non-ASF dependencies that go into
Apache OpenOffice binary distributions, take a look at this list: 
. 
 
(To see the full names, mouse over the names in the Name column.)
There is a non-neglible potential for more Category B dependencies
in the future, now that LibreOffice releases are under the MPL 2.0.



-- Brane



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

RE: Convenience Binary Policy

[Dennis E. Hamilton]

 below,

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Wednesday, October 22, 2014 21:37
To: general@incubator.apache.org
Subject: Re: Convenience Binary Policy

On Tue, Oct 21, 2014 at 5:57 AM, Marvin Humphrey  wrote:
> On Mon, Oct 20, 2014 at 10:26 PM, Roman Shaposhnik  
> wrote:
>
>>> P.S.: Why anyone would think voting on binaries makes any kind of sense
>>> around here is, of course, a different question. I can't even begin to
>>> count the number of times it's been pointed out that binaries are not
>>> Apache releases.
>>
>> And yet that issue keeps rearing its ugly head. Given the amount
>> of traffic I've seen around clarifying some finer (and not so fine)
>> points of release/licensing implication it is about time we start
>> an FAQ on that. Me thinks at least.
>
> We have several release FAQs spread across the ASF, though -- which, taken
> together, are comprehensive beyond the point of excess.
>
> The problem is that we lack a concise policy document.  That's where the "ASF
> release policy codification proposal" as worked through on legal-discuss a few
> months ago is supposed to help.
>
>   http://s.apache.org/aGm
>   https://github.com/rectang/asfrelease
>
> It's delayed because I got swamped but it seems that the need has not
> diminished.

It would be really nice if you/we could finish this. That said, I
still maintain,
that focusing exclusively on source releases will simplify our life greatly.
IOW, Apache FOO version x.y.z can only designate a source release.

I understand the need of projects like OO to provide binaries of some sort,
I just don't understand why do they have to be 'blessed' by ASF. Once
source gets built and packaged a whole new set of issues kick in. I don't
think the foundation is well prepared to deal with those. We might as
well admit it explicitly.


   That's fine.  However the Apache OpenOffice project has an important
   need to establish the provenance and integrity of the end-user 
   binary distributions it makes.  There are an incredible variety of
   poseur builds that are distributed by third parties for the purpose
   of embedding adware. These also pose as "official" releases, including
   all of the links to support, pinging for updates, etc.  When folks come
   with complaints, the project lists refer them to the authentic builds
   that the project curates.  This is a significant portion of support
   requests to users @oo.a.o and dev @oo.a.o.
  Now that there is code-signing for the Windows (and Mac?) builds,
   this is going to become easier to fend off.  Having the binary distros
   available from the operating-system "store" applications will provide
   further safeguards.
  It is true that the package systems of *nix systems is helpful
   in terms of authenticity and sourcing of OS-integrated builds and 
   their updates.  There is no such source for 80% of the community of
   Apache OpenOffice users.  Before, that community was served by Sun,
   Oracle, Novell, and IBM.  Now, but for the Apache OpenOffice project
   and The Document Foundation, there are no prominent, responsible parties
   for distributions to the Windows and Mac communities of users.
  I do agree that this can be considered a project-specific arrangement
   and does not need to be under ASF governance as strictly as for source
   distributions, so long as the "more-than-merely-convenient" binary
   distributions do not reflect badly on the foundation.  Guidance would
   still be helpful, since there are many projects and podlings need some
   touchstone to encourage good behavior in this area.


Thanks,
Roman.

P.S. To be super explicit: I'm not saying that binary artifacts should be
banned, rather that a binary artifact compiled by a member of a project
is no different from one compiled by RedHat or Debian and thus requires
no special treatment whatsoever.

-
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: [VOTE] Apache OpenOffice Community Graduation Vote

[Dennis E. Hamilton]

Of course, the good-faith reliance on upstream sources always comes to bear, 
even for source-code contributions.  But having access to all source is 
reported by some as being essential for ASF releases and that is tied to the 
notion that the source code is the release.  (This is despite specific 
provision in the treatment of licenses for distributing certain binary 
artifacts in order to avoid license confusion.)

I don't have any clarity on this.  I know that it would be a serious burden to 
some projects if there were restriction to authenticated builds for open-source 
platforms only and/or restriction to exclusively open-source libraries for 
other dependencies not satisfied by the platform itself.  

To the extent that the requirement is for more than IP provenance and license 
reconciliation, I am not clear who is being held to account for any deeper 
scrutiny than that.  Are the PMC votes for a release expected to establish some 
sort of serious attestation concerning the nature of the source?  

Instead, is the requirement of specific source-code availability instead a 
requirement for potential forensic requirements later in the lifecycle of a 
release?  Can this be satisfied without the source be in the release, by 
whatever arrangement and assurance that could be made to ensure its 
availability whenever needed?

I have only question in this area.  I believe there is a definite concern, but 
I am not sure where it has teeth beyond a ritual requirement.

 - Dennis


-----Original Message-
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Monday, August 20, 2012 18:50
To: general@incubator.apache.org
Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote

I do not dispute the existence of other reliable creators of binary 
distributions.  The *nix packagings and installation in consumer desktops are 
notable for the value that they provide.  

I think that experience teaches us that there absolutely needs to be a way to 
obtain and install *authentic* binary distributions made using the release 
sources with a proper set of options for a given platform.

It is near impossible to provide end-user support and bug confirmation without 
agreement on the authentic bindist that is being use and that it is a bindist 
made from known sources.

And there are enough fraudulent distributions out there that this is critical 
as a way to safeguard users.

For that reason alone, there needs to be an authenticated bindist, especially 
for Windows, the 80% that garners the focused attention of miscreants and 
opportunists.  

That is also the reason for wanting signed binaries that pass verification on 
Windows and OS X.  There needs to be a way for everyday users to receive every 
assurance that they are installing an authentic bindist and that it is 
verifiable who the origin is.  I suspect that reliable packagers of unique 
distributions (including any from IBM) will provide their own verifiable 
authenticity.

 - Dennis

-Original Message-
From: drew [mailto:d...@baseanswers.com] 
Sent: Monday, August 20, 2012 18:00
To: general@incubator.apache.org
Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote

[ ... ]


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

RE: key signing - issues

[Dennis E. Hamilton]

Following up on Benson's statement, I want to confirm my understanding of how 
the "LDAP key" connection works:

1. I generate an OpenPGP key pair for myself.  I use orcmid@ a.o as an e-mail 
address associated with the PGP cert.  I put the public key in an appropriate 
public place where it can be found by the fingerprint, my name, orcmid@ a.o, 
etc.  (Does it matter which established public place is used for this part?)

2. I go to the Apache Account Utility,  and log on with 
my Apache credentials for Apache User Name/ID orcmid.

3. I add the OpenPGP Public Key Primary fingerprint in the appropriate field of 
the account details.  

4. Somewhere there is a way that anyone who sees a signature with the private 
key (1) can confirm that public key cert carrying that fingerprint is the one 
in (3).  

I have to say "somewhere" because the link on the ASF Committers by ID page, 
 is a 404. A little 
URL fiddling reveals that the correct link is 
.  When I complete the ceremony (3), 
I assume orcmid.asc will appear in that directory by virtue of my having 
completed (1) successfully.

So, the level of trust, in this case, is via the fact that I used the Apache 
credentials to record the details of a key pair for which I am expected to have 
the exclusive possession of the private key.  And my possession of the Apache 
credentials for ID orcmid establishes the connection between the PGP key, 
orcmid, and the person who provided the iCLA for which ID orcmid was 
subsequently granted.

A repudiation, along with the public ways of doing that, is by removing the 
fingerprint from my Apache Account record, yes?  I might want to leave an 
expired-but-not-repudidated fingerprint there, since it is needed to check old 
signatures?  (The Account page appears to limit me to two such keys, but that 
may just because there are no entries just yet.)

If I understand this correctly, I have to agree with Benson that it can't be 
any better than this.  

The fundamental link is the association that is established by my being 
responsible for the secrecy of the private key and my Apache "persona" being 
tied to the possessor of that Apache account, how that account was approved, 
how the credentials were delivered for it to the provider of the iCLA, and the 
exclusive control of the setting of the fingerprint in the account record.  

It appears that key-signing ceremonies add nothing to this.  My public 
appearance might reveal that orcmid is an imposter or that the iCLA is 
fraudulent or something, but that applies to the chain of committer 
establishment trust, not whether I can convince folks to sign my public-key 
cert.

I agree that all of this needs to be documented in an understandable way, and 
that members of the public need to know how to verify and authenticate 
signatures created with these private keys.

 - Dennis





-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Sunday, October 07, 2012 08:32
To: general@incubator.apache.org
Subject: Re: key signing - issues

Shane,

After reading all the responses, I'm no longer very interested in
pushing the idea of key signing. I am much more interested in
explaining to users the existence and use of the LDAP keys.

We can explain: "If something is signed with a key associated with an
Apache committer via the Apache infrastructure, then you have
assurance of the pathway from Key -> Apache Account -> CLA on file.
Even if the key is not signed at all, this tells you that the
signature comes from the named Apache account."

The bigger the Foundation gets, the less likely that any number of key
signing parties at ApacheCons are going to put a dent in all the
possible release managers.

I suppose that comdev could try to organize a web of key signing
parties that aren't at ApacheCons.

--benson

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

[Dennis E. Hamilton]

I don't understand what "keys from LDAP" are?

Are these the same as keys whose fingerprints a ASF committer registers in 
their account or something else?

 - Dennis

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Monday, October 08, 2012 08:54
To: general@incubator.apache.org
Subject: Re: key signing

[ ... ]

In my opinion, that's vanishingly unlikely, and so the best we can do
is to allow users to verify that the signature was, in fact, made by
the 'Apache hat' that it claimed to be made by. Using the keys in
KEYS, or the fingerprints from LDAP, seems the best they can do.

[ ... ]


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

RE: key signing

[Dennis E. Hamilton]

+1

An Apache CA would also be handy for setting up code signing (the kind carried 
in the code package and recognized by operating systems, not an external 
signature of the kind being discussed here).

To clarify one aspect of the Apache Trust Chain.

It is not about email.  It is about the public-key cert being on 
 and the fingerprint of that cert 
being in the Account Record of the identified committer.  It is the fact that 
only a person with the committer's credentials (or a highly trusted internal 
party) can manipulate the Account Record to establish a fingerprint.  The 
appearance of a name@ a.o e-mail as an identifier in the cert is not a 
free-standing claim.  It is verifiable by confirming the Apache Trust Chain 
related to (1) that committer Apache Name/ID and (2) the cert/fingerprint 
provided for that identity in the keys/committer/ directory.  Someone who knows 
to do this can mark that certificate as one that is trusted in their own store 
of certs without contributing to any WoT.

The security issues are around privacy of the committer's Apache credentials 
(same as privacy of a secret key), security of modifications to Account Records 
(and whatever audit trails there are), and security of the keys/committer 
records.  That is the transitive trust dependency for the external signatures 
claimed to be made by that committer.  The foundation of the chain is the 
validity of the issuance of the committer ID and credentials and their 
connection to an iCLA for the e-mail to which the credentials were delivered.  

This process also depends on the trustworthiness of those individuals who 
produce and issue the initial credentials and operate the services on which the 
trusted artifacts are retained.  Since that is always the foundation, 
additional web-of-trust ceremony may be satisfying but the attack surface is 
right here and unchanged.  (One could even argue that reliance on WoT increases 
the attack surface, especially if folks rely on the WoT to the exclusion of the 
Apache Trust Chain.)

I think the fundamental problems are that (1) this trust structure is not 
widely understood, even among (new) committers, and (2) the process is opaque 
to external parties who might want to know how an external signature earns ASF 
trust.  (I'm not certain that there are such folks, apart from security wonks 
and vulnerability seekers, but that is no reason to avoid an understandable, 
transparent account.)  

 - Dennis

PS: I do think one might want to threat-model the existing attack surface and 
see what can be done there.  I am not sure it mitigates against malicious 
introduction of exploitable vulnerabilities, presumably the real concern.  That 
requires examination of a much broader attack surface around all the ways code 
can be injected and vulnerabilities passed undetected into an Apache release.  
There is a high level of trust placed in the processes used, and it has little 
to do with the trustworthiness of digital certificates.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Wednesday, October 10, 2012 04:20
To: general@incubator.apache.org
Subject: Re: key signing

I could argue that we'd be better-served with X.509 certs.
An Apache CA could be programmed to issue a cert to each committer.
Users would just verify the source CA, and we'd accomplish the goal of
giving users assurance.


[ ... ]


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

RE: key signing

[Dennis E. Hamilton]

Just for completeness for building an understanding what I have been 
capitalizing as the Apache Trust Chain:

 1. There must also be understanding of the cert expiration and cert revocation 
cases.

 2. As a demonstration for how it all comes down to the Apache logon for 
committers, consider the way that an SSH certificate is established for a 
people.apache.org account.  The initial login is with the Apache Name/ID 
credentials and the password that goes with the account.  Only then can the 
user upload an SSH certificate to the appropriate location for a 
certificate-based SSH login.  I'm not suggesting that is a particular weakness 
(although folks provide a fair amount of trust to their peers on 
people.apache.org).  The point is that it also stems from the foundation of the 
Apache Trust Chain.  And so do the authz record entries, of course.

-Original Message-
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Wednesday, October 10, 2012 09:28
To: general@incubator.apache.org
Subject: RE: key signing

[ ... ]

I think the fundamental problems are that (1) this trust structure is not 
widely understood, even among (new) committers, and (2) the process is opaque 
to external parties who might want to know how an external signature earns ASF 
trust.  (I'm not certain that there are such folks, apart from security wonks 
and vulnerability seekers, but that is no reason to avoid an understandable, 
transparent account.)  

 - Dennis

PS: I do think one might want to threat-model the existing attack surface and 
see what can be done there.  I am not sure it mitigates against malicious 
introduction of exploitable vulnerabilities, presumably the real concern.  That 
requires examination of a much broader attack surface around all the ways code 
can be injected and vulnerabilities passed undetected into an Apache release.  
There is a high level of trust placed in the processes used, and it has little 
to do with the trustworthiness of digital certificates.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Wednesday, October 10, 2012 04:20
To: general@incubator.apache.org
Subject: Re: key signing

I could argue that we'd be better-served with X.509 certs.
An Apache CA could be programmed to issue a cert to each committer.
Users would just verify the source CA, and we'd accomplish the goal of
giving users assurance.


[ ... ]


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

[Dennis E. Hamilton]

There is value of the external signature for attesting something about the 
creation of the artifact.  The digest simply demonstrates that the artifact is 
intact.

I've already agreed that the signing of other people's certificate is not that 
valuable in the case of Apache releases.

Because of the security of Apache credentials, confirming a certificate is 
easy: Import the certificate located on the Apache site into your favorite key 
(certificate) store.  Send an encrypted message to the corresponding name@ 
apache.org.
Have the recipient send the decrypted message back to you encrypted with your 
public key (also identified in the message, etc.)

If the recipient doesn't receive it or can't return the decrypted message, 
don't trust the public key cert.  You can probably indicate the key is trusted 
by you, locally, if the exercise succeeds.  You don't have to do a WoT signing 
though.

This is a pretty standard ceremony for an e-mail "non-persona."  

 - Dennis

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Wednesday, October 10, 2012 16:45
To: general@incubator.apache.org
Subject: Re: key signing

I've read this entire thread (whew!), and would actually like to throw out
a contrary position:

No signed keys.

Consider: releases come from the ASF, not a person. The RM builds the
release artifacts and checks them into version control along with hash
"checksums". Other PMC members validate the artifacts for release criteria
and matching checksums, voting +1 via version control.

All of the above is done via authenticated ASF accounts. The above
establishes an ASF release.

Please explain how "keys" are needed for this ASF release? Consumers are
already told to verify the SHA1 and nothing more. I doubt any more is
needed.

(assume secure Infrastructure)

Cheers,
-g
[ ... ]


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

RE: key signing

[Dennis E. Hamilton]

+1

I'm assuming Benson means the digest (SHA1) by "signature."  Using those from 
the Apache site is probably the first-line for power users and about as much 
extra effort that can be expected.  The use of download utilities that reliably 
check signatures from authentic sources is a small boost -- for power users.  

 - Dennis

The verification of the external signatures also on the Apache site is 
something that I believe is material only for review of the release candidate 
and also any subsequent forensics work if there is a problem.  In all cases, 
the public-key cert should be obtained from the Apache site keys folder.  

The most-significant improvement in this, for binaries at least, is the use of 
embedded signatures that are verified as part of operating-system functions on 
the relevant platform.  That's as low-friction as it gets and users don't have 
to take any special steps at all, other than pay attention to the warning 
dialogs that the platform coughs up.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Thursday, October 11, 2012 05:20
To: general@incubator.apache.org
Subject: Re: key signing

Greg having more or less restated my opening position ("how do we
improve assurance for probable actual users"), I'd throw in another
bit.

Threat analysis is all well and good, but it please don't forget the
biggest principle here. If the assurance mechanism is so abstruse that
users won't understand it, or so complex that they can't use it, then
they won't, and they will be at the mercy of the dumbest possible
attack.

Before we worry about MITM, or subverted Apache infrastructure, I
claim that we should be offering users a simple, easy-to-understand
means of protecting against fraudulent packages. As per Greg, the
signatures do that. As per me, unsigned keys verified against Apache
infrastructure do that.

Over and above that, we could then ask, 'how could we improve
protection against most complex problems?'

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

[Dennis E. Hamilton]

I see I committed the sin of using "signature" two different ways, below.

I mean the file digest value (digital hash, SHA1) for what power users and 
appropriate downloader utilities check.

I mean the external digital signature and the signers public-key cert in the 
Apache keys with regard to checking digital signatures on release candidates 
and in any subsequent forensic investigation/confirmation.  

 - Dennis

-Original Message-----
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Thursday, October 11, 2012 08:19
To: general@incubator.apache.org
Subject: RE: key signing

+1

I'm assuming Benson means the digest (SHA1) by "signature."  Using those from 
the Apache site is probably the first-line for power users and about as much 
extra effort that can be expected.  The use of download utilities that reliably 
check signatures from authentic sources is a small boost -- for power users.  

 - Dennis

The verification of the external signatures also on the Apache site is 
something that I believe is material only for review of the release candidate 
and also any subsequent forensics work if there is a problem.  In all cases, 
the public-key cert should be obtained from the Apache site keys folder.  

The most-significant improvement in this, for binaries at least, is the use of 
embedded signatures that are verified as part of operating-system functions on 
the relevant platform.  That's as low-friction as it gets and users don't have 
to take any special steps at all, other than pay attention to the warning 
dialogs that the platform coughs up.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Thursday, October 11, 2012 05:20
To: general@incubator.apache.org
Subject: Re: key signing

Greg having more or less restated my opening position ("how do we
improve assurance for probable actual users"), I'd throw in another
bit.

Threat analysis is all well and good, but it please don't forget the
biggest principle here. If the assurance mechanism is so abstruse that
users won't understand it, or so complex that they can't use it, then
they won't, and they will be at the mercy of the dumbest possible
attack.

Before we worry about MITM, or subverted Apache infrastructure, I
claim that we should be offering users a simple, easy-to-understand
means of protecting against fraudulent packages. As per Greg, the
signatures do that. As per me, unsigned keys verified against Apache
infrastructure do that.

Over and above that, we could then ask, 'how could we improve
protection against most complex problems?'

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

[Dennis E. Hamilton]

@Nick

I don't understand the supposed attack vector concerning the file digests being 
of no value and the WoT being essential.

 - Dennis

ANALYSIS

So long as the digest value is obtained from a reliable read-only source, it 
doesn't matter where the file comes from, the digest can be verified.  This 
will protect against and help detect a poisoned mirror site or a third-party 
redistribution that substitutes an inauthentic artifact.  That is, in fact, a 
very big deal and it defends against exploits that happen too regularly.

If the reliable read-only source is compromised, that means an adversary has 
managed to (1) replace the file in Apache custody, and (2) replace the digest 
that applies to that artifact.  (Or just replace the digest and make the 
authentic file look bogus and the poisoned downloads look authentic.)  If 
substitution of the file-digest pair is achievable, providing a different 
external signature can't be much harder, although the exploit might achieve the 
intended purpose without that. Introducing a verifiable external signature that 
finds a counterfeit public-key certificate on a key service may extend the ruse 
a little longer. 

The exploit continues until some Apache folk or security-proficient external 
party detect (1) the substitution or (2) a counterfeit external signature or 
(3) confirms that the external signature is not verifiable on the substituted 
file and digest pair.

I don't see the WoT as much of a factor if this exploit occurs.  It comes down 
to how quickly the exploit is detected, the damage detected, and a mitigation 
put in place.  I assume that infrastructure defense-in-depth measures have to 
expose the fact of an exploit, even if an insider is involved.  At the worst, 
it might be necessary to recall a release.

This assumes that the exploit is by exploit against the read-only distribution 
material in Apache custody.  

If the exploit is by tampering with a release prior to its approval, that is an 
entirely different problem, since it means the digital artifacts have been 
approved as authentic.  Even so, I think it is the trustworthiness committers, 
release managers, and PMC approval that matters here, not the WoT, and that is 
bolstered by the Apache Trust Chain.  The WoT does not protect against someone 
subsequently being revealed to have committed a bad act.  (The revocation of 
trust and how it is noticed is an aspect of WoT that I have not investigated.)

-Original Message-
From: Nick Kew [mailto:n...@webthing.com] 
Sent: Thursday, October 11, 2012 06:46
To: general@incubator.apache.org
Subject: Re: key signing


On 11 Oct 2012, at 09:57, Noah Slater wrote:

> On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew  wrote:
> 
>> 
>> You have to extend that assumption not only to our infrastructure but to
>> every proxy that might come between us and a user, and that might
>> substitute a trojan along with the trojan's own SHA1.
>> 
> 
> The same reasoning holds for the .asc file.

Only if there are no WOT paths to improve confidence in it.

And only if noone ever detects the imposter, which is a lot less
likely with a trojan PGP key (someone in particular is being
impersonated) than a checksum (owned by noone).

-- 
Nick Kew


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

[Dennis E. Hamilton]

@Marvin,

Can you say more about Multi-factor?  I know commonly-claimed schemes involve 
the same factor multiple times (e.g., more things that a party knows, like Aunt 
Gracie's dress size).  I agree that confirming a picture ID (something the 
individual has) is another factor.  What other factors are you thinking of?  (I 
am not sure how many factors signings by others count as new factors.)

 - Dennis

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Thursday, October 11, 2012 11:46
To: general@incubator.apache.org
Subject: Re: key signing

On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew  wrote:
> On 10 Oct 2012, at 17:04, Marvin Humphrey wrote:
>
>> In my opinion, we have sufficient expertise here at the ASF to devise an
>> authentication protocol whose reliability exceeds that of individuals
>> participating unsupervised in a web of trust, particularly if the protocol
>> were to incorporate archived video and auditing by a PMC.
>
> That may be, but I don't think general@incubator is the place to develop it.

The Incubator is where the acute need exists, because we are bootstrapping
entire communities where no one is linked into the web of trust.

For existing projects, the longer they've been around, the more likely that a
significant number of committers have attended an ApacheCon key-signing party
or otherwise had an opportunity to get their keys signed.  But here, we see
new RMs all the time who are isolated.  It would be nice if we had some
systematic way of integrating them.

In the absence of a formal protocol, suggesting that new RMs go find someone
to sign their key is unsatisfying, since at least some of the time that's
likely to mean email contact alone and potentially a tenuous relationship to
the signer.  The alternative of suggesting that new RMs with a release VOTE
pending go find a local key-signing party to attend seems unrealistic.

In my opinion, general@incubator is an appropriate venue to explore ways in
which the system can be improved.  That will necessarily mean talking about
some implementation details because it would be silly to assess feasibility
otherwise, but please note that the proposed protocol was labeled a "rough
draft".  Maybe we can call it "sample" instead, implying the need to start
over later -- it doesn't matter to me.  I had always imagined that if the
protocol were to move forward it would undergo a process of relentless
scrutiny and refinement by interested parties outside the Incubator.

The payoff is that with a protocol in place which enables us to establish
identity to a high degree of certainty and add an individual to web of trust
on a short turnaround, the Incubator need not approve another release signed
by an RM who is not linked into the ASF web of trust.

> FWIW for myself I like to back WOT paths by checking manually,
> and feel best about it when I can identify a chain of trust involving only
> people I trust to be savvy enough not to sign keys willy-nilly.
> PGP/GPG support different levels of trust, so the model helps there.

The PR challenge is a separate question.  I will acknowlege that I have been
taken aback by the extreme skepticism in what I view as a straightforward
application of the principles of multi-factor authentication, faithful to
the spirit and letter of the GnuPG docs.

It pains me that the only outcome of this discussion may be that it gets even
harder to make an incubating release. :(

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

[Dennis E. Hamilton]

@Benson

There are two things that can be done, with (2) being what
matters to you, it seems to me:

 1. The committer can upload the fingerprint-associated public key
to the PGP Global Directory at .

That will initiate an e-mail verification for every e-mail 
in the pubkey record (cert for short).  The procedure and its
risks are described in the Key Verification Policy, 
.  

The key will not be published on that server until the e-mail 
verification occurs.  It will there be countersigned by the PGP 
Global Directory Verification Key.  Note that there is a 
revocation procedure and revocation (i.e., removal from that 
directory) will happen if one of the periodic e-mail 
confirmations fails.

Here's an example of how those counter-signings show up:



The e-mail verification is vulnerable (as described in the Key 
Verification Policy) in much the same way that Apache credentials 
and Account records are vulnerable with respect to the use of 
e-mail association as authentication.

 2. In conjunction with checking for the key at (1), or independently, 
the advice from the PGP folk is that an independent means of 
identity agreement should be employed.  So long as you have a 
way of doing that, and the other party can confirms that is the 
public key for which they possess the secret key, it seems 
appropriate to countersign the public key.  

Technically, this should not rely on the e-mail address. Use a 
different channel whereby the committer confirms identity,
including having or knowing something that satisfies you.
Since you can be confident about your own public key, have
the party send you an encrypted message that satisfies you 
concerning the identity of the originator.  That message plaintext 
could also be signed by the party, demonstrating their possession 
of the private key for the pubkey in question.  

The odd thing about the WoT is that it depends on how much *you* 
are considered dependable in verifying the cert creator's identity. 
Each inspector of the committer certificate determines
their own trust of the counter-signing signatures (whether by
WoT transitivity rules or their own personal knowledge/trust). 


 -- Dennis 

Since I dropped in on this thread, I went through the key registration 
process for a unique key that only has orcmid@ a.o as the associated 
e-mail.  The public key was put wherever the Gnu Privacy Assistant puts 
them.  I uploaded the public key to the MIT PGP key server myself.  
I also went through the PGP Global Directory verification procedure.
I put the fingerprint in my Apache Account record and a version of the
cert magically appeared at 
.  (I'm not sure
where this is fetched from, so I'm not sure how counter-signed versions
show up.)
  I am continuing to experiment.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Monday, October 15, 2012 05:46
To: general@incubator.apache.org
Subject: Re: key signing

Now I have a practical problem. I've received email from a committer
on a project. I have met him in person -- some years ago. I helped him
get started at Apache. His fellow PMC members are telling him that
it's *necessary* for him to come up with one or more signatures on his
key to act at an RM.

Choices:

1) send email to him and his PMC fellows, referencing this thread, as
evidence that key signing is nice but optional.

2) go ahead and sign his key based on simple email. I'm a very bad
paranoid; I'm not interested in the idea that some person out there is
anxious to undermine Apache and has captured one or both or our gmail
accounts, or is acting as an MITM. I have plenty of writing-style
evidence that this email address disgorges communications from him.

3) Engage in some more or less baroque protocol involving skype or
carrier pigeons.

Anyone care to try to tell me what to do? My views are colored by my,
and his, complete disinterest in the WoT outside of its use at Apache,
and my conviction that I do, indeed, know that this key is under the
control of a particular person who signed a CLA and got voted in as a
committer of a particular project.

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

[Dennis E. Hamilton]

Ah, so the key servers federate!  Cool.

Thinking about the Man-in-the-Middle PKE attack, that is a little difficult 
with OpenPGP.

That involves a man in the middle substituting their public key for mine and 
also arranging to intercept messages sent to me that are encrypted using the 
MitM public key for decryption and re-encrypted with my actual public key.

Since I can easily tell whether or not the public key retrieved from any one of 
the key servers is one that goes with the secret key I have, it is pretty 
difficult to prevent me from detecting a public-key substitution.  And I can 
check even deeper than matching fingerprint reports.  

I think that is enough for two distant participants who are known to each other 
to find a way to confidentially exchange something private known only to the 
two of them as a way to confirm that their respective public keys are authentic 
and worthy of signing.  It does depend on our actually being known to each 
other in a way that allows such a procedure to be contrived.

I'm going to try that with a distant friend of mine.

 - Dennis

-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Monday, October 15, 2012 11:22
To: Dennis E. Hamilton
Cc: general@incubator.apache.org
Subject: Re: key signing

Dennis E. Hamilton wrote on Mon, Oct 15, 2012 at 11:07:56 -0700:
> <https://people.apache.org/keys/committer/orcmid.asc>.  (I'm not sure
> where this is fetched from, so I'm not sure how counter-signed versions

Currently keys.gnupg.net

https://svn.apache.org/repos/asf/infrastructure/site/trunk/people/keys-fetch.py

> show up.)

-
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: [PROPOSAL] Apache Linda

[Dennis E. Hamilton]

I've been biting my tongue all of this time and I can't resist any longer.

The missing case is "Lovelace" (bad joke), 

although WebLace is about linking too.

There's no need to borrow a human nick.

 - Dennis

-Original Message-
From: Nandana Mihindukulasooriya [mailto:nandana@gmail.com] 
Sent: Sunday, November 18, 2012 01:51
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Apache Linda

I have to say when I heard the name "Linda", I really liked it because it
is short, catchy, easy to remember and goes well with Linked Data. But I
totally agree that it is good to avoid any name conflict issues or
trademark issues in this early stage where it is easily possible. I was
thinking whether LindaWeb or WebLinda would be an alternative choice.

Best Regards,
Nandana

On Sun, Nov 18, 2012 at 4:14 AM, David Crossley  wrote:

> Another possblility is "Adnil" being reversed linked data.
> A nice twist.
>
> Anyway, up to the podling.
>
> There are some useful Incubator resources for quickly dealing
> with the Name issue. Here are some:
> http://incubator.apache.org/guides/graduation.html#notes-names
> http://incubator.apache.org/guides/names.html
> http://incubator.apache.org/guides/proposal.html#name
>
> There great advice in this thread that could be added
> to docs.
>
> -David
>
> -
> 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: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))

[Dennis E. Hamilton]

Not so fast about dispensing with Category B requirements for pointers to 
source code.

In MPL 2.0, a common case, it is very clear that location of the source code is 
one of the requirements for distribution of the code in executable form or 
within a larger work (distributed in binary), that there must be identification 
of the origin of the code and where source code is available.  It is 
insufficient to simply include the license (by reference or otherwise).  

MPL 2.0 has a handy Appendix (which I have never seen followed, but I don't get 
out much) that stipulates a suitable notice.  The key is that it must be 
possible for a recipient of the executable to directly find the specific source 
code at a suitably archival location.

This is also a requirement for distribution of most Category X works in binary 
form, and that applies in some cases where Category X licenses are bundled in 
binary distributions under sanitary conditions that satisfy ASF requirements.

 - Dennis

PS: That these requirements are typically satisfied in the breach is not, it 
seems to me, something that is appropriate for the ASF to countenance.  That 
there are projects out there that have never complied with such requirements is 
not justification.  For me, it does not serve the public interest, nor does it 
demonstrate the care for the provenance of contributions (and dependencies) 
that should be the norm.  Most of all, being careless about this undervalues 
the gift that such dependencies represent to projects that find reuse more 
convenient than not.

PPS: There is also a forensic value to satisfying these license requirements.  
In these days of rapid disclosures of security flaws all over the landscape, it 
is important for a recipient of executable code to know whether or not 
vulnerability disclosures apply to dependencies in the distribution they are 
relying upon and whether mitigation is called for.  (Although this is also of 
some benefit to adversaries, it must always be assumed that determined 
adversaries already know.)

-Original Message-
From: Sergio Fernández [mailto:sergio.fernan...@salzburgresearch.at] 
Sent: Tuesday, April 23, 2013 00:32
To: general@incubator.apache.org
Cc: Marvin Humphrey
Subject: Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 
3.0.0-incubating (RC8))

Hi Marvin,

thanks for your time analysing our release. Please, find my reply inline.

On 18/04/13 02:30, Marvin Humphrey wrote:
> On Wed, Apr 17, 2013 at 11:00 AM, Sebastian Schaffert  wrote:
[ ... ]
>> - for dependencies of category B, [2] specifies that "Although the source
>>must not be included in Apache products, the NOTICE file, which is
>>required to be included in each ASF distribution, must point to the source
>>form of the included binary (more on that in the forthcoming "Receiving
>>and Releasing Contributions" document).", a fact that is not mentioned in
>>any of the other documents.
>
> This passage has somehow escaped my notice until now.  Based on my
> understanding about the origins of the NOTICE file, it does not ring true.  It
> seems to me that what works for category A should also work for category B:
> reference/quote the license in LICENSE and address mandatory attribution
> requirements in NOTICE.  The goal is to satisfy the licensing requirements of
> the dependency, not to give credit -- so IMO linking only makes sense if
> that's a requirement of the dependency's license.

So keep in NOTICE only those which require additional attribution 
requirements?

> Does anybody know any TLPs that are actually following the advice to link to
> source for category B dependencies in binary NOTICE files?

[ ... ]


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

RE: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))

[Dennis E. Hamilton]

I agree, I didn't mean to generalize about Category B "notice" requirements.

With regard to there being a standard notice for MPL, I was careless. MPL 1.1 
had a template notice.  MPL 2.0 just has section 3.2(a):

  If You distribute Covered Software in Executable Form then:

  a.  such Covered Software must also be made available in Source
  Code Form, as described in Section 3.1, and You must inform 
  recipients of the Executable Form how they can obtain a copy 
  of such Source Code Form by reasonable means in a timely manner, 
  at a charge no more than the cost of distribution to the 
  recipient; [...]

The license is careful to discriminate between Source Code Form and Executable 
Form, and there is little detail on notifications associated with an Executable 
Form for MPL 2.0.

I would think that providing the information in NOTICE satisfies the 
requirement.  It would be much easier than coming up with another artifact 
beside LICENSE and NOTICE, which knowledgable folks already know to look for.  
I don't have any insight on dealing with the fact that the dependency is 
build-specific, however the information is provided.

 - Dennis




-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Tuesday, April 23, 2013 10:43
To: Marvin Humphrey
Cc: orc...@apache.org; Sergio Fernández; Roy T. Fielding; 
general@incubator.apache.org
Subject: Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 
3.0.0-incubating (RC8))

On 23 April 2013 18:05, Marvin Humphrey  wrote:

> On Tue, Apr 23, 2013 at 8:39 AM, Dennis E. Hamilton 
> wrote:
> > Not so fast about dispensing with Category B requirements for pointers to
> > source code.
>
> Thank you for the specific information about the MPL.  What I said was
> this:
>
> The goal is to satisfy the licensing requirements of the dependency,
> not
> to give credit -- so IMO linking only makes sense if that's a
> requirement
> of the dependency's license.
>
> We must not treat linking as a requirement of ALL category B licenses
> because
> SOME of them require it.
>
>
If the source code URL is required, then the question arises: does it
*have* to go in the NOTICE file?
Indeed is this one of the functions of the NOTICE file?
Or should it be documented somewhere else?


> Marvin Humphrey
>


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

RE: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

[Dennis E. Hamilton]

Four suggestions:

 1. Add a UID having your Apache ID, randgalt@ apache.org, in that PGP 
public-key certificate.  You can indicate that it is your preference for code 
signing, if you desire.

 2. Log into your randgalt@ a.o profile at  and provide 
the fingerprint of your key as part of your profile.  This will accomplish two 
things: (1) It establishes that the fingerprint was provided by someone having 
the ASF credentials for randgalt@ a.o; (2) it causes the public key to be added 
to a secure location as file 
.  That file is 
regularly synchronized with PGP key services and confirms that it is the key 
provided by randgalt@ in step (1) and also reflects (web-of-trust) 
certifications of that key by others as well as any revocation if that becomes 
necessary.

 3. BONUS RECOMMENDATION.  Do not put a copy of the public key in the 
repository.  Instead, put a link to 
 there, if desired.  If 
it is in a file called KEYS, update the instructions to refer to the locations 
in the committer keys folder.  (If there will be many release managers and 
signers in the future, you can instead instruct users to obtain all Curator 
committer keys from  once 
Curator becomes an ASF top-level project.)

 4. GRAND PRIZE RECOMMENDATION.  For all external signatures that you create, 
add to the ascii-armored signature text (outside of the armor) a link to 
.

The idea is to use access to your Apache profile as an additional factor beyond 
your self-signing of the certificate and any web-of-trust certifications of 
your certificate.  It also lets those non-ASF folk who desire to verify 
signatures know whose signature the verification is expected to confirm and 
that the signer is an ASF committer.

 - Dennis

 
-Original Message-
From: Jordan Zimmerman [mailto:jor...@jordanzimmerman.com] 
Sent: Wednesday, May 01, 2013 13:39
To: general@incubator.apache.org
Subject: Re: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

That was (yet another) misunderstanding on my part. The KEYS are now in the 
standard (?) location:

http://www.apache.org/dist/incubator/curator/KEYS

On May 1, 2013, at 1:32 PM, Marvin Humphrey  wrote:

> On Wed, May 1, 2013 at 1:07 PM, David Nalley  wrote:
>> While we are at it, a link to your project's KEYS file would be
>> helpful as well.
> 
> Just unzip the archive. ;)
> 
> Curator folks, please find another way to distribute the KEYS file.
> Distributing it embedded in the source archive is worthless at best.
> 
> 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: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

[Dennis E. Hamilton]

Regarding (4),

Once you've created the signature file, simply prepend text to it in front of 
the 

-BEGIN PGP SIGNATURE-

line.  You can have something like

Signature by Release Manager Jordan Zimmerman
Public Key Certificate: 
  
-BEGIN PGP SIGNATURE-
[ ... ]

I suppose it would be useful to also link to a page on how to check the 
signature.

It seems strange to have that in the clear, but it is harmless.

I just confirmed that text in front of the initial ASCII armor line is simply 
ignored by GnuPG and I suspect all other PGP signature verification 
implementations.

 - Dennis

PS: Here's a page that describes how to check, although a group of keys is 
recommended in that case:
.

-Original Message-
From: Jordan Zimmerman [mailto:randg...@apache.org] 
Sent: Wednesday, May 01, 2013 15:54
To: general@incubator.apache.org
Subject: Re: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

> 1. Add a UID having your Apache ID, randgalt@ apache.org, in that PGP 
> public-key certificate.  You can indicate that it is your preference for code 
> signing, if you desire.
That UID is there already. Can you explain what's missing?

> 2. Log into your randgalt@ a.o profile at  and 
> provide the fingerprint of your key as part of your profile.
done

> 3. BONUS RECOMMENDATION.  Do not put a copy of the public key in the 
> repository.
Already removed. My .asc file should show up in /keys/committer/ soon.

> 4. GRAND PRIZE RECOMMENDATION.  For all external signatures that you create, 
> add to the ascii-armored signature text (outside of the armor) a link to 
> .
No comprende. I'll research how to do this.

-JZ
-
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: [META DISCUSS] talking about the overall state of this PMC

[Dennis E. Hamilton]

It's often called a dead-man's switch.  I think the term applied originally to 
locomotive engineers and also metro car drivers.  (I'm not sure what a dead 
pilot switch could accomplish in an aircraft.)

I think having mentors review and "sign" PPMC status reports is an effective 
dead mentor's switch [;<).

 - Dennis

-Original Message-
From: Alan Cabrera [mailto:l...@toolazydogs.com] 
Sent: Saturday, May 11, 2013 10:10
To: general@incubator.apache.org
Subject: Re: [META DISCUSS] talking about the overall state of this PMC


On May 11, 2013, at 7:33 AM, Joseph Schaefer  wrote:

> Frankly I find the notion that the board will do a better job of MENTORING
> these projects than the IPMC to be batshit insane, but that's just me.
> We need manpower, and there is plenty of that available amongst the competent
> volunteers who actively participate in these projects.  Let's just do
> what's easiest for once and promote these folks to the IPMC in order
> to get the job done right.  It's a proven model that we need to stop
> fighting.


Yes, shuttling the kids off the the grandparents is not going to solve 
anything.  If individuals on the board have the bandwidth to help they should 
come over here. There's nothing specific about the auspices of the board that 
would improve the situation.


I personally think that we have "almost" enough people to mentor.  I think that 
the burnout comes from our constant churning of policy and lack of tooling to 
make mundane tasks easier.

For example, maybe
better reminders for reports
automatic nudging of mentors who have not signed reports
dead pilot buttons to detect inactive mentors (Is it called a dead pilot button)
maybe a standard to podling releases to make vetting easier - i.e. apply tooling
changes/additions to vetting procedures taking place outside of release votes. 
(ok not a tooling issue)


Regards,
Alan



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

RE: Correct process for signing keys?

[Dennis E. Hamilton]

@Christian

The other advantage of the people list is that it is automatically updated from 
the federation of PGP key servers so it reflects the latest "web of trust" and 
also, I presume, any revocation.  

In some cases, PMC wide is a bit too generous though.  I think the release 
manager's Apache ID is better, using . 
 This is probably more confidence-inspiring that the web of trust itself for 
those who do not participate in Apache projects and don't know who those folks 
who've counter-signed the certificate happen to be.  In that case, the lock to 
an ASF committer is valuable.  (It is unfortunate that committers and 
especially release managers are often not visible by their @apache.org, 
thus providing even more confidence in the connection for observers.)

 - Dennis

PS: I notice I just did the thing I'm complaining about.  But I don't think 
orcmid@ a.o is subscribed to this list [;<).

-Original Message-
From: Christian Grobmeier [mailto:grobme...@gmail.com] 
Sent: Sunday, June 2, 2013 01:24 AM
To: general@incubator.apache.org
Subject: Re: Correct process for signing keys?

Hi Andrew,

here are some basic docs:

http://www.apache.org/dev/release-signing.html
http://www.apache.org/dev/openpgp.html#update

I could not find information on your specific question. At log4php we were
curious recently about the same and decided to go with this:
http://www.apache.org/dist/logging/log4php/KEYS

But we made sure it would match this:
https://people.apache.org/keys/group/logging-pmc.asc

Basically my understanding is the one from people would be fine alone.
There is some danger people would take the KEYS file from a mirror which is
to my knowledge not possible from people.

My 2 cents- hopefully somebody with more knowledge on that matter (infra)
can add a note.

Cheers



On Thu, May 30, 2013 at 10:44 PM, Andrew Phillips wrote:

> Hi all
>
> Apologies in advance if this is not the correct audience for this
> question: what is the correct process now for publishing signing keys for
> releases? jclouds currently has a KEYS file [1]; there is another
> (different) file containing keys in the groups list [2] on people.apache,
> and most individual committers *also* have their personal keys
> automatically retrieved via people.apache (e.g. [3]).
>
> In an email thread on this topic Brian (McCallister) indicated that:
>
>  Upon investigation, if release signing keys are published via
>> https://people.apache.org/**keys/  then
>> we don't need a KEYS file and should remove it.
>>
>> -Brian
>>
>
> In that case, I'd be grateful if you could give some guidance on what the
> validity of the other approaches (KEYS file published somewhere or group
> KEYS file) is, and what we should do with those files, if anything.
>
> Thanks!
>
>
> Andrew
>
> [1] 
> http://www.apache.org/dist/**incubator/jclouds/KEYS
> [2] 
> https://people.apache.org/**keys/group/jclouds.asc
> [3] 
> https://people.apache.org/**keys/committer/andrewp.asc
>
> --**--**-
> To unsubscribe, e-mail: 
> general-unsubscribe@incubator.**apache.org
> For additional commands, e-mail: 
> general-help@incubator.apache.**org
>
>


-- 
http://www.grobmeier.de
https://www.timeandbill.de


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

RE: [PROPOSAL] OData Proposal for Incubator

[Dennis E. Hamilton]

I think one concern here is appropriation of a generic, specified-tied name to 
an implementation, even a reference implementation.

"Apache OData" seems over-reaching in that respect, especially since there are 
other projects, at ASF and elsewhere, that may employ OData bindings and 
services of one sort or another.

-Original Message-
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] 
Sent: Monday, June 17, 2013 08:36 AM
To: general@incubator.apache.org
Subject: [PROPOSAL] OData Proposal for Incubator

Dear ASF members,

We would like to propose the OData project to the Incubator.

The OData Proposal is available at: 
https://wiki.apache.org/incubator/ODataProposal

We welcome your feedback and suggestions.

Thanks!

Stephan Klevenz


[ ... ]



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

RE: [PROPOSAL] OData Proposal for Incubator

[Dennis E. Hamilton]

I think there will be an issue with regard to trademarks and you will have to 
deal with folks seeing the trademark of "Apache OData" as a land-grab at 
"OData" itself.  The simplicity you think is avoiding confusion is, in that 
respect, causing confusion.

In any case, it is always wise to avoid confusion of a (standard) 
specification, even OASIS Standard OData v3.0 or whatever, with the name of an 
implementation.  OASIS is going to make their own claims about some of those 
terms as well, if the past practice is any guide.

 - Dennis

The ODF Toolkit snuck by, much to my dismay, even capturing odf as their 
incubator repository name, but they may have to deal with that to graduate to a 
TLP.

-Original Message-
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] 
Sent: Tuesday, June 18, 2013 06:27 AM
To: general@incubator.apache.org
Cc: dennis.hamil...@acm.org
Subject: Re: [PROPOSAL] OData Proposal for Incubator

Hello Dennis,

Good point! The project naming was a challenge for us and maybe I just can
explain why we prefer Apache OData as project name. The main reason is
search. 

Someone who is interested in OData will use this term and the result page
will today list odata.org as the protocols homepage, Wikipedia which is
fine and the OASIS TC. In future we would like to see that Apache OData is
highly ranked and completes the search result list.

If we use a different name someone has to know this name and has to search
for it explicitly. We would like to keep it simple and avoid confusion.

We had also a look into the ASF project naming guidelines and I think most
of the points there are considered by the name Apache OData.


Regards,
Stephan

On 18.06.13 03:28, "Dennis E. Hamilton"  wrote:

>I think one concern here is appropriation of a generic, specified-tied
>name to an implementation, even a reference implementation.
>
>"Apache OData" seems over-reaching in that respect, especially since
>there are other projects, at ASF and elsewhere, that may employ OData
>bindings and services of one sort or another.
[ ... ]


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

RE: [PROPOSAL] OData Proposal for Incubator

[Dennis E. Hamilton]

Stephen,

I support your choice to have a different name.  

 - Dennis

I'm not sure how "Olingo" is pronounced in Spanish but I'm certain there will 
be much fun creating artwork of the little critter.  It looks like an animal 
that must be on the cover of an O'Reilly book somewhere.  (I find raccoons, 
their cousins, more appealing, except when they are pillaging the cherry tree 
at my house.)

-Original Message-
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] 
Sent: Friday, June 21, 2013 06:34 AM
To: dennis.hamil...@acm.org; general@incubator.apache.org
Subject: Re: [PROPOSAL] OData Proposal for Incubator
Importance: High

Hi Dennis,

Sorry for coming back so late to your valuable feedback. After re-thinking
about the trademark issue and your thoughts about confusion we come to
conclusion to use a different name for the project. I would like to change
our project name to

Apache Olingo

Olingo is a little bear [1] and that name should avoid any confusion with
the OASIS standard or any other potential trademark holder. If there are
no concerns then I will go and change our proposal to Apache Olingo.

WDYT?

Regards,
stephan

[1] http://en.wikipedia.org/wiki/Olingo

On 18.06.13 15:58, "Dennis E. Hamilton"  wrote:

>I think there will be an issue with regard to trademarks and you will
>have to deal with folks seeing the trademark of "Apache OData" as a
>land-grab at "OData" itself.  The simplicity you think is avoiding
>confusion is, in that respect, causing confusion.
>
>In any case, it is always wise to avoid confusion of a (standard)
>specification, even OASIS Standard OData v3.0 or whatever, with the name
>of an implementation.  OASIS is going to make their own claims about some
>of those terms as well, if the past practice is any guide.
>
> - Dennis
>
>The ODF Toolkit snuck by, much to my dismay, even capturing odf as their
>incubator repository name, but they may have to deal with that to
>graduate to a TLP.
>
>-Original Message-
>From: Klevenz, Stephan [mailto:stephan.klev...@sap.com]
>Sent: Tuesday, June 18, 2013 06:27 AM
>To: general@incubator.apache.org
>Cc: dennis.hamil...@acm.org
>Subject: Re: [PROPOSAL] OData Proposal for Incubator
>
>Hello Dennis,
>
>Good point! The project naming was a challenge for us and maybe I just can
>explain why we prefer Apache OData as project name. The main reason is
>search. 
>
>Someone who is interested in OData will use this term and the result page
>will today list odata.org as the protocols homepage, Wikipedia which is
>fine and the OASIS TC. In future we would like to see that Apache OData is
>highly ranked and completes the search result list.
>
>If we use a different name someone has to know this name and has to search
>for it explicitly. We would like to keep it simple and avoid confusion.
>
>We had also a look into the ASF project naming guidelines and I think most
>of the points there are considered by the name Apache OData.
>
>
>Regards,
>Stephan
>
>On 18.06.13 03:28, "Dennis E. Hamilton"  wrote:
>
>>I think one concern here is appropriation of a generic, specified-tied
>>name to an implementation, even a reference implementation.
>>
>>"Apache OData" seems over-reaching in that respect, especially since
>>there are other projects, at ASF and elsewhere, that may employ OData
>>bindings and services of one sort or another.
>[ ... ]
>


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

RE: [IP CLEARANCE] BigCouch

[Dennis E. Hamilton]

That page talks about transfer of copyright and addition of Apache copyright 
notices on the code as imported.  Huh?

Why aren't the guidelines for transfer of cleaned-up contributions under SGAs 
being followed, and an SGA being filed that details the contribution?

 - Dennis

-Original Message-
From: Noah Slater [mailto:nsla...@apache.org] 
Sent: Wednesday, June 26, 2013 06:03 AM
To: general@incubator.apache.org
Subject: Re: [IP CLEARANCE] BigCouch

Woop! Thanks Bob! +1


On 26 June 2013 13:55, Robert Newson  wrote:

> Cloudant has donated the source code artifact detailed at [1] to the ASF.
> This email is to request lazy consensus from the IPMC for the IP
> clearance of this donation.
>
> B
>
> [1] http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
NS


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

RE: [IP CLEARANCE] BigCouch

[Dennis E. Hamilton]

Under the heading "Copyright" there is an item with text "Check and make sure 
that the papers that transfer rights to the ASF [have] been received.  It is 
only necessary to transfer rights for the package, the core code, and any new 
code produced by the project."

In the next box it says

"Check and make sure that the files have been donated have been updated to 
reflect the *new* ASF copyright. ... " [emphasis mine].

It is my understanding that an SGA is not a transfer of rights but a grant of 
license.  This language is all wrong, wherever it comes from.  It suggests what 
appears to be a copyright transfer when everything we are told around here is 
that the ASF neither requires nor does such things.  Furthermore, adding ASF 
copyright notices in the headers for individual files that are otherwise 
unchanged is very naughty.  (Unless, of course, there has indeed been a 
copyright transfer, and I'm not all that sure about even that case.)

 - Dennis

PS: And, of course, the license grant is about more than the exclusive rights 
of copyright holders, too.  In any case, the non-exclusive licenses granted in 
SGAs and CLAs are not transfers.  (Since "standing" is much in the news today, 
another way to put it is that the ASF has no power to sue for infringement of 
copyright in the contributed works, nor any patent infringement related to the 
use of the contributed works.)

-Original Message-
From: Noah Slater [mailto:nsla...@apache.org] 
Sent: Wednesday, June 26, 2013 08:14 AM
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: [IP CLEARANCE] BigCouch

Dennis, can you clarify your concerns please?

The page you are looking at is generated from a template. Bob has simply
filled in the dates as he stepped through the process.

Which specific guidelines do you not believe have been followed?

Why do you believe that an SGA has not been filed?


On 26 June 2013 16:05, Dennis E. Hamilton  wrote:

> That page talks about transfer of copyright and addition of Apache
> copyright notices on the code as imported.  Huh?
>
> Why aren't the guidelines for transfer of cleaned-up contributions under
> SGAs being followed, and an SGA being filed that details the contribution?
>
>  - Dennis
>
> -Original Message-
> From: Noah Slater [mailto:nsla...@apache.org]
> Sent: Wednesday, June 26, 2013 06:03 AM
> To: general@incubator.apache.org
> Subject: Re: [IP CLEARANCE] BigCouch
>
> Woop! Thanks Bob! +1
>
>
> On 26 June 2013 13:55, Robert Newson  wrote:
>
> > Cloudant has donated the source code artifact detailed at [1] to the ASF.
> > This email is to request lazy consensus from the IPMC for the IP
> > clearance of this donation.
> >
> > B
> >
> > [1] http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> NS
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
NS


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

RE: [IP CLEARANCE] BigCouch

[Dennis E. Hamilton]

I don't think I've seen the template before, or it was too long ago and I 
failed to notice at the time.

Noah has explained my concern and added discussion on remedies.  (I won't be 
creating a JIRA issue and it appears that others have a better sense of what 
would express what is appropriate.  I just saw what was clear to me was 
inappropriate.)

With respect to that checklist, my only lingering concern is that it is 
difficult to know what was actually done, following the instructions as given, 
especially with regard to the headers of files, given how the item is worded.

I would definitely change the heading from "Copyright" to "Licensing" too.

 - Dennis

-Original Message-
From: Robert Newson [mailto:rnew...@apache.org] 
Sent: Wednesday, June 26, 2013 09:36 AM
To: general@incubator.apache.org; dennis.hamil...@acm.org
Cc: Noah Slater
Subject: Re: [IP CLEARANCE] BigCouch

Dennis,

I'm following the instructions I'm given, I don't know if this is the
place to comment on the process the incubator project has been
following up to this point. Have I followed it incorrectly? I don't
know you personally, are you pointing out problems with *this* ip
clearance thread in particular or are you commenting on the template
itself? Had you seen the template before today?

B.


On 26 June 2013 17:27, Dennis E. Hamilton  wrote:
> Under the heading "Copyright" there is an item with text "Check and make sure 
> that the papers that transfer rights to the ASF [have] been received.  It is 
> only necessary to transfer rights for the package, the core code, and any new 
> code produced by the project."
>
> In the next box it says
>
> "Check and make sure that the files have been donated have been updated to 
> reflect the *new* ASF copyright. ... " [emphasis mine].
>
> It is my understanding that an SGA is not a transfer of rights but a grant of 
> license.  This language is all wrong, wherever it comes from.  It suggests 
> what appears to be a copyright transfer when everything we are told around 
> here is that the ASF neither requires nor does such things.  Furthermore, 
> adding ASF copyright notices in the headers for individual files that are 
> otherwise unchanged is very naughty.  (Unless, of course, there has indeed 
> been a copyright transfer, and I'm not all that sure about even that case.)
>
>  - Dennis
>
> PS: And, of course, the license grant is about more than the exclusive rights 
> of copyright holders, too.  In any case, the non-exclusive licenses granted 
> in SGAs and CLAs are not transfers.  (Since "standing" is much in the news 
> today, another way to put it is that the ASF has no power to sue for 
> infringement of copyright in the contributed works, nor any patent 
> infringement related to the use of the contributed works.)
>
> -Original Message-
> From: Noah Slater [mailto:nsla...@apache.org]
> Sent: Wednesday, June 26, 2013 08:14 AM
> To: general@incubator.apache.org; dennis.hamil...@acm.org
> Subject: Re: [IP CLEARANCE] BigCouch
>
> Dennis, can you clarify your concerns please?
>
> The page you are looking at is generated from a template. Bob has simply
> filled in the dates as he stepped through the process.
>
> Which specific guidelines do you not believe have been followed?
>
> Why do you believe that an SGA has not been filed?
>
>
> On 26 June 2013 16:05, Dennis E. Hamilton  wrote:
>
>> That page talks about transfer of copyright and addition of Apache
>> copyright notices on the code as imported.  Huh?
>>
>> Why aren't the guidelines for transfer of cleaned-up contributions under
>> SGAs being followed, and an SGA being filed that details the contribution?
>>
>>  - Dennis
>>
>> -Original Message-
>> From: Noah Slater [mailto:nsla...@apache.org]
>> Sent: Wednesday, June 26, 2013 06:03 AM
>> To: general@incubator.apache.org
>> Subject: Re: [IP CLEARANCE] BigCouch
>>
>> Woop! Thanks Bob! +1
>>
>>
>> On 26 June 2013 13:55, Robert Newson  wrote:
>>
>> > Cloudant has donated the source code artifact detailed at [1] to the ASF.
>> > This email is to request lazy consensus from the IPMC for the IP
>> > clearance of this donation.
>> >
>> > B
>> >
>> > [1] http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html
>> >
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>> 

[OT] The promise of Olingo

[Dennis E. Hamilton]

Today, the Bing wall-paper features a beautiful image of a ring-tailed cat 
(clearly adaptable to an O'Reilly cover, if it hasn't been already).

Having read up on Olingo, I immediately thought "raccoon" and indeed, this is a 
Procyonidon cousin of the Olingo, 
<http://en.wikipedia.org/wiki/Ring-tailed_Cat>.

I'm sharing this because the Bing image is great and also because of an 
observation made about the domestic cat and the ring-tailed cat (not a feline) 
-- both have succeeded in domesticating humans by virtue of their habits 
(theirs, ours, whatever).

Let us trust that at last, the OAuth Olingo can do the same in the realm of 
safe habits in cyberspace.

 - Dennis

PS: If you go to http://bing.com, you'll see that the image is a video of the 
fellow.  You might need to click through earlier images to see it in its Utah 
red-rock environment.

-----Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Friday, June 21, 2013 08:42 AM
To: 'Klevenz, Stephan'; general@incubator.apache.org
Subject: RE: [PROPOSAL] OData Proposal for Incubator

Stephen,

I support your choice to have a different name.  

 - Dennis

I'm not sure how "Olingo" is pronounced in Spanish but I'm certain there will 
be much fun creating artwork of the little critter.  It looks like an animal 
that must be on the cover of an O'Reilly book somewhere.  (I find raccoons, 
their cousins, more appealing, except when they are pillaging the cherry tree 
at my house.)

[ ... ]


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

RE: [VOTE] Accept Olingo proposal as an incubating project

[Dennis E. Hamilton]

+1 (non-binding)

On Mon, Jul 1, 2013 at 11:38 AM, Florian Müller  wrote:

> Hi all,
>
> I'd like to call a VOTE for acceptance of Olingo into the Apache incubator.
>
> The proposal is pasted at the bottom on this email.
> The corresponding wiki page is: http://wiki.apache.org/**
> incubator/OlingoProposal 
>
> [ ] +1 Accept Olingo into the Apache incubator
> [ ] +0 Don't care.
> [ ] -1 Don't accept Olingo into the incubator because...
>


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

RE: OpenOffice.org Apache Incubator Proposal - Dependency License Clash

[Dennis E. Hamilton]

I've lost the thread on this, but I thought that one observation was about the 
dependencies in OpenOffice.org (and LibreOffice.org) on material from other 
sources and not necessarily under the same license.   In that regard, there may 
be a difference among some of those in terms of what is considered LGPL/GPL 
friendly and what is considered Apache 2.0 friendly.  The current contributors 
to LibreOffice code are asked to affirm that their contribution is an MPL/LGPL 
dual if they have not already done so as part of a submission.

For assessment of this situation, both distributions have maintained the Sun 
Microsystem practice of including a THIRDPARTYLICENSEREADME.html at the 
top-level of the install location.  I am sure these are on-line somewhere in 
the web view of their code bases, but I've given up looking.  (In SVN I can 
find stuff.  In git, not so much.)  The attachment is the one that came with 
the LibreOffice 3.3.2 stable release for Windows.

 - Dennis

-Original Message-
From: Ross Gardler [mailto:rgard...@apache.org] 
< 
http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3c4de8a9d4.2070...@apache.org%3e>
Sent: Friday, June 03, 2011 02:31
To: general@incubator.apache.org
Subject: Re: OpenOffice.org Apache Incubator Proposal

[ ... ]

Oracle owns all copyright in contributions to date and they have already signed 
the grant to allow Apache to sublicence it. The grant is identical to the one 
all other projects coming in sign, see 
http://www.apache.org/licenses/proposed/software-grant.txt


If there are dependencies that Oracle do not own these need to be addressed on 
a case by case basis. That is part of the incubation process. It would be 
helpful if the proposal identified what licence incompatibilities there are, 
this has been requested and promised in another thread. The incubator is 
experieced with dealing with these issues once clearly identified.

[ ... ]


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

RE: OO.o downloads on Day One (was: "opportunity to reunite the related communities" ...)

[Dennis E. Hamilton]

I don't know how you can QA and regression test any OpenOffice.org distro if 
you don't build it, and built it for multiple platforms.  And you need the 
distro to be "as-built" (uh, not exactly how that term is used these days, but 
think of the reason uucp was invented) or it is all over but shooting the 
wounded.

I think it is essential to address the entire software-lifecycle *spiral* and 
its support for this beastie.  

I also think that this may be the fertile ground for harmony with LibreOffice.  
LibreOffice has a very strong and getting-stronger position on the 
customer-delivery and feedback side of this adventure.  The cycle of learning 
and improvement has to come back through what gets developed (especially for 
bits sourced from Apache in the future) with as little friction as possible.  

Similarly, any refactoring and componentization of the Apache OpenOffice.org 
code base must not be without consideration for what LIbreOffice, as a 
significant consumer (let's say) needs in order to build what they want to 
deliver, including bits that will never be Apache's because that's how some 
LibreOffice committers (and users too) may want it.

It seems to me there needs to be a joint meritocracy around orchestrating the 
interdependency of LibreOffice and relevant aspects of an Apache undertaking.  
I don't think that means a new custodian or another non-profit.  We have two 
very transparent, open, and meritocratically-accountable organizations.   I'm 
thinking of some sort of technical council whose burden is to shepherd the 
interdependency and the life-cycle concerns that go with it, but without 
custody of any code and operating entirely under the good will of the two 
organizations.

An essential requirement is low friction, helping to avoid duplication and 
pointless deviation, and contribution to the sustained learning and improvement 
around the Apache <-> LibreOffice interdependency.   I think the 
interdependency is real, though not the only one that may emerge, and we should 
move to cultivate and nurture it quickly.

 - Dennis

PS: In my past lives, the answer to situations like this was market and 
customer forces compelling deviant solutions to align and avoid confronting 
anyone with a beta-vs-VHS situation.  Sometime it meant alignment on a standard 
(though at one level, the document format, we have the basics of that here).  
But that was around competition among private parties (e.g., corporations and 
closed-product commercial offerings) and it was perhaps all that could be 
achieved.  It seems to me that there is a different opportunity here and it is 
going to depend on developing trust and respect for the differences in 
organizational (and contributor) culture and that of adopters of the 
office-document software from either organization, as well.  It will take real 
elbow grease and we probably need to quickly find the least that can possibly 
work -- for now.  I also concede that we are looking at forks and what we need 
to secure for the mutual benefit of everyone is smoothness by which the common 
part can be maximized and embraced.

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Friday, June 03, 2011 14:04
To: general@incubator.apache.org
Subject: OO.o downloads on Day One (was: "opportunity to reunite the related 
communities" ...)

On Fri, Jun 3, 2011 at 16:29, Simon Phipps  wrote:
>...
> text in the wiki doesn't give that assurance. I'm also suggesting it's  
>/such/ a big deal for the open source community at large that  
>openoffice.org resolve to a working and current site without  
>interruption ...

I don't think there is any immediate plan to take down openoffice.org or any of 
its subareas on Day One. It should continue to function normally.

I honestly don't know what Oracle has said about this. Maybe somebody knows? 
Sam?

Over time, we'll need to move that "in-house". Whether binary downloads do or 
not... up to the project. Historically, being a volunteer-based org with little 
access to a complete range of build targets, we've not distributed binaries[1]. 
Some volunteers build stuff and post that into our mirror network, but it is 
typically a convenience thing rather than "official policy". But with that 
said, it would be entirely reasonable for an Apache $name project to make it 
policy and acquire the necessary build farms to produce the releases.

Cheers,
-g

[1] of course, Java projects build and post .jar files (or whatever); I'm 
talking about C/C++ apps like OO.o

-
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 OpenOffice.org Incubator Proposal: Collaboration with TDF/LO

[Dennis E. Hamilton]

I've edited it a tiny bit and may do more.  If we get into a Wikipedia 
edit-reversion war, I am sure that there are wiser heads who will intervene.  
(It is unfortunate that this wiki doesn't come with "Discuss" pages, but that 
doesn't mean we can't introduce one or more as our own convention.)

My suggestion is to take small steps. 

For bigger steps, it is probably a good idea to make new pages and have focused 
discussion on those pages until there is some apparent consensus on merging 
back into the main proposal text.

 - Dennis

-Original Message-
From: Simon Phipps [mailto:si...@webmink.com] 
< 
http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3cbanlktimkdxoce12t-xggq5ls+nmkluo...@mail.gmail.com%3e>
Sent: Friday, June 03, 2011 14:21
To: general@incubator.apache.org
Subject: Re: Apache OpenOffice.org Incubator Proposal: Collaboration with TDF/LO

[ ... ]

So to be clear, the wiki page for the OOo proposal is open for anyone to edit 
and not just Apache members or the project's proposers.

S.


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

RE: Discussion with TDF/LO people (was: Apache OpenOffice.org Incubator Proposal: Collaboration with TDF/LO)

[Dennis E. Hamilton]

Here are the global lists:
< http://www.documentfoundation.org/contribution/#lists>

I suggest the steering-disc...@documentationfoundation.org or, if you find that 
too forward (or if posting is restricted), just disc...@documentfoundation.org 
for starters.

 - Dennis



-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
< 
http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3cbanlktimu0roezdocxkgn_9dacyf6qej...@mail.gmail.com%3e>
Sent: Friday, June 03, 2011 16:08
To: general@incubator.apache.org
Subject: Discussion with TDF/LO people (was: Apache OpenOffice.org Incubator 
Proposal: Collaboration with TDF/LO)

[ ... ]

Now... with that said. Consider a typical person from the ASF who might want to 
do that. Say.. like myself. I don't know what list to subscribe to. (name only 
one!) ... If somebody can say what list that ASF people could subscribe to, 
then something like this could happen.

[ ... ]


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

RE: Apache OpenOffice.org Incubator Proposal: Collaboration with TDF/LO

[Dennis E. Hamilton]

Something about the licenses to be reconciled is useful to have somewhere so 
folks can understand what the big deal is.  Maybe in a location for backup 
details?

For example, contributors to the current LibreOffice code are asked to assert 
LGPL3/MPL.  The extensive effort and roadmap for user documentation is leading 
to documents that are GPL3/CC-by dual-licensed.

 - Dennis



-Original Message-
From: Simon Phipps [mailto:si...@webmink.com] 
Sent: Friday, June 03, 2011 15:16
To: general@incubator.apache.org
Subject: Re: Apache OpenOffice.org Incubator Proposal: Collaboration with TDF/LO

I suggest:

"The LibreOffice project is an important partner in the OpenOffice.org 
community, with an established potentially highly complementary focus on the 
GNU/Linux community as well as on Windows and Mac consumer end-users. We will 
seek to build a constructive working and technical relationship so that the 
source code developed at Apache can be readily used downstream by LibreOffice, 
as well as exploring ways for upstream contributions to be received as much as 
possible within the constraints imposed by mutual licensing choices.

There will be other ways we may be able to collaborate, including jointly 
sponsored public events, interoperability 'plugfests', standards, shared build 
management infrastructure, shared release mirrors, coordination of build 
schedules, version numbers, defect lists, and other downstream requirements. We 
will make this relationship a priority early in the life of the podlet."

S.


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

RE: OpenOffice.org Apache Licensing Q's [was: Incubator Proposal]

[Dennis E. Hamilton]

The extensive LibreOffice user-documentation project is producing 
GPL3[+]/CC-by3.0 dual-licensed documents.  I assume that CC-by is not toxic for 
Apache, since it is the closest CC license to permissive (i.e., it is at least 
as permissive as modified BSD) and it allows derivative works, of course.  

I'm not clear on the status of the separately-installed HelpPack on Windows.  I 
don't recall a license click-through for that installation, and there is no 
license information in the help content itself.  

There is also on-line help at locations such as . 
 I don't see any notices or license information.

 - Dennis

-Original Message-
From: Andre Schnabel [mailto:andre.schna...@gmx.net] 
Sent: Friday, June 03, 2011 15:38
To: general@incubator.apache.org
Subject: Re: OpenOffice.org Apache Licensing Q's [was: Incubator Proposal]

Hi William, *

 Original-Nachricht 
> Von: "William A. Rowe Jr." 
> An: general@incubator.apache.org
> > 
> > The CC was generated for non-code contributions as far as I know. I 
> > would need to have that confirmed.
> 
> That is my understanding.  But if we ask legal-discuss, all 
> contributions at the ASF must be editable (one pillar of the Open 
> Source Definition) and must allow derivative works ... IOW, under the 
> Apache License.
> 
> So I simply need to understand the scope of the CC elements of OOo 
> which will need to be entirely replaced.

Yes, CC has been introduced for documentation - or I would rather say marketing 
/ promotion materials (I've been member of the OOo community council when this 
was introduced). So you won't find CC elements in the code repository. And even 
in website or wiki content I would not expect to see many CC stuff, at least 
nothing really important.

But this raises another question - does Oracle donate the code only or will ASF 
also get the contents of the website, wiki, translation database (wich has some 
more information than what you see in the code), ooo-specific tooling (OOo used 
to have some web portals to support  development, qa, release and documentation 
processes) etc. 


reegards,

Andre

-
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: "opportunity to reunite the related communities" Re: OpenOffice.org Apache Incubator Proposal: Splitting the Community?

[Dennis E. Hamilton]

I've been wondering if there is a division of labor that works for the short 
term while community-spanning work continues:

 1. I'm thinking that it is important to recognize that LibreOffice has some 
remarkable momentum.  There is a great deal they are on top of or are getting 
on top of, including all of the localizations, the user documentation, user 
feedback and requests as well as bug reports, and a development community that 
is charging ahead.  The rebranding is going to be completed before the Apache 
Incubator will barely have sleeves to roll up.  I'm thinking it would be good 
to leave them to it, with any tighter coupling to be worked out as there is 
experience over matters of common interest.  

 2. I see something, already mentioned, that the Adobe Incubator can claim as 
its initial territory:  production of a reference implementation of a native 
OpenDocument Format processor along with component libraries and tooling.  The 
idea is to have, starting from the contributed OpenOffice.org code base, a 
running, narrated framework  for customization and delivery of polished 
products such as LibreOffice.  There are a number of areas, some of them rather 
large, that the Apache incubator could carve out, such as providing a reference 
implementation and test suites for the OpenFormula component of ODF 1.2.  I'm 
sure many others will come to mind.  I think LibreOffice would take a stake in 
such work, as would other producers of ODF-supporting products.  The reference 
implementation could also provide some missing calibration on the extent to 
which ODF is supported and what the typical omissions and deviations are (and 
ways to be transparent about them).  

 - Dennis

PS: Personal side notes: I don't care if it is called OpenOffice.org or not.  
Maybe not is a better answer.  I am also a fan of the vibrancy and vitality 
seen in the way that LibreOffice appeals to a wide variety of contributors, 
especially those with a focus on overcoming defects and limitations that users 
have observed personally and bring to LibreOffice for clarification or relief.  
I didn't sense that with OpenOffice.org.  I may have simply been looking in the 
wrong place, but it is clear that is being provided for LibreOffice.  I want to 
encourage that.  I fancy the some-kind-of-green-color branding too.  And 
installs that don't evangelize somebody else's browser or toolbar or virtual 
system run-time.
  I also worry a little that the pace of weekly beta  and release-candidates 
risks serious regression failures and is not sustainable as a practical matter. 
 I trust they'll adjust that in time as they rush toward whatever the vision 
for LibreOffice 4.0 happens to be.

-Original Message-
From: Jim Jagielski [mailto:j...@jagunet.com] 
Sent: Friday, June 03, 2011 12:36
To: general@incubator.apache.org
Subject: Re: "opportunity to reunite the related communities" Re: 
OpenOffice.org Apache Incubator Proposal: Splitting the Community?


On Jun 3, 2011, at 3:00 PM, Simon Phipps wrote:

> I am not even thinking of suggesting it, any more than I would dream of 
> telling TDF they have to switch to another license. But I do believe there's 
> a need to focus *in the proposal* on exactly how to sustain the consumer 
> deliverable from Day One.

Agreed. And that's why I suggested that that would be an excellent initial part 
of cooperation between the ASF and TDF, where they could provide the 
build/distribution.

One main, significant difference between TDF and the ASF is that the ASF just 
releases source; TDF fills a *huge* and important part of the entire OOo 
end-user experience.
I sincerely hope this is an easy to agree to.
-
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: OpenOffice and the ASF

[Dennis E. Hamilton]

Quoting the full context for "these" at 
:

"The second is projects that implement free standards that are competing 
against proprietary standards, such as Ogg Vorbis (which competes against MP3 
audio) and WebM (which competes against MPEG-4 video). For these projects, 
widespread use of the code is vital for advancing the cause of free software, 
and does more good than a copyleft on the project's code would do.

"In these special situations where copyleft is not appropriate, we recommend 
the Apache License 2.0. ... "

Considering that OO.o (and LibreOffice) support the ODF 1.0/1.1 OASIS Standards 
and the IS 26300:2006 International standards (with the ODF 1.2 Standard 
wrapping up), there is some interesting context that I hadn't noticed before.

This also fits the notion of figuring out a multi-layered reference 
implementation that covers at least the demonstration of a framework for 
processing the OpenDocument Format as well as those standards that ODF relies 
upon by reference or selective mimicry (i.e., under ODF namespaces using common 
local names and related semantics).

 - Dennis

-Original Message-
From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby

Sent: Saturday, June 04, 2011 05:19
To: general@incubator.apache.org
Subject: Re: OpenOffice and the ASF

[ ... ]

I encourage everybody to read the full citation, in its original context.

> S.

- Sam Ruby

-
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: OO/LO License

[Dennis E. Hamilton]

PS: As far as I can tell, what none of those distributions do in their appeals 
to LGPL3 is carry any indication of where and how their source code can be 
found.  Naughty, naughty.

 - Dennis

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 

Sent: Saturday, June 04, 2011 11:59
To: general@incubator.apache.org
Cc: charles.h.sch...@gmail.com; 'Jochen Wiedmann'
Subject: RE: OO/LO License

Just to un-muddy the waters a little, it should be clear that all distributions 
of OpenOffice.org and LibreOffice are under the LGPL3.  It is also the case 
that contributors of code to LibreOffice are required to affirm that their 
contributions are under LGPLv3+/MPL.

 - Dennis

[ ... ]


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

RE: OO/LO License + Why LO needs the AFL 2.0 to exist (quickly)

[Dennis E. Hamilton]

I have trouble imagining MPL'd binaries being baked into an Apache offering.

1.  For now, it doesn't matter.  At the moment, there are no separable MPL'd 
bits into something like reusable libraries at all.  There is simply no 
re-licensing of LibreOffice (especially the still-significant LGPL parts and 
derivatives that are from OpenOffice.org and that are not relicenseable at all).

2. With regard to building distributions, binary libraries are terribly awkward 
unless Apache were to limit its OpenOffice project to a single platform and 
programming model.  In contrast, LibreOffice is going full-up C++ and the Java 
dependencies are shrinking.  And for a reference implementation, or the parts 
of Apache OpenOffice that could serve that purpose, I don't think that will fly 
at all.

 - Dennis

PS: NEW SPECULATIVE TOPIC.  If the Apache Incubator has all of the code base of 
OpenOffice.org that is covered by the Oracle copyright, its being available 
under AFL 2.0 is a *benefit* to LibreOffice.  In that case, LibreOffice can 
re-acquire the AFL 2.0 bits and, for what is reasonably re-integrateable under 
the already-restructured LibreOffice code base, have that be the basis for 
relicensing the LibreOffice derivative as MPL or LGPL3+/MPL (or whatever 
combination of reciprocal licenses that tickles their fancy).  Short of a 
separate *permissive* license grant from Oracle directly to The Document 
Foundation, I don't see any other way for LibreOffice to have anything but 
LGPL3+ in our lifetimes.  The Apache OpenOffice availability is an avenue for 
LibreOffice changing its (multi-)licensing if and when it chooses to do so 
(though, like all good comedy, timing is everything).  [There are details to 
manage with regard to code provenance in order to pull this off, but it should 
work and managing code provenance is a good idea either way.]

-Original Message-
From: Dave Fisher [mailto:dave2w...@comcast.net] 

Sent: Saturday, June 04, 2011 14:36
To: general@incubator.apache.org
Subject: Re: OO/LO License

[ ... ]  Components and extensions with difficult IP provenance OOo might not 
have a place under the ASL. If LO/TDP were willing to package such components 
in, for example, an MPL licensed LO binary library, then the Apache OO podling 
or project might use these as a part of OOo until it makes the decision to 
replace it with other code.

[ ... ]


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

RE: OO/LO License

[Dennis E. Hamilton]

Hi Andrew,

I'm not talking about private bilateral arrangements between Sun/Oracle as the 
copyright holder and other entities.  I am talking only about the distributions 
and code that are made available to the public and other developers via 
OpenOffice.org.  There the only license offered is LGPL (not counting 
third-party components included in the distribution and not subject to the Sun 
copyright nor the OpenOffice.org license).

Also, I assume that other licensing arrangements that have not expired or hit a 
tripwire by virtue of Oracle making the AFL 2.0 licensing to Apache will 
continue to be in force, though not for any updates provided at Apache (or 
LibreOffice, for that matter).  

Finally, I am not objecting to the AFL 2.0 licensing in any way.  I welcome it. 
 I think bringing OpenOffice to Apache is a great idea.

I just wanted to get the facts straight with regard to some comments to the 
effect that LibreOffice is available under LGPL3+, MPL, and the GPL.  It is 
just LGPL3[+] although GPL provisions are there by reference.  (As far as I can 
tell, it is those provisions that require inclusion of information on how to 
obtain the source code for a distribution and both OpenOffice.org and 
LibreOffice are careless about that.)

 - Dennis

-Original Message-
From: Andrew Rist [mailto:andrew.r...@oracle.com] 
<http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3c4deab6a2.6010...@oracle.com%3e>
Sent: Saturday, June 04, 2011 15:50
To: general@incubator.apache.org
Subject: Re: OO/LO License

On 6/4/2011 11:58 AM, Dennis E. Hamilton wrote:
<http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3c009001cc22e9$73f6cbe0$5be463a0$@acm.org%3e>
> Just to un-muddy the waters a little, it should be clear that all 
> distributions of OpenOffice.org and LibreOffice are under the LGPL3.  
> It is also the case that contributors of code to LibreOffice are 
> required to affirm that their contributions are under LGPLv3+/MPL

The code was used under multiple licenses.  While it may be true that LGPL was 
the only Open Source license, it was not in fact the only license.
The choice of ALv2 going forward would ensure continuity for all constituencies 
under a single well accepted open source license, with all parties on equal 
footing.

-
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: OO/LO License + Why LO needs the AFL 2.0 to exist (quickly)

[Dennis E. Hamilton]

I was thinking about binary-only components such as a linker library or shared 
library that was under a non-Apache license but that needed to be included in 
deployments of OpenOffice.org.  That would require a different version of the 
binary-only component for every platform environment the Apache code is 
expected to build for and deploy to.   

Since OpenOffice.org code is mostly C++ and the trend is to remove the Java 
dependencies (at least over on LibreOffice), this seems more awkward than 
whatever the benefit might be.

I need to step back and look at this more carefully.  My starting-out 
assumptions are that OpenOffice.org builds don't depend on binary-only 
components in deployed distributions.  In addition, I'm trusting that any 
dependencies on third-party source code or binary libraries are either 
non-toxic, can be worked-around/done-without for as long as we'd need to have 
an alternative in place.  Whistling in the dark here ...
 
 - Dennis

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Saturday, June 04, 2011 23:22
To: dennis.hamil...@acm.org; general@incubator.apache.org
Subject: RE: OO/LO License + Why LO needs the AFL 2.0 to exist (quickly)


On Jun 4, 2011 6:25 PM, "Dennis E. Hamilton"  wrote:
>...
> 2. With regard to building distributions, binary libraries are terribly 
> awkward unless Apache were to limit its OpenOffice project to a single 
> platform and programming model.  In contrast, LibreOffice is going full-up 
> C++ and the Java dependencies are shrinking.  And for a reference 
> implementation, or the parts of Apache OpenOffice that could serve that 
> purpose, I don't think that will fly at all.

I'm not sure that I've parsed and understood this. Apache should only ship one 
binary? Or it should only go Java, or only C++? And is that just (reference) 
parts, or how we handle the whole distro?

 I'm not trying to poke fun of you here. Just trying to understand where 
you're going.

Thanks,
-g



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

RE: OpenOffice - Wiki - Required Resources - Subversion vs. Mercurial vs. Git

[Dennis E. Hamilton]

I say that the sooner one can move to uni-directional flows with the 
bi-directionals out in customization and adoption layers, if anywhere, the 
better.  It is difficult to conceive of any other way to get on top of the 
refactoring that is surely required as part of making a manageable, layered 
component structure.  

Yes, I  know this is simplistic in the face of the reality of OpenOffice.org.  
I maintain that such a separation of concerns should be sought.  That to some 
degree the problem of multi-platform distribution, localization, etc., has 
already been taken on by at least one "another" provides some important 
breathing room.

 - Dennis

-Original Message-
From: Robert Burrell Donkin [mailto:robertburrelldon...@gmail.com]
 

Sent: Sunday, June 05, 2011 00:49
To: general@incubator.apache.org
Subject: Re: OpenOffice - Wiki - Required Resources - Subversion vs. Mercurial 
vs. Git

[ ... ]

Apache uses a canonical pattern best suited to uni-directional flows.
This tends to force finely grained component based designs, and clearer 
distinction between up and downstream code bases. So, again, we probably need 
to think about how to maintain continuity and about allowing a transitional 
period...

Robert

-
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: List of files covered by the OpenOffice grant

[Dennis E. Hamilton]

Although it is still a daunting list (over 100 items), it is interesting to 
grep the list for ".mk" files.  This will show some places where some 
third-party components seem to be introduced (e.g., zlib.mk).  I'm not sure 
where the build process is handled and what the tooling requirement is.  I 
believe that http://OpenOffice.org developer pages provide more insight for 
that, such as the OpenOffice.org Building Guide, 
.

-Original Message-
From: Christian Lippka [mailto:c...@lippka.com] 
Sent: Sunday, June 05, 2011 04:10
To: general@incubator.apache.org
Subject: Re: List of files covered by the OpenOffice grant

Hi Sam,

thank you for the list. From a first glance it looks like that this is exactly 
the same set of sources that is already available in the OpenOffice.org 
repository.
I do not want to imply that this is too much or too little, just a FYI for 
those interested and to lazy to compare for themselfs :-)

Regards,
Christian

Am 05.06.2011 12:43, schrieb Sam Ruby:
> I extracted the text from the Grant.  It needed some minor cleanup 
> (for example, to remove page numbers).  It is possible that I 
> introduced errors in the process, but that seems unlikely given how 
> clean this data was.  In any case, in the event that there are any 
> differences the original grant is authoritative.
>
> Without further ado, here are the list of files:
>
>   http://people.apache.org/~rubys/openoffice.files.txt
>
> I do not recommend accessing this page via a dialup connection as this 
> list alone is ~1.75Mb
>
> - Sam Ruby


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

RE: OpenOffice & LibreOffice

[Dennis E. Hamilton]

As a type O-positive human, I think the metaphor works quite well.

I can donate blood that is compatible with folks that I can't receive blood 
from.  In fact, I can only receive blood of another O-type individual (positive 
or negative).  Yet my blood is compatible with that of all  *-positive 
individuals (* = A, B, AB).   I donate regularly (every 8-10 weeks or so), 
willingly and without need for compensation.

I didn't get to choose my blood type.  But I can choose to be an ALv2 
contributor and know that, technically, there is no one unable to use that 
contribution if they are able to use any at all.  I can also continue to 
contribute to LibreOffice, although it is unlikely that I will ever contribute 
code there.  That's like donating at a blood bank that only transfuses a single 
non-O type.  Likewise, I do not read code having non-permissive licenses if I 
can avoid it.  It is toxic for me (metaphorically and for practical reasons).

 - Dennis

-Original Message-
From: Keith Curtis [mailto:keit...@gmail.com] 
Sent: Sunday, June 05, 2011 16:04
To: general@incubator.apache.org
Subject: Re: OpenOffice & LibreOffice

On Sun, Jun 5, 2011 at 3:50 PM, Joe Schaefer  wrote:
>
> We are a type-O org.  Anyone can take our blood and mix it with their own.
> That "universal donor" condition places lots of restrictions on our 
> projects, but somehow they manage to release useful software.

It is an interesting analogy, but seems not accurate because you can't mix with 
anything but type-O. The Linux kernel seems more of a type-O because it accepts 
both kinds of licenses.

-Keith

-
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: OpenOffice: where are we now?

[Dennis E. Hamilton]

+1

-Original Message-
From: robert_w...@us.ibm.com [mailto:robert_w...@us.ibm.com] 

Sent: Sunday, June 05, 2011 15:34
To: general@incubator.apache.org
Subject: Re: OpenOffice: were are we now?

[ ... ]

Oracle has stated that they are committed to supporting the transition into 
Apache.  But I think the only way, as a practical matter, to guarantee that the 
podling can build OOo from the sources is for the podling to try building OOo 
from the sources.  That is the easiest and most accurate way of figuring this 
out.  All other ways are much more error prone.

-Rob


-
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: OpenOffice & LibreOffice - That's Not What Re-Licensing Is

[Dennis E. Hamilton]

If you remove the ALv2 license and don't provide the notice that the license 
requires, you are in violation and are infringing the Apache copyright.   
Likewise, adding a copyright notice to an intact public domain work is not a 
claim that is defensible.

There's a misunderstanding about relicensing in this discussion, and I have 
been guilty of it in my casual use of the term as well.

You can't relicense the copyright on something that is not your work and to 
which you do not have a grant of copyright.  It is not possible to legally 
usurp a copyright and nothing in ALv2 permits that (since it is *not* a 
copyright transfer, it is a license).

What the ALv2 (I am practicing this form as part of being kept after school to 
clean erasers) does is permit incorporation in derivative works, compilations, 
combined works, etc., without limitation.  But *your* license covers only the 
part that is your work.  The material sourced under the ALv2, to the extent 
that it remains, is still under the ALv2, although licensed to you and 
sublicensed to the recipients of your work.  In short, you can never legally 
claim copyright of that which is not your work unless you have been granted a 
copyright transfer.  The ALv2 doesn't do that.  The ALv2 is generous in how you 
can use that work in conjunction with yours and also licenses other exclusive 
rights of copyright owners that give you great freedom of use.  But claiming 
copyright and substituting your own license is not OK.
 
When LO incorporates any of the Apache OpenOffice.org code, it will have to 
treat it like third-party code the way it does now for material under 
compatible licenses from other third parties.  This is the same thing that IBM 
would have to do (if they have no other license that they can rely on from Sun 
or Oracle), and certainly what Microsoft or Google would have to do.

The sense in which re-licensing applies here is that, so long as everything is 
compatible, the derivative can be under any license whatsoever, and distributed 
in any manner whatsoever, so long as the non-negotiable conditions of ALv2 are 
honored (and hence the license is honored).  Similarly, if the producer of the 
derivative decides to change their license, but everything is still compatible, 
the ALv2 is no obstacle to that.  That is what the "re-licensing" opportunity 
is.  It would be great if there were a better term for this.  But the key thing 
is the ALv2 code is not relicensed, but the work it is combined into, 
derivative in, compiled in, whatever, can be produced with a different license 
and that license can be changed by someone who has that right.

Furthermore, and don't confuse this with re-licensing, even though the code is 
used in a proprietary product, it does not make the ALv2-licensed portions the 
property of the producer.  What the ALv2 does is give that producer a license 
to their doing that with the ALv2 subject matter and not requiring that their 
source code be made public and with no obligation to contribute back to Apache.

I guess my next after-school will be cleaning erasers for Larry Rosen.

 - Dennis

PS: This is why it is also important for projects to manage the provenance of 
every bit of their code, because third-party licenses still adhere to the 
extent that is required.  It also helps defend against claims that 
such-and-such code was plagiarized in a manner that violated some other license 
that the same or similar code can be found wrapped in.

PPS: That is also why one should read the freakin' ALv2 license at the provided 
link and not take advice from Wikipedia.  The language of the license is plain 
enough.

-Original Message-
From: Keith Curtis [mailto:keit...@gmail.com] 

Sent: Sunday, June 05, 2011 17:18
To: general@incubator.apache.org
Subject: Re: OpenOffice & LibreOffice

[ ... ]

The redistribution terms only have to be respected until I relicense the code. 
That can be done via grep.

-Keith

-
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: OpenOffice & LibreOffice

[Dennis E. Hamilton]

In support of Sam's point here, I add that OpenOffice.org and LibreOffice.org 
already provide the required ALv2 notices in their listings of third-party 
dependencies.  The list is installed as part of every install of one of the 
distributions.  I even included a copy of one of the latest LibreOffice ones in 
an earlier post.  So folks curious about this should satisfy themselves that 
the LibreOffice office team already knows how to handle this.  

 - Dennis

-Original Message-
From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby

Sent: Sunday, June 05, 2011 17:47
To: general@incubator.apache.org
Subject: Re: OpenOffice & LibreOffice

On Sun, Jun 5, 2011 at 8:39 PM, Greg Stein  wrote:

[ ... ]
>
> You cannot simply strip the Apache License off of the code. You must 
> respect its terms.
>
> Your overall work could be GPL'd, but that one file that comes with an
> ALv2 license must continue to have that license. Stripping the header 
> off of it, and applying a different license, is a copyright violation.

An example of how another project has dealt with this:

http://wikis.sun.com/display/GlassFish/Copyrights

> -g

- Sam Ruby


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

RE: Legal concern: Are we getting to close ot a "division of markets" conversation?

[Dennis E. Hamilton]

The problem here is that Rob and Sam and other well-known employees are being 
addressed as IBM employees here and even called to account for their employer's 
behavior and intentions by some of the participants.  I suggest that the best 
way to deal with those requests is to meet them with silence and those of us 
who know better should stop asking those questions.  

Furthermore, the competition laws that apply to Rob and Sam as IBM employees 
and their agreements with their employer are not waived by their having a 
different hat here.  They can't get out of it, just like a priest (or 
parishioner) can't avoid causing scandal by misbehaving in plain clothes.  They 
can operate as individuals but they must also honor the requirements on their 
conduct that are a consequence of their employment.

However, this is not a secret conversation and it is not about arrangements to 
exclude third parties (except the absent elephant that shall not be named, and 
I don't see how that can happen under a transparent Alv2 setup anyhow -- au 
contraire).  Furthermore, it is not clear to me that anything that happens here 
can create a "division of markets."

I think this can be more grounded by talking about specific actions that are 
called for in finalizing the proposal and in anticipating the essential work 
for taking over the OpenOffice.org code base, related artifacts, and making 
them available under ALv2, whether or not we ever make a distribution that is 
called Apache OpenOffice.org.

I have too many more thoughts, but it is time to take the trash to the curb and 
then feed the cats.  So you are spared for now [;<).

 - Dennis

-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com] 
Sent: Sunday, June 05, 2011 20:31
To: general@incubator.apache.org
Subject: Re: Legal concern: Are we getting to close ot a "division of markets" 
conversation?

[ ... ]

And these law apply to non-for-profit organization ? The Red-Cross and United 
Way cannot agree to 'Divide Territories' ? They have by law the obligation to 
'compete' for the potential recipient of their charity ?

Isn't Apache a non-for-profit ?

If I understand the 'Apache Way', I'd say you are wearing a 'Corporate' hat in 
this email, not your 'Apache member' hat

Norbert

-
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: Questions for the cheap seats. - Priming the Pump

[Dennis E. Hamilton]

I think this should be the very first step regardless, even for first materials 
accessible from the podling.

The next would be to figure out how to stage it onto the Apache infrastructure, 
build what can be built, see what the deltas are, etc.

This sort of preservation and assessment seems indispensible in getting going 
and seeing what the opportunities are.

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Sunday, June 05, 2011 20:45
To: general@incubator.apache.org
Subject: Re: Questions for the cheap seats.

[ ... ]

Not speaking for the Board, but this is what I'd lobby for: that we package up 
all the code that was granted to us, apply the ALv2, and drop the tarball onto 
archive.apache.org.

Third parties could pick up that code under the ALv2 license, but it would 
never be a "released product from Apache". Other producers of OOo-related 
software could incorporate that code, should they wish.

[ ... ]


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

RE: Questions for the cheap seats. - Priming the Pump

[Dennis E. Hamilton]

Since I don't know what "proper, vetted release" entails, I will have to shut 
up.  If it is a concern that Oracle has included something that doesn't belong 
to them, I suppose you might want to do whatever you need to do to ensure the 
IP is in order.  

But considering that this is the (initial) extent of the grant, I think having 
it archived for what it is would simply make sense (I am not talking about it 
being a release).  I also think it is a good idea just in case we mess up 
moving it into the Apache infrastructure and need a do-over.  

It is not about leaving the incubator or anything.  I think of it as baked 
prudence with a sauce of transparency.  I'm surprised this is a problem, but 
then I are a simple man ... .

 - Dennis

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Sunday, June 05, 2011 21:22
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: Questions for the cheap seats. - Priming the Pump

Sorry, but we don't typically release code from not-passed proposals or failed 
podlings. This would be an extraordinary circumstance, which is why I mentioned 
the Board input.

So... I would not recommend this as a "first step" since it would be abnormal. 
Tarballs on the sly aren't good; the ASF wants a proper, vetted release.

Cheers,
-g

On Mon, Jun 6, 2011 at 00:00, Dennis E. Hamilton  
wrote:
> I think this should be the very first step regardless, even for first 
> materials accessible from the podling.
>
> The next would be to figure out how to stage it onto the Apache 
> infrastructure, build what can be built, see what the deltas are, etc.
>
> This sort of preservation and assessment seems indispensible in getting going 
> and seeing what the opportunities are.
>
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: Sunday, June 05, 2011 20:45
> To: general@incubator.apache.org
> Subject: Re: Questions for the cheap seats.
>
> [ ... ]
>
> Not speaking for the Board, but this is what I'd lobby for: that we package 
> up all the code that was granted to us, apply the ALv2, and drop the tarball 
> onto archive.apache.org.
>
> Third parties could pick up that code under the ALv2 license, but it would 
> never be a "released product from Apache". Other producers of OOo-related 
> software could incorporate that code, should they wish.
>
> [ ... ]
>
>
> -
> 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: Legal concern: Are we getting to close ot a "division of markets" conversation?

[Dennis E. Hamilton]

I take Rob to mean that he has to deflect that kind of conversation.  And he 
probably has to think about distancing himself from such conversations of 
others.  Perhaps he could be better at it.  Does it really matter? (Not being a 
corporate employee of any flavor, I consider myself free to speak on this.)

Of course, others can talk about divisions of labor or whatever, but I think 
the Apache processes are safeguard enough.  Pontifications about who is 
upstream/downstream and what the relationship and collaborations are don't 
matter.  (It is patently obvious that Apache *can't* be downstream from 
LibreOffice.  As heads-of-state like to say, all other options are on the 
table.)

The only way this gets interesting, with regard to LibreOffice at any rate, 
would be if the Apache Incubator project declined to accept the proposal.  Then 
we can see how that works out for all concerned parties.  (I am not advocating 
that turn of events and I don't have a vote in any case.)

 - Dennis

-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com] 
Sent: Sunday, June 05, 2011 21:45
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: Legal concern: Are we getting to close ot a "division of markets" 
conversation?

On Sun, Jun 5, 2011 at 10:51 PM, Dennis E. Hamilton  
wrote:
> The problem here is that Rob and Sam and other well-known employees 
> are being addressed as IBM employees here

I perceive Sam answers and arguments to be consistent with the 'I am an 
individual member of Apache' position. I may disagree with his arguments or 
positions, but at least they are consistent with the framework posited.

I certainly cannot say the same for many of Rob's post...


>[..]They can operate as individuals but they must also honor the requirements 
>on their conduct that are a consequence of their employment.

and shall I emphasis:

Rob Weir said:
>There are some things we must not talk about, especially things where 
>competitors may be seen as arranging to reduce competition.  We need to 
>steer the conversation far from this.

_we_ here means who ? I understood it, by default, to mean _we_ AF member and 
by extensions the guests (like me) on this list
Am I to understand that AP members are bound by what-ever contractual 
obligation Rob may or may not have with IBM ?

Norbert

-
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: Questions for the cheap seats. - Priming the Pump

[Dennis E. Hamilton]

OK, I get that.  I am pushing for the least that could possibly work in terms 
of having a base under ALv2 that can then be refined, refactored, whatever, but 
it captures the contribution in a form that is suitable to continue from, 
however much it still needs to be wacked on.  It might not build, or only build 
with stubs, because there are toxic dependencies to be staunched off until they 
are dealt with.  I think one wants to minimize how long it is sat on in a 
non-ALv2 form is all, even if it isn't "release-worthy."  

I can stop yammering about that now.

In that sense, you're right, it is not the here-it-is-and-its-not-ours case 
were the incubator proposal to be declined.  In the case of OpenOffice.org, 
even a code dump under ALv2 is a significant artifact.

 - Dennis

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Sunday, June 05, 2011 23:19
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: Questions for the cheap seats. - Priming the Pump

Well, a quick answer is that we can't make a release that requires code under a 
license less permissive than ALv2. "Releasing" a tarball of the entry code 
would most likely not fulfill that requirement.
That's why it gets a bit tricky.

The meta-answer is that we don't want to surprise downstream consumers with a 
release that requires more than ALv2.

I don't disagree with the concept, mind you, but I'd rather push forward with 
making the podling accepted and successful. Then making a proper release that 
consumers can rely on, with the full backing of the ASF.

Cheers,
-g

On Mon, Jun 6, 2011 at 00:40, Dennis E. Hamilton  
wrote:
> Since I don't know what "proper, vetted release" entails, I will have to shut 
> up.  If it is a concern that Oracle has included something that doesn't 
> belong to them, I suppose you might want to do whatever you need to do to 
> ensure the IP is in order.
>
> But considering that this is the (initial) extent of the grant, I think 
> having it archived for what it is would simply make sense (I am not talking 
> about it being a release).  I also think it is a good idea just in case we 
> mess up moving it into the Apache infrastructure and need a do-over.
>
> It is not about leaving the incubator or anything.  I think of it as baked 
> prudence with a sauce of transparency.  I'm surprised this is a problem, but 
> then I are a simple man ... .
>
>  - Dennis
>
> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: Sunday, June 05, 2011 21:22
> To: general@incubator.apache.org; dennis.hamil...@acm.org
> Subject: Re: Questions for the cheap seats. - Priming the Pump
>
> Sorry, but we don't typically release code from not-passed proposals or 
> failed podlings. This would be an extraordinary circumstance, which is why I 
> mentioned the Board input.
>
> So... I would not recommend this as a "first step" since it would be 
> abnormal. Tarballs on the sly aren't good; the ASF wants a proper, vetted 
> release.
>
> Cheers,
> -g
>
> On Mon, Jun 6, 2011 at 00:00, Dennis E. Hamilton  
> wrote:
>> I think this should be the very first step regardless, even for first 
>> materials accessible from the podling.
>>
>> The next would be to figure out how to stage it onto the Apache 
>> infrastructure, build what can be built, see what the deltas are, etc.
>>
>> This sort of preservation and assessment seems indispensible in getting 
>> going and seeing what the opportunities are.
>>
>> -Original Message-
>> From: Greg Stein [mailto:gst...@gmail.com]
>> Sent: Sunday, June 05, 2011 20:45
>> To: general@incubator.apache.org
>> Subject: Re: Questions for the cheap seats.
>>
>> [ ... ]
>>
>> Not speaking for the Board, but this is what I'd lobby for: that we package 
>> up all the code that was granted to us, apply the ALv2, and drop the tarball 
>> onto archive.apache.org.
>>
>> Third parties could pick up that code under the ALv2 license, but it would 
>> never be a "released product from Apache". Other producers of OOo-related 
>> software could incorporate that code, should they wish.
>>
>> [ ... ]
>>
>>
>> -
>> 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
>
>


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

RE: OpenOffice.org Summit Proposal - Budget Concerns

[Dennis E. Hamilton]

Some of us in the region can probably find our way to Portland, Oregon, but 
OSCON doesn't fit an open-source budget [;<).

Could there be a venue where it is not necessary to register for OSCON to be 
able to participate?

 - Dennis

-Original Message-
From: Simon Phipps [mailto:si...@webmink.com] 
Sent: Monday, June 06, 2011 11:20
To: general@incubator.apache.org
Subject: Re: OpenOffice.org Summit Proposal

On Mon, Jun 6, 2011 at 7:13 PM, Simon Phipps  wrote:

>
>
> On Mon, Jun 6, 2011 at 7:10 PM, Danese Cooper  wrote:
>
>> However, it seems to me that October and November are still rather 
>> far off, and with the wealth of conferences over the next two months, 
>> perhaps we could set something up sooner than that? OSCON, anyone?
>>
>> I've just asked for a room at OSCON, although I'd like to mention 
>> that many of TDF's members are in Europe...we need to find venues 
>> there.
>>
>
> Not many big events in Europe before the end of August :-)   I can probably
> get us space at OWF in Paris, 22-24 September (I am on the programme
> committee) if that's interesting, but it's only a month before 
> LibreOfficeCon.
>
> S.
>
>
I've requested a space at Open World Forum too.

S.


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

RE: A little OOo history - and lining up our arrows

[Dennis E. Hamilton]

I am personally quite fond of this kernel.org-style idea.  

It is consistent with focused attention on ensuring a rock-solid reference 
implementation for ODF-native office-productivity software (and reusable 
components) while allowing its confident use in building user-facing 
distributions to a wide variety of target communities.  Those distribution 
producers will also help us assure that the code is successfully portable.

 - Dennis

PS: It might be good not to call that OpenOffice.org, and we should have it 
even if for some reason we perpetuate full-up OpenOffice.org distros too. 

-Original Message-
From: Danese Cooper [mailto:dan...@gmail.com] 

Sent: Tuesday, June 07, 2011 11:00
To: general@incubator.apache.org
Cc: general@incubator.apache.org
Subject: Re: A little OOo history

Hi Phil,

IMHO we would have to roll vanilla builds just to make sure it still builds 
when we declare a version. It used to take some iterations and tweaks per 
version to get a valid build (imagine that's still true). ASF should at least 
validate "buildability" as part of servicing the codebase, but I would assume 
effectively zero consumer end-users would get their software from us...

[ ... ]

>> This complexity is one of the reasons it 
>> might be a good idea to behave like kernel.org and let OOo "distros" 
>> handle end-user packaging and distribution. 

[ ... ]


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

Introducing orcmid

[Dennis E. Hamilton]

Hi,

My name is Dennis Hamilton.  I am a semi-retired software system architect 
living in Seattle, Washington.

My profile of profiles is already up at 
.  The "orcmid" handle goes back to 
DecWars on a PDP-10 and the early CompuServe CB chat rooms.

My connection and interest in Apache OpenOffice.org is from my commitment to 
interoperable solutions in the management and processing of documents.

A member of the OASIS OpenDocument Format TC, I was drawn to OASIS by the 
formation of the ODF Interoperability and Conformance (OIC) TC in late Summer 
2008.  Once in OASIS, it was a natural step to also join the ODF TC itself.  I 
had submitted public comments before that, and I was around when David Wheeler 
kicked-off OpenFormula, originally on SourceForge.

>From a career perspective, I wrote my first line of code in the Spring of 1958 
>when I was an engineering aide at Boeing Company.  The program (in Fortran, 
>there not being any reason to call it Fortran I yet) crashed on being given 
>the first test value.   I graduated from Fortran to assembly language, and the 
>last I wrote of that was for 8080/Z80 running CP/M-80.  My career moved 
>through Remington Rand Univac and Xerox Corporation, with occasional time-outs 
>as an independent consultant.

I don't write code that much anymore, although I am fascinated with coming up 
with C/C++ examples and tips for newcomers who struggle with tools like the 
Microsoft Visual C++ Express Editions.  My hands-on work with OpenOffice, 
LibreOffice, and other instances of support for ODF is mainly in document 
forensics and QA work, in addition to continued participation in the 
development of the ODF standards.  I'm allergic to GPL'd code, but not to 
permissive licenses, so I can see myself patching this 'n' that on Apache 
projects.

I have an itch about development work for an ODF reference implementation with 
customizable/reusable components, as some of my comments on this list have 
already revealed.  I think that will be very important for the long-term health 
of ODF-native software and the promise of interoperability (and 
substitutability) that users have been promised and that is not yet fulfilled.

 - Dennis




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

RE: Request: Can "proposed committers" introduce themselves?

[Dennis E. Hamilton]

I am pleased that we have been asked to introduce ourselves.  I am excited by 
what I have been reading this morning.

I consider myself to be handicapped as an American native-language English 
speaker.  It is very easy to say something in a very complex way and not notice.

With so many participants from other language communities here, I want to 
communicate well.  So your presence is an opportunity for my own training in 
having an international life.   

And, by the way.  If you had not said you are not a native speaker, I could not 
determine that from your introduction statement.  If I were to attempt to speak 
or write French, I think it would be a great embarrassment.

I share your interest in education.  For me it takes the form of ideas from 
CP4E (computer programming for everybody) and SE4E (software engineering ...).  
 But also fluency with computing and information technology.  I don't subscribe 
so much to the idea of "computational thinking" though.

 - Dennis

PS: Someday, I would like to know what about the University of Pennsylvania 
inspired UTC, UTBM, and UTT, 
.


-Original Message-
From: eric b [mailto:eric.bach...@free.fr] 
Sent: Wednesday, June 08, 2011 01:44
To: general@incubator.apache.org
Subject: Re : Request: Can "proposed committers" introduce themselves?

Hello,

My name is Eric Bachard. In the real life, I'm Professor of Applied Physics at 
UTBM (see [1]).

[ ... ]

Last but not least, I'm not a native speaker, so please, be gentle, and 
apologies for my terrible english :)


With best regards,
Eric Bachard



[1] UTBM :  http://www.utbm.fr
[2] OpenOffice.org Domain developers : http:// 
wiki.services.openoffice.org/wiki/DomainDeveloper
[3] OpenOffice.org Education Project : http://education.openoffice.org [4] 
EducOOo : http://www.educoo.org [5] OOo4Kids : http://wiki.ooo4kids.org [6] 
OOoLight : http://wiki.ooolight.org


[ ... ]



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

RE: Request: Can "proposed committers" introduce themselves?

[Dennis E. Hamilton]

Hi Christian.

What a great positive attitude.  I'm excited to see you here.

And moin moin to you too (it is 06:56 here in Seattle).  I did not know the 
relationship with "moien" auf Deutsch.  Now I know why Svante Schubert says it. 
 

Ciao,

 - Dennis

-Original Message-
From: Christian Lippka [mailto:c...@lippka.com] 
Sent: Wednesday, June 08, 2011 01:17
To: general@incubator.apache.org
Subject: Re: Request: Can "proposed committers" introduce themselves?


[ ... ]
 So for me it is obviously love and passion and it would make me sad to not 
even try to make this proposal a success.

Now a valid question could be, why ASF and not TDF. For me, this is not a 
binary question. I have already contributed to OpenOffice.org in my spare time. 
I have also already (though small) contributed to LibreOffice in my spare time.
While I have some different opinions, I do not oppose the TDF or LibreOffice. I 
am not here to make this project win and another project fail. I am not here to 
dishonor the good work that good people put into something that they think is 
the best way to go. But I hope that people will respect others for trying to do 
something different, even so we may share many of the same goals.

[ ... ]

My technical vision (as in, not plans, no facts, no "I tell you how to do it") 
for this particular project under the umbrella of the ASF is as follows. I see 
this as an opportunity to do some bold moves that will jumpstart the free 
office world to the next level. One such bold move in the past was the switch 
to XML. I think this changed everything, and I usually hate such marketing 
speech :) What I would love to see is a major rework concerning modularization 
and configurability.
In the past I was part of many discussions on what would be the best UI 
framework for OpenOffice.org to solve all problems including world peace. 
Obviously there was no such thing. This is even more true in the world we live 
in now. There is not only the desktop any more, my smartphone is faster than my 
first development pc at StarDivision.
My android tablet has a bigger screen resolution than my first VGA monitor. To 
serve this diverse market of target devices and different input idioms there 
can not only be one user interface, there must be many.
Also it would be cool to target different groups of users by providing a user 
interface that is optimized for a special task or need. See OOo4Kids as a great 
example.

I'm not a native speaker  but I tried hard to look up every more complicated 
word in the dictionary to check for possible misreadings. If you still find 
something that you have a grudge with or find offensive, please just blame it 
on a communication issue.

Best regards,
Christian

[1] http://moinmo.in/MoinMoinEtymology


-
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: Vote plans for OOo proposal

[Dennis E. Hamilton]

Subscribing to changes of a specific page, such as 

seem to work just fine, however.
Possible stop-gap for this particular activity?

 = Dennis

-Original Message-
From: David Crossley [mailto:cross...@apache.org] 
Sent: Thursday, June 09, 2011 18:54
To: general@incubator.apache.org
Subject: Re: Vote plans for OOo proposal

Greg Stein wrote:
>  wrote:
> >
> > Presumably the wiki locks, if not physically, then at least by convention,
> > when the call for a vote has been made?
> 
> Yeah.

Yes. However we have lost our ability to oversee the Wiki.

https://issues.apache.org/jira/browse/INFRA-3668
Moin Wiki change notifications not being received

-David

-
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

[VOTE] Accept OpenOffice.org for incubation

[Dennis E. Hamilton]

 [X] +1 Accept OpenOffice.org for incubation (non-binding)

Comment: While I favor focusing on the reference implementation for ODF, as my 
previous comments reflect, I believe that and related scope decisions about 
releases and deployment are a matter for the podling to work through.



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

RE: [DISCUSSION] Accept OpenOffice.org for incubation

[Dennis E. Hamilton]

I don't understand the assertions here.  It may not matter in the larger scheme 
of things, but I didn't want some of the assumptions here to go unquestioned.

 1. It is certainly the case that the proposal comprehends sustaining 
OpenOffice.org and continuing it as an Apache project.  The proposal also makes 
this statement:

"The OpenOffice.org implementation will serve as a reference implementation of 
the Open Document Format standard."

While that is broader (depending on what the Apache OpenOffice.org 
implementation ends up being) than serving as a clean reference implementation, 
the notion of having a layered set of reference components that serve as a 
reference implementation for customization as various distributions has been 
discussed on this list, including by me, among others.  It is my primary 
interest.

In any case, I believe that is for the podling to resolve as part of its march 
through incubation.

2. The relicensing of bits not desired by the podling as LGPL strikes me as (a) 
extremely unlikely -- based on what we have been repeatedly told about the 
Apache way and (b) twice unnecessary since (i) those bits are presumably 
already available under LGPL by those who choose to go fish them off the 
OpenOffice.org site and, for that matter, from LibreOffice among other places 
and (ii) having them available in an idle but IP-cleared state at Apache,  
though not exactly lined up with the Apache way, means as ALv2 bits they are 
usable by LGPL-focused projects anyhow.  (You say copyleft license, but there 
are reciprocal licenses that are not compatible with GPL/LGPL and I assume you 
mean [L]GPL.) 

Finally, the copyright has not been transferred from Oracle.  Oracle granted 
the ASF a license under the Apache conditions for such licenses.  The copyright 
on the licensed artifacts remains with Oracle.

3. As it appears the incubator podling will commence in a matter of days, I 
think it is now a matter of seeing how the importing of OpenOffice.org bits 
proceeds and where the podling chooses to focus in terms of establishing 
deliverables.  There may well be multiple vectors, although we have to guard 
against having our arrows not lined up enough to ensure achievement of any 
successful results.

 - Dennis

-Original Message-
From: Simos Xenitellis [mailto:simos.li...@googlemail.com] 

Sent: Saturday, June 11, 2011 11:55
To: general@incubator.apache.org
Subject: Re: [DISCUSSION] Accept OpenOffice.org for incubation

[ ... ]

Since Oracle was willing to transfer the OOo source code copyrights to
the ASF, the ASF could have accepted those copyrights,
extract the related code for the ODF reference implementation, and
re-release the source code with a copyleft license.

> There is certainly no consensus on whether this is viable and the original 
> proposers do not want to limit the scope of the project to just this aspect.  
> However, there is a desire from some initial committees and some TDF 
> representatives to explore this.
>
> As a mentor I aim to see if this refactoring, with the collaboration 
> opportunities it presents, can be realised.
>

I think you refer to overall OOo refactoring (which is indeed needed),
rather than code that relates to the ODF format.

[ ... ]


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

RE: ODF Toolkit Incubation Pre-Proposal

[Dennis E. Hamilton]

I support this idea.  

I think with regard to need for an SGA or not, there is the matter of the 
current headings at the tops of source files.  (I have no idea what is 
required, I'm simply
observing what is there.)

 - Dennis

"/
"*
"* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER
"* 
"* Copyright 2008, 2010 Oracle and/or its affiliates. All rights reserved.
"* Copyright 2009, 2010 IBM. All rights reserved.
"* 
"* Use is subject to license terms.
"* 
"* Licensed under the Apache License, Version 2.0 (the "License"); you may not
"* use this file except in compliance with the License. You may obtain a copy
"* of the License at http://www.apache.org/licenses/LICENSE-2.0. You can also
"* obtain a copy of the License at http://odftoolkit.org/docs/license.txt
"* 
"* Unless required by applicable law or agreed to in writing, software
"* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
"* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
"* 
"* See the License for the specific language governing permissions and
"* limitations under the License.
"*
"/"

-Original Message-
From: rabas...@gmail.com [mailto:rabas...@gmail.com] On Behalf Of Rob Weir
Sent: Monday, June 27, 2011 12:43
To: general@incubator.apache.org
Cc: d...@poi.apache.org; ooo-...@incubator.apache.org
Subject: ODF Toolkit Incubation Pre-Proposal

[ ... ]

Also, since this is already an open source project with all code under
Apache 2.0, I assume no SGA is required?

So please let me know if you agree that Apache would be a good
location to further develop the ODF Toolkit libraries.

Regards,

-Rob


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

RE: [PROPOSAL] ODF Toolkit for Incubation

[Dennis E. Hamilton]

 1. In the proposal,

"The coders on the existing ODF Toolkit will comprise the initial committers on 
the Apache project. These committers have varying degrees of experience with 
Apache-style open source development, ranging from none to being committers on 
other Apache projects."

That strikes me as inadequately expansive/inclusive.  It makes me wonder, why 
doesn't the project simply stay where it is?  You appear to have a definite 
roadmap for how you want to see this project proceed.

 2. Also, the current code carries template Apache ALv2 notices with copyright 
statements such as

/
*
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER
* 
* Copyright 2008, 2010 Oracle and/or its affiliates. All rights reserved.
* Copyright 2009, 2010 IBM. All rights reserved.
* [... usual ALv2 template text ...]
*/

Is it intended that there be an SGA or will this code simply be adapted as 
licensed?  [I am curious because I have been restructuring some projects of 
mine along these lines and I'd like to see how that works.]

 3. In the code base, there appear to be other committers (e.g., Devin and 
Michel).  Is there some reason they are not among the initial committers?  Are 
the listed Initial Committers the only current committers on the ODF Toolkit 
projects?

 4. Can we know the contact e-mail and current iCLA status of the initial 
committers?

 - Dennis

-Original Message-
From: Dave Fisher [mailto:dave2w...@comcast.net] 
Sent: Thursday, July 21, 2011 08:03
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] ODF Toolkit for Incubation


On Jul 21, 2011, at 7:10 AM, Andy Brown wrote:

> Rob Weir wrote:
>> On Wed, Jul 20, 2011 at 8:03 PM, Andy Brown  wrote:
>>> Rob Weir wrote:
 And I've added it to the wiki:
 http://wiki.apache.org/incubator/ODFToolkitProposal
 
 -Rob
>>> 
>>> What can I do to help?
>>> 
>> 
>> 
>> Good question.  Once the project is set up, there will be many areas
>> where we would benefit from contributions.  Naturally, this includes
>> Java programmers, but also QA, documentation, and of course, users.
> 
> I was referring to get it approved as an incubator project.  I see no
> where to sign up as a committer as we had with OOo.

I would like to help as well. Are people allowed to add their names to the 
proposal?

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: nbsp in unicode podling pages

[Dennis E. Hamilton]

Looking at the source of the text/html at 

it appears that this is relevant:



in the  element.  Unfortunately, the pages are served up as UTF8.  If I 
change the encoding in which the page is viewed to 8859-1, the problem goes 
away.

It could be because all of the CSS is in front of the  element.

It also could be because the server reports a MIME Type that has UTF-8 coding 
as its charset parameter and the file is not in UTF-8.

Finally, did the XML have   or &0xa0; ?  And what is the explicit 
character-set encoding specified in the XML prolog?  (Oddly, the default for 
MIME Type text/xml is not a Unicode encoding.)

There's a long chain of transformation/character-set-encoding-assumption points 
at which this could be going wrong in the web-site-production tool chain.

 - Dennis

-Original Message-
From: Michael Stroucken [mailto:mxs+apa...@cmu.edu] 
Sent: Sunday, August 14, 2011 21:32
To: general@incubator.apache.org
Subject: nbsp in unicode podling pages

Hi,

I'm noticing that non-breaking spaces are written out as chr(0xa0) in 
the HTML documents after being converted from XML. 
(http://incubator.apache.org/tashi/). To work properly, the spaces 
should be encoded something like chr(0xc0)+chr(0xa0), or   I guess.

Am I missing some configuration in the site building setup?

The locale I am running ant in is "de_DE.UTF-8".

Thanks for any help,
Michael.

-
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: A Spam ? (was: Re: You have been recruited to the Love/Avon Army of Women)

[Dennis E. Hamilton]

It's a version of the Nigerian scam, but claimed to be from Ivory Coast.

-Original Message-
From: Mohammad Nour El-Din [mailto:nour.moham...@gmail.com] 
Sent: Wednesday, August 31, 2011 05:03
To: general@incubator.apache.org
Subject: A Spam ? (was: Re: You have been recruited to the Love/Avon Army of 
Women)

Hi All...

   Is that a Spam ?

2011/8/31 frank_kamar...@yahoo.fr :
> frank_kamar...@yahoo.fr has invited you to the Army of Women website
>
> Assistance d'urgence.
>
> S'IL VOUS PLAÎT NOTE réponse à mon e-mail 
> privé
> CASE CI-DESSOUS frank_kamar...@yahoo.fr
> à Abidjan, en Côte d'ivoireWest afrique
>
> Bonjour Cher,
>
> Salutations Je souhaite demander votre aide dans une transaction 
> financière
> et je suis sûr que ce sera d'un avantage  mutuelle.
>
> Je souhaite investir dans la production et de gestion immobilière 
> dans votre pays.
> J'ai hérité de la somme de six millions, USD 
> (6,000,000.00 $) J'ai besoin de votre aide pour investir dans votre pays.
> Vous aurez juste a recevoir les fonds dans votre compte dans votre pays. Je 
> serai heureux de vous donner au moins
> 15% de la somme totale pour votre aide. S'il vous plaît, il est 
> important que vous me contacter je vous demande d'accepter de m ecrire  un 
> mot gentil dans mon email
> et je vous assure que je vous répondrai .
> Voici mon email: frank_kamar...@yahoo.fr
> En attente de votre réponse immédiate et que Dieu 
> vous bénisse.
> Cordialement
> FRANK KAMARA1.
>



-- 
Thanks
- Mohammad Nour

"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein

-
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: Confusion: Sponsoring entity and Champions

[Dennis E. Hamilton]

For example, the Apache OpenOffice.org Podling has no chair.

The creation of the monthly report has been undertaken as a community effort, 
although it seems to be a variant of launch-pad chicken (falling on whoever 
thinks the deadline is too close and it is time to put something up there for 
other PPMC members to review and amend).

 - Dennis

-Original Message-
From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] 
Sent: Thursday, September 22, 2011 06:34
To: general@incubator.apache.org
Subject: Re: Confusion: Sponsoring entity and Champions

On Thu, Sep 22, 2011 at 3:14 PM, sebb  wrote:
>>> Do PPMCs have chairs?
>>> If not, then maybe the Champion fulfils that role until eventual
>>> graduation; otherwise they fulfil the role until the PPMC elects a
>>> chair.
>>
>> I really thought PPMCs have chairs!  Otherwise how does the Incubator PMC
>> ensure that podlings report on time?

That is what the mentors are for. AFAIK there is no Chair role for
PPMCs. Electing one is typically done when the board resolution is
written. Usually the person picking up the tab of writing the reports
and instigating committer votes is the person to be picked as the
Chair.

Assigning a Chair role in a podling while incubating probably is a bad
idea as it invites BDFL proliferation...

Martijn

-
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

Establishing New Committers

[Dennis E. Hamilton]

Here's a Form letter that I have been evolving.  It has been used in recent
invitations from the Apache OpenOffice.org Podling where an iCLA is already
on file.

  You are welcome to try this.  There are additional places to be customized
for use by a different podling.  I have added brackets where that would
have to happen.

Also, you may have already done some or all of this with regard to your two
new invitees.  I would customize to get the essential information so that
an ACCOUNT REQUEST can be made.  There's a format for that too.  Let me know.

 - Dennis


USE FOR FIRST-TIME COMMITTER THAT HAS AN iCLA ON FILE
The only lines that need to be customized are the subject and the salutation
at the beginning.  Everything else can be copied "as is."
Remember to send as plaintext.
 - - - - - - - - - - - - - - - - - - - - - - - - - - - -


From: [PPMC Member]
To: [invitee e-mail]
Cc: ooo-priv...@incubator.apache.org
Subject: [invitee name]: Apache OOo Committer and PPMC Invitation

Hello [invitee name],

The [Apache OpenOffice Podling Project Management Committee] (PPMC) hereby
offers you committer rights to the project as well as membership in the PPMC.

Being a committer enables you to more easily make changes without needing to
go through the patch submission process.  Being a PPMC member enables you to
guide the direction of the project.

Being a committer does not require you to participate any more than you
already do.  It does tend to make one even more committed.  You will probably
find that you spend more time here.

Of course, you can decline and instead remain as a contributor, participating
as you do now.

 A. This personal invitation is a chance for you to accept or decline in
private.  Either way, please let us know in reply to the
[ooo-priv...@incubator.apache.org] address only.

 B. If you are accepting, your iCLA is already registered with the ASF so we
can establish your Apache User Name/ID immediately:

 1. Even though you may have included this in your iCLA, please include in
your reply a list of preferred Apache User Name/IDs.  The  will be a Unix
system User ID and should be a simple alphanumeric string.  Please verify that
the s you list have not already been taken:
.

 2. Also specify the e-mail address that you want your  @ apache.org
e-mail address to forward to.

 3. When you reply, please send from the e-mail that you supplied on your
iCLA, if possible.

 4. When that information is received, you will receive further information on
next steps.

We value your contributions and recognize that you are committed to the Apache
project.

Regards,

 - [The Apache OpenOffice.org PPMC]


smime.p7s
Description: S/MIME cryptographic signature

RE: Establishing New Committers

[Dennis E. Hamilton]

Here's a modification of the letter that I have been evolving.  It has been
used in recent invitations from the Apache OpenOffice.org Podling where no
iCLA is on file.

  You are welcome to try this.  There are additional places to be customized
for use by a different podling.  I have added brackets where that would
have to happen.  I also missed some places in the previous one out of over-
eagerness to be helpful.  There are more bracketed places in this one.

 - Dennis

NOTE: I intend to keep separate committer and committer+PPMC invite boiler
plate.  In the early days of the OOo podling, most are invited to both.


USE FOR FIRST-TIME COMMITTER THAT HAS NO iCLA ON FILE
The only lines that need to be customized are the subject and the salutation
at the beginning.  Everything else can be copied "as is."
Remember to send as plaintext. [Customize bracketed entries for other podling\
 - - - - - - - - - - - - - - - - - - - - - - - - - - - -


From: [PPMC Member]
To: [invitee e-mail]
Cc: [ooo-priv...@incubator.apache.org]
Subject: [invitee name]: Apache [OOo Committer [and PPMC]] Invitation

Hello [invitee name],

The [Apache OpenOffice Podling Project Management Committee] (PPMC) hereby
offers you committer rights to the project[ as well as membership in the 
PPMC].

Being a committer enables you to more easily make changes without needing to
go through the patch submission process.  [Being a PPMC member enables you to
guide the direction of the project.]

Being a committer does not require you to participate any more than you
already do.  It does tend to make one even more committed.  You will probably
find that you spend more time here.

Of course, you can decline and instead remain as a contributor, participating
as you do now.

 A. This personal invitation is a chance for you to accept or decline in
private.  Either way, please let us know in reply to the
[ooo-priv...@incubator.apache.org] address only.

 B. If you are accepting, the next step is to register an iCLA
with the Apache Software Foundation:

  1. Details of the iCLA and the forms are found through this
 link: .

  2. The form (text or PDF version) provides instructions for its
 completion and return to the Secretary of the ASF.

  3. When you transmit the completed iCLA, indicate that you are
 to be a committer and PPMC member of the Apache [OOo podling].
 This will allow the Secretary to notify the PPMC when your
 iCLA has been recorded.

When recording of your iCLA is noticed, you will receive a
follow-up message with the next steps for establishing you as
a committer.

Regards,

 - [The Apache OpenOffice.org PPMC]


smime.p7s
Description: S/MIME cryptographic signature

RE: incubator is a single group

[Dennis E. Hamilton]

Small items:

 1. There are no podling PPMC members that have the necessary authorizations, 
even though they are committers.  Mentors (and a champion) yes, chair no.  This 
is partly why there are these regular calls for a mentor or someone on the 
incubator PMC to connect some dots.

 2. The authz is currently the only structure that carries who the official 
committers of a podling are and this can be cross-checked with in-podling 
records for managing intake of new committers, PPMC members, and reflecting 
changes in status that arise.  This can be maintained within the PPMC but it is 
great to have "ground truth" in a concrete artifact that does not depend on how 
well a podling does or does not manage its administrivia.  Making more work for 
secretary@ also doesn't seem like a win.

I sympathize with Roy's concern for where this moves some burdensome work.  My 
only concern that it not make it even more awkward/unreliable to operate within 
a podling, where not all the dots are visible, let alone a means to connect 
them.

 - Dennis

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Friday, November 11, 2011 05:24
To: general@incubator.apache.org
Subject: Re: incubator is a single group

On 11 November 2011 07:58, Roy T. Fielding  wrote:
> Hi folks,
>
> It has come to my attention that we are wasting resources and
> time trying to manage separate committer lists within infra for
> every podling.  That is something that we can effectively manage
> once a TLP has become self-governing and self-sufficient in its
> interaction with infrastructure.  It is not something that we can
> effectively manage when we have dozens of podlings trying to make
> changes through the incubator chair.

SVN podling access is currently managed through a file which can be
updated by members of the pmc-chairs group.
[And a few others such as infra/execs]
So it is no only just the incubator chair who can update the file.

[AFAIK, there aren't any separate LDAP groups for podlings; all
podling SVN access groups are managed by that file.]

> I *suggest* that incubator change the procedure such that all
> committers (or at least all committers within a single LDAP
> group) have access to all incubator areas and that new people
> simply be requested to only commit within areas for which they
> have been given permission by the podling developers.  That
> will significantly ease everyone's job and allow more direct
> control by podlings for inviting/uninviting their devs.

There is already an "incubator" LDAP group, to which all podling
committers should belong, as it gives access to website updates.
This could also be given access to podling SVN directories.

If the individual podling member lists were abandoned, I think there
would still need to be a way to document the current members of a
podling.

The lists in the SVN auth file are currently used for that purpose
(e.g. they are used in creating
http://people.apache.org/committers-by-project.html)

> Roy
>
> -
> 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: incubator is a single group

[Dennis E. Hamilton]

It is the case that Initial Committers are eligible to serve on the PPMC, 
though not all choose to do so.  

Also, it is apparently a recommendation that invited committers be invited to 
the PPMC, but it doesn't seem to be a requirement.  Again, not all that are so 
invited choose to serve on the PPMC.

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Saturday, November 12, 2011 03:52
To: general@incubator.apache.org
Subject: Re: incubator is a single group

[ ... ]

Is this an alternative?
Aren't podling committers the same as PPMC members?

[ ... ]


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

RE: [PROPOSAL] Clarify the role of the Champion as an "incubation coordinator" (was: should podlings have informal chairs?)

[Dennis E. Hamilton]

As member of a PPMC whose champion continued after formation of the podling, I 
would miss someone in that role.  

Also, the notion of the champion as the podling mentor herder has a certain 
appeal. 

At the moment, our champion is the person who performs many of the actions that 
require more than PPMC committer karma, and having that spread around (but not 
diffused out of existence) would be great.

 - Dennis

-Original Message-
From: Shane Curcuru [mailto:a...@shanecurcuru.org] 
Sent: Wednesday, November 23, 2011 10:52
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Clarify the role of the Champion as an "incubation 
coordinator" (was: should podlings have informal chairs?)

Great stuff, and great discussion.  Thanks in particular Bertrand for 
making it a specific proposal.  +1


On 2011-11-22 4:29 PM, Bertrand Delacretaz wrote:
...
> 3. The Champion is not necessarily a mentor.

Correct - from the organizational point of view, the champion role as 
defined is almost more about ensuring the mentors are working, and 
ensuring podling reports are done well - and not necessarily about 
actively mentoring and working with the podling committers.

Obviously, in many/most cases the champion will be a mentor too, but it 
isn't strictly part of what we need the role to be.

Make sense?

And although I understand there are some issues with the choice if the 
word, I'd still suggest staying with "Champion", since it's already in 
use and fits pretty well.

- Shane

-
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: [PROPOSAL] Clarify the role of the Champion as an "incubation coordinator" (was: should podlings have informal chairs?)

[Dennis E. Hamilton]

I'm sorry.  I did not mean to suggest that the champion of the PPMC of which I 
am a member is any of those cases.  I'm certain our champion is an ASF Member.  
I haven't checked to see if the champion is a member of the IPMC, though I 
wouldn't be surprised.

I was not speaking on behalf of champions being elected at all.  The case in my 
experience is where a champion continued championing after the podling was 
established.

 - Dennis

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Wednesday, November 23, 2011 14:34
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: [PROPOSAL] Clarify the role of the Champion as an "incubation 
coordinator" (was: should podlings have informal chairs?)

On Wed, Nov 23, 2011 at 02:09:13PM -0800, Dennis E. Hamilton wrote:
> Also, the notion of the champion as the podling mentor herder has a certain
> appeal. 

It seems a little odd to me that a PPMC member who is neither an ASF Member
nor on the IPMC may be elected to the Champion role and then would take on
responsibility for herding Mentors.

Marvin Humphrey


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

RE: [PROPOSAL] Clarify the role of the Champion as an "incubation coordinator" (was: should podlings have informal chairs?)

[Dennis E. Hamilton]

My apologies for the diversion.  I should not have said anything about my 
direct knowledge of a champion being an IPMC member or not.  Whether I knew 
that or not was irrelevant to the point I wanted to make, which is now 
evidently lost.

1. I find value in the idea of the original champion continuing as a champion 
over the life of the PPMC (unless replaced) and serving as a mentor of the 
mentors.

2. I do not find value in that role being taken over by a non-mentor PPMC 
member because of the hazards already mentioned and because a champion has 
karma that PPMC members do not.  Losing such a resource (and a go-to person 
when mentor-support is MIA, and vice versa) strikes me as too costly/risky.  
Also, it strikes me as important that a graduatable PPMC not have any 
indispensable members.  One way to ensure that is to keep the responsibilities 
diffuse and also accounted for.

 - Dennis

-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Thursday, November 24, 2011 02:08
To: general@incubator.apache.org
Cc: dennis.hamil...@acm.org
Subject: Re: [PROPOSAL] Clarify the role of the Champion as an "incubation 
coordinator" (was: should podlings have informal chairs?)

On 24 November 2011 03:29, Sam Ruby  wrote:
> On Wed, Nov 23, 2011 at 6:12 PM, Dennis E. Hamilton
>  wrote:
>> I'm sorry.  I did not mean to suggest that the champion of the PPMC of which 
>> I am a member is any of those cases.  I'm certain our champion is an ASF 
>> Member.  I haven't checked to see if the champion is a member of the IPMC, 
>> though I wouldn't be surprised.
>
> You (as a committer) can verify that for yourself by looking here:
>
> https://svn.apache.org/repos/private/committers/board/committee-info.txt

Or consult the public

http://people.apache.org/committers-by-project.html#incubator-pmc

which *should* be the same (it's the LDAP committee list for incubator).

>> I was not speaking on behalf of champions being elected at all.  The case in 
>> my experience is where a champion continued championing after the podling 
>> was established.
>>
>>  - Dennis
>
> - Sam Ruby
>
[ ... ]


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

RE: [PROPOSAL] Clarify the role of the Champion as an "incubation coordinator" (was: should podlings have informal chairs?)

[Dennis E. Hamilton]

I had hoped that the business of a PPMC-member champion being a VP-elect would 
have just gone away.  That coupling is certain to inspire political motivation 
and purpose.

I think that's a terrible trick to play on a PPMC.

 - Dennis

-Original Message-
From: Mattmann, Chris A (388J) [mailto:chris.a.mattm...@jpl.nasa.gov] 
Sent: Thursday, November 24, 2011 07:45
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Clarify the role of the Champion as an "incubation 
coordinator" (was: should podlings have informal chairs?)

That would work for me, Bertrand...with the assumption that the 
later *Champion* would be the eventual VP. I think that *has* 
to happen and is consistent with what I have seen even now.

[ ... ]


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

RE: [PROPOSAL] Clarify the role of the Champion as an "incubation coordinator" (was: should podlings have informal chairs?)

[Dennis E. Hamilton]

I understand about PMC chairs, but I thought that is for a TLP and happens at 
Podling graduation.

Having PPMC chairs is a different story, and I hope I was careful not to 
confuse the two.  I also don't want to collapse champion and PPMC chair in 
some way.  I still favor the one and not the other.  I have no need to say 
more about that.

Clarifying the role of champion is certainly a good idea.

 - Dennis

-Original Message-
From: Mattmann, Chris A (388J) [mailto:chris.a.mattm...@jpl.nasa.gov]
Sent: Thursday, November 24, 2011 09:37
To: general@incubator.apache.org
Cc: dennis.hamil...@acm.org
Subject: Re: [PROPOSAL] Clarify the role of the Champion as an "incubation 
coordinator" (was: should podlings have informal chairs?)

On Nov 24, 2011, at 9:25 AM, Ross Gardler wrote:

> On 24 November 2011 17:17, Dennis E. Hamilton  
> wrote:
>> I had hoped that the business of a PPMC-member champion being a VP-elect 
>> would have just gone away.  That coupling is certain to inspire political 
>> motivation and purpose.
>>
>
> The suggestion below that the PPMC member elected as champion be the
> eventual VP is just a suggestion that the PPMC elected champion will
> be the PMC chair when the podling graduates.

Thanks Ross. That's what I was trying to say, just didn't put it as elegantly
as you.

Dennis, I get what you're saying and no worries, I'm not saying
anyone should be an "auto-elect" based on political motivations, or
based on how loud they scream. What you'll find over time in the ASF
is that "those who do, decide". I haven't seen a PMC chair (aka eventual
VP of a project) get elected so far that didn't "do" in some way, and
that was merely appointed as a political thing.

Not to say that it couldn't happen, I just haven't seen it.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++


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


smime.p7s
Description: S/MIME cryptographic signature

RE: [PROPOSAL] Clarify the role of the Champion as an "incubation coordinator" (was: should podlings have informal chairs?)

[Dennis E. Hamilton]

Ross,

I don't see the champion (who is at least a mentor) and an informal PPMC chair 
somehow selected among the PPMC members as interchangeable or equivalent.  My 
concern was, to the extent that view exists (and I may simply be confused), I 
don't get it.

I'd be happy to learn that I have misunderstood some of the positions expressed.

 - Dennis

-Original Message-
From: Ross Gardler [mailto:rgard...@opendirective.com] 
Sent: Thursday, November 24, 2011 11:26
To: dennis.hamil...@acm.org; general@incubator.apache.org
Subject: RE: [PROPOSAL] Clarify the role of the Champion as an "incubation 
coordinator" (was: should podlings have informal chairs?)

Sent from my mobile device, please forgive errors and brevity.
On Nov 24, 2011 5:59 PM, "Dennis E. Hamilton" 
wrote:
>
> I understand about PMC chairs, but I thought that is for a TLP and
happens at
> Podling graduation.

The official role of PMC  chair is created upon graduation, yes. But the
responsibilities the role carries start once incubation starts. At present
nobody l owns those responsibilities during graduation.

>
> Having PPMC chairs is a different story, and I hope I was careful not to
> confuse the two.  I also don't want to collapse champion and PPMC chair in
> some way.  I still favor the one and not the other.  I have no need to say
> more about that.
>

I'm confused, and therefore request more info about your concern. The two
roles, as I understand them are essentially the same (once incubation
starts).  I don't see any significant differences and thus don't see any
"collapse" of two roles into one. Can you point to the differences you
perceive?

Ross

> Clarifying the role of champion is certainly a good idea.
>
[ ... ]


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

RE: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release Kafka 0.7.0-incubating)

[Dennis E. Hamilton]

I notice that the NOTICE has this incomplete statement:

   This product includes the scala runtime and compiler
   (www.scala-lang.org) developed by EPFL, which includes
   the following license:

There is not any following license.

I also notice that the LICENSE file has copyright notices.

 - Dennis

-Original Message-
From: Neha Narkhede [mailto:neha.narkh...@gmail.com]
Sent: Wednesday, November 30, 2011 18:30
To: general@incubator.apache.org
Cc: kafka-us...@incubator.apache.org
Subject: Feedback on updated NOTICE and LICENSE files (was: [VOTE] Release 
Kafka 0.7.0-incubating)

Hi,

The Kafka community is hoping to get some feedback on the updated NOTICE
and LICENSE files for Kafka, before we post a new vote for it.

http://people.apache.org/~nehanarkhede/NOTICE
http://people.apache.org/~nehanarkhede/LICENSE

The previous vote thread or release artifacts are here -
http://apache.markmail.org/message/hntuhwkbazwlfdoe?q=Kafka+list:org.apache.incubator.general

We would appreciate it if you can please take the time to review this now,
since we would like to ensure a smoother vote this time around.

Thanks,
Neha


smime.p7s
Description: S/MIME cryptographic signature

RE: [PROPOSAL] Apache Bloodhound

[Dennis E. Hamilton]

Uh, here's the TRAC License: .

You have to do what it says.  The language is very simple.  So is the Copyright 
notice.

If this is the codebase that you propose to be the foundation of Bloodhound 
development, I suspect that an SGA (Software Grant Agreement) from Edgewall 
Software is preferred in order to have it be licensable by Apache under the 
ALv2.  If an SGA is possible, it would deal with the patent issue that has been 
raised on this thread.  See .

I have no idea how much the SGA is a requirement for the incubator proposal 
moving forward.  Your champion or proposed mentors should know.  I recommend 
that be figured out ASAP.  How that will be handled might need to be added to 
the incubator proposal, also.

 - Dennis

If you end up needing a plan B, it might be appropriate to move where further 
development under the BSD license is possible.  SourceForge might be an useful 
choice.  SourceForge offers Trac as an available feature for projects, and it 
also supports SVN as one of its repository services.  (I only mention that 
because I was looking into the SourceForge 2.0 beta recently and I have some 
small projects there.)

-Original Message-
From: Niclas Hedhman [mailto:nic...@hedhman.org] 
Sent: Monday, December 05, 2011 18:38
To: general@incubator.apache.org
Cc: Mark Struberg; Ian Wild; Greg Stein
Subject: Re: [PROPOSAL] Apache Bloodhound

I suggest legal-discuss@ is involved to answer it. Although it is Cat
A license, I don't think it is fully kosher, as we promise that the
original contributor hasn't submarined any patents, but BSD doesn't
state this. Maybe it is a tiny point, but more eyes from
legal-discuss@ won't hurt...

On Tue, Dec 6, 2011 at 6:26 AM, Hyrum K Wright
 wrote:
> I don't know the proper answer to the licensing and patent questions.
> My understanding (standard caveats apply) is that the BSD is a
> Category A license, and as software distributed under it may be
> included in ASF software such as Bloodhound.  I'm unsure what the
> concern about BSD notices in source file is, nor do I know if such
> concern is well-founded.
>
> -Hyrum
>
> On Fri, Dec 2, 2011 at 8:22 PM, Niclas Hedhman  wrote:
>> SO, IIUIC, the first step is to import TRAC, and we will have
>> primarily a BSD codebase as the main body of code?
>> Does this mean that all BSD notices in source files must live in ASF
>> repository for all eternity, assuming that we are allowed to
>> sublicense into ALv2 (which I think is no problem)?
>> And what about the lack of patent license that we offer downstream,
>> but have not received from upstream?
>>
>>
>> Cheers
>> Niclas
>>
>> On Sat, Dec 3, 2011 at 12:14 AM, Mark Struberg  wrote:
>>> so this is basically Trac ++ and a fork of Trac ?
>>>
>>> Or is it a completely rewritten new approach?
>>>
>>> just curious :)
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> - Original Message -
 From: Hyrum K Wright 
 To: general@incubator.apache.org
 Cc: Ian Wild ; Greg Stein 
 Sent: Friday, December 2, 2011 4:53 PM
 Subject: [PROPOSAL] Apache Bloodhound

 Hello Incubator!

 WANdisco would like to propose the inclusion of a new project, Apache
 Bloodhound, to the Incubator.  The proposal has been posted to the
 wiki[1], and is also included below.  We've privately discussed this
 project with a number of individuals, but would now like to get the
 discussion rolling here.  Bloodhound is new effort, based on Trac[2],
 to provide issue tracking and collaboration tools for developers.

 We realize the proposal is a work-in-progress, and as such look
 forward to feedback and discussion.  We hope to attract mentors and
 other interested parties through the incubation proposal process, and
 further diversify the community as we move through incubation.  In
 particular, this project is an opportunity to build a new community
 around the codebase, and we look forward to doing so at the ASF.

 -Hyrum

 [1] http://wiki.apache.org/incubator/BloodhoundProposal
 [2] http://trac.edgewall.org/


 = Bloodhound - Collaborative development tools based on Trac =

 == Abstract ==

 Bloodhound will be a software development collaboration tool,
 including issue tracking, wiki and repository browsing.  Essentially
 an improved distribution of the well-known Trac project, Bloodhound
 will include the common and useful plugins to enable a more complete
 distribution than a typical Trac installation.

 == Proposal ==

 Bloodhound will be a software development collaboration tool, based on
 the existing Trac project, which will include a repository browser,
 wiki, and defect tracker.  In addition to the standard Trac
 installation, Bloodhound will incorporate a number of popular modules
 into the core distribution, and include addi

RE: [PROPOSAL] Apache Bloodhound

[Dennis E. Hamilton]

-Original Message-
From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com]
< 
http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3cCAJjMeYMb0+uCrbuaX83b1NSbhq8G3SfzafXUkfrKjxi=ubq...@mail.gmail.com%3e>
Sent: Tuesday, December 06, 2011 10:06
To: general@incubator.apache.org; dennis.hamil...@acm.org
Cc: Mark Struberg; Ian Wild; Greg Stein; hwri...@apache.org
Subject: Re: [PROPOSAL] Apache Bloodhound

On Mon, Dec 5, 2011 at 10:22 PM, Dennis E. Hamilton
 wrote:
> Uh, here's the TRAC License: <http://trac.edgewall.org/wiki/TracLicense>.
>
> You have to do what it says.  The language is very simple.  So is the 
> Copyright notice.
>
> If this is the codebase that you propose to be the foundation of Bloodhound 
> development, I suspect that an SGA (Software Grant Agreement) from Edgewall 
> Software is preferred in order to have it be licensable by Apache under the 
> ALv2.  If an SGA is possible, it would deal with the patent issue that has 
> been raised on this thread.  See <http://www.apache.org/licenses/#grants>.

"preferred" or "required"?


   I said preferred because I don't know where the line is.
   A substantial body of work is being brought over and it
   seems to me that it should be required, but I'm not the
   authority.  However, to the extent that this draft is
   authoritative, I would use it for guidance:
   <http://incubator.apache.org/guides/mentor.html#initial-ip-clearance>.


I'll also note that small bits of the Trac test suite are already
being distributed in ASF releases of Subversion and hosted in our
public repo.  See:
  http://svn.apache.org/repos/asf/subversion/trunk/NOTICE
and
  
http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/python/tests/trac/test.py

Subversion still maintains the required attribution per the Trac
License, but also adds the ALv2.  This was a point of discussion
during the Subversion incubation, but was vetted and approved and has
been the status quo for over 2 years.


   I have no reason to believe that the SVN usage is a precedent for
   the Bloodhound situation, nor vice versa.  I'm not touching that.


> I have no idea how much the SGA is a requirement for the incubator proposal 
> moving forward.  Your champion or proposed mentors should know.  I recommend 
> that be figured out ASAP.  How that will be handled might need to be added 
> to the incubator proposal, also.

What specific questions would you like to see addressed in the proposal?


  I think the need for an SGA from Edgewall should be identified
  as a key requirement in being able to have a successful IP
  Clearance.  This is not a small amount of BSD code, it is the
  foundation for the Bloodhound project.
 It would also be good to indicate in the proposal whether the
  copyright holders have expressed any willingness to provide such
  an agreement.  This strikes me as a material issue for incubation.


>  - Dennis
>
> If you end up needing a plan B, it might be appropriate to move where 
> further development under the BSD license is possible.  SourceForge might be 
> an useful choice.  SourceForge offers Trac as an available feature for 
> projects, and it also supports SVN as one of its repository services.  (I 
> only mention that because I was looking into the SourceForge 2.0 beta 
> recently and I have some small projects there.)
>
> -Original Message-
> From: Niclas Hedhman [mailto:nic...@hedhman.org]
< 
http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3ccadmm+kcjgtteoth9wz-kfmkgkfgvtemt9rwkgonu0az+v2s...@mail.gmail.com%3e>
> Sent: Monday, December 05, 2011 18:38
> To: general@incubator.apache.org
> Cc: Mark Struberg; Ian Wild; Greg Stein
> Subject: Re: [PROPOSAL] Apache Bloodhound
>
> I suggest legal-discuss@ is involved to answer it. Although it is Cat
> A license, I don't think it is fully kosher, as we promise that the
> original contributor hasn't submarined any patents, but BSD doesn't
> state this. Maybe it is a tiny point, but more eyes from
> legal-discuss@ won't hurt...

It would surprise me if this question isn't already answered.  In fact, it is:
http://www.apache.org/legal/resolved.html#category-a

I humbly submit that reopening the question with legal-discuss@ would
be disrespectful of their time.


   I agree.  There is enough information to do the right thing.
   Be careful though.  Being a dependency to an Apache product
   does not alleviate requirements for IP clearance.
  Inclusion within an Apache project does not mean that the
   Apache project notice can be substituted without appropriate
   SGAs or iCLAs.  It seems to me that the IP Clearance guidelines
   are clearly applicable to the Trac/Bloodhound case.
  This policy provides useful concrete guidance:
   <http://www.apache.org/legal/src-headers.html>.



-Hyrum

[ ... ]


smime.p7s
Description: S/MIME cryptographic signature

RE: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)

[Dennis E. Hamilton]

I think a bigger issue specifically for Apache OpenOffice has to do with 
branding and status of the "released" binaries.  

It is where the Apache (plus "incubating") origin is brought to the users 
attention and what will be understood for it.  It is served up directly (from 
the user perspective) from www.openoffice.org and the rebranding of that site 
as under Apache (plus "incubating") custodianship.  There is in no sense an 
indication that this is a downstream product of the formal Apache source-code 
release.  I suspect that ordinary users would be baffled by such a distinction 
and find it difficult to see why that is significant.

To the extent I understand it, I can sympathize with what Roy Fielding says 
about provenance and reproducibility.  I just don't know how the catch-22 here 
can be dealt with.

 - Dennis 

AN ILL-CHOSEN THOUGHT-PROBLEM?

Perhaps not a good example, but one that still nags me in wondering how I would 
handle it on a non-ASF project, especially in the context of Fielding's maxim, 
is that it has finally been considered all right to bundle GPL-origin artifacts 
(spelling dictionary, its index, and any thesaurus) in AOO binary 
distributions.  There appears to me -- and I am not expert in this matter -- 
that there is no evident means to build those artifacts from what the GPL (and 
the OSD) deems the source code to be.  The original distributors have not seen 
fit to indicate where that can be found (if it was ever made available).  

Some claim these artifacts are their own sources, being essentially coded data, 
and the provision of a reliable location not in the Apache SVN for obtaining 
them may suffice here.  If so, I suspect that modifications carried out to 
correct and modernize these artifacts needs to be under a same-license project 
somewhere so that the license conditions on the derivatives are satisfied, 
including combining into OpenOffice extension artifacts and making them readily 
available.  (They are not readily extracted from the AOO bundle and the 
resulting installed software, although it is technically possible to separate 
them out if one knows where to look.)  

Such a project, if that is the appropriate resolution, needs to be meticulous 
with regard to the license and having its license-honoring artifacts reliably 
available.  It would appear that must be done elsewhere (but not on Apache 
Extras?).  I suppose it is valuable, in this context, that SourceForge has been 
helpful with related matters.

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Wednesday, March 28, 2012 08:26
To: general@incubator.apache.org
Subject: Re: Binary dependencies in source releases (Was: [VOTE] Release 
ManifoldCF 0.5-incubating, RC0)

On Tue, Mar 27, 2012 at 1:16 PM, Roy T. Fielding  wrote:

> On Mar 27, 2012, at 12:57 PM, Jukka Zitting wrote:
>
> > Hi,
> >
> > [dropped infra@, I believe most interested people are already on
> general@]
> >
> > Let's decouple this thread from the specific issue of the ManifoldCF
> > release. There's a long tradition of Apache releases like the ones
> > ManifoldCF is producing, so turning this suddenly into a blocker is
> > IMHO bad business, especially since no legal issues are involved (this
> > is about Apache policy). If we do come to the consensus that releases
> > like this are contrary to Apache policy, then affected projects should
> > be given a reasonable amount of time to adapt.
>
> I don't see where you get the idea that there is a long tradition of
> including binary artifacts within the source package releases at Apache.
> There may be specific groups who are apparently lacking the appropriate
> clue and stubbornly refuse to read the messages I have sent multiple
> times to this mailing list, legal-discuss, and members, but there is
> no question whatsoever that a source package cannot include binaries.
> It would not be a source package otherwise.
>
>
I think this may be overstating things. The issue should be lack of source
code, not presence of binary code.

For example, I could have a Java code that relies on a native method
implemented in C code.  I could have a source package that contains the
complete Java and the complete C code, all under ALv2.  But do we really
want to say that we cannot also include, in the source page, the native
code, pre-compiled as a convenience for the developer?

The alternative would be that a downstream developer who is modifying only
unrelated Java portions of the source code would be required to compile the
native code on all platforms in order to create a package.  (It would also
require the PMC to have rather elaborate build rituals to create that JAR,
since it would require that we shuffle libraries across multiple buildbots)

-Rob


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

RE: CloudStack Incubation proposal

[Dennis E. Hamilton]

Minor nit:

In economic terms, Apache OpenOffice and LibreOffice are not complementary. 

 - Dennis

In computing, an example of complements are hardware and software.  Software 
vendors want the hardware to be free (more for us!) and hardware vendors want 
the software to be free (more for us!).  Throw in telecommunication carriers, 
smartphones, and software and it gets really exciting.

There is some other term needed for independent producers that deliver 
comparables while cooperating in areas of mutual interest.  Although 
monopolistic competition arises (mines better than yours), it is moderated in 
the case of open-source efforts.  (Perhaps this is because there cannot be 
abuse of, let alone achievement of, monopoly power where feature 
differentiation is in the open-source code base.)

-Original Message-
From: Jim Jagielski [mailto:j...@apache.org] 
Sent: Tuesday, April 03, 2012 13:32
To: general@incubator.apache.org
Cc: Simon Phipps
Subject: Re: CloudStack Incubation proposal


On Apr 3, 2012, at 3:27 PM, Andreas Kuckartz wrote:

> On 03.04.2012 20:10, Jim Jagielski wrote:
> 
>> Oh come on... 1st of all, it's a joke.
> 
> One I do not find funny at all.

You should have. It was funny. Maybe you need a
funny bone transplant?

> 
>> And 2ndly, people could complain that we should
>> refuse the donation and force them to
>> put all their code/energies into OpenStack...
> 
> CloudStack and OpenStack seem to be complementary and they use the same
> license. I expect collaboration between these projects to increase not
> decrease.
> 

LO and AOOo are complementary and they are setup so that
code can move in a very Pro-LO direction. I would like
collaboration between these projects to increase not
decrease.



-
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: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of "April2012" by robweir)

[Dennis E. Hamilton]

I don't think the problem is with the size of the ooo-security list membership. 
 I think it is in the assumption that the [P]PMC has somehow delegated the 
ability to make a release of any kind to the ooo-security team.  I don't mean 
slip-streaming fixes and working off the public SVN until that happens.  I mean 
developing and deploying all the rest of what accompanies an advisory along 
with provision of a mitigation.

The breakdowns were not in analyzing the reported vulnerability and the 
proof-of-exploit that accompanied it.  I assume that ooo-security acquitted 
itself well in that regard as well as with the coordination with other parties, 
including ones external to Apache, having common concerns.  The breakdown was 
in all of the non-security considerations and assumptions, even though they 
needed to be developed in confidence.  The PPMC would have provided a proper 
arena for working that out.

The PPMC has much to offer concerning the announcement of CVEs and the 
appropriate coordination and form of patch releases/updates.  Those with 
valuable perspective on the deployment strategy and its support might have no 
sense of the technical work that ooo-security members undertake.

There was nothing about this particular vulnerability that made it dangerous 
for the PPMC to know about it and the approach being taken to release an 
ASF-appropriate patch.  The exploit is by crafting an ODF 1.2 document and all 
unpatched OO.o 3.x (and LibreOffice 3.x) installations remain vulnerable.  I 
think it is safe to presume that there are, at this moment, significantly more 
unpatched installations than patched ones and I see that as a greater concern, 
if there is any, than consultation and review by the PPMC before the public 
advisory and patch release.  A significant number of people external to the 
PPMC, including non-experts and those who may see themselves as competitors, 
knew about this prior to the announcement and there does not appear to have 
been any damage.  

 - Dennis

PS: I followed the public back-and-forth about the operation of security lists 
and venues for security coordination that Dave Fisher feels embarrassed about.  
I don't think it matters.  Whether there was a way for the Apache OpenOffice 
project to issue repairs to OpenOffice.org distributions, or not, did not seem 
to be a significant feature of the dispute as I followed it.  Indeed, knowledge 
of the possibility of an ASF patch was not a fact that could be used as a 
counter-point.  Announcement of the particular vulnerability that was going to 
be dealt with by ASF in that manner was still under embargo.  
   It remains a valid point that those who can't wait for a stable Apache 
OpenOffice release to satisfy their security concerns, especially on Linux 
where there is still no Apache patch, might want to look to other distributions 
whose current releases have that and other vulnerabilities repaired.  It all 
depends.

-Original Message-
From: ant elder [mailto:ant.el...@gmail.com] 
Sent: Thursday, April 12, 2012 02:04
To: general@incubator.apache.org
Subject: Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] 
Update of "April2012" by robweir)

On Thu, Apr 12, 2012 at 9:36 AM, Ross Gardler
 wrote:
> On 12 April 2012 09:27, Ross Gardler  wrote:
>> On 12 April 2012 08:59, ant elder  wrote:
>>> On Thu, Apr 12, 2012 at 8:37 AM, Ross Gardler
>>>  wrote:
 On 12 April 2012 07:48, Dave Fisher  wrote:
[ ... ]
> Sorry, I can't remain mute, but I offended anyone, sorry, but this was 
> wrongly done. I don't know a better way
[ ... ]
>>> Surely at the ASF the line is at PMC membership. If only a subset of
>>> the PPMC is trusted enough to be part of some inner circle then the
>>> PPMC should be disbanded and reformed from just that inner circle.
>>
>> This is a podling with a very unusual history. it is not as simple as
>> that. However, your general observation is a valid one. The time for
>> addressing this is during incubation when it becomes possible to
>> determine who is contributing positively to the running of the PPMC.
>
> I should also point out that the perception that information was kept
> to a limited group implies mistrust of PPMC members is *false*. The
> PPMC have an appointed security team just as many top level PMCs do
> that team is tasked with handling security issues and it did so in
> this case.
>
> As has been noted, this was *not* an ASF release, only one
> *facilitated* by the ASF in the interests of supporting legacy users
> of a project that has come to incubation. It is a very unusual
> situation to which normal ASF policy does not apply. Handling it
> outside normal ASF processes does not imply a problem with those
> processes or the PPMC.
>
> Ross
>

Ross, I'm not trying to stick an oar in or anything and i don't know
the details of what was done other than whats in this thread here, it
just seems odd to me and it seems like there is some acknowledgement
that 

RE: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of "April2012" by robweir)

[Dennis E. Hamilton]

@Rob,

In fact, I posted to ooo-dev and ooo-users information on the significance of 
the vulnerability and ways to mitigate it.

I was unsuccessful in posting instructions, after several failed attempts, for 
applying the patch on Windows XP where the dialogs are different and have 
different consequences than described in the Windows-patch PDF, which gives 
instructions for Windows 7.  (This has to do with an over-zealous spam filter 
on our lists and I could not get around it.)  I have however put what I could 
on the Media Wiki as the basis for a possible FAQ, using 
<http://wiki.services.openoffice.org/wiki/Talk:Documentation/FAQ/Installation/How_Can_I_Install_the_Security_Patch_(CVE-2012-0037)>.

I can't do anything about the fact that the need for a Linux patch has not been 
resolved.  I can't do anything about the fact that the patch requires the 
confidence and experience of a power user to apply on any platform.  I 
understand why that is; I can't do anything about it myself beyond attempt to 
provide supporting information and supplementary instructions.  

And I, am, of course, a volunteer here.

I also don't see what that has to do with the relationship between the PPMC and 
ooo-security.  That's about getting many eyes, not about where orcmid might 
exercise his heroic super powers.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, April 12, 2012 09:46
To: general@incubator.apache.org
Subject: Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] 
Update of "April2012" by robweir)

On Thu, Apr 12, 2012 at 12:32 PM, Dennis E. Hamilton
 wrote:
> I don't think the problem is with the size of the ooo-security list 
> membership.  I think it is in the assumption that the [P]PMC has somehow 
> delegated the ability to make a release of any kind to the ooo-security team. 
>  I don't mean slip-streaming fixes and working off the public SVN until that 
> happens.  I mean developing and deploying all the rest of what accompanies an 
> advisory along with provision of a mitigation.
>
> The breakdowns were not in analyzing the reported vulnerability and the 
> proof-of-exploit that accompanied it.  I assume that ooo-security acquitted 
> itself well in that regard as well as with the coordination with other 
> parties, including ones external to Apache, having common concerns.  The 
> breakdown was in all of the non-security considerations and assumptions, even 
> though they needed to be developed in confidence.  The PPMC would have 
> provided a proper arena for working that out.
>
> The PPMC has much to offer concerning the announcement of CVEs and the 
> appropriate coordination and form of patch releases/updates.  Those with 
> valuable perspective on the deployment strategy and its support might have no 
> sense of the technical work that ooo-security members undertake.
>

Dennis, if the PPMC wishes to make any changes to the patch, or the
documentation, or the announcement, or the website related this patch,
they have had that ability for nearly a month now.  But no one,
including yourself, has offered one change.  A lot of criticism,
certainly, but no patches. The actions (or inaction) of the PPMC since
this patch was announced proves the point.  It was good enough, and no
one -- including you -- has ventured to raise a finger to improve any
of the patch materials.

-Rob

-
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: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of "April2012" by robweir)

[Dennis E. Hamilton]

Oh, and I communicated to another podling (via their podling-private@ ) whose 
PPMC I am not on that they might want to pay attention to this vulnerability as 
well, and that was apparently valuable input. 

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Thursday, April 12, 2012 11:55
To: 'general@incubator.apache.org'
Subject: RE: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] 
Update of "April2012" by robweir)

@Rob,

In fact, I posted to ooo-dev and ooo-users information on the significance of 
the vulnerability and ways to mitigate it.

I was unsuccessful in posting instructions, after several failed attempts, for 
applying the patch on Windows XP where the dialogs are different and have 
different consequences than described in the Windows-patch PDF, which gives 
instructions for Windows 7.  (This has to do with an over-zealous spam filter 
on our lists and I could not get around it.)  I have however put what I could 
on the Media Wiki as the basis for a possible FAQ, using 
<http://wiki.services.openoffice.org/wiki/Talk:Documentation/FAQ/Installation/How_Can_I_Install_the_Security_Patch_(CVE-2012-0037)>.

I can't do anything about the fact that the need for a Linux patch has not been 
resolved.  I can't do anything about the fact that the patch requires the 
confidence and experience of a power user to apply on any platform.  I 
understand why that is; I can't do anything about it myself beyond attempt to 
provide supporting information and supplementary instructions.  

And I, am, of course, a volunteer here.

I also don't see what that has to do with the relationship between the PPMC and 
ooo-security.  That's about getting many eyes, not about where orcmid might 
exercise his heroic super powers.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, April 12, 2012 09:46
To: general@incubator.apache.org
Subject: Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] 
Update of "April2012" by robweir)

On Thu, Apr 12, 2012 at 12:32 PM, Dennis E. Hamilton
 wrote:
> I don't think the problem is with the size of the ooo-security list 
> membership.  I think it is in the assumption that the [P]PMC has somehow 
> delegated the ability to make a release of any kind to the ooo-security team. 
>  I don't mean slip-streaming fixes and working off the public SVN until that 
> happens.  I mean developing and deploying all the rest of what accompanies an 
> advisory along with provision of a mitigation.
>
> The breakdowns were not in analyzing the reported vulnerability and the 
> proof-of-exploit that accompanied it.  I assume that ooo-security acquitted 
> itself well in that regard as well as with the coordination with other 
> parties, including ones external to Apache, having common concerns.  The 
> breakdown was in all of the non-security considerations and assumptions, even 
> though they needed to be developed in confidence.  The PPMC would have 
> provided a proper arena for working that out.
>
> The PPMC has much to offer concerning the announcement of CVEs and the 
> appropriate coordination and form of patch releases/updates.  Those with 
> valuable perspective on the deployment strategy and its support might have no 
> sense of the technical work that ooo-security members undertake.
>

Dennis, if the PPMC wishes to make any changes to the patch, or the
documentation, or the announcement, or the website related this patch,
they have had that ability for nearly a month now.  But no one,
including yourself, has offered one change.  A lot of criticism,
certainly, but no patches. The actions (or inaction) of the PPMC since
this patch was announced proves the point.  It was good enough, and no
one -- including you -- has ventured to raise a finger to improve any
of the patch materials.

-Rob

-
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: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] Update of "April2012" by robweir)

[Dennis E. Hamilton]

Yes, this was already raised on the PPMC (on March 22) as you know.  It seems 
to me that the PPMC is not concerned.

It is interesting that it is thought, here, that the remedy is to add more 
ooo-security subscribers from the PPMC.  That had not come up before.

 - Dennis

-Original Message-
From: Ross Gardler [mailto:rgard...@opendirective.com] 
Sent: Thursday, April 12, 2012 12:41
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: Extraordinary OpenOffice security patch (Was: [Incubator Wiki] 
Update of "April2012" by robweir)

On 12 April 2012 17:32, Dennis E. Hamilton  wrote:
> I don't think the problem is with the size of the ooo-security list 
> membership.  I think it is in the assumption that the [P]PMC has somehow 
> delegated the ability to make a release of any kind to the ooo-security team. 
>  I don't mean slip-streaming fixes and working off the public SVN until that 
> happens.  I mean developing and deploying all the rest of what accompanies an 
> advisory along with provision of a mitigation.
>

Whether this is the case or not should be discussed on the ooo-dev
lists rather than the IPMC general list. This is not an IPMC issue.
All IPMC members are free to join that list or read its archives if
they so desire.

Ross

-
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: [VOTE] Release Apache OpenOffice 3.4 (incubating) RC1

[Dennis E. Hamilton]

@Norbert,

I don't see any mention of patent issues in that message.  Since 
Symphony-related contributions have not occurred yet, they certainly are 
irrelevant to the release of Apache OpenOffice (incubating) 3.4.0.  It is a 
good thing that IBM will ensure there is no encumbrance in anything that they 
contribute under an IBM SGA.

In any case, unlike the situation with the simple declarations used by many 
copyleft projects, iCLAs and SGAs provide clear declarations concerning patents 
as does the ALv2 itself.

If you know of a specific IP difficulty, I am sure that the AOO PPMC and the 
IPMC would appreciate having sufficient details to be able to confirm the 
consequences.

What do you have in mind?

 - Dennis

-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com] 
Sent: Tuesday, May 01, 2012 21:34
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache OpenOffice 3.4 (incubating) RC1

I trust that the Patent issues raised by Rob Weir on this mailing-list in

http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3cof1a1f1f97.0ba57c1e-on852578a4.004ec606-852578a4.004fc...@lotus.com%3E

have been disclosed and addressed to the satisfaction of the IPMC ?

Norbert

-
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: [VOTE] Release Apache OpenOffice 3.4 (incubating) RC1

[Dennis E. Hamilton]

I have no reason to believe that the remediation Rob speaks of has anything to 
do with any part of OpenOffice.org.  I would presume it matters with regard to 
the IP of IBM or others licensed by IBM that may apply to Symphony content 
beyond whatever OpenOffice.org code they started with.  

With regard to OASIS Standard ODF, of course, there is already the IP regime 
that applies to IBM as a contributor, just as for Sun Microsystems and Oracle.  
There is also the Oracle SGA.

So, do you have knowledge of a specific IP conflict that Apache OpenOffice.org 
is subject to that is somehow not applicable to LibreOffice and its inheritance 
from OpenOffice.org ?

 - Dennis

-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com] 
Sent: Tuesday, May 01, 2012 22:31
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: [VOTE] Release Apache OpenOffice 3.4 (incubating) RC1

On Wed, May 2, 2012 at 12:17 AM, Dennis E. Hamilton
 wrote:
> @Norbert,
>
> I don't see any mention of patent issues in that message.

it says:
"But one thing not to lose track of is that Symphony has done IP
remediation at many levels.  Where we've worked around things, we'll be
able to contribute our fixes back. [..](I'm talking patents)

Symphony is based on OOo so 'remediation' would have to be
'remediation' to the OOo code base, which is the code base of AOO. So
presumably the Allege Patent issues where in OOo and possibly are
still in AOO... furthermore they could not have been Sun/Oracle
Patent, otherwise they would have been covered by LGPLv3, so the
Oracle SGA does not help there...


>
> If you know of a specific IP difficulty, I am sure that the AOO PPMC and the 
> IPMC would appreciate having sufficient details to be able to confirm the 
> consequences.

I am not the one that claimed that there was such IP difficulty, I'm
just reminding everyone that Rob claimed at the beginning of the
project that such difficulties and I quote: " I know with certainty
that we've fixed things."

At the time these issue have been pushed aside as irrelevant to the
admission of the project in the incubator, and that such concerned
would be addressed in due time prior to Release...

>
> What do you have in mind?

Since I have not seen any discussion or patch related to that topic, I
must have missed them. Hence my inquiry.

Norbert

-
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: [VOTE] Release Apache OpenOffice 3.4 (incubating) RC1

[Dennis E. Hamilton]

@Norbert,

It seems more direct to ask Rob what he was thinking of when he made that post 
last June.

I can imagine two kinds of remediation that might have happened or be needed 
with respect to Symphony:

 1. Perhaps IBM detected IP issues in the OO.o code base they received under 
license from Sun and they cleaned out those IP problems in their customization. 
 That means there is potentially an IP problem that remains in the AOO and the 
LO code bases.  It is not clear that it has anything to do with IP that IBM 
possesses, although it could have.  They would have had no reason to work 
around their own IP for their own use in Symphony though.

 2. Perhaps IBM relied on IP that they had owned or licensed in the 
customization they did.  Before committing Symphony improvements to AOO, they 
need to "remediate" those to have it be clean.  

Note that there is no issue with regard to IBM IP in a contribution from IBM, 
since contribution to ODF under the OASIS IP regime for ODF and to Apache under 
the rules of iCLAs and SGAs grants a license to those patents.  Of course, IBM 
could remove those dependencies on essential claims anyhow and avoid licensing.

I don't see how any of this impacts the just-concluded vote to approve release 
of Apache OpenOffice (incubating) 3.4.  

If you are worrying about being submarined, I think a bigger concern is that 
there may be unexploded landmines in the existing LO and original OO.o 
codebases. It still has nothing to do with what IP clearance means here.  
However, if IBM (and Rob) know of an IP issue in the code base that won't be 
detected in how IP clearance was accomplished, there is an obligation to report 
it.  The fact that there has been no such revelation has to be sufficient at 
this point.  

If you want to see proof of negatives, I suggest that you conduct that plowing 
in your own fields. Or try groklaw, perhaps, where there is a willing chorus of 
believers and supportable facts are not required.

 - Dennis

-Original Message-
From: Norbert Thiebaud [mailto:nthieb...@gmail.com] 
Sent: Tuesday, May 01, 2012 23:21
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: [VOTE] Release Apache OpenOffice 3.4 (incubating) RC1

On Wed, May 2, 2012 at 12:57 AM, Dennis E. Hamilton
 wrote:
> I have no reason to believe that the remediation Rob speaks of has anything 
> to do with any part of OpenOffice.org.

You mean except for Rob's own statement ?

"But one thing not to lose track of is that Symphony has done IP
remediation at many levels.  Where we've worked around things, we'll be
able to contribute our **fixes** **back**." (emphasis mine)

How can you logically conclude that Rob is not talking about
remediation in the OOo code-base ?
So unless such remediation was indeed done also in the to-be-released
AOO code, then the PPMC would be knowingly releasing patent traps.
Either that or Rob's above statement was pure FUD.

Norbert

-
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: [MENTORS] Third Party source

[Dennis E. Hamilton]

Along with the policy and trustworthiness matters that Sam provides, I can 
speculate some other reasons for concern about removing/replacing notices (of 
any kind) --

 * Removal of a copyright notice can be taken as evidence of intentional 
infringement if not negligent infringement.

 * Removal of notices is often an indication that someone things relicensing is 
possible and valid when that is almost never the case except when done by the 
copyright holder(s).

 * Preserving the provenance of combined/derivative works is extremely 
important, not merely because of the way the ASF chooses to operate in the 
public interest.  It can be critical in demonstration that the ASF has been 
diligent in avoiding infringement and making reasonable but responsible 
reliance on the care and diligence of its contributors.

 - Dennis

-Original Message-
From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby
Sent: Friday, June 08, 2012 09:07
To: general@incubator.apache.org
Cc: flex-...@incubator.apache.org
Subject: Re: [MENTORS] Third Party source

On Fri, Jun 8, 2012 at 9:28 AM, Kalle Korhonen
 wrote:
> On Thu, Jun 7, 2012 at 11:06 PM, Roy T. Fielding  wrote:
>> I fear we are miscommunicating again.
>> Only the copyright owner is allowed to (re)move copyright notices
>> or permit others to (re)move them on the owner's behalf.
>
> Interesting, why is that? Is it so by the law?

It would be helpful if somebody could point out the actual words in
the copyright headers being discussed.  I may have missed it.

The copyright holder may impose limits on copying.  I have seen
headers that say, in effect, that you are welcome to copy the source
as long as you retain this header intact.

Meanwhile, much of the goodwill the ASF has accumulated over the years
is due to our policy of only accepting voluntary contributions.  We
should not throw that away lightly.

In this case, Adobe isn't hard to reach here.  We should seek their
opinion, and respect it.

If Adobe wishes us to retain the headers, my opinion is that we should
evaluate the impact that such a request will have on the community,
and either follow their request or decline the contribution.

If Adobe collectively takes the time to understand our position and
agrees to moving it, there are a number of ways that this can be
expressed clearly.  I still maintain that having an Adobe employee do
such a move would be the simplest and clearest way, but other ways are
possible too.

> Kalle

- Sam Ruby

-
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: References to "Apache OpenOffice"

[Dennis E. Hamilton]

If you identified the public places and were more specific about it, it would 
help us to clean it up as appropriate.

 - Dennis

-Original Message-
From: Nick Kew [mailto:n...@apache.org] 
Sent: Friday, June 22, 2012 22:03
To: general@incubator.apache.org
Subject: References to "Apache OpenOffice"

I've seen a couple of recent references to "Apache OpenOffice" appearing
in public places.  Places for which Apache committers are responsible.

Have I missed a graduation, or a change in practice concerning use of
the Apache trademark in the context of incubating projects?

-- 
Nick Kew

-
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: References to "Apache OpenOffice"

[Dennis E. Hamilton]

Nick, the AOOi project does not write those tweets from @TheASF and they are 
not under AOOi control.  

Are these and blog text occurrences the ones that attracted your attention or 
are there others?

If you follow the links to the referenced blog posts you will see that the full 
term is used in the blog title.   E.g., 
<https://blogs.apache.org/OOo/entry/5_million_downloads_of_apache>.

Would it have been sufficient to add it in the title of the individual post, 
and in the first mention in the opening paragraph?

How many times do you require that the qualifier be used to satisfy the 
requirement for identifying incubation as the origin of a release, an 
announcement, etc?

 - Dennis



-Original Message-
From: Nick Kew [mailto:n...@apache.org] 
Sent: Saturday, June 23, 2012 00:24
To: general@incubator.apache.org
Subject: Re: References to "Apache OpenOffice"


On 23 Jun 2012, at 06:47, Dennis E. Hamilton wrote:

> If you identified the public places and were more specific about it, it would 
> help us to clean it up as appropriate.

In fact the word pair "Apache OpenOffice" appears no fewer than three times
on the front page www.apache.org at this moment.  None of those three are
qualified with any hint at its incubating status.

-- 
Nick Kew
-
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: References to "Apache OpenOffice"

[Dennis E. Hamilton]

@Nick,

Ross offered to come to the AOOi PPMC to fix it.  I'm not clear what the PPMC 
has to do with it.

Specifically, @TheASF is not of AOOi PPMC origin.  The question is, who is 
expected to do something about that and how is it to be communicated to them?  
Someone else is responsible for those tweets and their aggregation on the ASF 
home page.

Also, you refer to a blog post by Rob Weir on his own site.  It is true that 
Rob Weir is a member of the AOOi PPMC, but that blog site is not a product of 
the AOOi PPMC and its aggregation into Roller is no different than the 
aggregation of any Apache committer posts that a committer arranges to include 
in the feed picked-up by Roller.  (I believe the PPMC did authorize that "Get 
it Here" image and link to be used by sites that wanted to promote the 
availability of the software.  If there should have been greater formality 
before doing that, there are places to raise that specific problem.)

My concern is how to determine what the infractions are that someone can do 
something about and also being clear who that someone is expected to be.  The 
general claim just has us running around like headless chickens over on ooo-dev.

 - Dennis

PS: I'm now in time-penalty and will check back anon.

-Original Message-
From: Nick Kew [mailto:n...@apache.org] 
Sent: Saturday, June 23, 2012 11:38
To: general@incubator.apache.org
Subject: Re: References to "Apache OpenOffice"


On 23 Jun 2012, at 18:48, Dennis E. Hamilton wrote:

> Nick, the AOOi project does not write those tweets from @TheASF and they are 
> not under AOOi control.  
> 
> Are these and blog text occurrences the ones that attracted your attention or 
> are there others?
> 
> If you follow the links to the referenced blog posts you will see that the 
> full term is used in the blog title.   E.g., 
> <https://blogs.apache.org/OOo/entry/5_million_downloads_of_apache>.

So what appears on www.apache.org doesn't matter?

Nor what appears on planet.apache.org, featuring the article that first struck 
me
as using the name in a way I wouldn't expect when I read it in my feed reader:
http://www.robweir.com/blog/2012/06/pache-openoffice-34-downloads.html

> Would it have been sufficient to add it in the title of the individual post, 
> and in the first mention in the opening paragraph?

I should think so, but that's just me!

> How many times do you require that the qualifier be used to satisfy the 
> requirement for identifying incubation as the origin of a release, an 
> announcement, etc?

If the guidelines are unclear then maybe they need reviewing?
I was just pointing out usage that seems at odds with my understanding
of the incubator rules.

If a blog gets aggregated, then readers will see what appears in their
aggregator, as I did.  That's without the context of the page title in your 
link!

-- 
Nick Kew
-
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: [VOTE] Apache OpenOffice Community Graduation Vote

[Dennis E. Hamilton]

I do not dispute the existence of other reliable creators of binary 
distributions.  The *nix packagings and installation in consumer desktops are 
notable for the value that they provide.  

I think that experience teaches us that there absolutely needs to be a way to 
obtain and install *authentic* binary distributions made using the release 
sources with a proper set of options for a given platform.

It is near impossible to provide end-user support and bug confirmation without 
agreement on the authentic bindist that is being use and that it is a bindist 
made from known sources.

And there are enough fraudulent distributions out there that this is critical 
as a way to safeguard users.

For that reason alone, there needs to be an authenticated bindist, especially 
for Windows, the 80% that garners the focused attention of miscreants and 
opportunists.  

That is also the reason for wanting signed binaries that pass verification on 
Windows and OS X.  There needs to be a way for everyday users to receive every 
assurance that they are installing an authentic bindist and that it is 
verifiable who the origin is.  I suspect that reliable packagers of unique 
distributions (including any from IBM) will provide their own verifiable 
authenticity.

 - Dennis

-Original Message-
From: drew [mailto:d...@baseanswers.com] 
Sent: Monday, August 20, 2012 18:00
To: general@incubator.apache.org
Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote

On Mon, 2012-08-20 at 17:01 -0700, Marvin Humphrey wrote:
> On Mon, Aug 20, 2012 at 3:03 PM, drew  wrote:
> > Well, for myself, I don't have a problem with the AOO project not having
> > official binary releases - in such a circumstance I would strongly
> > prefer no binary release at all.
> 
> I wonder who might step into the breach to provide binaries for such a
> package...

Hi,

Well, for a start:

IBM stated it will release a free binary version at some point, after
shutting down the Symphony product.

CS2C, a Chinese firm working in cooperation with Ernest and Young IIRC,
releases a binary based on the source code - in fact I'm not even sure
AOO supplied binaries are available to most folks in China.

Multiracio releases a closed source version of the application for sale
in Europe and the US.

In the past quite a few Linux distributors included binary releases in
their offerings, they consume source not binaries.

The current BSD, OS/2 and Solaris ports will go out as source only from
AOO, but come to end users from a third party repository, unless I
totally missed what was happening there (and I might off ;)

There are currently two groups which offer binary versions packaged to
run off USB drives, as far as I understand it, they work from source and
don't require binaries.

Finally this is a well known brand now, it would be hard to believe that
if AOO did not release binaries the void would not be filled by others.

//drew

ps - sorry if this double posts... 

> 
> > On the other hand if there is a binary release from the AOO project then
> > I believe it should be treated as a fully endorsed action.
> 
> At the ASF, the source release is canonical.  I have never seen anyone assert
> that the source release is not offical and endorsed by the ASF.
> 
> There has been disagreement about whether binaries should be official or not.
> To the best of my knowledge, every time the matter has come up, the debate has
> been resolved with a compromise: that while binary releases are not endorsed
> by the ASF, they may be provided in addition to the source release for the
> "convenience" of users.
> 
> What is different with AOO is that the compromise does not seem to satisfy
> an element within the PPMC and thus the matter is being forced.
> 
> It would be a lot of hard, time-consuming work for the ASF to build the
> institutions necessary to provide binary releases that approach the standards
> our source releases set.  (As illustrated by e.g. the challenges of setting up
> the code signing service.)  Not all of us are convinced that it is for the
> best, either.
> 
> 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


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

RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Dennis E. Hamilton]

+1 on how to start, with the maturity model as exemplar, is an outstanding 
idea.  Thanks. 

(I even have a poddling in mind for stress-testing it.)

 - Dennis

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Tuesday, August 4, 2015 05:57
To: Incubator General 
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

Hi Daniel,

On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno  wrote:
> On 2015-08-04 13:01, Bertrand Delacretaz wrote:
>>... IMO the Incubator PMC can very much own this checklist, and I
>> volunteer to contribute to creating it...

> If interested, I would very much like to work with you on perhaps turning
> this into a sort of 'online compliance check' where podlings could upload a
> tarball or some such, and the service would scan it for compliance, go
> through the checklist, and report back which elements are compliant and
> which are not...

Wow, that's more ambitious than what I envisioned but I know your are
able to do that  ;-)

Creating a release checklist in a structured text format sounds like a
good start anyway, so we can start with that and if you and others
want to turn it into an online analysis service that would be
fantastic.

-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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Dennis E. Hamilton]

Sorry, my comment was too brief.  

I understand the maturity model to be something to aspire to and that Apache 
Projects will always be working toward it.  I mean TLPs, not podlings, although 
podlings should be aware of it and also aspire to it.  

I was commending the structure and clarity of the maturity model as a basis, 
not about it being somehow held to podlings as a graduation yardstick or 
anything else.

I was responding in the context of Bertrand's comment,

   Creating a release checklist in a structured text format
   sounds like a good start anyway, so we can start with that
   ... .

that used the maturity model format as a suggested form.

 - D



-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Tuesday, August 4, 2015 10:37
To: general@incubator.apache.org; orc...@apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

On 4 August 2015 at 18:46, Dennis E. Hamilton  wrote:

> +1 on how to start, with the maturity model as exemplar, is an outstanding
> idea.  Thanks.
>
> (I even have a poddling in mind for stress-testing it.)
>
It is clear to me, that incubator offer many advantages...but our current
overweight to control everything is seen (and are) a negative effect,
anything
that can reduce that is good.

I think the maturity model is good, but to used with care. If I think of
the same podling as Dennis, that would clearly be a test done too early.

rgds
jan i.


>
>  - Dennis
>
> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Tuesday, August 4, 2015 05:57
> To: Incubator General 
> Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
> the Apache Incubator)
>
> Hi Daniel,
>
> On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno  wrote:
> > On 2015-08-04 13:01, Bertrand Delacretaz wrote:
> >>... IMO the Incubator PMC can very much own this checklist, and I
> >> volunteer to contribute to creating it...
>
> > If interested, I would very much like to work with you on perhaps turning
> > this into a sort of 'online compliance check' where podlings could
> upload a
> > tarball or some such, and the service would scan it for compliance, go
> > through the checklist, and report back which elements are compliant and
> > which are not...
>
> Wow, that's more ambitious than what I envisioned but I know your are
> able to do that  ;-)
>
> Creating a release checklist in a structured text format sounds like a
> good start anyway, so we can start with that and if you and others
> want to turn it into an online analysis service that would be
> fantastic.
>
> -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
>
>


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

RE: Podlings and the ASF maturity model (was: Reform of Incubator...)

[Dennis E. Hamilton]

OK, thanks Bertrand.  My recollection of the maturity-model discussion was that 
it is about an ideal state and not some gate, and that projects would always be 
correcting their state toward that defined in the model.  I confirm that the 
current document simply characterizes what the state is for a mature project.

I see no statement anywhere that a TLP, or a graduating incubator project, must 
pass through a maturity assessment.  It would certainly be useful for a podling 
to conduct a self-assessment of its maturity before requesting graduation.  

It would also be useful for an operating TLP to assess itself with respect to 
the model, especially if there are concerns in that regard.

I am neutral on how this fits into graduation criteria for podlings.  However, 
if it is used for gating purposes, I think that needs to be made very clear by 
the IPMC lest it just lead to more randomizing of the podling seasoning 
process.  In particular, mentors need to be on board with respect to their 
responsibilities.  I can also imagine a graduation going forward (just as 
releases can) with certain items remaining to be addressed post-graduation.  I 
note that, at the moment, there is no direct reference to the Project Maturity 
Model at the <https://www.apache.org/dev/project-requirements> draft nor at the 
Incubation Policy, 
<https://incubator.apache.org/incubation/Incubation_Policy.html>.

I can also imagine a TLP using (or being asked to use) the project maturity 
model as a checklist in assessing their current state in a report to the Board. 
 

Are these the kinds of applications that folks have in mind?

 -- Dennis

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Wednesday, August 5, 2015 00:44
To: Incubator General ; dennis.hamil...@acm.org
Subject: Podlings and the ASF maturity model (was: Reform of Incubator...)

Hi,

On Wed, Aug 5, 2015 at 12:24 AM, Dennis E. Hamilton
 wrote:
> ...I understand the maturity model to be something to aspire to and that 
> Apache Projects
> will always be working toward it.  I mean TLPs, not podlings, although 
> podlings should be
> aware of it and also aspire to it...

I don't see why podlings should be different here, once they are about
to graduate.

Why can't we define our incubation process as a way for podlings to
learn to operate according to that maturity model [1]?

This would allow us to use the maturity model [1] as a checklist for
graduating podlings - do you see anything in there that shouldn't be
required from a podling that's about to graduate?

-Bertrand

[1] http://community.apache.org/apache-way/apache-project-maturity-model.html

-
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: third party tooling.

[Dennis E. Hamilton]

I don't have an answer about tooling with respect to the need for 
widely-available tools.  If the concern is for ability to use free tools on 
Windows, but there are alternatives to requiring an expensive commercial IDE 
for users while still taking advantage of the Microsoft development tool chain.

The Visual Studio Community Edition 2013 is free to use for open-source 
projects.  I would recommend it simply because it is available for development 
on and for Windows and should work for Corinthia (although I haven't tried your 
builds there).  This works if you are creating/publishing Visual Studio 
projects.

It might also be desirable to use Visual Studio Community Edition 2015, which 
is now released and available. 

-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Wednesday, August 5, 2015 12:04
To: general@incubator.apache.org
Subject: third party tooling.

Hi.

We have recently (again) on different list discussed third party libraries.
Some strong
opinions have been aired.

So we have rules/policies for libraries but how about tooling, I have not
been able to
find any "do not do this" page.

I am about to prepare a release for Corinthia, which is a C99 project. I
would like to
write in the release note, that on ms-Windows we test with Visual Studio
2013, simply
because that is a fact.

But Visual Studio 2013 is not a free version so which rules/policies will I
break by not
testing with e.g. GCC on windows ?
(I hope none, but better ask than have to cut a new release candidate).

rgds
jan i.


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

RE: Podlings and the ASF maturity model (was: Reform of Incubator...)

[Dennis E. Hamilton]

+1 

with the understanding that there is the usual flexibility between policies and 
practices, consistent with the spirit and principles of the ASF for Apache 
Projects.  

And, to be fair, I think TLPs should also self-assess on a periodic basis as an 
accountability of the PMC, nudged as necessary by the Chair (not to do it as 
much as to direct the PMCs eyes to the ball).

I can also imagine the maturity model items being used on an exception basis, 
only reporting maturity-model deviations and how they are being addressed as 
part of a report to the Board.

 - Dennis

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Thursday, August 6, 2015 00:28
To: Incubator General 
Subject: Re: Podlings and the ASF maturity model (was: Reform of Incubator...)

On Thu, Aug 6, 2015 at 8:46 AM, Niclas Hedhman  wrote:
> ...the maturity model shouldn't be a set of gating criteria, but that the
> podling should self-assess its position and to what degree, as well as how,
> each point is handled. Yes, many of the points are non-negotiable, but
> don't claim that all are...

So you would see the maturity model as one element of the Incubation
graduating checklist, with self-assessment from the podling and its
mentors? I like the idea.

-Bertrand

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


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

RE: third party tooling.

[Dennis E. Hamilton]

I want to come back to the question about the dependency of a source release on 
third-party tooling to be built.

There is some sort of principle involved when it comes to how others can build 
the source easily, even if only to confirm that it builds and operates.  

I would not want to see an Apache release that provides building on a 
significant explicitly-targeted platform exclusively via expensive commercial 
tools as the only means for directly confirming builds by an user of the 
release, a volunteer tester, some-one verifying the build, etc. 

I don't believe that is necessary for any project that I am aware of.  In the 
odd case of Visual Studio, mentioned in the original question, I think the 
danger is that the developers will use a Professional or more-expensive version 
and not confirm that a free version is readily available and can be sufficient 
to accomplish all of the builds by limiting their development to use of the 
free version or at least confirming that the free version will build it.  

I would think that this is in the spirit of maturity-model clause CD30's 
"widely available standard tools." I would question any unnecessary dependence 
on tools that are a barrier to use by casual users and volunteer developers.

 - Dennis

MUSINGS

I see no reason that a podling with a small, new initial code base could rely 
on freely available tools, providing portable source code that can be easily 
built on and for different platforms by including platform-abstraction layers 
that suit that project's purposes and that otherwise satisfy requirements for 
Apache releases.

TLPs, such as Apache OpenOffice, where Microsoft Windows is a crucial target 
platform, have greater difficulty when the project-specified versions of the 
Visual C++ compiler and essential platform libraries (including redistributable 
run-time) predate the current comprehensive, freely-available versions.  This 
is a different challenge with historical origins in a legacy code base.


-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Thursday, August 6, 2015 02:13
To: general@incubator.apache.org; ro...@shaposhnik.org
Subject: Re: third party tooling.

On Thu, Aug 6, 2015 at 2:25 AM, Bertrand Delacretaz 
wrote:

> On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik 
> wrote:
> > ...you can call yourself open source software all you want,
> > but unless you get an exception from Fedora Packaging Committee
> > you are not open enough for the distribution to consider your work...
>
> But that's doesn't make your project invalid or useless.
>

Right.

I don't know where you're coming from Roman, but the Foundation doesn't
require our projects to be built via "bootsrappable [sic] from source using
*only* open source software binaries as the input". Never has, never will.
So to Jan's original question: totally fine, no issues with compiler
dependencies for certain platforms.

Our software is defined by ALv2 and the "Category" licenses for
dependencies.

[ ... ]


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