Re: Getting through the hoops

[Dirk-Willem van Gulik]

On 16 Oct 2018, at 13:26, Daniel Gruno  wrote:
> 
> So, I took a stab at this, Work-In-Progress and what not:
> 
> https://icla.live/

Rather neat.  I’d practice data-minimalisation right out of the gate though - 
as to not burden the ASF with data that becomes a liability.

E.g. drop the phone number.

Secondly - the first question -I’d be a lot clearer about the option to `hide’ 
this by providing a public name.

Perhaps pre-fill the public name with the full one - or ask the public name 
-first- and rephrase it - under what name  are you publicly known in the ASF 
community.

For some countries - I’d keep the option open to simply print it and sign & 
scan and email.

Dw.




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

Re: License question

[Dirk-Willem van Gulik]

On 21 Feb 2016, at 14:25, Dor Ben Dov  wrote:

> Let's say I (company) go the ASF way.
> 
> To incubator and later on into TLP.
> 
> Does it mean that the license would be in the end only Apache License 2 ? or 
> can it still remain for example, lgpl ?

Any and all code the ASF releases/distributes is under the Apache license. 

Likewise; any further contributions to that code that Apache receives and, 
which under the auspices of the PMC, are incorporated into the codebase, are 
released under the ASF license.

It is (initially) possible for the (original) author of the code to also 
distribute the (originally donated) code under an different license. 

So then there are two strands. One maintained at the ASF and one maintained by 
the original author. 

Over time the two versions are likely to start to differ. And the 
fixes/improvements made to the ASF strand are only available under the ASF 
license.

It is possible for that author to incorporate these apache changes to his 
version of the code base. These will then be under the apache license. So at 
that point the original author his derived work will be under the apache 
license for the apache part of the code; and under some other license of his or 
her choosing for the rest.

It is also possible for a totally different third party to combine the apache 
code base with his or her ‘own’ fixes or special changes - and release that as 
a derived work; keeping their ‘own’ fixes under a different, potentially more 
restricted, license.

This is fairly common - for example the IBM WebSphere and Oracle product suites 
contain apache code (under an ASF license) augmented by a lot of proprietary 
code from these companies,

> By means, when It is Apache License 2, can one company take this open source 
> and offer support for it for money ? or adopt it and sell it ?

The Apache license allows for a wide range of business models. A company can 
offer support on it; can make a commercial version; can add its own 
(commercial) modules, make a special binary only version for an arcane 
platform, etc, etc. It can make that special version open source or it can 
hoard it.

However the (original) apache source code continues to be available under the 
Apache License - as is any further contribution given to the ASF.

Or in other words - you can pretty much do with it what you want - but the 
apache version is always available under an apache license.

Dw.



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

Re: CCLA's and SGA's

[Dirk-Willem van Gulik]

 On 09 Feb 2015, at 15:08, Jim Jagielski j...@jagunet.com wrote:
 
 These are all different vehicles for different things.
 
 The SGA is basically a formal code-donation to the ASF. It
 provides deep IP provenance.
 
 A CCLA is a document that sez that a company is aware that its
 employee(s) is/are working on Apache projects and that they
 (the company) is OK with that. Usually this is in direct response
 to those employee agreements that claim that any IP created
 by an employee (at any time) is the property of the employer.
 A CCLA is not usually required, but if it is, it's up to the
 employer to determine when/if it is.
 
 An iCLA is required once someone gets commit privs and provides
 a belts-and-braces provenance history, ensuring that all code
 that comes into Apache has history and can be included.

I would refine this into

A CCLA is not required unless either 1) the company prefers to have 
such in place on its own accord or 2) an individual with an  iCLA has 
determined (e.g. in consultation with his employer or customers) that in his or 
her specific situation a CCLA is needed in addition to his own iCLA.

So start with gating the code we (ultimately) distribute and have to have good 
governance over to have the release ‘stick’ to the license by gating what goes 
into SVN.

-   That we do with the Software Grant

-   Or with the iCLA of the individual committing.

and provide companies and individuals the ability to clarify their (relative or 
absolute) position with a CCLA if they feel so inclined.

Dw

 
 NOTE: Apache only accepts voluntary code donations; no matter
 what the license, if the copyright holder does not want the
 code to be included in Apache projects, Apache will honor that
 request. So the above agreements also align with that policy.
 
 
 -
 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

[Dirk-Willem van Gulik]

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

Dw*.

*: who is in a - what the hack mood - and thinks that  get this code base in a 
state where people can start hacking is better than let it bitrot any further. 
And fully trust the incubator process to attic the code  jettison the 
community if it is non functional. In which case we have at least one copy of 
this code base under a very liberal license for other communities to use as a 
starting point.



smime.p7s
Description: S/MIME cryptographic signature

Re: OpenOffice LibreOffice

[Dirk-Willem van Gulik]

On 5 Jun 2011, at 23:45, Keith Curtis wrote:

 On Sun, Jun 5, 2011 at 3:24 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 
 We only benefit if the code is contributed to us, as we only accept
 ..
 As the trees diverge, it will get harder to give code to you both.
 What if some changes depend on other GPL code? Your insistence on
...
 LibreOffice will for a long time be using a substantial amount of
 your software. 

Great! Don't worry about that. We celebrate that. 

The folks here at apache tend to like  to code - and if others use it - build 
amazing things with it -  so much the better. 

We're happy to see our children travel the world - and do not insist that they 
call home every night.

Seriously. 

Dw.

smime.p7s
Description: S/MIME cryptographic signature

Hardware, build farms and the like

[Dirk-Willem van Gulik]

So code is one thing. Open office does also come with quite a need for build 
farms, automated test and so on.

It would be good to understand this early - and understand wether this matters. 
I.e. Can normal development continue with the basics (svn, bug tracking, 
mailing lists, archives and a delivery CDN of released products) - or is it 
paramount that there is more on day one ?

And secondly - is it crucial that such happens very near to the code ? Or can 
it happen at a distance ? E.g. at companies or at specific community focal 
points ? 

Apache is all over the board - some projects just test, tag and release source 
tarballs, others rely on volunteers (usually a mix of companies and 
individuals) to contribute compiled binaries while others actually use ASF 
hardware to build these*. While others almost completely rely on others to take 
their raw products and integrate it into products.

Or is there currently in the OpenOffice world a distinct lack/loss of 
capability associated with this transition - and it would be important to 
ensure that that capability is part of the incubator proposal ? Do we know how 
much hardware that is ?

And secondly - does this cover it - or are their subtle other bits of 
infrastructure (end user help/document servers, core/crash-dump receivers, 
special DNS setups, template servers or what not) which are needed too ? Is 
that documented sufficiently ?

Dw.

*: And yes - we're fine with that - in apache we're process oriented - and if 
the PMC has clear oversight of a well managed process to get zips and exe's 
'released' - then they can use whatever appropriate magic.

smime.p7s
Description: S/MIME cryptographic signature

Re: Code covered by the Oracle grant

[Dirk-Willem van Gulik]

On 7 Jun 2011, at 13:06, Michael Stahl wrote:
 On 07/06/11 11:42, Christian Lippka wrote:
 Am 07.06.2011 11:09, schrieb Thorsten Behrens:
 

 If you re-read Christian's mail, the answer to both is yes. And
 another remark: given the overall state of the code (~20 years of
 sedimentation), the full project history is of great value, when one
 tries to figure out how one specific piece of code came to pass.
 
 yes, the history is definitely valuable; in fact i sometimes am frustrated 
 that it only starts in 2000 and misses out the first 10 years...


Keep in mind that one can do both - keep all the history -but- at the same time 
ensure that releases done under the ASF its banner only contain code covered by 
the software grant. And that any code added since that software grant 'stake in 
the sand' point is covered by the normal CCLA agreement with an indivudal 
committer. Combine that with a bit of frugal oversight by the PMC (to spot 
accidental cut-and-paste from pre-watershed code) and one has the best of both 
worlds perhaps?

Dw

smime.p7s
Description: S/MIME cryptographic signature

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

[Dirk-Willem van Gulik]

On 6 Jun 2011, at 09:13, Andreas Kuckartz wrote:
 Am 06.06.2011 09:25, schrieb Greg Stein:
 One of the main topics of the whole discussion regarding the
 OpenOffice.org incubation proposal was and is collaboration with TDF /
 LO. And now the first initial committer from IBM in the proposal
 states that some ways of collaborating with TDF /LO might be illegal and
 should not even be discussed.


I think that this is a very *very* valid concern. And one I've certainly heard 
expressed in recent months more regularly than in the years past.

And it is one which is common for 'industry consortia' like ours - who end up 
having a lot of market impact due to their neutrality combined strength of 
their respective markets. And that is not a theoretical thing - nor is 
intervention (though historically such intervention has usually been at the 
source - i.e. the amount of leeway a large company/organisation gets to work  
bestow their good-will onto others).

However - it is just a concern. I do not think that it is a problem - as these 
effects are well understood at a regulatory level - and are common to a lot of 
standards bodies and industry coordination entities. 

One of the things we could do on this side of the pond (e.g. in Europe) is 
pro-actively open a dialogue with, say, the EU, under the digital agenda[1]. 
I'd suggest the latter - as it has identified a number of 'actions' to which 
collaboration between the ASF, TDF and LO would be very conductive. As opposed 
to working with the enforcement side of the regulatory arm.

That way we'd have the right-hand of the regulators help us shape this, we help 
the regulators by introducing them into relatively new technology  power 
systems and we'd also further some of the Digital Agenda - which I personally 
think is a good thing.

Thanks,

Dw

1: http://ec.europa.eu/information_society/digital-agenda/index_en.htm



smime.p7s
Description: S/MIME cryptographic signature

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

[Dirk-Willem van Gulik]

On 6 Jun 2011, at 10:51, Sam Ruby wrote:
 On Mon, Jun 6, 2011 at 4:45 AM, dsh daniel.hais...@googlemail.com wrote:
 
 If IBM has legal concerns in this regards they may involve their own
 IP and patent attorney stuff IBM-internally.
 
 I really didn't want to participate in this thread, and like Greg wish
 it would end, but I will state a number of things:
 
 (1) that I have not (yet?) heard this particular concern from IBM
 attorneys on this particular project
 
 (2) I am quite willing to talk to IBM attorneys (and those that know
 me also know that I am quite willing to tell them in straight terms
 what the ASF is, and is not, willing to tolerate)
 
 (3) The ASF that I know would never tell a project that they can't do
 something for which there are volunteers simply because similar
 functionality is available under a less permissive license.
 
 (4) Finally I will (re)state my vision[1]:
 
 Part of this vision is also that participants don't block one another.
 If IBM, for example, has a proprietary value add they should not be
 able to block somebody else from contributing substantially similar
 functionality to the ASF under a more liberal license. Similarly, if
 LO has some CopyLeft value add, they should not be able to block
 others from contributing substantially similar functionality to the
 ASF under a more liberal license.



Right - but I think we're now sidestepping another conversation  - should we, 
that is the community, worry about being *perceived* by larg(ish) organisations 
as having enough of a dominance in a market that they feel they should regulate 
how they work with us. Or is there a risk that regulators misunderstand us - 
and talk to those larg(ish) companies about that. 

IMHO - if there is any such risk - we 1) should both help the regulators 
understand the situation better and 2) do this in such a transparent way that 
members of our communities are better equipped to have their part of that 
conversation. And this is nothing new or special - plenty of (industry) 
standards bodies have had this issue - and the drive for open standards and 
readily accessible documentation, both from a regulatory point as well from a 
post-damage repair perspective, is now well understood and common.

We got fairly close to these issues some 10-12 years ago - but (I personally 
think that we) where saved by the fast growth of java and other projects (and 
the fact that the internet was still tiny as an industry). And hence we never 
really addressed this. But perhaps it is time to do so.

Thanks,

Dw (who is happy to commit to making a stab at this on the East side of the 
atlantic).

smime.p7s
Description: S/MIME cryptographic signature

Commerce and open-soure (Was) Proposal to join Apache OpenOffice

[Dirk-Willem van Gulik]

Having finally caught up with most of the discussion so far - I am wondering if 
there is a fundamental disconnect between how the various communities model 
commercial interests and open source.

Perhaps it is fair to surmise that Apache rules of engagement matured during 
the start of the dot-com boom. And where virtually each and every person 
involved was there for what I would almost call very 'selfish' reasons[0]. 
Fierce competitors (on content) easily conceded to collaboration (on technology 
and open standards). Driven by clear tradeoffs around time-to-market, 
interoperability or cost. Driven by clear 'win's for the contributors (and not 
necessarily considering a win-win at both contributor and nascent ASF) as the 
amplifying force. 

Now above is probably too stark of a caricature - and a lot of people where 
motivated by a lot more (cool technology, the joy of collaborating and 
learning, access to smarter people, the challenge) and generally well attuned 
to the 'lets make the world a slightly better' place of internet engineering 
dominant in that period.

However I'd still argue that the fact that a lot of people then (and now) were 
driven by powerful commercial forces became part of the ASF its fabric. And 
then since then - the  apache community has learned how to work with that.

You may have noticed that above mentions 'people' far more often than 
companies. 

And that is part of that lesson - Apache tends to work with individuals - who 
get their 'commit bit' based on merit, based on the opinion of their peers and 
their visible contributes. As opposed to corporate access or dealing with 
companies[1].  We trust people.

And unless they specifically state otherwise (and this is rare!), when an 
Apache member or committer posts on any mailing list - they do it as 
themselves. It is their personal point-of-view, wearing their personal hat and 
not as a mouthpiece for whatever company happens to be signing their paying 
their salary at that point. Likewise - VP's and ASF directors very rarely use 
their 'hat' - and if they do so - will identify themselves clearly. . And we do 
see a lot of ASF committers move from company to company - over periods of 
decades even - loyal to the codebase and apache[2] . Some have even managed to 
make a full circle.

But none of this makes the ASF a counter balance or a shield for- or from- 
corporate interests. It just makes it a place where individuals can safely 
contribute to code, release that code, get the benefit of proven processes and 
know that they shielded form the usual liabilities. And it makes it a place 
where anyone, individuals and companies alike - can pick up release - and where 
they know that their exposure is as it says of the tin.

So this is somewhat in contrast with other possible community structures. Where 
the collaboration structure _itself_ is there to protect, to shape; or where 
the contributors and interest sitting at the coding table are companies, rather 
than people. And where the collaboration structure needs to be strong enough to 
keep this in check.  Or where strong licenses, like the GPL, are needed to keep 
certain undesired commercial land grabs at bay.

The ASF its structure, culture and bylaws are simply not conductive to the 
latter. All it is, can do, is considering to accept a donation (software 
grant[3]) under very specific terms and then allow a self managing[2] group of 
individuals who are peers, work on that code within a fairly narrow set of 
processes[4] following a defined path[5].  And the ASF will only do this when 
that group of individuals is there. People. Willing to do work.  Only during 
that first bootstrapping phase is there some help[6] - but beyond that - 
projects are self manage, self select their PMCs, self propose individuals for 
commit access and so on.

And I think that this difference in expectation is at the heart of some of the 
current debates. 

I'd personally expect that the Open Office world - which its sizeable impact on 
a very commercial enterprise world with expensive demands will need to garner a 
solid and balanced support ecosystem which is far beyond the ASF - where the 
free and strong ideological chops of, say, LibreOffice balance commercial 
product and support companies.

Hope this helps,

Dw.
-- 
Dirk-Willem van Gulik dirkx(at)webweaving(punto)org

0: I'll be the first to admit that - though arguably in my case it was research 
money and getting satellite pictures distributed by other means than faxed 
request forms and large boxes of tape.
1: In all fairness - we do have Company Contributor License Agreements - partly 
as to make things easier on the process side for individuals which work in 
(large) companies. Companies do not contribute code - people do.
2: http://www.apache.org/foundation/how-it-works.html
3: http://www.apache.org/licenses/software-grant.txt
4: http://incubator.apache.org/guides/graduation.html#releases
5: http://incubator.apache.org

Re: [Libreoffice] Proposal to join Apache OpenOffice

[Dirk-Willem van Gulik]

On 6 Jun 2011, at 18:00, Ian Lynch wrote:

 what happens. The fact is the software grant is made. My understanding is
 that if the code goes into the incubator it does not even guarantee it will
 emerge as a marketable product.
...
 OTOH it might thrive and take over the desktop office world (I wish :-)
 ) . At this point there is no way of knowing.

Correct.

 All this incubator process is
 supposed to do is see if ASF members think it has some potential. 

No. It is a lot more nefarious than that :) Its a filter. It ensures that the 
IPR is in order, that rights are cleared - and that, should the project make it 
through, the community has the ability to be in control of its own destiny 
(within the limits of local law and government induced monopolies and 
interventions). It ensures that people can do releases with well understood 
liabilities, can work on the code with well understood rules (and subsequent 
personal protection).  It also ensures there is a viable community of peers, 
selected on merit, who are self-manging their community and their code base. 
And who are able to manage the code in such a way that all this continues to 
hold true. And it ensures that people and companies alike can pick up releases 
and use them in a well defined set of circumstances in the products and 
services they use or sell.

  It might just sit on a shelf in ASF
 gathering dust because no-one really has the resources to do anything with
 it. 

And its (also) the thing which happens to ensure that it won't be sitting on a 
shelf in the ASF gathering dust. :) :) As it will get killed and chucked away 
if it does not make it through the process.

So I'd just see this as a 'here is a piece of code' - it came in with a well 
defined legal situation [2]. Assuming the cross validation of all files check 
out - it is now over the community at large to (re)organise and create a merit 
based group of peers who collectively want to work on this code[3]. And it is 
those peers, these people we trust. Companies, while part of the larger 
ecosystem, and with occasionally well understood intentions which one could 
charecterise as 'trust', are not.

Dw

1: http://incubator.apache.org/guides/graduation.html
2: http://www.apache.org/licenses/software-grant.txt
3: http://www.apache.org/foundation/how-it-works.html



smime.p7s
Description: S/MIME cryptographic signature

Re: [Libreoffice] Proposal to join Apache OpenOffice

[Dirk-Willem van Gulik]

On 6 Jun 2011, at 18:08, Simon Phipps wrote:
 On Mon, Jun 6, 2011 at 6:05 PM, Phillip Rhodes 
 motley.crue@gmail.comwrote:
 
 Let's say we persuaded the good guys at Apache that this is a ploy to
 manipulate them and they reject the code. Where then will it go? If
 conspiracy is right it definitely won't be to TDF and it could be to
 somewhere a lot more damaging to TDF than the ASF.
 
 100% agreed. Once this project is approved, it will be much easier to work
 out ideal compromises together too.

Also - keep in mind that Apache is a fairly simple beast when it comes to 
driving ideology, agendas and making the world generally a better place. I 
could easily see the two very effectively working on different planes. The ASF 
as a place for peers to work on the code - and a higher plane (or several) 
where TDF or commercial groupings would engage with the ecosystem at a very 
different level.

Dw.




smime.p7s
Description: S/MIME cryptographic signature

Re: Commerce and open-soure (Was) Proposal to join Apache OpenOffice

[Dirk-WIllem van Gulik]

On 6 Jun 2011, at 18:43, Benson Margulies wrote:

 The expression 'land-grab' in here bothers me.
 
 I understand (if not agree with) the 'deep philosophy justification'
 of the FSF for a particular licensing strategy.
 
 I understand the views of individuals who don't want to benefit
 corporations without extracting, at least, some token cooperation in
 return.
 
 I don't understand the analogy in which code is 'land' which can be
 'grabbed'. If a corporation takes ALv2 licensed code and uses it to
 launch some close-source thing, the code isn't used up. It's still
 there where anyone else can use it for anything else.

Apologies - what I meant was that there is a fairly fundamental choice in the 
contract with the wider ecosystem - will you simply allow anyone to do 
anything* with the code (including forking it, making totally closed/private 
versions and even distributing these modified versions) ? And let (new) 
communities morph code and social contracts as they see fit.

Or do you fundamentally as the owner feel responsibility towards the 'code' - 
and grab the moral high ground - and keep some level of control over that - as 
to ensure that both code and community are viable  benefit long term. And then 
work very hard (but collectively) from there on.

The ASF does the first (and allows others to do the latter by not 'caring' 
about that all too much). IMHO the value of some other organizations are in 
their strength to do the latter.

Or in other words - a small aspect of the wider free beer vs free speech 
discussion. Or, the one I like better, is one a carpenter - you make a most 
lovely roof - and do not care about other (builders) building on to your work 
or owning it in any way - or are you a true artist or architect - caring about 
your work and the IPR beyond the point it was gifted to an owner.

Dw

*: which can't be called by the original apache project name anymore - and 
liability shielding applies for the code incorperated.


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

Re: [VOTE] Graduate CouchDB as TLP (Was: Re: Asking for Feedback: CouchDB Graduation)

[Dirk-Willem van Gulik]

On Nov 10, 2008, at 2:44 PM, Jan Lehnardt wrote:
[ ] Yes, CouchDB is ready to become a top lavel project at the ASF  
and the
IPMC will recommend the proposed resolution quoted below to the  
Board.


+1, go go gO GO!

Dw.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Asking for Feedback: CouchDB Graduation

[Dirk-Willem van Gulik]

On 6 Nov 2008, at 15:11, Martijn Dashorst wrote:


I agree with Paul. CouchDB is ready IMO—it meets all the exit criteria
(just having given the talk about graduation at the ASF).




Aye to that !

Dw.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Asking for Feedback: CouchDB Graduation

[Dirk-Willem van Gulik]

On 4 Nov 2008, at 14:15, Jan Lehnardt wrote:


I haven't been following CouchDB but a PMC of five seems small - you
only have to loose a couple of people and you're on the verge of not
being a viable project. I took a look through the lists and from what
I can see CouchDB entered incubation with four committers in February
(the proposal listed six, but apparently was a mistake[1]) and has
added one new person just over a month ago[2].


We (informally, again :) decided to hold back a release and adding  
more
committers in favour of doing the graduation first (just to not have  
three
things running at the same time. While our software is highly  
concurrent,


While I am not going to strongly argue to the contrary - I do want to
offer my observation thatL

-   CouchDB is a small code base - and potentially quite a simple thing.

-   A few dedicated people is all it takes (and those are there) and
a few other involved people for the balance (which we also see)
are needed to keep this stable for long periods of time.

-   From personal experience - the code is working well, reliable
and so on.

-   From personal observation - the community is healthy and responds
well to its environment and even if there are hidden side
channels - communication seems open and inclusive.

Given that - I'd say that incubation with a handful people or so at this
stage is, while early and somewhat risky - certainly an option.

Now you only take risk when there is a reward. Given that I expect this
community to simply mature regard less of a hold or a go - there is  
little

reward. But lets make sure that we come back to this by the end of this
year, or early next year - and re-evaluate. As otherwise we risk  
listening

too much to the 'rules' - rather than define them by the exceptions :)

However - if anyone sees any risk at loosing community spirit, causing
friction, frustration, etc - in the couchdb space - do pipe up -- as  
that

should IMHO change this immediate.

Thanks,

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Asking for Feedback: CouchDB Graduation

[Dirk-Willem van Gulik]

On 4 Nov 2008, at 19:02, Bertrand Delacretaz wrote:


On Tue, Nov 4, 2008 at 2:13 PM, Dirk-Willem van Gulik
[EMAIL PROTECTED] wrote:
...Given that - I'd say that incubation with a handful people or so  
at this

stage is, while early and somewhat risky - certainly an option...


I assume you mean graduation - and agree that that's an option.


Sorry - yes :)

...Now you only take risk when there is a reward. Given that I  
expect this
community to simply mature regard less of a hold or a go - there is  
little

reward


I see the reward in that CouchDB is a very innovative product, and
graduating it could give it an additional boost - so no need to wait
IMHO.

I suggest trusting the mentors who voted +1 on this.


Dw.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of PGP support in Maven

[Dirk-Willem van Gulik]

On Sep 24, 2008, at 3:44 PM, Hiram Chirino wrote:


On Wed, Sep 24, 2008 at 1:27 AM, Henning Schmiedehausen
[EMAIL PROTECTED] wrote:

On Mon, 2008-09-22 at 13:42 -0400, Hiram Chirino wrote:

On Mon, Sep 22, 2008 at 10:12 AM, sebb [EMAIL PROTECTED] wrote:

On 22/09/2008, Hiram Chirino [EMAIL PROTECTED] wrote:
The only reason I suggested including the sigs in the source  
distro is
because a source build like Apache ServiceMix depends on  
hundreds of

third party dependencies.. so an end user would need to end up
trusting LOTs different signatures to get ServiceMix to build.

It would be easier if the end user could just trust the Apache  
source
distro and also transitively trust the signatures that we trust  
for

our dependencies.





I actually meant to say include the pub key for the dependency in  
the

source distro.


How do you validate that the pub key presented to you is genuine?  
What

you currently proposing is

src-artifact - signed with A's privkey, validated with A's pubkey

A's pubkey is inside src-artifact.


NO I'm not.  I'm saying that A artifact has 100 dependencies by say 30
different signers.. we include
those 30 pub keys in the src-artifact.  NOT the A key!

You have to validate the A source distro the same way you would
validate an ANT based build source distro today.


Ok we can do something where the X +1's issued are sent to a keyserver  
along with the OK of a PMC member or human gate (as one does not want  
to also automate veto counting) or similar - together with the md5/ 
sha1. And returned is the later hash signed by some rolling apache key  
or x509.


Thanks,

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Apache CouchDB 0.8.1-incubating release

[Dirk-Willem van Gulik]

On 13 Aug 2008, at 18:12, Noah Slater wrote:


Hello,

The community has approved a release of Apache CouchDB 0.8.1- 
incubating.


Pursuant to the Releases section of the Incubation Policy we would  
now like to

request the approval of the Incubator PMC to make the release.

Release proposal:

 
http://mail-archives.apache.org/mod_mbox/incubator-couchdb-dev/200808.mbox/[EMAIL
 PROTECTED]

Vote result:

 
http://mail-archives.apache.org/mod_mbox/incubator-couchdb-dev/200808.mbox/[EMAIL
 PROTECTED]

Please note that the vote result contains an error, we had four  
binding and two
non binding +1 votes which exceeds the minimum three +1 votes  
required.



Its a darn good piece of work !

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: (qpid) Diversity

[Dirk-Willem van Gulik]

On Mar 5, 2008, at 7:27 PM, Marnie McCormack wrote:

Several of our project (Qpid) memebers are legally in a difficult  
position

disclosing their employer in Apache world. They have signed a legal
document, in order to be allowed to contribute to Apache, and thus  
this is

not a simple preference issue.



Two thoughts:

1.  As to avoid having trust or distrust affecting the community
(i.e. some rot setting in at a later stage) I would
completely ignore these people as adding to the 'diversity' and in
fact advise to assume the 'worst' - and treat them as one block.

I.e. they are _counter_ to the diversity you want to show.

That is the most robust approach. As information leaks and attitude
shift the situation only gets better and more trust is build.

2.  Having the employer invisible either implies one of two:

a)  The employer totally does not enter into this and
the committer is acting a 100% as a private, free
individual; and his work does not pertain or is
associated in any way with his other endeavors.

b)  The employer is in fact part of the 'agreement' - and
hence known to the foundation.

In the last case we, that is the foundation, would need to figure out if
we can act as such a 'clearing house' - and would allow such provided  
the

CCLA's are visible to the members.

I personally would be very wary of this though. As ultimately the CCLA
and software grants carry a lot of sensitive rights - and part of
standing within our role in the current open source/standards
ecosystem has been gained by allowing full downstream visibility.

Dw


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Subversion vs other source control systems

[Dirk-Willem van Gulik]

On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:


Noel J. Bergman wrote:

J Aaron Farr wrote:

J Aaron Farr wrote:

git could be an issue.

Can you explain what the issue is with Git?

Leo already gave a decent explanation.
Basically, it comes down to two aspects:
 1) infrastructure support
 2) cultural bias

Only the first one is marginally correct, IMO.
Santiago wrote:

1. You have to use subversion.



Sorry, I've missed the thread that led to this, so sorry if I'm  
repeating others.


I understand that GiT can be used locally as a layer on top of SVN.  
I believe this gives you most of the perceived benefits of GiT  
locally without the need for a project itself to switch to GiT.


I am a bit lost here as well -- what does GiT add to the processes/ 
workflows common in the ASF ?


One of the great things about GiT is that you can can have lots of  
parallel and non-linear merges (every developer their own branch; lots  
of people merging the same patch into different sequences) -- and as  
such I can see it being perfectly tuned for, say, Linux.


However in the ASF most groups work roughly along fairly linear lines;  
with 'one' or just a 'few' points at which a patch is accepted - and  
essentially few, or just one, merge point (or a single line of merge  
points when backported). Rarely do we merge multiple 'HEAD's.


And I'd almost argue that SVN is a useful framework which helps us  
stay on the paved roads - where a single head progresses with group  
consensus and generally agreed merit.


Thanks,

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binding term

[Dirk-Willem van Gulik]

On Jan 31, 2008, at 6:40 AM, Noel J. Bergman wrote:


and only the PPMC member votes are binding.


The error is the use of PPMC.  It should say that only PMC member  
votes

are binding.


But somehow I like the fact that in most cases the vote is much wider  
- and I think that this helps foster a community responsiblity.


Perhaps we need to do something like having the whole community vote  
and then taking this as their proposal to the PMC which then votes as  
to wether to pass this community advice on.


This has the interesting benefit that if the community votes 'no' --  
the PMC cannot make it a yes.


Dw.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Binding term

[Dirk-Willem van Gulik]

On Jan 31, 2008, at 4:08 PM, Erik Abele wrote:


Perhaps we need to do something like having the whole community  
vote and then taking this as their proposal to the PMC which then  
votes as to wether to pass this community advice on.


Yes, we're already doing that it's just very confusing to a lot of  
people :)


Well -- you and I (and a lot of others) understand it that way. But I  
am not sure if this is universally shared ? I often find people, say  
at a non apache conference, who just do not see/experience it that way.


I like your term communiy advice - the PPMC gauges interest by  
holding a vote where only


I'd go a step further - and would expect the PPMC to either follow or  
'reject with explanation' -- rather than do something totally  
different. Or if they do - announce such clearly with another chance  
for the community to visibly rally.


Problem is - in the end of the day - the boards hold that same PMC  
accountable - no matter wath their community did.


the votes of the PPMC members are *counting* (binding) and then  
forwards this as a community advice to the IPMC which holds another  
vote to sign it off (where only the votes of the IPMC members are  
counting/binding).


Later, as soon as the Podling has graduated, the second step goes  
away and the former PPMC can now directly vote and sign-off by  
itself...



Agreed.

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: License grant

[Dirk-Willem van Gulik]

On Wed, 1 Feb 2006, Manuel Mall wrote:

 On the grant form is says: Licensor owns or has sufficient
 rights to contribute the software source code. In this case we don't
 have a single Licensor but a group of people. How does the form work in
 such a case as it seems to make the assumption that the Licensor is
 either a single person or a single organisation?

In the past this was solved by:

-  All the people in the group all sign the same software grant
and thus together hand over the code. (And assuming that all
authors are still alive and willing to do so).

Logistically this is a bit of a pain; so what was done in the past is
simply to have each person sign his 'own' (but identical) version of the
softwate grant (with the other people listed as well - but with a blank
behind their name) - and then filing the umpteen copies together which are
all idnetical expect that they have a different dotted line signed.

Dw.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ajax proposal?

[Dirk-Willem van Gulik]

On Wed, 4 Jan 2006, Martin Cooper wrote:

 On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote:
 
  So .. amidst all of our soul searching .. what'd we decide to do with
  the Ajax proposal from IBM et al.?? Did I miss the vote and decision??
..
 Personally, I would prefer that the ASF not accept _any_ AJAX framework at
 this point in time. The area is relatively new and in a great deal of flux
 right now, and crowning one of them with the ASF brand will create a de
 facto standard instead of letting the market decide, whether we like it or

We are part of that market - and I have no illusions about our ability to
set standards; we canot; we ONLY seem to do so when we happen to a) to
jump on the boat with the right technology and b) get the market to play
in our playground. (Marginally helped of course by the fact that so many
talented peopel and companies come to play here that we do set the odd's
for 'a' and have 'b' causal).

If your argument is that the quality of Zimbra code is relatively low; or
too immature by itself - and that is why you worry about spoiling the
market by betting on the wrong horse - then we should simply reject -this-
proposal based on the fact that there is a) not enough quality in the
donation and b) no hope for it to improve in our playground.

But in general - having the ASF offer it's eco system a place where we all
can work on Ajax (and have synergy with all the portal code we have, with
MyFaces^H^H^H^H^H^HOurFaces) seems like the right thing to do -when- there
are sufficient people interested to work on it. Which is the right
validating feedback loop.

Dw.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: incubating jabberd2?

[Dirk-Willem van Gulik]

On Fri, 2 Sep 2005, Peter Saint-Andre wrote:

 I've talked with the developers of the jabberd2 server [1] about the
 possibility of initiating their Jabber/XMPP server into the ways of
 Apache. They're open to and interested in incubation and would like to
 know if Apache folks might be interested, too. If so, I'll work with
 them to develop a proposal.

Obviously this is needs to be a very concious and full community choise
for the entire 'them' - i.e. the whole deveoper community. In that process
a number of things need to be clarified and cleaned up.

-  Right now there is the Jabber Software Foundation (which odly
seeems more concerned with protocol than wiht code :-).

-  The current code is under the GPL. And I am fairly sure that
few, if any, developers have ever excuted any (c) transfers
or (c) licenses. Furthermore - some of it may be developed
in the 'boss its time' - perhaps even jabber.com. So any
work here would propably involve some historic work and
a full purge/cleansing.

-  There are very few developers on that code base. All of
you folks would neeed to be on board.

-  There is no point in doing this if the end result of all
this is a fractured jabber community or an abandoned version
of the code base. As we, that is the ASF, care more about a self
sustaining healthy community for the long term.

-  We may have to look at patent issues as well.

And perhaps even more important - we need to wonder if there is a healty
commercial ecosystem around jabber - and if there is synergy between all
teh various parties - and what messaging, trust and reassuring is needed
to ensure that that synergy gets bettter. Noting of course that with the
transition of the jabber protocol to a `proper' XMPP - there is safeness
for folks to collaborate on the protocol stack.

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Request for Comment : Harmony Contribution Policy

