Re: Experience with Contribution Agreements
Cool. Always nice to see communities in sync. Craig On Feb 16, 2011, at 10:18 AM, eduardo pelegri-llopart wrote: Perfect. Thanks. It's always very useful to be able to borrow best practices from other communities. - eduard/o On Wed, Feb 16, 2011 at 5:30 AM, Matthias Wessendorf mat...@apache.org wrote: Hi Eduardo, there is a list of committers (they have all submitted the ICLA) and the page also contains the contributors (non-committers), that signed the individual CLA: http://people.apache.org/committer-index.html (search for Persons with signed CLAs but are not committers) HTH, Matthias On Wed, Feb 16, 2011 at 5:12 AM, eduardo pelegri-llopart pele...@calterra.com wrote: Hi Craig! On Tue, Feb 15, 2011 at 5:24 PM, Craig L Russell craig.russ...@oracle.com wrote: Hi Eduardo, Well, I remember you from Sun. ;-) :-) I think the situation isn't well-understood. Once you sign the ICLA, your contributions are covered. If you don't want future contributions to be covered by the agreement, don't contribute any more. If you have a test case for a bug you submit, and don't want the test case to become part of your contribution, there's a tick box on the bug report that says this is not a contribution. Didn't know about that tick box; seems a good idea. What is the situation that you need covered? I can think of two cases. One is an unintentional contribution. This seems covered by the ASF ICLA clause about intentionally submitted, which is not present in Sun's SCA. The other is more of a statement where the individual might want to indicate that it no longer is supportive of the institution, but there are other ways to do that. BTW, is there a public list of everybody that has signed an ICLA/ CCLA? Something like Sun's [4]. [4] http://sca.java.net/CA_signatories.htm For completeness, the current version of Oracle's CA is OCA 1.6 [5]. I believe it is the same as SCA 1.5, with s/Sun/Oracle/, but not 100% sure. It has several clauses not in the ICLA, including one specific to commercial entities indicates Any contribution we make available under any license will also be made available under a suitable FSF (Free Software Foundation) or OSI (Open Source Initiative) approved license. - that, of course, would not apply to ASF. [5] http://oss.oracle.com/oca.pdf - eduard/o [1]http://www.apache.org/licenses/icla.txt [2]http://oss.oracle.com/oca-1.3.pdf [3]http://oss.oracle.com/oca-1.4.pdf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org Craig L Russell Secretary, Apache Software Foundation Chair, OpenJPA PMC c...@apache.org http://db.apache.org/jdo - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Experience with Contribution Agreements
Hi Eduardo, Well, I remember you from Sun. ;-) On Feb 15, 2011, at 4:34 PM, eduardo pelegri-llopart wrote: Hi there. Matthias suggested this would be a good alias to ask for experience at ASF on Contribution Agreements. Some of you may remember me from my Sun days; I'm now working at RIM and as I apply my experience to our projects I notice situations I had not considered/encountered at Sun [2,3]. The Apache contribution agreement [1] does not seem to include a mechanism by which a signatory of the CA can indicate that future IP is no longer covered. Not something to revoke previous contributions but just for the future, say to be clear of his/her intentions. Is that correct? If so, is it because the need has never arisen?, because its hard to do legally?, because it is very easy to do?, or something else? BTW, as far as I know, Sun didn't have any such mechanism either. I think the situation isn't well-understood. Once you sign the ICLA, your contributions are covered. If you don't want future contributions to be covered by the agreement, don't contribute any more. If you have a test case for a bug you submit, and don't want the test case to become part of your contribution, there's a tick box on the bug report that says this is not a contribution. What is the situation that you need covered? Regards, Craig Thanks, Eduard/o (Pelegri-Llopart) - OSS @ RIM [1]http://www.apache.org/licenses/icla.txt [2]http://oss.oracle.com/oca-1.3.pdf [3]http://oss.oracle.com/oca-1.4.pdf - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org Craig L Russell Secretary, Apache Software Foundation Chair, OpenJPA PMC c...@apache.org http://db.apache.org/jdo - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: [VOTE] Change community@ list settings
On Jul 8, 2009, at 9:01 AM, Jukka Zitting wrote: Hi, On Wed, Jul 8, 2009 at 5:57 PM, Craig L Russellcraig.russ...@sun.com wrote: What's your plan to avoid spam? Same as what we use on all our public project mailing lists: Posts from non-subscribers still need to pass moderation. I volunteer as a moderator. Ok. +1 Craig BR, Jukka Zitting - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Information request to projects using OpenJPA
Hi, I'm looking for information from projects that are using OpenJPA. I'm giving a talk in two weeks and I'd appreciate anything you would want to share. I'd also like to open a more extended dialog to get more feedback if you're open to it. Any kind of feedback would be useful, and if you don't have anything specific, here are some questions to start with: Why are you using an object-relational mapping (ORM) framework for your project? Do you need to support different relational databases (e.g. Derby, MySQL, PostgreSQL)? Can you be specific as to the databases you need to support? Roughly how many tables are in your database schema? About how many different database queries do you use in the project? Do you need to generate dynamic queries? What alternatives did you investigate? Writing your own JDBC framework? Writing your own ORM layer? Using another Apache project (e.g. ibatis, Cayenne)? Using another open source project (e.g. Hibernate, TopLink)? Why did you choose OpenJPA over the alternatives? Are there missing features that you'd like to see in OpenJPA? Any advice to other projects with object persistence or ORM requirements? Any advice for the OpenJPA project? I appreciate any and all information you can share. Thanks, Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Community Guidelines (was Code of Conduct)
I have a question about this part of the guidelines: Project source code and documentation must be donated to the ASF under a inline: moin-www.png Contributor's License Agreement. Donated source code and documentation must carry the ASF copyright and be placed under the Apache License. Code and documentation donated to the ASF must be maintained on ASF hardware. Obtaining a non-exclusive ASF copyright on all material in the ASF repository is encouraged. I'd like to understand if the requirement is to donate code and documentation or to license it to ASF. I thought that the requirement was to simply license it to ASF under ASL v2.0. Craig On Jun 28, 2007, at 1:56 PM, Ted Husted wrote: Some of the ASF Members have indicated a wish to draft a code of conduct. A working draft of a set of Community Guidelines is available on the incubator wiki, * http://wiki.apache.org/incubator/CodeOfConduct Any comments would be very welcome. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
