[board-discuss] feedback needed for TDF annual report
Hello, one of the legal requirements of running a foundation is to send in an annual report. In fact, it's two reports: One financial report, which mostly Thorsten takes care of (thanks so much!), and one activity report, which is mostly on my desk at the moment. We need to list all activities we have done, all milestones achieved, and hand that over to the authorities, to show that we have been doing what's outlined in our statutes, and that we were active and not just collected money. ;-) This report is due end of April, and to be in time and have some reserve for changes and translations, the board wants to approve it end of March (!) already. It must be formally approved by the board. I will look at the announce mailing list as well as the blog, but the more material I receive, the better it is. So, today, I would like to ask everyone in the community for feedback: - What major achievements have you done? - What events did you participate in? - Did you get new contributors, donors, supporters? - Did you participate in any third-party projects on behalf of LibreOffice? - What were your highlights of the previous year? In a nutshell: We are about to write a review of our first year as foundation. The good news is, we have been very active. ;-) The report will be public, so please only send in information that is meant for the general public. It does not need to be too technical, so rather than telling we have implemented function XYZ, improved API functions ABC and so on, make it understandable for a wide audience. So we can collect all documents in one place, please send your feedback directly to i...@documentfoundation.org (I am not subscribed to all mailing lists). Images, videos, slides and other materials are highly welcome as well. You would *really* help me a lot if you could send already some written text I can work with, but if that's not possible, some keywords are ok as well. 2012 was an exciting and very successful year for TDF, so let's present this to the public - thank you for your cooperation on this! Thanks a lot! Florian
Re: [tdf-discuss] Scripting for LibreOffice
Hi Keith, On Sat, 2013-03-09 at 16:16 -0800, Keith Curtis wrote: I see how LO is heading in this direction, but you could be explicit about it, create more workitems, There always plenty of work-items and opinions; the only shortage is of people to work on them. Working code speaks far louder than vague wishes for change and E-mails :-) You could get involved in (for example) the FireBird database backend, which we plan to replace the Java hsqldb (for various reasons) or the ongoing Wizards work which is here (which actually uses python): https://bugs.freedesktop.org/show_bug.cgi?id=38820 You may have to support Java for years, but that doesn't mean you should invest in the language. Java is here to stay of course; it's a great way of writing cross-platform extensions. Having said that - what makes you think we're investing significantly in it ? and what does 'invest' mean in the context of a volunteer project ? Ultimately if someone wants to come and improve the Java support they are more than welcome, and we'll help them out / review their patches. Likewise if people want to get stuck into python porting - which has a pragmatic, end-user benefit - and/or helping python be a better quality citizen in our ecosystem - I'm all for that too: bring on the patches ! but you could make a point to recruit new people with Python experience like you do for German speakers. It is also a lot easier of a way to get into the LibreOffice codebase. STL makes my head hurt, Gratuitously irritating some significant segment of our contributors by importing some completely un-necessary and pointlessly dogmatic language-war seems like a particularly self-defeating strategy for success :-) by the time we've carefully driven away everyone except those who use our preferred language: say Haskell - we may notice that we're down to a team of one ;-) I can also imagine a number of new Python extensions that could be bundled by default. Please do write them; then we'll review/merge and bundle them. Real is better than imaginary when it comes to code ;-) so get stuck in ! prove the power of python by writing some fantastic functionality with it. All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
[tdf-discuss] feedback needed for TDF annual report
Hello, one of the legal requirements of running a foundation is to send in an annual report. In fact, it's two reports: One financial report, which mostly Thorsten takes care of (thanks so much!), and one activity report, which is mostly on my desk at the moment. We need to list all activities we have done, all milestones achieved, and hand that over to the authorities, to show that we have been doing what's outlined in our statutes, and that we were active and not just collected money. ;-) This report is due end of April, and to be in time and have some reserve for changes and translations, the board wants to approve it end of March (!) already. It must be formally approved by the board. I will look at the announce mailing list as well as the blog, but the more material I receive, the better it is. So, today, I would like to ask everyone in the community for feedback: - What major achievements have you done? - What events did you participate in? - Did you get new contributors, donors, supporters? - Did you participate in any third-party projects on behalf of LibreOffice? - What were your highlights of the previous year? In a nutshell: We are about to write a review of our first year as foundation. The good news is, we have been very active. ;-) The report will be public, so please only send in information that is meant for the general public. It does not need to be too technical, so rather than telling we have implemented function XYZ, improved API functions ABC and so on, make it understandable for a wide audience. So we can collect all documents in one place, please send your feedback directly to i...@documentfoundation.org (I am not subscribed to all mailing lists). Images, videos, slides and other materials are highly welcome as well. You would *really* help me a lot if you could send already some written text I can work with, but if that's not possible, some keywords are ok as well. 2012 was an exciting and very successful year for TDF, so let's present this to the public - thank you for your cooperation on this! Thanks a lot! Florian -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Dual licensing of patches and code
How could I infer? Because, as I stated, it was *specifically* inferred to other entities who subsequently asked me if I knew the real answer. As such, I specifically asked the 2 controlling bodies of the 2 projects. I rec'd a responses quickly from AOO, but none was coming from LO, and therefore I had to broaden my contact on that end, and was even directed/suggested to do so, which I did. The ASF and AOO have no issue with patches which are dual-licensed (alv2-lgplv3) or triple-licensed (alv2-mpl-lgplv3). They are on records as saying so. I am simply seeing if TDF and LO are just as willing. So far, more time has been spent on bypassing the question than simply answering it. On Mar 10, 2013, at 11:07 AM, Simon Phipps si...@webmink.com wrote: How could you possibly infer from any earlier answer that triple-licensed contributions would be inherently refused? Like Andrew Pitonyak I read exactly the opposite. Florian said that in the sort of theoretical argument you're attempting, code under a triple license is just as acceptable and explained why, just as at Apache, the actual acceptability of any contribution in practical terms is about much more than just the copyright license. I struggle to see how that could be misunderstood, especially by someone I know to be highly intelligent and experienced. S. On Thu, Mar 7, 2013 at 5:42 PM, Jim Jagielski j...@jagunet.com wrote: Just so I'm clear: If a company wishes to contribute code to TDF/LO, but wants their contributions to be triple-licensed (alv2-mpl-lgplv3), they would be refused. Is that correct? If so, what, exactly, is the reason? tia! On Mar 7, 2013, at 9:42 AM, Florian Effenberger flor...@effenberger.org wrote: Hi Jim, Jim Jagielski wrote on 2013-03-06 16:05: I have a patch which is written for LibreOffice. However, I want to provide that patch to LO under both LGPLv3 AND ALv2. Based *solely* on the fact that it is dual-licensed and nothing else, is such a patch acceptable. as our licensing page states, in order to contribute to LibreOffice and be part of our community, we require a dual-license of MPL/LGPLv3+ for contributions, which gives everyone the benefit of the strong rights these licenses grant. From time to time, depending on the specific case and the quality of the code, we may use and merge other licensed pieces of code with compatible licenses. We examine each case, depending on its merits. And this is not a theoretical question. I have been approached by people and companies stating that they wish to help LO but want to provide their code patches also under ALv2 (for internal legal reasons) and have been told that TDF and LO refuses to accept such code/patches/etc *simply* because it is dual/triple/quadruple licensed under the ALv2 In theory, code under a triple license is just as acceptable. In practice, however, TDF has hundreds of affiliated developers working as a team together, doing the actual code review and acceptance work. There is a spectrum of developer opinion on your nurturing of a competing project. Many core developers may be less inclined to invest their time into significant, active assistance: mentoring, reviewing, finding code pointers, merging, back porting, and so on, for functionality that will not provide a distinctive value for LibreOffice. So, while there may be many possible acceptable variations of inbound license and contributions, there are likely relational consequences of those choices that are hard to quantify. Having said that, all developers who want to contribute constructively to LibreOffice are welcome in our community, and we have a high degree of flexibility to fulfill their genuine needs. The best thing to do is just to point them to our developers list. Florian -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Scripting for LibreOffice
I'm with you on the UI design, Keith. The way software looks influences how people perceive its capability, and LO looks like something from the 90's. I like your design because it's attractive, yet leaves the menus in place for those users who can't get into using the ribbon. Now on the idea of removing VBA… I hate VBA, but I'd rather see LO become *more* compatible, rather than ditching it. I want LO to become the product people can switch to, but you close the door on switchers when you reduce compatibility. I can tell you that for sure because of my own recent difficulties fixing a macro so automated data export from SAP will work with LO. Step 1: Get the world to use LO as its Office standard. Step 2: Drop M$ Office compatibility. It's too early to leap into step 2 before we accomplish step 1. Reverse the order, and LO's growth stagnates. -- Charles -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Dual licensing of patches and code
Since you answered a different question and continue to allege your question has not been answered, I will ask again: How could you infer *from any earlier answer* that triple-licensed contributions would be inherently refused as you allege? Like Andrew Pitonyak and Jonathon Blake I read exactly the opposite in the multiple, detailed answers you've received. S. On Mon, Mar 11, 2013 at 1:18 PM, Jim Jagielski j...@jagunet.com wrote: How could I infer? Because, as I stated, it was *specifically* inferred to other entities who subsequently asked me if I knew the real answer. As such, I specifically asked the 2 controlling bodies of the 2 projects. I rec'd a responses quickly from AOO, but none was coming from LO, and therefore I had to broaden my contact on that end, and was even directed/suggested to do so, which I did. The ASF and AOO have no issue with patches which are dual-licensed (alv2-lgplv3) or triple-licensed (alv2-mpl-lgplv3). They are on records as saying so. I am simply seeing if TDF and LO are just as willing. So far, more time has been spent on bypassing the question than simply answering it. On Mar 10, 2013, at 11:07 AM, Simon Phipps si...@webmink.com wrote: How could you possibly infer from any earlier answer that triple-licensed contributions would be inherently refused? Like Andrew Pitonyak I read exactly the opposite. Florian said that in the sort of theoretical argument you're attempting, code under a triple license is just as acceptable and explained why, just as at Apache, the actual acceptability of any contribution in practical terms is about much more than just the copyright license. I struggle to see how that could be misunderstood, especially by someone I know to be highly intelligent and experienced. S. On Thu, Mar 7, 2013 at 5:42 PM, Jim Jagielski j...@jagunet.com wrote: Just so I'm clear: If a company wishes to contribute code to TDF/LO, but wants their contributions to be triple-licensed (alv2-mpl-lgplv3), they would be refused. Is that correct? If so, what, exactly, is the reason? tia! On Mar 7, 2013, at 9:42 AM, Florian Effenberger flor...@effenberger.org wrote: Hi Jim, Jim Jagielski wrote on 2013-03-06 16:05: I have a patch which is written for LibreOffice. However, I want to provide that patch to LO under both LGPLv3 AND ALv2. Based *solely* on the fact that it is dual-licensed and nothing else, is such a patch acceptable. as our licensing page states, in order to contribute to LibreOffice and be part of our community, we require a dual-license of MPL/LGPLv3+ for contributions, which gives everyone the benefit of the strong rights these licenses grant. From time to time, depending on the specific case and the quality of the code, we may use and merge other licensed pieces of code with compatible licenses. We examine each case, depending on its merits. And this is not a theoretical question. I have been approached by people and companies stating that they wish to help LO but want to provide their code patches also under ALv2 (for internal legal reasons) and have been told that TDF and LO refuses to accept such code/patches/etc *simply* because it is dual/triple/quadruple licensed under the ALv2 In theory, code under a triple license is just as acceptable. In practice, however, TDF has hundreds of affiliated developers working as a team together, doing the actual code review and acceptance work. There is a spectrum of developer opinion on your nurturing of a competing project. Many core developers may be less inclined to invest their time into significant, active assistance: mentoring, reviewing, finding code pointers, merging, back porting, and so on, for functionality that will not provide a distinctive value for LibreOffice. So, while there may be many possible acceptable variations of inbound license and contributions, there are likely relational consequences of those choices that are hard to quantify. Having said that, all developers who want to contribute constructively to LibreOffice are welcome in our community, and we have a high degree of flexibility to fulfill their genuine needs. The best thing to do is just to point them to our developers list. Florian -- *Simon Phipps* http://webmink.com *Meshed Insights Knowledge * *Office:* +1 (415) 683-7660 *or* +44 (238) 098 7027 *Mobile*: +44 774 776 2816* * -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Scripting for LibreOffice
Hi; On Mon, Mar 11, 2013 at 3:43 AM, Michael Meeks michael.me...@suse.com wrote: Hi Keith, On Sat, 2013-03-09 at 16:16 -0800, Keith Curtis wrote: I see how LO is heading in this direction, but you could be explicit about it, create more workitems, There always plenty of work-items and opinions; the only shortage is of people to work on them. Working code speaks far louder than vague wishes for change and E-mails :-) I know there are plenty of workitems. Fortunately your team is growing, with new people showing up looking for discrete, easy to get into, interesting and important tasks. Right now, it seems there is less than one Python person. Perhaps it is because there are just one or two Python Easy Hacks, and not much of a group focus yet like was done with uncalled functions. With effort to improve this aspect of your community, you could noticeably polish / improve the product a lot over time, with each volunteer generally more productive per hour. You may have to support Java for years, but that doesn't mean you should invest in the language. Java is here to stay of course; it's a great way of writing cross-platform extensions. Having said that - what makes you think we're investing significantly in it ? and what does 'invest' mean in the context of a volunteer project ? Java is a fine language for some of your enterprise, etc. customers, but it is not nearly as popular or respected in the Linux desktop hacker community, who LibreOffice are recruiting many from. As one piece of evidence, there doesn't seem to be anyone improving the Java code today. Ultimately if someone wants to come and improve the Java support they are more than welcome, and we'll help them out / review their patches. Likewise if people want to get stuck into python porting - which has a pragmatic, end-user benefit - and/or helping python be a better quality citizen in our ecosystem - I'm all for that too: bring on the patches ! That is great to hear you want Python patches, but requests on this alias will not be as effective a recruitment tool. but you could make a point to recruit new people with Python experience like you do for German speakers. It is also a lot easier of a way to get into the LibreOffice codebase. STL makes my head hurt, Gratuitously irritating some significant segment of our contributors by importing some completely un-necessary and pointlessly dogmatic language-war seems like a particularly self-defeating strategy for success :-) I think some of your contributors might be too sensitive ;-) The point I was trying to get at is that C++ is a complicated language, and Python is a growing and fun language, and yet there is not too much of a Python dev team. I don't mean to irritate, so it is best to focus on anything I write that might be useful and be happy for it ;-) by the time we've carefully driven away everyone except those who use our preferred language: say Haskell - we may notice that we're down to a team of one ;-) If someone wants to support Haskell for some of your users, that is great and you've got a bunch of UNO code that could be easily changed. However, I wouldn't recommend volunteers writing a bunch of wizards in it that LibreOffice would have to maintain, etc. It isn't about personal preferences, but about community. Python is not popular to many regular computer users, but their community is massive and has an incredible amount of free code with libraries like: http://nltk.org/, http://www.sagemath.org/, http://scipy.org/Topical_Software. Other languages have good free libraries as well, and I don't want to devolve into a language war here but given you already ship with a Python interpreter, etc., efforts to get people could be valuable for your next 2.5 years. I can also imagine a number of new Python extensions that could be bundled by default. Please do write them; then we'll review/merge and bundle them. Real is better than imaginary when it comes to code ;-) so get stuck in ! prove the power of python by writing some fantastic functionality with it. The point isn't about my patches, but about your community. That is why I wrote to the discuss alias. It shouldn't be necessary to prove the power of Python anymore, in LibreOffice alone, the Lightproof grammar checker has already done that. In any case, you are supportive already, so it would be great if more were with you. Warm regards, -Keith -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Dual licensing of patches and code
exhaustively, yes, but not concretely. The exhaustive reply boils down to it depends, which is really no answer at all. Furthermore, it implies that the simply inclusion of the alv2 as part of the license suite *does* change the dynamic, since something provided under mpl-lgplv3 as not handed the same way it depends... Furthermore it does not describe the actual mechanism. I will be blunt: it certainly *appears* that all this hand waving is being done to be able to accept code when it is beneficial to LO only, and not accept code when it is beneficial to LO *and* AOO, as code under alv2-mpl-lgplv3 would be, except for small code patches and fixes that have no real value. Such a it depends policy allows this, and this is the core of the question. The people who contacted me specifically wanted to provide code to LO, that merged with LO w/ no conflicts, would require extensive re-work to be folded into AOO, but would be licensed under the alv2 and were told that the inclusion of the alv2 as the license of the donation was unacceptable. When asked if dual or triple licensing was acceptable, they were told No. To them, it appeared that the *mere possibility* that it could be used by AOO, even though their people are being paid to work on LO, was enough to prevent their work being even considered. Will the ASF and AOO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is yes. Will the TDF and LO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is it depends... the logical assumption regarding WHY is not-complimentary to TDF and LO, nor is it beneficial to the OO ecosystem itself, nor is the policy defined enough that code providers know what to do. On Mar 11, 2013, at 6:55 AM, Thorsten Behrens t...@documentfoundation.org wrote: Jim Jagielski wrote: Bjoern Michaelsen bjoern.michael...@canonical.com wrote: That was not what either Florian or the policy said. This is a matter of community, not just of license. Such combinations of licenses do not lead to a contribution being automatically accepted or rejected, either at Apache or at TDF, we look at each case on its merits. That is true, and I, of course, understand that. The question is whether such a triple-licensed patch would be rejected *regardless* of technical merit, and that is a valid question to ask. Hi Jim, Florian answered that exhaustively in his earlier email: On Mar 7, 2013, Florian Effenberger wrote: as our licensing page states, in order to contribute to LibreOffice and be part of our community, we require a dual-license of MPL/LGPLv3+ for contributions, which gives everyone the benefit of the strong rights these licenses grant. From time to time, depending on the specific case and the quality of the code, we may use and merge other licensed pieces of code with compatible licenses. We examine each case, depending on its merits. In theory, code under a triple license is just as acceptable. In practice, however, TDF has hundreds of affiliated developers working as a team together, doing the actual code review and acceptance work. There is a spectrum of developer opinion on your nurturing of a competing project. Many core developers may be less inclined to invest their time into significant, active assistance: mentoring, reviewing, finding code pointers, merging, back porting, and so on, for functionality that will not provide a distinctive value for LibreOffice. So, while there may be many possible acceptable variations of inbound license and contributions, there are likely relational consequences of those choices that are hard to quantify. Having said that, all developers who want to contribute constructively to LibreOffice are welcome in our community, and we have a high degree of flexibility to fulfill their genuine needs. The best thing to do is just to point them to our developers list. Jim Jagielski wrote: Unfortunately, I am not at liberty to divulge the identity of the contacts, but that should not matter. I understand, but in general we like to work directly with those contributing the code, rather than dealing in hypotheticals. With kind regards, -- Thorsten -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Dual licensing of patches and code
On Mon, Mar 11, 2013 at 1:35 PM, Jim Jagielski j...@jagunet.com wrote: exhaustively, yes, but not concretely. The exhaustive reply boils down to it depends, which is really no answer at all. Furthermore, it implies that the simply inclusion of the alv2 as part of the license suite *does* change the dynamic, since something provided under mpl-lgplv3 as not handed the same way it depends... Furthermore it does not describe the actual mechanism. On the contrary, the answer to your original question was clearly that the inclusion of ALv2 in the licensing of a contribution does not per se prevent it being used. You have then been given a more detailed response than appears to have come from the AOO PMC: that licensing alone is not sufficient for an open source project to accept any given contribution. I don't understand why you continue to agitate and accuse. S. -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Scripting for LibreOffice
On Mon, Mar 11, 2013 at 6:23 AM, Charles Jenkins cejw...@gmail.com wrote: I'm with you on the UI design, Keith. The way software looks influences how people perceive its capability, and LO looks like something from the 90's. I like your design because it's attractive, yet leaves the menus in place for those users who can't get into using the ribbon. Now on the idea of removing VBA… I hate VBA, but I'd rather see LO become *more* compatible, rather than ditching it. I want LO to become the product people can switch to, but you close the door on switchers when you reduce compatibility. I can tell you that for sure because of my own recent difficulties fixing a macro so automated data export from SAP will work with LO. Step 1: Get the world to use LO as its Office standard. Step 2: Drop M$ Office compatibility. I agree that improving VBA compatibility would be helpful, my point was about extensions written by volunteers. Regards, -Keith -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Dual licensing of patches and code
Hello Jim, There's something quite wrong in this conversation. Some entity -a corporation or a government- has approached you and asked you questions on how to contribute to LibreOffice (by the way, please be so kind as using the term LibreOffice and not LO). As the Chairman of the Apache Software Foundation the useful and effective thing to do is to point this entity directly at the Document Foundation. It is not up to the ASF to speak on behalf of the Document Foundation, but you obviously know this as you came here to ask your question on this mailing list and I thank you for doing so. At this stage let me reiterate that if this entity you have mentioned repeatedly has questions about possible contributions to LibreOffice, these should be directed to the Document Foundation and not to any other foundation. For the record, the Document Foundation has not been contacted (privately or publicly) by anyone but you with respect to a triple licensing scheme for contributing to LibreOffice. Best regards, -- Charles-H. Schulz Co-founder Director, The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint Mobile Number: +33 (0)6 98 65 54 24. Le Mon, 11 Mar 2013 09:35:08 -0400, Jim Jagielski j...@jagunet.com a écrit : exhaustively, yes, but not concretely. The exhaustive reply boils down to it depends, which is really no answer at all. Furthermore, it implies that the simply inclusion of the alv2 as part of the license suite *does* change the dynamic, since something provided under mpl-lgplv3 as not handed the same way it depends... Furthermore it does not describe the actual mechanism. I will be blunt: it certainly *appears* that all this hand waving is being done to be able to accept code when it is beneficial to LO only, and not accept code when it is beneficial to LO *and* AOO, as code under alv2-mpl-lgplv3 would be, except for small code patches and fixes that have no real value. Such a it depends policy allows this, and this is the core of the question. The people who contacted me specifically wanted to provide code to LO, that merged with LO w/ no conflicts, would require extensive re-work to be folded into AOO, but would be licensed under the alv2 and were told that the inclusion of the alv2 as the license of the donation was unacceptable. When asked if dual or triple licensing was acceptable, they were told No. To them, it appeared that the *mere possibility* that it could be used by AOO, even though their people are being paid to work on LO, was enough to prevent their work being even considered. Will the ASF and AOO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is yes. Will the TDF and LO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is it depends... the logical assumption regarding WHY is not-complimentary to TDF and LO, nor is it beneficial to the OO ecosystem itself, nor is the policy defined enough that code providers know what to do. On Mar 11, 2013, at 6:55 AM, Thorsten Behrens t...@documentfoundation.org wrote: Jim Jagielski wrote: Bjoern Michaelsen bjoern.michael...@canonical.com wrote: That was not what either Florian or the policy said. This is a matter of community, not just of license. Such combinations of licenses do not lead to a contribution being automatically accepted or rejected, either at Apache or at TDF, we look at each case on its merits. That is true, and I, of course, understand that. The question is whether such a triple-licensed patch would be rejected *regardless* of technical merit, and that is a valid question to ask. Hi Jim, Florian answered that exhaustively in his earlier email: On Mar 7, 2013, Florian Effenberger wrote: as our licensing page states, in order to contribute to LibreOffice and be part of our community, we require a dual-license of MPL/LGPLv3+ for contributions, which gives everyone the benefit of the strong rights these licenses grant. From time to time, depending on the specific case and the quality of the code, we may use and merge other licensed pieces of code with compatible licenses. We examine each case, depending on its merits. In theory, code under a triple license is just as acceptable. In practice, however, TDF has hundreds of affiliated developers working as a team together, doing the actual code review and acceptance work. There is a spectrum of developer opinion on your nurturing of a competing project. Many core developers may be less inclined to invest their time into significant, active assistance: mentoring, reviewing, finding code pointers, merging, back porting, and so on, for functionality that will not provide a distinctive value for LibreOffice. So, while there may be many possible acceptable
Re: [tdf-discuss] Dual licensing of patches and code
As stated, they contacted me because they had been told that such licensing was not accepted to BOTH parties, not just one. This should have been clear from my 1st post. That is why I asked both parties. On Mar 11, 2013, at 10:25 AM, Charles-H. Schulz charles.sch...@documentfoundation.org wrote: Hello Jim, There's something quite wrong in this conversation. Some entity -a corporation or a government- has approached you and asked you questions on how to contribute to LibreOffice (by the way, please be so kind as using the term LibreOffice and not LO). As the Chairman of the Apache Software Foundation the useful and effective thing to do is to point this entity directly at the Document Foundation. It is not up to the ASF to speak on behalf of the Document Foundation, but you obviously know this as you came here to ask your question on this mailing list and I thank you for doing so. At this stage let me reiterate that if this entity you have mentioned repeatedly has questions about possible contributions to LibreOffice, these should be directed to the Document Foundation and not to any other foundation. For the record, the Document Foundation has not been contacted (privately or publicly) by anyone but you with respect to a triple licensing scheme for contributing to LibreOffice. Best regards, -- Charles-H. Schulz Co-founder Director, The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint Mobile Number: +33 (0)6 98 65 54 24. Le Mon, 11 Mar 2013 09:35:08 -0400, Jim Jagielski j...@jagunet.com a écrit : exhaustively, yes, but not concretely. The exhaustive reply boils down to it depends, which is really no answer at all. Furthermore, it implies that the simply inclusion of the alv2 as part of the license suite *does* change the dynamic, since something provided under mpl-lgplv3 as not handed the same way it depends... Furthermore it does not describe the actual mechanism. I will be blunt: it certainly *appears* that all this hand waving is being done to be able to accept code when it is beneficial to LO only, and not accept code when it is beneficial to LO *and* AOO, as code under alv2-mpl-lgplv3 would be, except for small code patches and fixes that have no real value. Such a it depends policy allows this, and this is the core of the question. The people who contacted me specifically wanted to provide code to LO, that merged with LO w/ no conflicts, would require extensive re-work to be folded into AOO, but would be licensed under the alv2 and were told that the inclusion of the alv2 as the license of the donation was unacceptable. When asked if dual or triple licensing was acceptable, they were told No. To them, it appeared that the *mere possibility* that it could be used by AOO, even though their people are being paid to work on LO, was enough to prevent their work being even considered. Will the ASF and AOO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is yes. Will the TDF and LO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is it depends... the logical assumption regarding WHY is not-complimentary to TDF and LO, nor is it beneficial to the OO ecosystem itself, nor is the policy defined enough that code providers know what to do. On Mar 11, 2013, at 6:55 AM, Thorsten Behrens t...@documentfoundation.org wrote: Jim Jagielski wrote: Bjoern Michaelsen bjoern.michael...@canonical.com wrote: That was not what either Florian or the policy said. This is a matter of community, not just of license. Such combinations of licenses do not lead to a contribution being automatically accepted or rejected, either at Apache or at TDF, we look at each case on its merits. That is true, and I, of course, understand that. The question is whether such a triple-licensed patch would be rejected *regardless* of technical merit, and that is a valid question to ask. Hi Jim, Florian answered that exhaustively in his earlier email: On Mar 7, 2013, Florian Effenberger wrote: as our licensing page states, in order to contribute to LibreOffice and be part of our community, we require a dual-license of MPL/LGPLv3+ for contributions, which gives everyone the benefit of the strong rights these licenses grant. From time to time, depending on the specific case and the quality of the code, we may use and merge other licensed pieces of code with compatible licenses. We examine each case, depending on its merits. In theory, code under a triple license is just as acceptable. In practice, however, TDF has hundreds of affiliated developers working as a team together, doing the actual code review and acceptance work. There is a spectrum of developer opinion on your nurturing of a competing project. Many core
Re: [tdf-discuss] Dual licensing of patches and code
Jim, I do not know who made these assertions to this entity, however it is really important to understand that it was not the Document Foundation. We have never been in contact with such parties. Let me stress again that it is necessary for this entity to contact us directly. Thanks, Charles. Le Mon, 11 Mar 2013 10:38:44 -0400, Jim Jagielski j...@jagunet.com a écrit : As stated, they contacted me because they had been told that such licensing was not accepted to BOTH parties, not just one. This should have been clear from my 1st post. That is why I asked both parties. On Mar 11, 2013, at 10:25 AM, Charles-H. Schulz charles.sch...@documentfoundation.org wrote: Hello Jim, There's something quite wrong in this conversation. Some entity -a corporation or a government- has approached you and asked you questions on how to contribute to LibreOffice (by the way, please be so kind as using the term LibreOffice and not LO). As the Chairman of the Apache Software Foundation the useful and effective thing to do is to point this entity directly at the Document Foundation. It is not up to the ASF to speak on behalf of the Document Foundation, but you obviously know this as you came here to ask your question on this mailing list and I thank you for doing so. At this stage let me reiterate that if this entity you have mentioned repeatedly has questions about possible contributions to LibreOffice, these should be directed to the Document Foundation and not to any other foundation. For the record, the Document Foundation has not been contacted (privately or publicly) by anyone but you with respect to a triple licensing scheme for contributing to LibreOffice. Best regards, -- Charles-H. Schulz Co-founder Director, The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany Rechtsfähige Stiftung des bürgerlichen Rechts Legal details: http://www.documentfoundation.org/imprint Mobile Number: +33 (0)6 98 65 54 24. Le Mon, 11 Mar 2013 09:35:08 -0400, Jim Jagielski j...@jagunet.com a écrit : exhaustively, yes, but not concretely. The exhaustive reply boils down to it depends, which is really no answer at all. Furthermore, it implies that the simply inclusion of the alv2 as part of the license suite *does* change the dynamic, since something provided under mpl-lgplv3 as not handed the same way it depends... Furthermore it does not describe the actual mechanism. I will be blunt: it certainly *appears* that all this hand waving is being done to be able to accept code when it is beneficial to LO only, and not accept code when it is beneficial to LO *and* AOO, as code under alv2-mpl-lgplv3 would be, except for small code patches and fixes that have no real value. Such a it depends policy allows this, and this is the core of the question. The people who contacted me specifically wanted to provide code to LO, that merged with LO w/ no conflicts, would require extensive re-work to be folded into AOO, but would be licensed under the alv2 and were told that the inclusion of the alv2 as the license of the donation was unacceptable. When asked if dual or triple licensing was acceptable, they were told No. To them, it appeared that the *mere possibility* that it could be used by AOO, even though their people are being paid to work on LO, was enough to prevent their work being even considered. Will the ASF and AOO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is yes. Will the TDF and LO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is it depends... the logical assumption regarding WHY is not-complimentary to TDF and LO, nor is it beneficial to the OO ecosystem itself, nor is the policy defined enough that code providers know what to do. On Mar 11, 2013, at 6:55 AM, Thorsten Behrens t...@documentfoundation.org wrote: Jim Jagielski wrote: Bjoern Michaelsen bjoern.michael...@canonical.com wrote: That was not what either Florian or the policy said. This is a matter of community, not just of license. Such combinations of licenses do not lead to a contribution being automatically accepted or rejected, either at Apache or at TDF, we look at each case on its merits. That is true, and I, of course, understand that. The question is whether such a triple-licensed patch would be rejected *regardless* of technical merit, and that is a valid question to ask. Hi Jim, Florian answered that exhaustively in his earlier email: On Mar 7, 2013, Florian Effenberger wrote: as our licensing page states, in order to contribute to LibreOffice and be part of our community, we require a dual-license of MPL/LGPLv3+ for contributions, which gives everyone the benefit of the strong rights these licenses grant. From time to time, depending on
Re: [tdf-discuss] Macro Difficulties
I'm making some progress. Here's my code so far: == Public Sub OpenExcelFile(excelPath As String) Attempt1: on error goto Fail1 ' snip The Excel method that doesn't work ' under LO, and which I don't own copyright to exit sub Fail1: resume Attempt2 Attempt2: dim starDesktop as object dim url as string dim doc as object dim dummy() ' Empty array of parameters starDesktop = createUnoService(com.sun.star.frame.Desktop) url = ConvertToUrl( ExcelPath ) doc = starDesktop.loadComponentFromURL( url, _blank, 0, dummy ) End Sub == The problem is, since the file output by SAP ends with the .txt extension, Calc opens the new file as a Writer document, not a spreadsheet. I think I need what is described in http://knowledgebase.progress.com/articles/Article/P147655 -- an extension that can wrap strings into the property values required by loadComponentFromUrl(), so I can fill the array of parameters in a way that tells LO it will be loading the text file into a spreadsheet. Does anyone out there happen to have experience with such an extension, or know how to get the open-source code for something similar? (The LO Extensions site has a CSV-opening extension, but I'd have to modify it to remove the UI, and there's no indication at all of how to get the source!) -- Charles -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
[tdf-discuss] Google Summer of Code 2013
Hello, There is one week left to the deadline to apply for GSoC 2013 http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Are there any plans to send an application for TDF and LibreOffice ? Immanuel -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Google Summer of Code 2013
Hi Immanuel, On 11/03/2013 16:13, Immanuel Giulea wrote: Hello, There is one week left to the deadline to apply for GSoC 2013 http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Are there any plans to send an application for TDF and LibreOffice ? Information can be found here https://wiki.documentfoundation.org/Development/GSoc This is usually managed by Cédric and Fridrich Kind regards Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org Tel:+33683901545 Membership Certification Committee Member - Co-founder The Document Foundation -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Macro Difficulties
Hi Charles, *, On Mon, Mar 11, 2013 at 3:55 PM, Charles Jenkins cejw...@gmail.com wrote: dim dummy() ' Empty array of parameters starDesktop = createUnoService(com.sun.star.frame.Desktop) url = ConvertToUrl( ExcelPath ) doc = starDesktop.loadComponentFromURL( url, _blank, 0, dummy ) I think I need what is described in http://knowledgebase.progress.com/articles/Article/P147655 -- an extension that can wrap strings into the property values required by loadComponentFromUrl(), so I can fill the array of parameters in a way that tells LO it will be loading the text file into a spreadsheet. The extension just is a helper function for pretty-printing, you surely don't need that, but can enter the values right away. Dim args() as new com.sun.star.beans.PropertyValue args(0).Name = FilterName args(0).Value = Text - txt - csv (StarCalc) args(1).Name = FilterOptions args(1).Value = yourfilteroptionsstring http://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Filter_Options#Filter_Options_for_the_CSV_Filter HTH, ciao Christian -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Scripting for LibreOffice
While working on my wiki page about a new Writer toolbar, I realized that independently of my proposal, I believe it makes sense for LibreOffice to prefer Python. I see how LO is heading in this direction, but you could be explicit about it, create more workitems, perhaps track it like you do the German comments and uncalled functions, etc. It could also be helpful to have a handbook for PyUno... ;-) The point is that a *lot* of users of Python (and there are bulkloads out there) are non-developers who don't give a darn for Java or VBA (because those don't provide what these users need) and who might have never even learned C++. So without specific documentation they're essentially stalled, while with a handbook, you could get a lot of helpers to implement additions in Python. Looks like a classic multiplier situation to me. You may have to support Java for years, but that doesn't mean you should invest in the language. I wrote almost an entire chapter in my book about some of the biggest problems with it (http://keithcu.com/wordpress/?page_id=2228). Java is not a scripting language. It was *deliberately* designed and implemented to make interfacing with anything outside the Java runtime environment as difficult as possible (sandboxing). And interfacing easily with anything that has an API is *the* very purpose of a scripting language. Besides, it doesn't offer an interactive commandline interpreter, so you can't really use it for actual scripting anyway. VBA (or the LO/OO dialect of it) is entirely irrelevant outside the locked-up MS world anyway, and especially in the FOSS world. Sincerely, Wolfgang -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Experimental UI for LibreOffice proposal
I'm working on a proposal for building an experimental new LibreOffice toolbar / UI in Python: https://wiki.documentfoundation.org/User:KeithCu Err, I would like to point out the fact that trying to emulate MS in any way is always a B-A-D idea. Especially, but not limited to GUI ergonomics, where MS has been consistently been implementing things exactly the wrong way, from the perspective of the proficient user who knows also something else than MS. Your idea of a ribbon turned into a sidebar by 90° rotation imho is nothing else than the revival of the old (pre-Windows) Lotus 1-2-3 menu system. Pulldown-menus (and dialog boxes) are a far more advanced concept. Besides the issues with screenspace. A concept that could be a *lot* more useful imho would be to allow tearing off individual (sub-)menus and placing them as floating (or docked if the user prefers that) toolboxes next to the workspace. See typical graphics software or e.g. RagTime. When I was working in RagTime (or FrameMaker, but that was more than a decade ago), all I had on-screen besides the document itself and the pull-down menubar above were the listboxes with character and paragraph styles and very few other floating palettes. Sincerely, Wolfgang -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Dual licensing of patches and code
On Mon, Mar 11, 2013 at 7:46 AM, Charles-H. Schulz charles.sch...@documentfoundation.org wrote: Jim, I do not know who made these assertions to this entity, however it is really important to understand that it was not the Document Foundation. We have never been in contact with such parties. Let me stress again that it is necessary for this entity to contact us directly. It's beginning to be clearer and clearer that the entity does not wish to be named as I think at least 10-15 times in this thread the information has been requested but has subtly been ignored by the OP. IMO (just to be clear to OP - I do not speak on behalf of the TDF as a whole) the thread should be closed at this point in time as we're up to 30 posts with a circular pattern - OP requests information about hypothetical contributor under dual or tri license, TDF requests potential contributors to contact TDF directly, OP goes back to requesting information. The whole thread seems quite strange to me as there appears to be an effort to hide who is actually thinking of contributing. Best, Joel -- *Joel Madero* LibreOffice QA Volunteer jmadero@gmail.com -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Install path for LibreOffice under Windows
On Mon, Mar 4, 2013 at 4:45 PM, Pedro pedl...@gmail.com wrote: So my question is: is there any reason that LibreOffice under Windows does not install to \LibreOffice\? Not really. AFAIK it is just a legacy setting. Default install location can be changed either from installer UI, or by the INSTALLLOCATION property from the msiexec's command line. All settings, registry keys etc. will accommodate automatically. Migration of extensions is a different issue, I'm not an expert of that. Best regards, Andras -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
