On Thu, Nov 17, 2011 at 05:33:48AM -0600, Norbert Thiebaud wrote: > On Thu, Nov 17, 2011 at 5:05 AM, Lionel Elie Mamane <lio...@mamane.lu> wrote: >> On Thu, Nov 17, 2011 at 03:22:33AM -0600, Norbert Thiebaud wrote: >>> On Wed, Nov 16, 2011 at 4:22 PM, Lionel Elie Mamane <lio...@mamane.lu> >>> wrote:
>>>> postgresql-sdbc >>> few questions/remarks (mostly on the form, rather than on substance... >>> I only glanced at the commits) >>> 5a2b8cba519bb9d34d3a28a51adcda334147096f: >>> Humm, not sure you can do that, >> Sure I can: the code being *dual*-licensed means anybody legitly >> getting a copy of the code can *choose* between obeying the LGPLv2.1 >> *OR* obeying the SISSL. I chose LGPLv2.1. > And that is a problem, because that is not compatible with the > project license. Obviously, if it is useful or necessary to include the code in LO, I agree to keep SISSL. I just didn't think it is. >>> but even if you could, removing SISSL is not a good idea since that >>> is what allow that code to be merged in libreoffice (which is >>> MPL/LGPLv3+) >> I understand you are saying that the SISSL allows us to relicense the >> code under MPL/LGPLv3+; I'm not sure I agree. Could you please explain >> why you think that is? >> In particular, by (re)distributing the SISSL-covered code under >> MPL/LGPLv3+, we allow downstream users to not obey the "standards >> body" clause of the SISSL. And we are not allowed to allow others to >> not obey that clause of the SISSL. > The least of 2 'evils': we are LGPLv3+ + MPL that can't work at all > with LGPLv2 It can, in so far that postgresql-sdbc is compiled as a 'stand-alone' .so file, and LO dlopen()s it (or more generally links to it). That's allowed under both postgresql-sdbc's LGPLv2.1 and LO's LGPLv3. I expect it is also allowed under LO's MPL (section 3.7). > OTOH SISSL explicitly permit integration under a bigger work with > the license of the bigger work, provided that SSIL is respected for > the piece inserted. Ah, clause 3.7, you are right, that would work. Postgresql-sdbc stays under SISSL, LO under LGPLv3+/MPL and they are allowed to be combined. The SISSL just allows it unconditionally (with even the 'obey standard' clause applying only to postgresql-sdbc, not the whole), LO's LGPLv3+ because it is a separate library and LO's MPL unconditionally. We still have to be cautious *not* to copy/paste code between LO and postgresql-sdbc, because of the different licenses. I feel we don't gain anything of substance by keeping the SISSL, and I'm not very strongly opposed to it. If, as a project, LibreOffice prefers to keep SISSL licensing on that code, I'll agree to it. >> Do you mean that you intend to write code in another style within the >> same file? To me it seems bad practise to mix *different* styles >> within the same file. >> If not, well, the default emacs style (...) does *not* match the >> style of the existing code in that file, (...) > The 'factory' default yes, but the 'the default'. my .emacs is set the > way I like it, and it behave the way I am accustomed to (I used a > customized ellemtel for instance) > If you want to set-up your emacs to use the built-in bsd style, > please by all means to so, but in your own .emacs My .emacs applies to *all* C(++) code I open, not only to LO, so that's IMHO not the right approach. What you are saying is that every contributor should change their .emacs to match the style in LO? From where I stand, the purpose of the modeline is to make contributor's like easier, that they open the file, start hacking, and emacs will (as far as possible) automatically apply the right indentation. And what if I want to hack on emacs itself, or Linux, or any other C(++) project that has different style guidelines? I have to change my .emacs every time I switch from the one to the other? (Or have in my .emacs functions "linux-style", "libreoffice-style", "emacs-style" that I need to *manually* call every time I open a file from one of these projects to modify it...) To me it seems like gratuitously making contributor's life more complicated. All this being said, I don't think this is worth the time to discuss it, so OK, I'll remove that (and most probably in future at some point slip up and commit code indented in the wrong style). Or how about this: eval:(if (fboundp 'libreoffice-c-set-style) (libreoffice-c-set-style)) This allows each and every person to set their libreoffice-specific C(++) indentation styles in their .emacs without impacting the rest of their C(++) editing work. It has a *big*, *big* disadvantage, that is that the first time one opens a file with that in the modeline, one gets a warning about "unsafe value in local variable list"; so *every* emacs-using LO contributor is annoyed at least once until he/she marks that expression as safe :-( -- Lionel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
