Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache OGNL
I'm sorry that I can't help out but when reading this I thought that using the spec name as the project name is probably not ideal. How about calling it Apache (Commons) Ogranal? Hopefully, this doesn't have any strange meaning in some language. Just a thought. On 08.04.2011 09:26:43 Simone Tripodi wrote: Hi all guys, I'm almost ready to submit a new proposal I'm preparing on Wiki[1] for Apache OGNL. The idea is importing the OGNL project under the Apache umbrella and, once/if ready, be promoted in Apache Commons - the Commons PMC already voted to be the Sponsor. All legal issues have been resolved, we have the Champion - Lukasz Lenart - and a great Mentor - Olivier Lamy - what we miss are 2 more mentors... any volunteer? :) It would be nice also if you can provide your feedbacks, once raw the proposal. Many thanks in advance, have a nice day!!! Simo [1] http://wiki.apache.org/incubator/OGNLProposal http://people.apache.org/~simonetripodi/ http://www.99soft.org/ Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache OGNL
The reference to Ogre did cross my mind. But the emphasis is on the O, not the a. ;-) On 08.04.2011 10:00:10 Antonio Petrelli wrote: 2011/4/8 Jeremias Maerki d...@jeremias-maerki.ch How about calling it Apache (Commons) Ogranal? Are you serious? Ogr(e)anal? :-D Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] JPPF : a parallel processing framework for Java
== Cryptography == JPPF does not have any cryptographic component. However, the distribution includes a sample that shows encryption/decryption of data as a demonstration of one of its features. The sample is delivered with full source code and can be found at: http://www.jppf.org/wiki/index.php?title=Extending_and_Customizing_JPPF#Transforming_and_encrypting_networked_data == Required Resources == Mailing lists * jppf-private (with moderated subscriptions) * jppf-dev * jppf-commits * jppf-user Subversion Repository * https://svn.apache.org/repos/asf/incubator/jppf Issue Tracking * JIRA (JPPF) Others * Web site: Confluence (JPPF) == Initial Committers == * Laurent Cohen (laurent.cohen at jppf.org) * John Channing (john.channing at gmail.com) == Affiliations == None of the initial committers are paid by their employer, nor do they represent their employer in any activity related to JPPF. == Sponsors == Champion * Emmanuel Lecharny (elecharny at apache dot org) Nominated Mentors We are currently looking for mentors within the community. Sponsoring Entity * Apache Incubator -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduation for Sanselan
A late +1 from me. Good to see that happening. On 22.06.2009 04:11:48 Craig L Russell wrote: Hi, Sanselan has been in incubation since September 2007. Sanselan is a pure-java image library for reading and writing a variety of image formats. Monthly and then quarterly reports can be found at http://svn.apache.org/repos/asf/incubator/sanselan/board/ The first official Apache Sanselan incubating release occurred on July 30th, 2008. A few months back we took a final look at Sanselan's status with regard to exiting the incubator. We concluded that while the code and the committer for Sanselan were ready to exit the incubator, community was an issue. We didn't see the prospect for getting enough of a community to graduate Sanselan as a TLP. But Apache Commons was eager to adopt Sanselan, and they voted to do so. Sanselan is now ready to graduate the incubator and assume its role as a subproject of Apache Commons. Please review the checklist at http://incubator.apache.org/projects/sanselan.html and verify that Sanselan is ready. +1 graduate Sanselan into Apache Commons +-0 don't care -1 don't graduate because... Voting will remain open until Thursday June 25. Craig L Russell Incubator PMC, DB PMC, OpenJPA PMC c...@apache.org http://db.apache.org/jdo Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Sling as Top Level Project
On 29.05.2009 22:11:02 Felix Meschberger wrote: [X] +1 to recommend Sling's graduation And +1 to more OSGi. ;-) Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Sanselan as a Commons library
On 18.04.2009 22:03:53 Jochen Wiedmann wrote: Hi, Craig, I'm personally not sure that commons would be the best fit for Sanselan. Despite the name, I'd consider the commons of xmlgraphics (despite the name, this is not only about XML) a better place. I thought along similar lines but the problem is as follows: XML Graphics currently doesn't use Sanselan. It currently does not offer anything that we don't already have or need. If it had a 100% Java JPEG decoder or a JBIG2 codec, that would be different. Also, XML Graphics barely has enough energy to keep itself afloat. I don't think there's going to be large enthusiasm to integrate Sanselan as further subproject. That said, I'm personally not opposed to include Sanselan in XML Graphics but don't expect much help from any of the project members. I'm just being realistic. Nevertheless, I'd vote in favour of Sanselan, if it comes to that. On Fri, Apr 17, 2009 at 11:17 PM, Craig L Russell craig.russ...@sun.com wrote: 1. It appears that d...@commons is the general mailing list for all commons projects. Would a small project like sanselan get lost in the traffic? That's a problem that every part of Commons has. And another reason, why you could possibly prefer the above place: No doubt, commons-dev is relatively high volume. I am not sure, whether the shared mailing list is the best solution, but I wouldn't like to have that discussion in this context. As already said, it applies to every part and isn't specific to Sanselan. Right. That's my problem with Commons as a whole. By some it is presented as an advantage, but I see it as the opposite. But this is how Commons currently works and I don't see that changing, so if Sanselan went down that road, it would have to live with it. I guess it's mainly Charles (the original author and single active committer) who has to be comfortable with this. 2. Most commons components have a functional name instead of a fun name. Would Sanselan need to be renamed, e.g. Commons Image, or would it be ok to have the sub-project called Sanselan, or Commons Sanselan? IMO, no. I am unaware of an existing example without the commons prefix, but what gives. I guess it would automatically be Commons Sanselan, but it would probably still just be referred to as just Sanselan. I don't think that's so important. 3. Would any changes be required from the existing packaging of Sanselan? For example, packages are named org.apache.sanselan. Would these need to be renamed to org.apache.commons.sanselan (or less fun name as above)? Definitely no. I am not even sure, whether there is *any* existing part of commons with the org.apache.commons prefix. OTOH, I am quite sure that there are lots of examples without. I agree, that shouldn't be necessary. Another package change doesn't feel right. Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Publishing a podling website
Under http://incubator.apache.org/guides/sites.html I can read that the preferred mechanism is to update the podling websites is via SVN. I'm currently preparing the PDFBox website and was surprised to see that not a single podling has put their generated website in a subdirectory under https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/ So my question: Is it ok to put the generated PDFBox website in: https://svn.apache.org/repos/asf/incubator/public/trunk/site-publish/pdfbox ??? Thanks, Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
+1 from me, obviously. On 01.02.2008 15:18:51 Jukka Zitting wrote: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [X] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) Here's my +1 BR, Jukka Zitting snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Karma to commit IP Clearance form
Cameron, the directory for the IP clearance forms seems to be restricted to members, PMC chairs, the apsite group and the incubator projects. You can also just send the XML file to me and I'll handle it. Nevertheless, I think it would make sense to open at least the ip-clearance directory to all committers. That makes it easier for everyone to help with necessary evils like IP clearance. Jeremias Maerki On 20.11.2007 12:32:18 Cameron McCormack wrote: Hi incubator PMC. Could I please have karma to commit an IP clearance form to SVN. Thanks, Cameron (username cam) -- Cameron McCormack, http://mcc.id.au/ xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] PDFBox proposal
Ok, so why not generate XSL-FO and use Apache FOP? You get multiple output formats that way. Only drawback at the moment: No support for automatically sized column-widths in tables. If you interface directly with a PDF library you have to do all the difficult page-breaking yourself. FOP does all that already. Of course, if you have an HTML component (with pagination support) that can paint to Java2D/Graphics2D you can easily use a PDF library with Java2D support directly. Unfortunately, PDFBox doesn't have that, yet, while FOP does. Another example where PDFBox and FOP's PDF library could profit from each other. Jeremias Maerki On 15.11.2007 08:41:19 Janne Jalkanen wrote: How? Just curious. We don't have built-in PDF generation from pages, which is one of the more requested features. Apparently many companies like the ability to create documentation on a wiki, and then dumping it to a PDF for shipping. /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] PDFBox proposal
How? Just curious. Jeremias Maerki On 15.11.2007 06:51:03 Janne Jalkanen wrote: JSPWiki could certainly use it! +1 from me... /Janne On Nov 15, 2007, at 03:08 , Jukka Zitting wrote: Hi, Ben Litchfield, the author of the PDFBox library, has been working with us at the ApacheCon preparing a proposal to bring PDFBox into the Apache Incubator. See http://wiki.apache.org/incubator/PDFBoxProposal for the current draft of the proposal. Some of the details are yet to be worked out, but the general idea is there. All comments and questions are welcome! BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Incubator Proposal: Sanselan - a java image library
(cc'ing [EMAIL PROTECTED] to inform the team, discussion in the incubator, please) Interesting. I've added two additional relationships to the Wiki page: Apache XML Graphics (Batik/FOP) and Apache Harmony. I didn't know about Sanselan, but then we don't really have many open wishes in XML Graphics land with the availability of ImageIO in all but the most exotic environments. What we might profit from is a better way to extract metadata (extents, resolution) from images before actually decoding the image data (while reusing the InputStream). In FOP, we need to know the extents and the resolution of an image for the layout engine. Only during rendering do we need the actual image data either in raw or decoded format, depending on the active output format. Apache Harmony might be interested in additional codecs for the ImageIO API. I would like to see a statement in the proposal about the relationship of Sanselan with ImageIO. Are there plans/ideas to make Sanselan ImageIO-compatible? On 27.07.2007 08:42:32 Carsten Ziegeler wrote: Hi, together with Charles M. Chen I came up with a proposal to move the great open source java image library, Sanselan, to Apache. You'll find all the details here: http://wiki.apache.org/incubator/SanselanProposal Now, currently we are looking for interested parties, especially for mentors and a sponsoring project, perhaps commons would be a good place for sanselan? So if you are interested in this proposal, please add your name to the wiki page (I cc'ed committers to inform all committers, please continue the discussion just in the general incubator list). If anything is missing/unclear etc. let's discuss it :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED] Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Incubator Proposal: Sanselan - a java image library
On 27.07.2007 17:04:41 Yoav Shapira wrote: Hey, On 7/27/07, Carsten Ziegeler [EMAIL PROTECTED] wrote: together with Charles M. Chen I came up with a proposal to move the great open source java image library, Sanselan, to Apache. You'll find all the details here: http://wiki.apache.org/incubator/SanselanProposal Now, currently we are looking for interested parties, especially for mentors and a sponsoring project, perhaps commons would be a good place for sanselan? +1. I like the effort in general, and I'd be willing to help if you need a mentor. BTW, I could also help as mentor but not before October 2007. I also like the effort, but my itch here isn't that big. As for what existing Apache project Sanselan would go into, I'm not sure. Commons is an option, since Sanselan is a component to be used by other applications, not its own stand-alone thing, and image processing is a common requirement. I agree. Commons is probably the best place. The questions about Java ImageIO and/or FOP and/or Batik interactions are interesting, but not critical IMHO. We don't limit ourselves to only one project in one area. It's nice to chat and coordinate where possible, but neither Sanselan nor other projects need to kill themselves to comply with someone else's API. Agreed. I hope my note didn't suggest anything else. I mean FOP could easily work against the Sanselan API instead of ImageIO but generally the usefulness of Sanselan would increase a lot with an ImageIO adapter. A thing I forgot in my first message: The Sanselan page indicates that GIF is supported as well as TIFF with LZW compression. It should be noted that the LZW algorithm [1] has patent issues although in most countries (if not all) the patent has by now expired. If this functionality should be kept I suggest to involve the legal affairs committee. Personally, I'd remove the functionality just out of principle. The German WikiPedia entry [2] mentions that many experts think that decoding only doesn't fall under the patent. Maybe just the encoding capability should be removed. [1] http://en.wikipedia.org/wiki/LZW [2] http://de.wikipedia.org/wiki/Lempel-Ziv-Welch-Algorithmus Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gauging interest for incubating PDFBox...
At ApacheCon last week, I got the impression that quite a few Apache projects (especially the Lucene and XML Graphics communities) have a particular interest in PDFBox, a library for manipulating PDF files (BSD license): http://www.pdfbox.org Ben Litchfield, PDFBox's main author, has contacted the FOP devs about a year ago to find out if there are possibilities to work together more closely. FOP has a PDF library of its own but both projects could gain a few things by eventually merging the PDF functionality. Back then, a few FOP people basically found this a good idea but due to the lack of free resources on both sides this hasn't been pursued, yet. Maybe the itch wasn't hard enough but it's building. So, after hearing PDFBox mentioned many times last week, I thought it might be a good idea to ask around inside a wider area to see how the ASF is potentially interested in adopting PDFBox among its projects. Ben and I exchanged another mail yesterday and and he is still interested in pursuing this idea. I could allocate time for this starting in October 2007. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tika - a content analysis toolkit
non-binding +1 from me. On 18.03.2007 10:51:37 Jukka Zitting wrote: snip/ [ ] +1 Accept Tika as a new podling [ ] -1 Do not accept the new podling (provide reason, please) snip/ Instead of implementing its own document parsers, Tika will use existing parser libraries like Jakarta POI [1] and PDFBox [2]. I would like to make the Tika people aware that we've recently started a little XMP framework as part of the XML Graphics Project. XMP is used with a number of document formats, with PDF its most prominent format. It could be interesting to work together on this. I've also been in contact with Ben Litchfield, author of PDFBox, about possibly joining forces on the topic. However, not much has happened. At the moment, the XMP code can only cover what is necessary to implement the very basics of the PDF/A-1b specification. But I'm sure it can be easily enhanced to fit a wider audience. I already see the need to take the code a step further in order to cover extension schemas that is mandated by the PDF/A-1 standard. Finally, the code doesn't absolutely have to stay within XML Graphics, I guess, but that's only me speaking. Links: http://xmlgraphics.apache.org/commons/ http://svn.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/xmp/ snip/ Jeremias Maerki (watching with interest) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IP CLEARANCE] PostScript DSC parser for XML Graphics Commons
On 27.02.2007 09:38:44 Niclas Hedhman wrote: On Tuesday 27 February 2007 05:01, Jeremias Maerki wrote: I've added a new IP clearance document: https://svn.apache.org/viewvc/incubator/public/trunk/site-publish/ip-cleara nce/xmlgraphics-commons-postscript-dsc-parser.html?view=co (SVN URL for the lack of karma to update the incubator website.) Incubator PMC, please review and get back to me if something's wrong. It looks Ok to me. Perhaps a line of who is the Copyright owner (not only distribution rights) would be better... Done. Maybe that should go in the template if that info is desired. +1 from me otherwise (binding). Cheers Niclas Thanks for the feedback! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IP CLEARANCE] PostScript DSC parser for XML Graphics Commons
I've added a new IP clearance document: https://svn.apache.org/viewvc/incubator/public/trunk/site-publish/ip-clearance/xmlgraphics-commons-postscript-dsc-parser.html?view=co (SVN URL for the lack of karma to update the incubator website.) Incubator PMC, please review and get back to me if something's wrong. Thanks, Jeremias Maerki for the XML Graphics PMC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAXB API target
An alternative would be XML Commons Externals where we already have the whole JAXP and W3C DOM family of APIs. Maybe we should make an inventory of all those APIs on a Wiki page and write down where they are currently located. That should give us a better overall picture. Charging into uncontrolled action might not be the best thing to do. Maintaining APIs also requires some amount of coordination among projects which also means that everybody should know what our idea is. Not everybody is on this list. That said: +1 for a TLP and for consolidating all API efforts in one place. Will be back after a good night's sleep... On 07.06.2006 21:27:30 robert burrell donkin wrote: On 6/7/06, James Strachan [EMAIL PROTECTED] wrote: Am kinda thinking it needs a very different kind of pmc/committer model so a new top level project might be simplest. e.g. any comitter at apache should be pretty much welcome to come in and add a spec or fix any errors in the specs or build system or documentation - as they are generally static and don't change (until a new spec comes along or a spec changes). So its kindof a cross-project project with a low barrier to entry for any apache committer (since no real development happens other than typing in the specs from the javadoc). jakarta already has a low barrier for existing apache committers and has the advantage of no setup overhead (the pmc and lists already exists). might be worth considering kickstarting at jakarta and then look to move it to a top level pmc later. - robert Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP clearance: xmlgraphics-fop-afp-renderer
Approval didn't happen within a reasonable time frame. I'm assuming lazy consensus. We're going to continue with the process. Maybe the requirement to present the IP clearance paper work to the Incubator PMC for approval should be removed again if it doesn't work. I think it's good enough if the stuff is put up on the IP clearance page where everyone can see it. If there's something wrong with it, an intervention is still easily possible. On 20.04.2006 16:41:14 Jeremias Maerki wrote: Incubator PMC, please approve the IP clearance paper work for the contribution called XML Graphics FOP - AFP Renderer which I've recently committed to the Incubator site. Thanks, Jeremias Maerki for the XML Graphics PMC Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IP clearance: xmlgraphics-fop-afp-renderer
Thanks for the feedback, Noel! On 26.04.2006 13:43:41 Noel J. Bergman wrote: please approve the IP clearance paper work for the contribution called XML Graphics FOP - AFP Renderer which I've recently committed to the Incubator site. What you filed seems fine to me. +1 --- Noel Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IP clearance: xmlgraphics-fop-afp-renderer
Incubator PMC, please approve the IP clearance paper work for the contribution called XML Graphics FOP - AFP Renderer which I've recently committed to the Incubator site. Thanks, Jeremias Maerki for the XML Graphics PMC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OFBiz - next steps
Thanks to everyone helping clear up things. What Roy says here would indicate that we wouldn't strictly need the grant for out FOP contribution because the code is already published under the ALv2 and all three people involved have ICLAs on file with the ASF. :-) But I'm sure we can get them to do the additional paperwork. On 08.02.2006 22:12:04 Roy T. Fielding wrote: On Feb 8, 2006, at 10:01 AM, Jim Jagielski wrote: The reason is that the Software Grant is a legal vehicles that says I/We own this software and we are granting it to the ASF. So unless there is a legal entity that owns the code, they cannot grant it to the ASF to allow us to relicense it. yep In that case, each person who ever committed a line of code needs to submit a iCLA which allows their patches (and therefore, once everyone has one on file, the complete codebase) to be relicensed under the AL. Actually, it is only needed from everyone who might own copyright to some part of the work. So, it is those people who have contributed functionality greater than a simple bug fix. OTOH, the mentors should be aware that, because this work is already licensed under BSD terms, there is no LEGAL risk to the foundation if we can't get all the signatures -- those remaining are simply considered reuse of BSD-licensed code. However, we still want the CLAs for social reasons and to confirm that moving the contributions to Apache License is a voluntary act. Also, it reduces the vulnerability of the original OFBiz group if we obtain this permission now, while their contributors are still in the mood. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubation vs. Donating Code to Existing Project
IMO, going through the Incubator is not mandatory. The Xerces PMC could decide to integrate CyberNeko (right?) into Xerces-J as an additional component/feature. If it depends on Xerces-J and is a useful addition to Xerces but has too little mass to lead a life on its own, I'd say it could make a fine addition to Xerces-J. If Xerces chose to adopt CyberNeko the only things that would need to be done are: vote on adoption by the Xerces PMC and go through the IP clearance process. Just my thoughts... On 31.01.2006 19:43:45 Andy Clark wrote: /me removes Zimbra hat. For the past several years, I've wanted to donate my HTML parser code built on Xerces-J to the Xerces project. It is written using the Xerces Native Interface and provides HTML parsing with XML APIs. When I mentioned donating the code to the project, it was suggested that I go through the incubator process. But after getting to know more about the incubator through the Kabuki proposal, I'm not sure if the incubator is appropriate. Here's the deal: I have a piece of code that relies directly on Xerces-J and cannot be used without it. It's a relatively small piece of code so it's not really a full project by itself. And, unlike other projects considered for incubation, there is no community because I have been the sole implementor. So the incubator doesn't seem like the right place for it but that's what the Xerces-J folks have suggested. Thoughts? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: License grant
I went to legal-discuss with this and received a satisfactory answer. Here's the proposed patch to the IP clearance page. If I don't get any negative feedback I'll apply the patch within 48 hours. Index: C:/Dev/apache.org/rw/incubator-public-trunk/site-author/ip-clearance/index.xml === --- C:/Dev/apache.org/rw/incubator-public-trunk/site-author/ip-clearance/index.xml (revision 374837) +++ C:/Dev/apache.org/rw/incubator-public-trunk/site-author/ip-clearance/index.xml (working copy) @@ -36,7 +36,8 @@ /p pThe receiving PMC is responsible for doing the work. The Incubator is simply the repository of the needed information. Once a PMC directly -checks-in a filled-out short form, everything is done. +checks-in a filled-out short form, the Incubator PMC will need to approve the +paper work after which point the receiving PMC is free to import the code. /p pAll PMCs must handle incoming code in this way. Any code that was developed outside of the ASF SVN repository must be processed like @@ -208,6 +209,30 @@ /td /tr /table + section id=notes +titleAdditional notes/title +p + The software grant requires that Licensor owns or has sufficient + rights to contribute the software source code In the case where + there are multiple entities involved that only together have sufficient + rights (for example in the case of an existing external project with + multiple contributors), there are basically two possibilities to continue: +/p +ol + li +All entities sign the same software grant together and submit one software +grant form. This is preferred but obviously can complicate the process +considerably. + /li + li +The alternative is that each party sign its own software grant while +everyone references the same contribution (designated by a URL and an MD5 +hash over the ZIP file representing the contribution). It is recommended +that a comment is added to the software grant form that it is only a part +in the puzzle. + /li +/ol + /section /section /body /document On 01.02.2006 14:09:02 Manuel Mall wrote: On Wednesday 01 February 2006 20:40, Leo Simons wrote: On Wed, Feb 01, 2006 at 08:05:01PM +0800, Manuel Mall wrote: We would like to include a software module currently hosted on SourceForge into the codebase of the Apache FOP project. The developers who wrote the module have indicated their willingness to do so (actually are very keen to do this) and we have their ICLAs. What I don't quite understand is the additional software grant (http://www.apache.org/licenses/#grants) required. 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? I think the answer is that every person from that group sends in the grant paperwork. The legal-discuss mailing list is probably where to query for an authoritive answer. OK, I'll go to legal-discuss with this question. The problem is if I for example would be a contributor to the SourceForge project in question and would get presented with the form I won't be able to sign it (in good conscience) as I individually have not sufficient rights to contribute the software. I think that the receiving PMC is the body responsible for figuring this stuff out, so they should probably be CCed in (sorry, don't know top-of- head which PMC is for FOP). It was a member of the receiving PMC (xmlgraphics) who send me to this mailing list for clarification :-). http://incubator.apache.org/ip-clearance/index.html Is the base URL for incubator-related IP stuff information. cheers, Leo Manuel Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: incubator-altrmi status.xml
I wonder when this is finally going to be hammered into stone somewhere on the Apache website. Sorry, couldn't resist. On 17.02.2003 15:29:41 Aaron Bannert wrote: On Sunday, February 16, 2003, at 07:58 AM, [EMAIL PROTECTED] wrote: Index: BCELProxyGeneratorTestCase.java === /* * Copyright (C) The Apache Software Foundation. All rights reserved. * * This software is published under the terms of the Apache Software License * version 1.1, a copy of which has been included with this distribution in * the LICENSE.txt file. */ Last I heard, we don't allow inclusion of the license by reference, which means someone will have to go into each one of these files and put the full license... Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