[Dirk-Willem van Gulik]

On Mon, 1 Aug 2005, robert burrell donkin wrote:

 of trade secrets and strictly limits the rights of employers to
 material created by an employee in their own time using their
 materials.

On paper - yes - but national law and case-law shows that as soon as that
material is even remotely in the same line of work as gainfully employed
to do; cases err. towards the employer.

 time. any agreements related to employment will be interpreted under
 employment law rather than contract law (which are quite different) so

Agreed.

 even a signed CCLA may offer little help to the ASF in the event of a
^
 dispute. so, may need an additional clause with different wording for
 those in similar jurisdictions.

This I do not see - a CLA yes (esp. if the employer was not informed about
it - which in most EU countries an employee effectively has to do). But a
CCLA from the employer ? Because then the dispute is between the ASF and
the Employer about the agreement set out in the CCLA.

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: better docs for new committer procedure

[Dirk-Willem van Gulik]

On Mon, 23 May 2005, Roy T. Fielding wrote:

 Jackrabbit is following the procedures of the original Apache Group
 in adding new committers.  We nominate them first on the
 jackrabbit-private mailing list (which includes all of the existing
 Jackrabbit committers and any members who want to help incubation)
 and, if there are no objections, perform a formal vote in public.

 I found that process to be more encouraging of new community members
 than the current httpd habit of doing the vote in private and
 simply giving the person commit access without so much as a notice
 on the public list saying that they had earned it.

 Because incubator is the project, we need 3 +1s from the incubator
 PMC in order to validate our vote and add a new account.

