Re: [IP CLEARANCE] [VOTE] Apache Celix shared memory Remote Service Admin implementation (2nd attempt)
Hello Craig, As suggested, I updated the document to contain the location of the grant. Greetings, Marcel On 19 Dec 2013, at 17:29 pm, Craig L Russell craig.russ...@oracle.com wrote: Hi Marcel, The ip looks good, but the ip clearance document is our historical record and needs to be updated. No need to re-run the vote if the document is corrected. On Dec 18, 2013, at 2:28 PM, Marcel Offermans wrote: Note that this is a new vote, after cancelling the previous one. Apache Celix received the donation of a shared memory implementation of the remote service admin specification. The donation is tracked by CELIX-81 [1]. The (updated) IP clearance document is placed under: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml The ip clearance document should provide one stop shopping to verify the provenance of the ip and the grant. Can you please update the above document to include the location of the grant from Thales Nederland B.V.? https://svn.apache.org/repos/private/documents/grants/thales-nederland-celix-remote-services-admin-bundle.pdf Thanks, Craig The software grant can be found in the appropriate document in svn (I’ve included a few relevant lines to make it easier to locate it): Thales Nederland B.V. file: thales-nederland-celix-remote-services-admin-bundle.pdf for: A remote services admin bundle and a discovery bundle which uses shared memory for information interchange. See: CELIX-81 Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Greetings, Marcel [1] https://issues.apache.org/jira/browse/CELIX-81 Craig L Russell Secretary, Apache Software Foundation c...@apache.org http://db.apache.org/jdo - 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: Question about jar files in svn.
On 23 December 2013 05:50, David Crossley cross...@apache.org wrote: Marvin Humphrey wrote: Greg Trasuk wrote: Thanks everyone for the input. To summarize, it appears that the consensus argument is: - Jar files are not prohibited by policy in project repositories (svn), although they may not make a lot of sense. - Source distributions must not distribute executable code in binary form. i.e. Don’t ship dependency jars in the source archive. However it may be acceptable to include things like jar files that are processed during testing (sample archives, for instance). - The project repositories are not generally considered “distributions”, but we need to be a little careful to avoid users’ confusion on this point. Regarding that last part, i reckon that is about: only referring the development community to the development resources and not instructing users to do that. However, many projects refer to SCM repos on public pages, some even on the download page. Also, projects that use Maven will have the SCM URLs in the POM. Maven generated sites will have the Source Repo as part of the standard documentation. Such projects should ensure that the SCM has appropriate NL files at the top level. Note also that Roy [1] at least considers that SCM should be classed as a distribution. See also [2] and [3] [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200907.mbox/%3C7A0220B7-5DF1-4F4C-8C27-6CA8A175CFCD%40gbiv.com%3E [2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200907.mbox/%3C1706952606.1247865134823.JavaMail.jira%40brutus%3E [3] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200907.mbox/%3C1809771433.1247865614827.JavaMail.jira%40brutus%3E -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
permission to edit wiki
Hi! I would like to add something to the wiki, can I please have access? My login name is Neng Geng Huang Thanks! Huang -- -- Mr. Huang Neng Geng -- Associate Professor School of the Internet of Things Wuxi Institute of Technology Wuxi, Jiangsu, China, 214121 Mobile: 86-13921501950 email: huan...@gmail.com
a new proposal Busilet
Hello community, Please find below a proposal draft wish to submit to the ASF. The proposal is only a draft and persons interesting to this project are welcome to join. I am new here and also need help for the proposal and the further processing. A brief introduction of IDTP, UTID, and Busilet could be found in http://www.utid.org/, http://tools.ietf.org/html/draft-huangng-idtp-01 and http://tools.ietf.org/html/draft-huangng-utid-01 Thanks in advance Best regards, Huang Busilet Proposal === ===Abstract Busilet is a reference implementation of IDTP (Identifier Tracing Protocol) and UTID (Universally Traceable Identifier), a new communication protocol and an identification system, which were submitted to IETF as two Internet-Drafts (http://tools.ietf.org/html/draft-huangng-idtp-01, http://tools.ietf.org/html/draft-huangng-utid-01). The IDTP is an application-level protocol for distributed and collaborative information systems, potentially used in wide areas of computation, such as the Internet of Things, cloud computing, pervasive computing, distributed database, and remote procedure call. ===Proposal I propose to move future development of Busilet to the Apache Software Foundation in order to build a broader user and developer community. Busilet had been under developing by me only and published as open software inhttps://sourceforge.net/p/busilet. I hope that with the help of developers all around the world, the system could become more powerful and functional in wide areas of computation. ===Background Busilet was originated from a project called Things Mail (tmail) System in a small innovative company nearly three years ago. The tmail system require full interoperation among operating system platforms, organizations (express companies and delivery stations), physical things (mails and smart mail boxes), and persons (senders, delivery men, and receivers). UTIDs were designed to identify these various objects and IDTP is used as a communication protocol to exchange message among them. After the project finished, I recognized that the development prospects of the UTID and IDTP so that continued to conduct further researches on them during the last two years. I wrote specifications of UTID and IDTP while I was developing Busilet to proof the feasibility and practicality of the specifications. I had submitted the specifications to IETF as two Internet Drafts. I realized that it is impossible for me alone to fulfill the task. Therefore, I do hope more persons are involved in the task making contributes to the computation world. ===Rationale As the reference implementation of UTID and IDTP in Java language, Busilet Project is developed for following reasons: **To demonstrate the feasibility and practicality of the two Internet-Drafts of UTID and IDTP. **To find errors in the two Internet-Drafts and improve them. **To provide a new communication protocol for public used in the Internet of Things, cloud computing, pervasive computing, distributed database, and remote procedure call. ===Recent Goals The initial goals for Apache Busilet are: **Improve the existing Busilet project by refactoring the codes. **Implements all features defined in the two Internet-Drafts. **Extends two features: session and encryption, which are already implemented in the Busilet Project at present. **Release a stable version of code. **Rewrite development documents and user manuals. ===Current Status Several versions of code of Busilet Project could be accessed in: https://sourceforge.net/p/busilet The latest version of Busilet Project is fully compatible with the two Internet-Drafts. The early versions of Busilet Project have been successfully applied in four real production projects. ===Meritocracy The project is completely new and there is no person involved in it at present. ===Community Busilet will try to foster a diverse community that is open to everyone. It is released under a Apache License 2.0 to encourage the maximum possible adoption by all potential users and developers. The Busilet community encourages suggestions and contributions from any potential user and developers. ===Core Developers The project is completely new and I am the only developer. I would like to have more competent developers joining this project and have the project leaded by an excellent leader. ===Alignment The initial Busilet makes use of Jackson component and other components such as org.json component. It is possible to use a better json component to replace these components in the future. ===Known Risks ===Orphaned Products There is a small risk of being orphaned. We will try to avoid it happens from the beginning. ===Inexperience with Open Source The Busilet has been treated as an open source project since its beginning. While our experience with public open source is limited, we do not anticipate difficulty in operating under Apache's development process. ===Homogeneous Developers
Re: LICENSE and NOTICE Role Models
I was thinking that the real problem is that each new project is forced to rediscover the right thing to do each time. From my POV there really aren't that many licenses out there. If there were just a wiki that said... 1) If you include source with X license, then Y must go in LICENSE and Z in NOTICE. 2) If you use a binary with X license, then Y must go in LICENSE and Z in NOTICE. As new or one off license are discovered the legal or whomever actually knows the rules adds to the wiki. On 12/22/13 10:08 PM, Marvin Humphrey wrote: On Wed, Dec 11, 2013 at 2:24 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: It would be great if we could get a resolution on some of the JIRA's in legal, e.g. https://issues.apache.org/jira/browse/LEGAL-26 https://issues.apache.org/jira/browse/LEGAL-27 https://issues.apache.org/jira/browse/LEGAL-31 https://issues.apache.org/jira/browse/LEGAL-136 +1 The continuing lack of clear resolution also impacts the Incubator. Podlings challenge us with You say do X, but Apache Foo does Y -- where is it documented that we have to do X? Then we go down the path of hunting up Board member quotes and past threads on legal-discuss. It would make things easier on all Apache TLPs and Incubator podlings if we could get the following elements in sync: * Apache Legal policy documentation. * http://www.apache.org/dev/licensing-howto.html * Maven's processes. * The actual LICENSE/NOTICE practices for the ASF's top ten or so most popular products. The most critical one to the Maven PMC is LEGAL-26: Perhaps, though the way that Maven would implement LEGAL-26 (LICENSE/NOTICE in svn) is impacted by LEGAL-27 (LICENSE/NOTICE must reference *only* bundled dependencies). I'm not on the Legal Affairs committee, but I did write most of the Licensing How-To. Come January, I'd like to do what I can to move the process forward. A lot of valuable developer time has been wasted over the years rehashing these issues over and over again, and it's not like most developers relish this stuff. Clear policy documentation would be a valuable contribution to all of the Foundation's projects. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LICENSE and NOTICE Role Models
On 23 December 2013 15:28, Kevin Minder kevin.min...@hortonworks.com wrote: I was thinking that the real problem is that each new project is forced to rediscover the right thing to do each time. From my POV there really aren't that many licenses out there. If there were just a wiki that said... 1) If you include source with X license, then Y must go in LICENSE and Z in NOTICE. 2) If you use a binary with X license, then Y must go in LICENSE and Z in NOTICE. As new or one off license are discovered the legal or whomever actually knows the rules adds to the wiki. As far as LICENSE is concerned, the rule is simple, the full license text must be provided with the bundle that includes the bits. This can either be in the LICENSE file itself, or (generally better) the file name should be noted in LICENSE. Since 3rd party licenses may vary between versions, the LICENSE file should state the product name *and version* for example: MegaCorp Foobar version 3.2.1 is included under license XYZ, see file res/licenses/XYZ.txt A separate issue is whether the inclusion is allowed - but if it is, the above applies. For the NOTICE file the rule is also simple - it is for *required notices only. However, the problem here is that it is not always obvious what is required. For some licenses, it is sufficient to have the license text. I don't think a Wiki page is suitable as the formal documentation for this however. It needs to be part of the foundation website. On 12/22/13 10:08 PM, Marvin Humphrey wrote: On Wed, Dec 11, 2013 at 2:24 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: It would be great if we could get a resolution on some of the JIRA's in legal, e.g. https://issues.apache.org/jira/browse/LEGAL-26 https://issues.apache.org/jira/browse/LEGAL-27 https://issues.apache.org/jira/browse/LEGAL-31 https://issues.apache.org/jira/browse/LEGAL-136 +1 The continuing lack of clear resolution also impacts the Incubator. Podlings challenge us with You say do X, but Apache Foo does Y -- where is it documented that we have to do X? Then we go down the path of hunting up Board member quotes and past threads on legal-discuss. It would make things easier on all Apache TLPs and Incubator podlings if we could get the following elements in sync: * Apache Legal policy documentation. * http://www.apache.org/dev/licensing-howto.html * Maven's processes. * The actual LICENSE/NOTICE practices for the ASF's top ten or so most popular products. The most critical one to the Maven PMC is LEGAL-26: Perhaps, though the way that Maven would implement LEGAL-26 (LICENSE/NOTICE in svn) is impacted by LEGAL-27 (LICENSE/NOTICE must reference *only* bundled dependencies). I'm not on the Legal Affairs committee, but I did write most of the Licensing How-To. Come January, I'd like to do what I can to move the process forward. A lot of valuable developer time has been wasted over the years rehashing these issues over and over again, and it's not like most developers relish this stuff. Clear policy documentation would be a valuable contribution to all of the Foundation's projects. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. - 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: permission to edit wiki
Done. -David Neng Geng Huang wrote: Hi! I would like to add something to the wiki, can I please have access? My login name is Neng Geng Huang Thanks! Huang -- -- Mr. Huang Neng Geng -- Associate Professor School of the Internet of Things Wuxi Institute of Technology Wuxi, Jiangsu, China, 214121 Mobile: 86-13921501950 email: huan...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Release Retention Policy
Hi all, Recently, DeltaSpike got a ticket to clean up the old dist area in SVN from when it was a podling. Since we have everything tagged in git, it's not a big deal to recreate the release in case something goes wrong, but looking at it we only have 1 release (0.3-incubating) in there. I'm curious though about the retention policy. If I delete this directory, do I need to the release somewhere else? Or is it, delete it and it's gone, you'll need to rely on git tags. John - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release Retention Policy
On 24 December 2013 00:03, John D. Ament john.d.am...@gmail.com wrote: Hi all, Recently, DeltaSpike got a ticket to clean up the old dist area in SVN from when it was a podling. Since we have everything tagged in git, it's not a big deal to recreate the release in case something goes wrong, but looking at it we only have 1 release (0.3-incubating) in there. I'm curious though about the retention policy. If I delete this directory, do I need to the release somewhere else? Or is it, delete it and it's gone, you'll need to rely on git tags. See: http://www.apache.org/dev/release.html#archived Everything on the ASF dist/ tree is archived. John - 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
