Re: [CODE] gmake and AOO build system
On Tue, Oct 9, 2012 at 6:27 AM, Andre Fischer awf@gmail.com wrote: re 2: This looks like a serious problem. Without understanding the goal of these changes, it is hard to come up with a fix. ause130 migrated udkapi to gbuild... looks like you picked up udpaki: empty d.list by Michaerl Stahl without picking up the patches that actually do the migration to gbuild: ause130: #i117218# * (4 patches by Hans-Joachim Lankenau) Norbert
Re: Next steps for Symphony and AOO
On Tue, Jun 12, 2012 at 1:38 PM, Rob Weir robw...@apache.org wrote: (That is the essentially lie of copyleft, IMHO. The GPL just forces one to disclose the code. It does not force anyone to actively share, integrate, work through issues, etc.). 1/ Are you publishing this under GPL ? if not, then what is the relevance of that remark ? 2/ If that code had been developed under a coplyleft regime then you would not be dumping multiple year of fix + improvement in one big dump. Incremental changes are easier to assimilate. Norbert
Re: Legal question about (re)licensing
On Tue, May 1, 2012 at 11:48 AM, Rob Weir robw...@apache.org wrote: We accept relatively small contributions without an ICLA. But all contributions get reviewed, and all releases go through scans (what we call RAT == Release Audit Tool) and are voted on in a transparent, open process. RAT does not help you track to provenance of patches applied to existing files. RAT only check that a correct/compatible license is claimed, not that it is true. For larger contributions, an ICLA (or an SGA) is in order. Ditto for smaller ones, if there are questions/concerns. Remember, any committer can veto a patch. So incoming patches without an ICLA need to meet a high bar to get into the code. My default posture would be to veto any patch more than 10 lines long that does not come with an iCLA. really? so why didn't you veto r1182539, for example ? Norbert
Re: Legal question about (re)licensing
On Tue, May 1, 2012 at 2:10 PM, Pedro Giffuni p...@apache.org wrote: On 05/01/12 12:20, Norbert Thiebaud wrote: ... For larger contributions, an ICLA (or an SGA) is in order. Ditto for smaller ones, if there are questions/concerns. Remember, any committer can veto a patch. So incoming patches without an ICLA need to meet a high bar to get into the code. My default posture would be to veto any patch more than 10 lines long that does not come with an iCLA. really? so why didn't you veto r1182539, for example ? I committed it so I will answer what is my personal position on this. The patches were submitted to Oracle which provided the bugzilla dump to us. At the time the patches were committed, the codebase was under LGPLv3. The license for the code headers were later changed by Oracle in hands of Andrew Rist. Nice ex-post facto rationalization... so lets take r1226336 where you pushed code that was not yours _after_ the AL2 re-license of the base by Andrew... In any case, the point is that Rob's claim that My default posture would be to veto any patch more than 10 lines long that does not come with an iCLA. does not seems to be enforced in practice. As for review... I have yet to see any questions from reviewers, mentors or ppmc members, to clarify the provenances of these sort of patches nor the licensing ground behind them. In all this process, people that have submitted patches were notified through bugzilla that we were integrating the code and one person even went ahead and requested his patch were reverted (and I did it despite considering the patch was not copyrightable). yeah that was r1195527 - which met Rob's 10 lines threshold - and yet he did not veto it. in fact it only got reverted (r1198909) because the author noticed and complained. So the process is to add code, and wait for the original author to complain... if he doesn't complain before the release, then it is deemed to have met the rigorous IP scrutiny that Rob tout ? Norbert PS: the specific svn revisions here are not the central point, the point is the lack of any discussion/scrutiny on any of these followed by the self-fulfilling prophecy: To be released the code must be clean. Releasing imply a detailed IP review (RAT was run), so surely if the release was approved by a vote then the release _is_ IP clean, and therefore if it is released then it is clean. Rob's 'holier than thou' public attitude on the topic remind me of the old saying: People who live in glass houses shouldn't throw stones.
Re: Legal question about (re)licensing
On Tue, May 1, 2012 at 11:23 PM, Pedro Giffuni p...@apache.org wrote: I think you are just trying to find some silly excuse to complain about code that *you* clearly didn't write or own. All the code either from version control or bugzilla was provided by Oracle That is not what was said in the ooo-dev list http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201204.mbox/%3CCAKQbXgCF0b8qtXkF1C_Yryx=EXfww4gX=-+vfkv15k_nnme...@mail.gmail.com%3E clearly your assumption that the SGA extend to everything that one can put his hands on does not seems supported by the document itself. At the very least there are serious doubt as to the extent the SGA cover CWSs and/or random patch from bugzilla that had not been integrated into the project prior to the grant. But to my point: there are questions about the extent of the scope of the SGA, question that have been brushed-off with a 'let's cross-that-bridge-when-we-get-there' to avoid addressing the complex 'general statement'. Fine, but thn one would expect the actual applied instance of this general problem to be at least discussed and resolved with the copyright owner(s) no such things occurred, at least not on publicly accessible mailing-list. Norbert
Re: Question related derivative code based on our Apache licensed code
On Mon, Jan 16, 2012 at 9:28 AM, Pedro Giffuni p...@apache.org wrote: It is really nice because in this project we don't request silly licensing statements. We assume people are not stupid enough to send us code that we can't use. oh really ? Is that Apache's position that any code than end-up in an Apache Mailing list is 'assumed' to be under AL2 ? Norbert
Re: Time for the ASF to send an Open Letter?
On Sat, Dec 17, 2011 at 6:38 PM, Pedro Giffuni p...@apache.org wrote: --- Sab 17/12/11, Michael Meeks ha scritto: Sure - if it is easier for us to include an existing feature, under an acceptable license into LibreOffice why would we bother re-writing it ? conversely if it is easier to re-write, why not ? And it's usually so much easier to take. Steve jobs had a famous quote about that that I don't remember very well ;-). http://svn.apache.org/viewvc?view=revisionrevision=1208206 an English proverb about stone and glass house comes to mind... Norbert
Re: Neutral / shared security list ...
On Tue, Oct 25, 2011 at 2:29 PM, Dave Fisher dave2w...@comcast.net wrote: If there is a meta-list for security for all of the peers in the OOo / LO and the rest community. This is some confederation that shares security issues in a private manner between peers. The peers have the mutual interest of their communities in mind. I think that i the best concise summary of the only relevant issue on this topic. Norbert
Re: working on a OpenOffice roadmap
On Tue, Oct 25, 2011 at 6:41 AM, Rob Weir robw...@apache.org wrote: On Tue, Oct 25, 2011 at 6:28 AM, Simon Phipps si...@webmink.com wrote: On Mon, Oct 24, 2011 at 8:20 PM, Pedro Giffuni p...@apache.org wrote: If libreoffice encourages, but not requires, AL2 for stuff in the core package, that would be a huge advance to get a bit nearer both camps. Given licenses are the expression of the ethos of a community, it's LO had no choice but to take LGPL. So more necessity/inertia than ethos. And -- according to Michael -- when it thought that MPL might be more acceptable TDF was quick to add MPL for new code contributions. This shows an ethos of flexibility. And look how well it has served us. Despite that very large concession, IBM still snubbed it and 9 month later started a new fork. You give a hand, it want the whole body... This is a good thing. Only in others right ? Do as I say not as I do... [ snip trolling ] disingenuous and divisive to assume any community will drop its governance approach like this, Pedro. It translates as the path to collaboration is your surrender; we can negotiate once you've done that. You make it sound This is obviously a touchy subject for you, Simon. But please read what Pedro wrote. He said: If libreoffice encourages, but not requires, AL2 for stuff in the core package, that would be a huge advance to get a bit nearer both camps. This is not asking for LO members to surrender or fall on their swords. As a TDF member, I'm telling you: Yes it is _exactly_ what it sound like. It is suggesting that information be made available to LO developers who might wish to voluntarily make their code available under ALv2 as well as the existing LGPL/MPL. Please correct me if I'm wrong, but I had the impression that nothing at TDF/LO that would prevent someone from doing this? It is one thing to not 'prevent' someone from abandoning free-software principles (as if anyone had such power anyway) It is quite another to have libreoffice [more exactly TDF] ask its members or contributors to do so Norbert
Re: working on a OpenOffice roadmap
On Sat, Oct 22, 2011 at 1:03 PM, Pedro Giffuni p...@apache.org wrote: I am pretty sure we are safe. good, I have no stake in the old bugzilla content... so as long as you are confident that all such stake-holder share Rob's interpretation of what 'accepted, for incorporation' means (i.e that mere posting on a ML or attachment to a bug repport means 'accepted, for incorporation'... (I wonder why we bother with code review then, if any patch submitted is deemed 'accepted, for incorporation') - it is my understanding that Oracle will also be making legal provisions about the bugzilla database. They provided the dump, its not like we stole anything. I haven't seen the secret SGA... but I don't recall mention by Oracle's representative of a blanket re-licensing of the bugzilla databse under AL2... or for that matter about anything but a list of file based on a specific snapshot of the source tree. The problem is not really integrating the codebases but the fact that the ownership of LO is so disperse and that TDF is incapable of taking any relicensing decision. This is not a problem, this is a feature. It is a limitation. Only the copyright owner can make effective license claims so if the time comes to enforce the LGPL you will find the surprise of owning less than 10% the code doesn't help much. That is much more than 0% which is what both SUN/Oracle CLA and AL2 effectively offer. It is interesting though that you think that one need to 'own' more than 800K lines of LO code before having standing. Oh, and you are overlooking one option: it is quite possible to designate an entity as your agent in these matter. so a bunch 'small' copyright owner could mandate TDF, for example, to represent them. Well I use FreeBSD and I am very glad to have helped Apple overthrow Microsoft. We are not quite there yet... but in anycase this is 'meet the new boss, same as the old boss'. out there underestimate the resources SUN/Oracle put into OpenOffice. Ask Rob how much IBM bill internally for translation on a per-word basis. Then calculate the investment for OpenOffice for 100+ languages... and you'll get an idea why Rob is so interested in Pootle. It seems that IBM, contrary to you, is very aware of the resource invested by the community. Norbert
Re: working on a OpenOffice roadmap
On Tue, Oct 25, 2011 at 11:03 PM, Pedro Giffuni p...@apache.org wrote: --- On Tue, 10/25/11, Norbert Thiebaud nthieb...@gmail.com wrote: LO had no choice but to take LGPL. So more necessity/inertia than ethos. And -- according to Michael -- when it thought that MPL might be more acceptable TDF was quick to add MPL for new code contributions. This shows an ethos of flexibility. And look how well it has served us. Despite that very large concession, IBM still snubbed it and 9 month later started a new fork. You give a hand, it want the whole body... I will ignore for now the paranoia/plot theory, to note two issues: And yet the very page you quote also says: While in general we think LGPLv3 is a great sufficient license for our code, others eg. Sun IBM appear reluctant to include LGPL code into their products, so much for paranoia/plot theory... 1) Its so easy to criticize IBM while ignoring the corporate interests that acelerated the original and only real fork. A fork that ended up costing the jobs of many good guys. It is very flattering of you to assign such power to TDF, but the reality is that OpenOffice did not fit in Oracle Business model Oracle would have closed the OOo shop with or without LibreOffice. Look at the rest of the Open Source porfolio Oracle 'inherited' from SUN... and how well things have gone... If for you considering the MPL was a very large concession, for Oracle, which actually owns the code, making all the code AL2 is much bigger concession. How is that? The only concession I see is one to IBM, probably a contractual one. making all the code AL2 does not 'concede' anything more. It is just yet another Hudson/Jenkins tantrum: If I can't make 70+% margin with the toy, at least I'll try to break it as much as I can before leaving the playground 2) I can still read on the Go-OO site the desire to have the OpenOffice.org code owned by a meritocracy like the Apache Foundation: http://go-oo.org/ (Freer Licensing section) And we ended-up with the best of both world: a meritocratic foundation _and_ a free software license. why on earth would you imagine that after having successfully done that, we'd want to settle for less ? Norbert
Re: working on a OpenOffice roadmap
On Fri, Oct 21, 2011 at 9:26 PM, Pedro Giffuni p...@apache.org wrote: I merged some fixes from bugzilla that may be shared, and they have taken a lot of code that they tagged as contributed by Oracle. Are you sure about that? please read the CLA which many of the said bugzilla patches are covered with : 1. Contributor owns, and has sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the OpenOffice.org open source product (the Contribution) which Contributor has ever delivered, and Sun has accepted, for incorporation into the technology made available under the OpenOffice.org open source project. Are you sure that all the pieces you are scrubbing from bugzilla meet the 'and Sun has accepted, for incorporation into the technology made available under the OpenOffice.org open source project requirement ? Seems to me that if they are still lingering in bugzilla, surely they have not been 'accepted' by SUN yet... So you are essentially merging some LGPLv3 patches, with no clear legal path to AL2. The problem is not really integrating the codebases but the fact that the ownership of LO is so disperse and that TDF is incapable of taking any relicensing decision. This is not a problem, this is a feature. Copy-left + decentralized ownership is a very effective way to protect 'Free' software... free as in freedom aka 'Libre'. Linux is a prime example of that. But if you want to pin-point a problem. that _IS_ the attempt of some corporate interest to force a unilateral re-licensing of the project, and then claim that 'convergence' is desirable. If convergence was desirable, then one obvious solution would have to continue contributing according to the license of the project. On Thu, Oct 20, 2011 at 4:02 AM, Martin Hollmichel martin.hollmic...@googlemail.com wrote: Hi, * A call to LibreOffice contributors also to contribute their changes to Apache as the ASF is the long desired independent foundation for OpenOffice.org. The long desired independent foundation _is_ TDF. By the time Oracle did its IBM-approved tantrum, TDF had already few releases out-the-door... On Sat, Oct 22, 2011 at 6:35 AM, Ian Lynch ianrly...@gmail.com wrote: It just seems that there are too many individual interests outweighing such a goal at present. Apache OOo fork is born out of 'corporate' interest not 'individual' interests. Hence the fatal license road block. Norbert
Re: Top posting is bad
On Fri, Sep 30, 2011 at 7:18 AM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: The assumption behind this recommendation seems to be that all mail clients are the same and the list is read the same by everyone. Choosing to use inadequate tools is no excuse to be bad mannered. bad may be unpleasant for you Not just merely 'unpleasant' A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: The lost context. Q: What makes top-posted replies harder to read than bottom-posted? A: Yes. Q: Should I trim down the quoted part of an email to which I'm replying? Norbert
Re: Top posting is bad
On Fri, Sep 30, 2011 at 10:44 AM, Dave Fisher dave2w...@comcast.net wrote: When the questions and answers are deep in the bottom and get deeper and deeper then I tend to tune out and move on. That is because 'bottom post' is not just adding stuff at the end... it is adding stuff 'after' the relevant 'quote', eliminating as much of the original message that is not necessary to understand the context. Done properly that lead to short message, to the point. The poster child example (no pun intended) of the efficiency of this technique is patch review/comment. Norbert
Re: [DISCUSS] Having New Committers also be on the PPMC
On Fri, Sep 30, 2011 at 10:35 AM, Rob Weir robw...@apache.org wrote: BTW, LO/TDF has a steering committee of what? 13 people total? Have you recommending to them that they put their entire elected membership into a flat leadership structure? Or is that wisdom, by your grace, reserved for us alone? Rob, you are comparing Apple and Oranges. The Steering Committee, soon to be BoD, is not similar to a PMC. It is similar, in function, to the Apache Board. Norbert
Re: [DISCUSS] Having New Committers also be on the PPMC
On Fri, Sep 30, 2011 at 12:47 PM, Rob Weir robw...@apache.org wrote: I agree let's not make it adversarial. But I would be interested to know why Simon speaks up in favor of us have a congress-sized PMC, but has not made a similar recommendation for TDF/LO. Because there is no such thing as a PCM. The Engineering Steering Committee has an advisory role. And most of the time a good half of the dev/qa that join the weekly call are not 'officially' member of the ESC. There is no 'binding' vote... in fact there is no vote at all. Decision are made by those who do, and so far the role of ESC has more been one of coordination, in the sens of sharing and communicating what is happening rather than 'deciding'. So really, who got what 'title' or what 'distinction' is very far from the daily concern. Note that there is not even the requirement to be a TFD member to be on the ESC... not for that matter to have commit access. And you asked: who approve 'release': well roughly the calendar modulated by Bugzilla and QA volunteers. Norbert
Re: Not new but under a new hat
On Wed, Sep 28, 2011 at 8:05 AM, Ian Lynch ianrly...@gmail.com wrote: On 28 September 2011 13:31, drew d...@baseanswers.com wrote: On Wed, 2011-09-28 at 13:05 +0100, Ian Lynch wrote: or why not just shake hands and part as friends. Of course we can but that makes inefficient use of the resources and is less good for Open Source in general. Well, as you can guess I disagree - it's only inefficient if one doggedly holds to the idea that the two projects should (nor need to) share a common code base going forward - by why would that be? Because it takes more resources to maintain two different code bases. Resources are at a premium therefore duplicating effort makes no logical sense. This is simple logic, nothing to do with dogmatism. The illogical and emotional position is to do with ownership, not the logic of optimising resources. These concerns have been raise during the incubation proposal review back in June... and, back then, were rejected. Rob even wrote a blog dismissing them http://www.robweir.com/blog/2011/06/openoffice-libreoffice-and-the-scarcity-fallacy.html I come back to the point that if division is intrinsically good, why not fork Inkscape, Audacity, Gimp, etc etc. All these project a free-software, and no corporation is a position to re-license them. So the only reason for a fork would be a technical one, and technical issues rarely escalate to a fork. (one notable exception is egcc vs gcc... and indeed that lead to a re-unification... but that worked because gcc did not decided to switch to an incompatible license in response to the fork) Norbert
Re: A systematic approach to IP review?
On Wed, Sep 28, 2011 at 5:42 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: It is unlikely that machine-generated files of any kind are copyrightable subject matter. I'd imagine that Pixar, for instance, would have a problem with that blanket statement... The very existence of this paragraph in the Bison manual : http://www.gnu.org/s/bison/manual/bison.html#Conditions also raise doubt as the the validity of the premise. Norbert
Re: A systematic approach to IP review?
On Wed, Sep 28, 2011 at 7:55 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: I'll stand by my original statement. I'm not going to get into the Pixar case since it doesn't apply here. I did not say it applied to the Visual studio generated cruft... I merely commented on the blanket assertion that 'computer generated = no copyright' The Bison manual may have license conditions on what can be done with the generated artifact, but I suggest that is not about copyrightable subject matter in the artifact. Actually it is. The only claim they could legally have _is_ on the generated bit that are substantial piece of code copied from template they provide, namely in the case of a bison generated parser the whole parser skeleton needed to exploit the generated state-graph. the whole paragraph is about the copyright disposition of these bits. and in the case of bison they explicitly grant you a license to use these bits in the 'normal' use case... my point being that the existence of that paragraph also disprove the assertion that 'computer generated = no copyright' You could write a program that print itself... the mere fact that it print itself does not mean you lose the copyright on your program... That being said, I do think you are on the clear with the Visual Studio generated cruft... but not merely because there is 'computer generation' involved. Norbert
Re: What is needed for Support Forums to be fully integrated into the Apache OpenOffice.org project
On Mon, Sep 5, 2011 at 9:04 AM, Rob Weir robw...@apache.org wrote: Terry, your penchant for whipping out your resume at the slightest provocation as been noted, and dismissed, elsewhere on the list. It is an approach that lacks substance . It reminds me those small aquatic creatures (does anyone know the name?), http://en.wikipedia.org/wiki/Tetraodontidae who lacking any other defense mechanisms puff themselves up to look much larger that they are, in hopes of intimidating potential foes. I suppose it works for fish. It does not work for me. I'm not impressed. But luckily I'm not a foe either. I'm here to help.
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir r...@robweir.com wrote: Looks like LO discussed it briefly [4], but dismissed it under the misapprehension that since they are not in the US, the regulation is irrelevant. I'm confused, how is that a 'misapprehension' exactly ? Are you concerned about compliance with http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00801164dateTexte=#LEGISCTA06136109 ? if not, why not ? are you under the misapprehension that since [you] are not in [France], the regulation is irrelevant. ? Norbert
Re: Request dev help: Info for required crypto export declaration
On Thu, Sep 1, 2011 at 8:57 PM, Rob Weir robw...@apache.org wrote: On Thu, Sep 1, 2011 at 9:38 PM, Norbert Thiebaud nthieb...@gmail.com wrote: On Thu, Sep 1, 2011 at 11:15 AM, Rob Weir r...@robweir.com wrote: Looks like LO discussed it briefly [4], but dismissed it under the misapprehension that since they are not in the US, the regulation is irrelevant. I'm confused, how is that a 'misapprehension' exactly ? Are you concerned about compliance with http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00801164dateTexte=#LEGISCTA06136109 ? if not, why not ? are you under the misapprehension that since [you] are not in [France], the regulation is irrelevant. ? You should take a look at the Wassenaar convention. There is a lot more similarity than you might think between French and US requirements. You're missing the point. The point is: it makes a lot of sens of Apache, being legally established in the US, to comply with the export regulation of its host country... but claiming that not paying attention to US regulation for a non-US-based entity is a 'misapprehension' does not make much sens to me. 'France' here was just a convenient example to illustrate the fallacy of the argument. one could find hundreds of jurisdictions with each their own hoops and quirks... most likely some of them contradicting each others. The diligence you do to satisfy US regulations will also help you with the regulations in any other countries you, or your users, need to work with. The French term that best describe this vision of the world is 'nombrilism' (I'm afraid the english translation doesn't quite does it justice.. too literal, doesn't carry the larger meaning, I think) Norbert
Re: [Repo] SVN ETA? (was Re: Request for comments: Community Wiki Services web page.)
On Wed, Aug 10, 2011 at 2:14 PM, Michael Stahl m...@openoffice.org wrote: On 10.08.2011 20:10, Mathias Bauer wrote: On 10.08.2011 19:13, Dennis E. Hamilton wrote: [Nosing around OpenOffice.org I could find no source repositories, although release tarballs are stated to be available. I probably don't know where to look.] look here: http://hg.services.openoffice.org/ (I see that LibreOffice has gotten down to one, but that doesn't help here and I'm not sure what that means in any case.) I think that you are confusing things here. If you are talking about the one git effort from LibreOffice: for historical or other reaons LibreOffice always had more than one repository for their code base (IIRC even more than five), while OOo always only had one until we in my LO checkout (from before migration) i've got 18 repositories... there seems to be a script in the top-level that can run git commands across all repositories (guess otherwise this kind of setup would be completely unusable). yes: ./g it is a fairly simple wrapper to run the same git command on all the repositories. but it has still serious limitation, and the setup with split repo has inherent pita like making bisection extremely hard... separated the l10n stuff. As having more than one repository is a major PITA for developers if you need them all for even the smalles build, they decided to go back to one repository. there still seem to be 5 repos left (but 3 of them are said to be optional: binfilter, dictionaries and translations). binfilter was kept separate because it is on the chopping block... translations was kept separate for the same reason l10n was split in OOo dictionaries was kept separate for the same reason translations/l10n was the last one is help. right now it is not an optional repo, but the longer term goal is to have the help as a separate build/package. Norbert
Re: An example of what's wrong up with the wiki
On Sun, Aug 7, 2011 at 11:30 AM, Rob Weir robw...@apache.org wrote: As mentioned before I'm concerned with the concentration of power on the wiki, with a few moderators/admins having arbitrary power over content, even though they have not signed the iCLA, are not committers and have not been appointed by the PPMC. So there is arbitrary authority, with no accountability. Having a system like this abdicates the PPMC's responsibility for providing oversight to our Apache-hosted project websites. I posted a new FAQ on the wiki today. This was to demonstrate that anyone could post anything on the wiki, under any license. The post was quickly taken down and my account was permanently blocked. You are talking about: # (Block log); 15:45 . . Ccornell (Talk | contribs) blocked Foobar (Talk | contribs) with an expiry time of infinite (account creation disabled, autoblock disabled) (Inserting nonsense/gibberish into pages: Creating nonsesne content not realted to OOo Account banned.) # (Deletion log); 15:44 . . Ccornell (Talk | contribs) deleted Documentation/FAQ/General/What is a good rhyme about OpenOffice? (Vandalism: content was: '{{DISPLAYTITLE: What is a good rhyme about OpenOffice.org?}} section begin=question/ What is a good rhyme about OpenOffice.org? section end=question/ section…' (and the only contributor was '[[Special:Contributions/Fo) right? So basically you tried to troll the wiki to prove a point: If your edit stay in place you claim that there is a problem... if your edit are taken down, you claim there is a problem... Damn if you do, damn if you don't implacable logic. There was no discussion on the ooo-dev or ooo-private about the content removal Do you suggest that every wiki reversal of 'Vandalism' (I mean, you created a User named FooBar... you might as well have chosen SuperTroll2000) be subject do a Discussion on a mailing list... ? Norbert
Re: Population of ooo-security
On Fri, Jul 29, 2011 at 10:48 AM, Rob Weir apa...@robweir.com wrote: On Fri, Jul 29, 2011 at 10:58 AM, Florian Effenberger flo...@documentfoundation.org wrote: Hi, Rob Weir wrote on 2011-07-29 16:49: What did you think of Simon's idea of having a discussion list, perhaps outside of Apache, where interested parties could discuss issues related to the security of OOo and related code bases? Something like that could be useful, even if it is not part of the official incident response process of Apache or LibreOffice. I was not talking about chatting on security topics, I was talking about effectively cooperating on security issues, like we did in the past, in a trusted, well-proven group. However, people made it clear that this is not of interest, so I simply shut up here. The offer remains open: If any LibreOffice security expert joins this list, states that they have relevant expertise and that expresses a commitment to work on Apache OpenOffice security, and are willing to sign and return the Apache iCLA, then I will gladly nominate them as a committer and recommend that they be added to the ooo-security list. Sarcasm does not travel well, maybe you should add sarcasm /sarcasm to the above paragraph ? Norbert
Re: Population of ooo-security
On Fri, Jul 29, 2011 at 1:48 PM, Pedro F. Giffuni giffu...@tutopia.com wrote: --- On Fri, 7/29/11, Norbert Thiebaud nthieb...@gmail.com wrote: ... So let me use a analogy to illustrate why I though that was a sarcasm: to me, Rob's paragraph read as: The offer remain open: If any gay person want to marry, we will gladly recognize that marriage, as long as they marry someone of the opposite sex. Religion is off topic here, but indeed you can't expect that a specific church that defines marriage as the union between a man and a woman to procreate will recognize same sex unions as marriages. No sarcasm there, just the rules. The sarcasm here is not each other position, but the claim that there is any 'open offer' is such proposal. PS: why o why would signing an iCLA be a requirement to be a project security liaison ? The ICLA covers two things that are essential for any contribution: license and patents. It would be unacceptable to accept security patches that could cause problems in either topic. ok let me use a concrete example: Let say person A found somewhere in the code something like printf( s_usingText ); where there is a risk that s_usingText is not sanitized... let's say person A notify this security risk to LibreOffice security risk What should happen then: a/ LibreOffice keep it private to LibreOffice member only, make and publish a Fix, then and only then unleashed the news on the rest of the world, including AOO.org ? b/ LibreOffice security list has subscriber that represent their cousin project AOO.org so they are aware of it immediately and can themselves asses, fix and prepare a patch (if applicable)... and since they are cross-list access they can coordinate release and announce if need be. If you selected option a/ then fine subject closed.. but let's not be hypocrite about it. If you selected option b/ how do you rationalized that the behavior should not be reciprocal ? 'because that is how Apache work ?' really ? Ambassadors only get notified of internal issues; they don't decide. A security officer would be more analogous to a defense minister. being subscribed as a liaison to a ooo-security list does not confer the subscriber any decision power... and yes the whole point of the cross-pollination _is_ to get notified as soon as possible of possible issues. Norbert
Re: Population of ooo-security
On Fri, Jul 29, 2011 at 2:04 PM, Dave Fisher dave2w...@comcast.net wrote: Let's stop misinterpreting and offending each other and find a way to co-operate. Several possibilities have been discussed. (1) A private list of experts that will be contacted as needed by ooo-security. Maybe this should be public, self-identified and on the commiunity wiki? (2) A list of interested, interrelated projects that want to be informed of upcoming fixes, etc, slightly in advance. Registered on the community wiki? (3) Remembering that anyone who actually has an issue can report it to ooo-security and ooo-security would likely include that individual in their discussion and remediation. Other APache projects actually show who reported, when it was privately and when it was publicly disclosed. (4) An offer to anyone who is an OOo security expert including LO/TDF people to join the podling as a committer and member of the PPMC - requires an ICLA (which is not a baptism nor is it circumcision) and the vote of the PPMC. Do you have something constructive to add here? yes: to quote Malte Timmermann: (0) From the people on the current OOo security team, there are (iirc) only 2 people beside myself who regularly worked on fixes for security issues: Caolan McNamara and Rene Engelhard. I would like to add them to ooo-security. They are also in the LibO security team, so adding them should give enough LibO coverage. Norbert