Thanks for sharing this.

Dw.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: What is a healthy community? WAS: log4net 1.2.9 beta release

[Dirk-Willem van Gulik]

On Mon, 14 Mar 2005, Ceki Gülcü wrote:

 At 12:51 PM 3/14/2005, Dirk-Willem van Gulik wrote:

 body, as long  as that developer agrees to submit  to the decisions of
 the supervisory  body. The number of supervised  developers should not
..

Bear in mind that in essese that most of us do not see this as a
democracy; we delegate a lot down to the PCM's and even down to the
committer body when it comes to code - but at the same time; your vote
(binding or not) also means that you as a commiter are standing behind a
release on behalf of the ASF and are commited to its future.

You could make the argument that this means that aggregate PMC's are
simply not possible. Or you could make the argument that each code base
must grow its very own community.

Dw

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] How to prevent abusing Apache priviliges

[Dirk-Willem van Gulik]

On Fri, 15 Oct 2004, thorsten wrote:

 what if incubating mentors would abuse their powers to interfer with the
 normal evolution of Apache incubation projects.

Please report any such issue to the PMC of the incubator; or in private to
any pmc member. If there are any trust issues with the PMC- please contact
any board member directly. If you want to discuss a theoreticla thing
[EMAIL PROTECTED] is the right place.

However cross posting to community@ is certainly not the most appropriate
thing to do.

Dw.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OpenSAML (was RE: Incubator DOA)

[Dirk-Willem van Gulik]

On Thu, 13 Mar 2003, Scott Cantor wrote:

 In any case, my thoughts notwithstanding, it's obviously something that
 the people interested in building new Apache WS projects on SAML should
 decide.

Aye - and the board@ is unlikely to do anything significant until at least
that group has reached some sort of consensus :-)

Dw


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]