Apache list archive issues must be fixed soon

[Kazunari Hirano]

Hi all,

Thank you, Ariel Constenla-Haile (arielch), for building developer's
snapshot builds and langpacks for Windows.
http://people.apache.org/~arielch/packages/
Now we can find untranslated threads in the product.
http://wiki.services.openoffice.org/wiki/JA/Apache_OpenOffice/OOO340_m1
We would like to discuss in Japanese about Japanese translation for
Apache OpenOffice on our native language list and made it public to
Japanese users and contributors.
But you see,
http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/thread?0
the list archive is unreadable.
https://issues.apache.org/bugzilla/show_bug.cgi?id=52195
https://issues.apache.org/bugzilla/show_bug.cgi?id=52182
We want these issues to be fixed soon.

We are getting closer to Apache OpenOffice release, aren't we?
We should start localization and translation efforts as soon as possible, right?
As soon as the list archive issues are fixed, I would like to prepare
an announcement to the world people "Apache OpenOffice call for help
on localization and translation, Help build Apache OpenOffice for your
language"
:)
Thanks,
khirano
-- 
khir...@apache.org
Apache OpenOffice (incubating)
http://incubator.apache.org/openofficeorg/

[BUILD]: propose new Developer snapshot builds based on revision r1231878

[Jürgen Schmidt]

Hi Oliver, Ariel,

i submitted minor branding relevant changes to get an impression how it 
can look like (nothing 100#% final if decide to change it).


I would like to propose that we prepare a new set of developer snapshots 
based on this version.


I have already started to build ...

- openofficedev_en-US
- a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
- language packs
ooodevlanguagepack_de
ooodevlanguagepack_fr
ooodevlanguagepack_es
ooodevlanguagepack_it
ooodevlanguagepack_ja
ooodevlanguagepack_zh-CN
ooodevlanguagepack_pt-BR
- sdkoodev

If you have time it would be perfect if you can provide the windows and 
Linux builds.


Juergen

Re: Wiki configuration problem

[TJ Frazier]

On 1/15/2012 23:03, Yakov Reztsov wrote:

Hi!

Apache OOo Wiki configuration problem
Can not  edit math formula, "Can not parse expression (texvc not found)"



Problem is visible on next-to-last revision here:

http://wiki.services.openoffice.org/w/index.php?title=NLPSolver&curid=21644&diff=198864&oldid=195113&rcid=207812

The addition of a final "^2" operand triggers an error. Investigating.

--
/tj/

Re: PROPOSAL (was Re: Category-B tarballs in SVN )

[Andre Fischer]

On 13.01.2012 21:27, Pedro Giffuni wrote:

Hello fellow indians; ;)

I think there is consensus that this is (at least)
a gray area so I have the following proposal, which
shouldn't get in the way of having this properly
solved by legal but which I think should solve at
least temporarily the issues that we have. It's
actually very simple but who knows, maybe it's even
acceptable as a general incubator policy at the ASF.

The ext_source in shall be divided, according to
the categories of the licenses, into two
directories in SVN, namely:

ext_source_A
ext_source_B


main/ooo.lst already offers a poor-mans version of this.  It has to 
sections headed with comments


# Libraries with category A license

and

# Libraries with category B license

which reference the tar balls in ext_sources/ that have, surprise, 
category A or category B license.




- Ext_source_B shall have a prominent text note that warns
users that the code there is made available only for
builder convenience but that the code is in general
not acceptable for inclusion in Apache source code
releases.

- It is understood that ext_source_B is a quarantine
area. The idea is that the code we have there will
only shrink with time. The code there can be updated
for security reasons but in general no new code should
be brought in without specific consensus (voting, checking
with the PPMC, etc, but not lazy consensus).


This, I think, is an important point. Discourage people from adding more 
cat-B tar-balls, and encourage developers to replace the existing ones 
with category-A libraries.


We can start a Wiki page for the replacement tasks.  I think some time 
back you mentioned a possible replacement of rhino with V8.


-Andre



NOTE: Consensus for replacing standard OOo 3.4
functionality like the CoinMP solver code is a given
(particularly as the licensing is being worked on) but
we don't want this to be a loophole to bring in MPL'd
code into AOO.

Of course we still have to comply with the standard
Apache policies concerning Category-B : "Code that is
more substantial, more volatile, or not directly consumed
at runtime in source form may only be distributed in
binary form." but at least now it should be pretty clear
and easy for everyone downloading the code from SVN where
they can expect licensing issues.

Pedro.

Re: PROPOSAL (was Re: Category-B tarballs in SVN )

[Ross Gardler]

On 15 January 2012 03:29, Rob Weir  wrote:
> On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni  wrote:
>> Hello fellow indians; ;)
>>
>> I think there is consensus that this is (at least)
>> a gray area so I have the following proposal, which
>> shouldn't get in the way of having this properly
>> solved by legal but which I think should solve at
>> least temporarily the issues that we have. It's
>> actually very simple but who knows, maybe it's even
>> acceptable as a general incubator policy at the ASF.
>>
>> The ext_source in shall be divided, according to
>> the categories of the licenses, into two
>> directories in SVN, namely:
>>
>> ext_source_A
>> ext_source_B
>>
>
> This is assuming all 3rd party modules are pure, under a single
> license.  I don't believe this is always the case.

Then can /should they be put in the most restrictive category?

> Why not treat it the way we treat 3rd party modules in releases, e.g.,
> with a LICENSE and NOTICE file?  We could put a LICENSE file in
> /ext-src.  That would make it clear to anyone who browses that
> directory.

+1

On one of the projects I work on we require libraries to have a
corresponding licences/FOOBAR_license.txt file This then allows some
simple machine processing to check the license is correctly recorded
against all libraries included. This is built into the build system
and automatically flags when something seems to be missing.

>> - Ext_source_B shall have a prominent text note that warns
>> users that the code there is made available only for
>> builder convenience but that the code is in general
>> not acceptable for inclusion in Apache source code
>> releases.
>>
>
> OK, though this is solving a problem we don't really have, right?

I think the point is that it clearly separates out stuff that is OK to
stay and stuff that needs to be carefully managed. It's a step towards
satisfying those who are concerned about including this source whilst
avoiding the need to remove the convenience for developers of having
the source available.

This separation will make it easier for people to evaluate the impact
of these files when it comes to graduation and will serve to signal
that there is a process in place for the management of these
dependencies (or that there needs to be a process).

>  So if we really want to give proper notice
> to the person downloading our source release, this needs to be done:
> 1) In the LICENSE and NOTICE files

That has to happen anyway (for cat b licenses).

> Putting extra verbiage in the SVN tree that is not included in the
> releases -- I don't see the point.  Is this to protect casual browsers
> of our SVN tree?

For me the point is not about casual browers it is about developers
like me who don't download source tars but instead checkout from SVN.
We can't assume that all such developers will understand the nuances
of license compatibility or even bother to check.

Ross

Re: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Oliver-Rainer Wittmann]

Hi,

On 16.01.2012 10:37, Jürgen Schmidt wrote:

Hi Oliver, Ariel,

i submitted minor branding relevant changes to get an impression how it can look
like (nothing 100#% final if decide to change it).

I would like to propose that we prepare a new set of developer snapshots based
on this version.

I have already started to build ...

- openofficedev_en-US
- a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
- language packs
ooodevlanguagepack_de
ooodevlanguagepack_fr
ooodevlanguagepack_es
ooodevlanguagepack_it
ooodevlanguagepack_ja
ooodevlanguagepack_zh-CN
ooodevlanguagepack_pt-BR
- sdkoodev

If you have time it would be perfect if you can provide the windows and Linux
builds.



I have started the preparation (update local repository) of these builds and 
will start building soon.


Best regards, Oliver.

[LEGAL] Something to solve: (c) Sun

[Pavel Janík]

Hi,

my build log contains 78 instances of:

   Copyright: 2003 by Sun Microsystems, Inc.

It is in this file:

main/l10ntools/source/filter/merge/FCFGMerge.java:
sOut.append("Copyright: 2003 by Sun Microsystems, Inc.\n");

-- 
Pavel Janík

Re: PROPOSAL (was Re: Category-B tarballs in SVN )

[Andre Fischer]

On 16.01.2012 12:07, Ross Gardler wrote:

On 15 January 2012 03:29, Rob Weir  wrote:

[...]

Putting extra verbiage in the SVN tree that is not included in the
releases -- I don't see the point.  Is this to protect casual browsers
of our SVN tree?


For me the point is not about casual browers it is about developers
like me who don't download source tars but instead checkout from SVN.
We can't assume that all such developers will understand the nuances
of license compatibility or even bother to check.


Maybe the ability of SVN to include/reference an external SVN repository 
from another SVN repository can help (see [1]).


We could put the cat B tar-balls into an SVN repo, that is or is not 
located on an Apache Server, and reference that repo from our OpenOffice 
repository.


The developer, who checks out the source code, can then decide whether 
to automatically checkout the cat B tar-balls together with the rest of 
the code or to just check out the OpenOffice source.


One downside of this approach is the wrong default behavior on checkout:
the command "svn checkout" checks out all referenced external 
repositories.  In order to not include the cat B tar balls you have to 
add the "--ignore-externals" option.  But with a little bit of 
documentation and by adding this option to the Source Control wiki page 
[2] that is maybe OK.


-Andre

[1] http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html
[2] http://incubator.apache.org/openofficeorg/source.html

[...]

Re: Question related derivative code based on our Apache licensed code

[Michael Meeks]

Hi Pedro,

On Wed, 2012-01-04 at 06:38 -0800, Pedro Giffuni wrote:
> What will happen is that the code will keep the MPL/LGPL3
> restrictions in addition to the AL2.

That would be the plan; though our code will -emphatically- not be
available under the AL2; only an MPL/LGPLv3+ [as well as any lingering
terms from the AL2].

> - They will have to carry the AL2 license among their code
> and headers, and the clause 5 is particularly nice to have.

Clause five of the AL2 is:

"5. Submission of Contributions. Unless You explicitly state
 otherwise, any Contribution intentionally submitted for
 inclusion in the Work by You to the Licensor shall be under the
 terms and conditions of this License, without any additional
 terms or conditions. Notwithstanding the above, nothing herein
 shall supersede or modify the terms of any separate license
 agreement you may have executed with Licensor regarding such
 Contributions."

IANAL, but to create a superabundance of clarity - no contribution
submitted to LibreOffice is a 'Contribution'. It is not submitted to
'Licensor' which is ASF (cf. definition of Contribution). The TDF
infrastructure is not /managed by, or on behalf of, the ASF/.

If it would help to clarify this, we can add a "Not a contribution"
line or similar language to our new (MPL/LGPL)onAL2 header as/when we've
got that worked through.

Of course, individuals are quite at liberty to choose to license their
contributions to the ASF if they so choose, and to include -their- code
into either project; though that is something I'd personally
discourage :-)

So - any expansion on "is particularly nice to have" would be helpful
Pedro - why do you think this is particularly nice ? :-)

All the best,

Michael.

-- 
michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot

[ANNOUNCEMENT][THANKS] Apache ODF Toolkit(Incubating) 0.5-incubating Release

[Devin Han]

Hi all,

Thanks all of the voters from this list. Now there is a result ;)

The Apache ODF Toolkit(Incubating) team is pleased to announce the release
of 0.5-incubating. This is our first Apache release.

The Apache ODF Toolkit is a set of Java modules that allow programmatic
creation, scanning and manipulation of Open Document Format (ISO/IEC 26300
== ODF) documents. Unlike other approaches which rely on runtime
manipulation of heavy-weight editors via an automation interface, the ODF
Toolkit is lightweight and ideal for server use.

A full list of changes is available in the change log[1]. People interested
should also follow the mail list[2] to track progress.

The ODF Toolkit source release as well as the pre-built binary deployment
packages are listed in the downloads page[3]. Pre-built versions of all ODF
Toolkit components are available in the central Maven repository under
Group ID "org.apache.odftoolkit" and Version "0.5-incubating".

[1]
http://www.apache.org/dist/incubator/odftoolkit/CHANGES-0.5-incubating.txt.
[2] http://incubator.apache.org/odftoolkit/mailing-lists.html.
[3] http://incubator.apache.org/odftoolkit/downloads.html

-- 
-Devin

Re: Localized builds

[Andre Fischer]

I made some changes for issue 118778 
(https://issues.apache.org/ooo/show_bug.cgi?id=118778) so that when the 
--with-lang option is given to configure the extras/ directory is added 
automatically to the list of repositories.


See the issue comments for more details.

Regards,
Andre

On 05.01.2012 19:41, Andrew Rist wrote:



On 1/5/2012 3:06 AM, Jürgen Schmidt wrote:

Hi,

maybe i have missed somehting but i stumbled over a problem to build
localized packages.

I used configure with --with-lang="en-US de" and got a problem in
instsetoo_native to resolve a dependency to module l10n

The solution is to put a source.config file besides main

.../main
.../extras
.../source.config

source.config
###
[repositories]
main=active
extras=active
###

My question is how do others make localized builds without this file?

I am running into this same problem - with one caveat...
the file seems to need to be *source_config *(with an underscore as
opposed to a '.')

Is there a downside to checking this in? This will block doing a
--with-lang build on the buildbot if this is not in svn.

A.


Any ideas?

Juergen

[RELEASE]: help wanted to define default dictionaries for languages

[Jürgen Schmidt]

Hi,

[based on the assumption that we get the approval to bundle the 
dictionaries/thesaurus with our binary releases]


I am not really familiar with thwe dictionaries/thesaurus and would like 
to ask for help to define a list of default dictionaries/thesaurus for 
each language if possible.


Based on this list we have to work on a mechanism to include the 
dictionaries in our binary releases.


I think about a simple list where we define the default dictionary for 
each language. Something like


[DICTIONARIES]
de -> (German (de-DE frami) dictionaries), 
http://extensions.services.openoffice.org/en/download/5092, download file>
de-DE -> (German (de-DE frami) dictionaries), 
http://extensions.services.openoffice.org/en/download/5092, download file>
de-AT -> (German (de-AT frami) dictionaries), link not available- 
network error, 
de-CH ->  (German (de-CH frami) dictionaries), 
http://extensions.services.openoffice.org/en/download/5091, download file>
en -> (English dictionaries with fixed dash handling and new ligature 
and phonetic suggestion support), 
http://extensions.services.openoffice.org/en/download/3814, download file>
en-US -> (US English Spell Checking Dictionary), 
http://extensions.services.openoffice.org/en/download/1471, download file>

...

[THESAURUS]
...


[this example list is based on wild guessing and browsing the available 
dictionaries in the ext repo, 
http://extensions.services.openoffice.org/en/dictionaries ]


I propose that we collect this list in the wiki first and prepare later 
on a simple text file that we can check-in in svn for the build process. 
As place for the wiki page I suggest a sub-page under 
https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning 
with the name "Bundled Default Language Tools" or so.


We need also a volunteer who analyze the mechanism to include these 
extensions in our binary releases ...


Does this make sense or does anybody have a better idea how to move 
forward with this?


Juergen

Re: [LEGAL] Something to solve: (c) Sun

[Louis Suárez-Potts]

Wow.
louis

2012/1/16 Pavel Janík :
> Hi,
>
> my build log contains 78 instances of:
>
>   Copyright: 2003 by Sun Microsystems, Inc.
>
> It is in this file:
>
> main/l10ntools/source/filter/merge/FCFGMerge.java:        
> sOut.append("Copyright: 2003 by Sun Microsystems, Inc.\n");
>
> --
> Pavel Janík
>
>
>

Re: Question related derivative code based on our Apache licensed code

[Pedro Giffuni]

Hi Michael;

Just to be clear ...
I am not a lawyer, and even if I were whatever I say in
respect to licensing doesn't have any legal permission
or state any rule wrt what should be done.

just to make that clear :).

--- Lun 16/1/12, Michael Meeks  ha scritto:

> Hi Pedro,
> 
> On Wed, 2012-01-04 at 06:38 -0800, Pedro Giffuni wrote:
> > What will happen is that the code will keep the
> MPL/LGPL3
> > restrictions in addition to the AL2.
> 
>     That would be the plan; though our code
> will -emphatically- not be
> available under the AL2; only an MPL/LGPLv3+ [as well as
> any lingering terms from the AL2].
> 

In the projects I participate we never *ever* replace a
license, we just add a copyright header with our license
when relevant. I would expect LO will have to comply
with AL2, adding the respective restrictions imposed
by your own licensing scheme (MPL/GPL).

> > - They will have to carry the AL2 license among their
> code
> > and headers, and the clause 5 is particularly nice to
> have.
> 
>     Clause five of the AL2 is:
> 
>     "5. Submission of Contributions. Unless
> You explicitly state
>  otherwise, any Contribution
> intentionally submitted for
>  inclusion in the Work by You
> to the Licensor shall be under the
>  terms and conditions of this
> License, without any additional
>  terms or conditions.
> Notwithstanding the above, nothing herein
>  shall supersede or modify the
> terms of any separate license
>  agreement you may have
> executed with Licensor regarding such
>  Contributions."
> 
>     IANAL, but to create a superabundance of
> clarity - no contribution
> submitted to LibreOffice is a 'Contribution'. It is not
> submitted to
> 'Licensor' which is ASF (cf. definition of Contribution).
> The TDF
> infrastructure is not /managed by, or on behalf of, the
> ASF/.
> 

Issue 5 only applies to contributions made to the Apache
project. Surely the code that has been contributed to LO
cannot be taken by us unless the author specifically
authorizes sends it to us too.

>     If it would help to clarify this, we can
> add a "Not a contribution"
> line or similar language to our new (MPL/LGPL)onAL2 header
> as/when we've got that worked through.
> 

This type of sillyness, attempting to obfuscate the language,
is one of the reasons why I keep away from projects with
unreadable licenses.

>     Of course, individuals are quite at
> liberty to choose to license their
> contributions to the ASF if they so choose, and to include
> -their- code
> into either project; though that is something I'd
> personally
> discourage :-)
> 
>     So - any expansion on "is particularly
> nice to have" would be helpful
> Pedro - why do you think this is particularly nice ? :-)
> 

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. Here
the term "stupid" has the same connotation as defined in
Carlo Cipola's classical paper:
http://cantrip.org/stupidity.html

(BTW, Anyone has a link to the original in italian?)

cheers,

Pedro.

R: [LEGAL] Something to solve: (c) Sun

[Pedro Giffuni]

Hi Pawel;

In general terms Copyright is not really an issue in Apache
projects. Apache projects don't ask for copyright assignment
and you can include your own copyright notices as long as
the licensing terms are acceptable.

This said, SUN Microsystems is now owned by Oracle so this
indicates there might be code to update there.

Pedro.

--- Lun 16/1/12, Pavel Janík  ha scritto:

> Data: Lunedì 16 gennaio 2012, 06:47
> Hi,
> 
> my build log contains 78 instances of:
> 
>    Copyright: 2003 by Sun Microsystems,
> Inc.
> 
> It is in this file:
> 
> main/l10ntools/source/filter/merge/FCFGMerge.java: 
>       sOut.append("Copyright: 2003 by Sun
> Microsystems, Inc.\n");
> 
> -- 
> Pavel Janík
> 
> 
> 
>

Re: Question related derivative code based on our Apache licensed code

[Norbert Thiebaud]

On Mon, Jan 16, 2012 at 9:28 AM, Pedro Giffuni  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: Question related derivative code based on our Apache licensed code

[Ross Gardler]

On 16 January 2012 15:41, Norbert Thiebaud  wrote:
> On Mon, Jan 16, 2012 at 9:28 AM, Pedro Giffuni  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 ?

It is the ASFs position that we do not take code that has not been
willingly contributed to us.

What this means in practical terms is that if we are not certain that
the code was intended as a contribution then we will not use it.
Furthermore, if we have any reason to doubt that the contributor is
authorised to make that contribution then we will not accept it.

Ross

-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: PROPOSAL (was Re: Category-B tarballs in SVN )

[Pedro Giffuni]

Hi Rob;

I specifically avoided answering to this on Sunday because
in my religious beliefs it is a day to rest and I didn't
really want to spend time on this.

Since the time this was posted I think I have seen the light
(TM) and I am willing to share it with you if you have the
patience.

The comments that follow are NOT meant for the faint of
heart if you are likely to have strong feelings about this
please STOP READING NOW. 

Also, if you are still here, remember ... don't kill
$MESSENGER.

--- Sab 14/1/12, Rob Weir  ha scritto:

> 
> OK, though this is solving a problem we don't really have,
> right?
> Although we have not yet built a script to produce a source
> package per Apache rules, when we do it will not include
> any of the /ext-src modules, correct?  It won't include
> the category-a and it will not include the category-b
> either?  What would be the point, since the
> build script brings down what it needs via the bootstrap,
> per the configuration flags used?  So if we really want to
> give proper notice to the person downloading our source
> release, this needs to be done:

We do have to include Category-A in the release or the
release wont build. Separation has to happen.

Here is the first big flaw in your reasoning: there is no
such thing as a source release or a binary release, there
is simply a release.

Let me explain it this way: long, long ago, before the
Internet ever was, release engineers would talk about
preparing the distribution stuff they could put into
specific media as a Release. The media then was usually
tapes, later floppies, then CDs, and with the advent of
the Internet new forms of media appeared and new formats
corresponded to those distribution, ZIP files, .tar.gz
archives, you get the idea.

Eventually, new releases and updates were made available
by electronic means without dealing directly with tarballs
or zipfiles and the tendency is indeed to use such modern
methods when possible. One of such methods is called
"subversion" (SVN) and it has been very popular in the
advent of Opensource software, where the source code is
sometimes more important than the accidental binaries.

And the point here is: a release is not just what is
included in a source tarball or a zipfile it is
what is tagged and branched in SVN. Also, if you
check the documentation on how tags and branches
are created you will notice we have to clearly separate
what belongs to the release to what doesn't.



> 
> I have no objections if you want to shuffle things around
> in the directory structure, and update bootstrap logic
> accordingly.

"shuffling" things is not a problem but I don't think
updating the bootstrap logic was mandatory. Our releases
have to build on their own and as you note the sources for
Category B stuff are not included anyways, but let me point
out the second big failure in your reasoning.

As I said before there is no such thing as "source releases"
or "binary releases" and such terms don't appear anywhere in
the the Apache licensing policies:

http://www.apache.org/legal/3party.html

Now, this phrase concerning Category-B has received a particular
wrong reading:

"Code that is more substantial, more volatile, or not directly
consumed at runtime in source form may only be distributed in
binary form."

We, and particularly you, have read this as a prohibition to
include MPL'd code in "source release" but the truth is that
it is a prohibition to distribute Category-B software *at
all*. Distribution certainly includes subversion.

The point is further clarified:
"In addition, C-based projects may have difficulty using works
under these licenses since they would have to deal with
platform-specific binaries, rather than just distributing
source that can be built on most any platform."

This last clarification has an upside: we can include in
our releases (and therefore in SVN) platform independent files
like Java bytecode and fonts under a Category-B license.

Pedro.

PS. My proposal was a step in the right direction but
given that it's already insufficient I hereby withdraw
it.

Re: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Jürgen Schmidt]

On 1/16/12 12:24 PM, Oliver-Rainer Wittmann wrote:

Hi,

On 16.01.2012 10:37, Jürgen Schmidt wrote:

Hi Oliver, Ariel,

i submitted minor branding relevant changes to get an impression how
it can look
like (nothing 100#% final if decide to change it).

I would like to propose that we prepare a new set of developer
snapshots based
on this version.

I have already started to build ...

- openofficedev_en-US
- a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
- language packs
ooodevlanguagepack_de
ooodevlanguagepack_fr
ooodevlanguagepack_es
ooodevlanguagepack_it
ooodevlanguagepack_ja
ooodevlanguagepack_zh-CN
ooodevlanguagepack_pt-BR
- sdkoodev

If you have time it would be perfect if you can provide the windows
and Linux
builds.



I have started the preparation (update local repository) of these builds
and will start building soon.


great, let me know when the builds are available and i will extend the 
new wiki page 
(https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots) 
where I have already linked to my MacOS developer snapshots.


@Ariel: please let me know if you can't provide new builds based on this 
revision. I will then setup my vbox to prepare the new builds.


I think it would be perfect when we try to provide new builds at least 
once a week (for example on Monday/Tuesday) based on the same revision. 
This way we can ensure that others can start with testing already and 
that we have a more or less aligned and coordinated process to provide 
these snapshot builds until we have build-bots for all platforms available.


Juergen




Best regards, Oliver.

Re: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Jürgen Schmidt]

On 1/16/12 6:07 PM, Jürgen Schmidt wrote:

On 1/16/12 12:24 PM, Oliver-Rainer Wittmann wrote:

Hi,

On 16.01.2012 10:37, Jürgen Schmidt wrote:

Hi Oliver, Ariel,

i submitted minor branding relevant changes to get an impression how
it can look
like (nothing 100#% final if decide to change it).

I would like to propose that we prepare a new set of developer
snapshots based
on this version.

I have already started to build ...

- openofficedev_en-US
- a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
- language packs
ooodevlanguagepack_de
ooodevlanguagepack_fr
ooodevlanguagepack_es
ooodevlanguagepack_it
ooodevlanguagepack_ja
ooodevlanguagepack_zh-CN
ooodevlanguagepack_pt-BR
- sdkoodev

If you have time it would be perfect if you can provide the windows
and Linux
builds.



I have started the preparation (update local repository) of these builds
and will start building soon.


great, let me know when the builds are available and i will extend the
new wiki page
(https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots)
where I have already linked to my MacOS developer snapshots.


One note to the MacOS builds. The icons in the dmg window of the Dev 
builds are at the wrong position. I know the root cause for this already 
and I am investigating a solution how I can fix it. The position in 
non-Dev builds is fine ;-)


Juergen



@Ariel: please let me know if you can't provide new builds based on this
revision. I will then setup my vbox to prepare the new builds.

I think it would be perfect when we try to provide new builds at least
once a week (for example on Monday/Tuesday) based on the same revision.
This way we can ensure that others can start with testing already and
that we have a more or less aligned and coordinated process to provide
these snapshot builds until we have build-bots for all platforms available.

Juergen




Best regards, Oliver.

Re: Apache list archive issues must be fixed soon

[Dave Fisher]

On Jan 16, 2012, at 12:11 AM, Kazunari Hirano wrote:

> Hi all,
> 
> Thank you, Ariel Constenla-Haile (arielch), for building developer's
> snapshot builds and langpacks for Windows.
> http://people.apache.org/~arielch/packages/
> Now we can find untranslated threads in the product.
> http://wiki.services.openoffice.org/wiki/JA/Apache_OpenOffice/OOO340_m1
> We would like to discuss in Japanese about Japanese translation for
> Apache OpenOffice on our native language list and made it public to
> Japanese users and contributors.
> But you see,
> http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/thread?0
> the list archive is unreadable.
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52195
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52182
> We want these issues to be fixed soon.

So sorry, but these are filed in the AOO issue tracker. Apache Infrastructure 
will never find issues there. It is not their issue tracker.

For Apache Infrastructure issues, it is JIRA here: 
https://issues.apache.org/jira/browse/INFRA

I created https://issues.apache.org/jira/browse/INFRA-4334 which links to the 
two issues in the AOO BZ.

I think that parts of these issues have been resolved for other reasons and 
that the subject encoding is the remaining issue. I could be wrong.

Regards,
Dave


> 
> We are getting closer to Apache OpenOffice release, aren't we?
> We should start localization and translation efforts as soon as possible, 
> right?
> As soon as the list archive issues are fixed, I would like to prepare
> an announcement to the world people "Apache OpenOffice call for help
> on localization and translation, Help build Apache OpenOffice for your
> language"
> :)
> Thanks,
> khirano
> -- 
> khir...@apache.org
> Apache OpenOffice (incubating)
> http://incubator.apache.org/openofficeorg/

Re: New feature: Drawing thick lines with line caps

[Armin Le Grand]

Hi Andrea,

On 14.01.2012 23:32, Andrea Pescetti wrote:

On 13/01/2012 Armin Le Grand wrote:

again updated to trunk (after some Svg fixes) and built. Find the
linecap install sets under:
Win: http://people.apache.org/~alg/linecap/wntmsci12/
Linux64bit: http://people.apache.org/~alg/linecap/unxlngx6/
Have fun checking out the LineCap feature!


Thanks Regina, Armin,
but would it be possible to have just a couple screenshots with "Before
and After" the Linecap feature, for those who are not familiar with
terminology and can't install the builds you provided? It's all stuff
that we will need to reuse in the release notes anyway, and useful
information for potential testers.


Well, screenshots would be stripped from the newsgroup, but I can at 
least offer this link 
(http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#StrokeLinecapProperty) 
to the Svg definition of w3.org. This feature is pretty much exactly 
about that. OOo did never support it, but pretty much all other graphic 
systems/definitions do nowadays. The feature is about integrating this 
into AOO, UI, core, Odf, painting, printing, exports, imports, etc. In 
short everywhere where it will be useful.




Regards,
Andrea.



HTH!
Sincerely,
Armin
--
ALG

RE: Question related derivative code based on our Apache licensed code

[Dennis E. Hamilton]

OT: 
?

It is conceivable that Cipola produced the English versions himself.  A number 
of his papers have English-language titles.

But the Italian title, leads to these: 


The full title is "Le leggi fundamentali della stupidità humana" and I see 
there is a Facebook group for it (?!).

 - Dennis

-Original Message-
From: Pedro Giffuni [mailto:p...@apache.org] 
Sent: Monday, January 16, 2012 07:28
To: ooo-dev@incubator.apache.org; michael.me...@suse.com
Subject: Re: Question related derivative code based on our Apache licensed code

[ ... ]

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. Here
the term "stupid" has the same connotation as defined in
Carlo Cipola's classical paper:
http://cantrip.org/stupidity.html

(BTW, Anyone has a link to the original in italian?)

cheers,

Pedro.

Re: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Ariel Constenla-Haile]

On Mon, Jan 16, 2012 at 06:07:27PM +0100, Jürgen Schmidt wrote:
> On 1/16/12 12:24 PM, Oliver-Rainer Wittmann wrote:
> >Hi,
> >
> >On 16.01.2012 10:37, Jürgen Schmidt wrote:
> >>Hi Oliver, Ariel,
> >>
> >>i submitted minor branding relevant changes to get an impression how
> >>it can look
> >>like (nothing 100#% final if decide to change it).
> >>
> >>I would like to propose that we prepare a new set of developer
> >>snapshots based
> >>on this version.
> >>
> >>I have already started to build ...
> >>
> >>- openofficedev_en-US
> >>- a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
> >>- language packs
> >>ooodevlanguagepack_de
> >>ooodevlanguagepack_fr
> >>ooodevlanguagepack_es
> >>ooodevlanguagepack_it
> >>ooodevlanguagepack_ja
> >>ooodevlanguagepack_zh-CN
> >>ooodevlanguagepack_pt-BR
> >>- sdkoodev
> >>
> >>If you have time it would be perfect if you can provide the windows
> >>and Linux
> >>builds.
> >>
> >
> >I have started the preparation (update local repository) of these builds
> >and will start building soon.
> 
> great, let me know when the builds are available and i will extend
> the new wiki page 
> (https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots)
> where I have already linked to my MacOS developer snapshots.
> 
> @Ariel: please let me know if you can't provide new builds based on
> this revision. I will then setup my vbox to prepare the new builds.

I can. I guess they will be uploaded tomorrow (building is faster in my
6 core PC, but uploading each full install set takes about 30 min, vid.
http://people.apache.org/~arielch/packages/scp.log )


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpMzQs7w8ZHh.pgp
Description: PGP signature

Re: [ANNOUNCEMENT][THANKS] Apache ODF Toolkit(Incubating) 0.5-incubating Release

[Mattmann, Chris A (388J)]

Congrats guys!

Cheers,
Chris

On Jan 16, 2012, at 4:59 AM, Devin Han wrote:

> Hi all,
> 
> Thanks all of the voters from this list. Now there is a result ;)
> 
> The Apache ODF Toolkit(Incubating) team is pleased to announce the release
> of 0.5-incubating. This is our first Apache release.
> 
> The Apache ODF Toolkit is a set of Java modules that allow programmatic
> creation, scanning and manipulation of Open Document Format (ISO/IEC 26300
> == ODF) documents. Unlike other approaches which rely on runtime
> manipulation of heavy-weight editors via an automation interface, the ODF
> Toolkit is lightweight and ideal for server use.
> 
> A full list of changes is available in the change log[1]. People interested
> should also follow the mail list[2] to track progress.
> 
> The ODF Toolkit source release as well as the pre-built binary deployment
> packages are listed in the downloads page[3]. Pre-built versions of all ODF
> Toolkit components are available in the central Maven repository under
> Group ID "org.apache.odftoolkit" and Version "0.5-incubating".
> 
> [1]
> http://www.apache.org/dist/incubator/odftoolkit/CHANGES-0.5-incubating.txt.
> [2] http://incubator.apache.org/odftoolkit/mailing-lists.html.
> [3] http://incubator.apache.org/odftoolkit/downloads.html
> 
> -- 
> -Devin


++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++

Trying to add more quality to openoffice

[p.a.sa.h.]

A good day,
Still not knowing how to find an OpenOffice more appropriate contact, this
is the most immediate i found, so please forward it to someone who can
really do something. I'm sending two files that weren't opened correctly by
your application software: the two originally contain a cover sheet from
the Microsoft word (latest version i guess) library, but openoffice does
not show that cover sheet, only the body of the text.


Ficha de Cliente.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document


Título do documento.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

Re: New feature: Drawing thick lines with line caps

[Regina Henschel]

Hi Andrea,

Andrea Pescetti schrieb:

On 13/01/2012 Armin Le Grand wrote:

again updated to trunk (after some Svg fixes) and built. Find the
linecap install sets under:
Win: http://people.apache.org/~alg/linecap/wntmsci12/
Linux64bit: http://people.apache.org/~alg/linecap/unxlngx6/
Have fun checking out the LineCap feature!


Thanks Regina, Armin,
but would it be possible to have just a couple screenshots with "Before
and After" the Linecap feature, for those who are not familiar with
terminology and can't install the builds you provided? It's all stuff
that we will need to reuse in the release notes anyway, and useful
information for potential testers.


I have added a Wiki page about it
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Release+Notes

[Feel free to correct it, I'm no native English speaker.]

Kind regards
Regina

Re: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Oliver-Rainer Wittmann]

Hi Jürgen,

On 16.01.2012 18:07, Jürgen Schmidt wrote:

On 1/16/12 12:24 PM, Oliver-Rainer Wittmann wrote:

Hi,

On 16.01.2012 10:37, Jürgen Schmidt wrote:

Hi Oliver, Ariel,

i submitted minor branding relevant changes to get an impression how
it can look
like (nothing 100#% final if decide to change it).

I would like to propose that we prepare a new set of developer
snapshots based
on this version.

I have already started to build ...

- openofficedev_en-US
- a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
- language packs
ooodevlanguagepack_de
ooodevlanguagepack_fr
ooodevlanguagepack_es
ooodevlanguagepack_it
ooodevlanguagepack_ja
ooodevlanguagepack_zh-CN
ooodevlanguagepack_pt-BR
- sdkoodev

If you have time it would be perfect if you can provide the windows
and Linux
builds.



I have started the preparation (update local repository) of these builds
and will start building soon.


great, let me know when the builds are available and i will extend the new wiki
page
(https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots)
where I have already linked to my MacOS developer snapshots.



My builds are available at 
http://people.apache.org/~orw/DevSnapshots-Rev.1231878/win32/



@Ariel: please let me know if you can't provide new builds based on this
revision. I will then setup my vbox to prepare the new builds.

I think it would be perfect when we try to provide new builds at least once a
week (for example on Monday/Tuesday) based on the same revision. This way we can
ensure that others can start with testing already and that we have a more or
less aligned and coordinated process to provide these snapshot builds until we
have build-bots for all platforms available.



+1

Best regards, Oliver.

Re: Seeking Bugzilla Admin Volunteers

[Rob Weir]

On Sun, Jan 15, 2012 at 10:05 AM, Dave Fisher  wrote:
>
> On Jan 15, 2012, at 1:49 AM, Andrea Pescetti wrote:
>
>> Rob Weir wrote:
>>> Did you read anyone say that current privileges are going to be
>>> dropped?  I certainly did not say that.
>>
>> No, but that was a doubt I had: in the process of granting new privileges, 
>> it might be that someone notices that a lot of people already have high 
>> privileges, and that this group includes people currently unaffiliated with 
>> the project. I was just making sure that current privileges are not dropped 
>> now: this will still be an issue, but it can be dealt with separately.
>
> We need to have a common set of privileges for ALL committers. We should not 
> have to request it, it should be done.
>

That is a curious statement, considering that:

- committers are not automatically subscribed to ooo-private.

- committers are not automatically list moderators.  They need to request it.

- committers are not automatically blog editors.  They need to request it.

- committers are not automatically wiki editors or admins.  They need
to request it.

- committers are not automatically forum editors or admins.  They need
to request it.

So far as I can tell, the only thing that happens automatically for
committers is SVN access. And even that is not really automatic.

Given the above, I had no expectations that Bugzilla access for
committers would happen without request.  Do you have a reason to be
optimistic in this case?

And are you suggesting we wait for this to happen?  Or would it make
more sense to get a few volunteers, per my original note, and go
forward with that for now?

-Rob


> The PPMC should decide what the normal set of privileges should be for the 
> general community as well.
>
> Maybe as another thread this will noticed.
>
> I am really glad I rejected using BZ to discuss the website a few months ago 
> since no privileges with the AOO BZ have been assigned to anyone who wasn't 
> with the former project yet former members who have not continued with this 
> project still have privileges.
>
> This is a huge issue and ought to be addressed this week.
>
> Regards,
> Dave
>
>>
>> Regards,
>>  Andrea.
>

Re: Seeking Bugzilla Admin Volunteers

[Rob Weir]

On Sun, Jan 15, 2012 at 4:49 AM, Andrea Pescetti  wrote:
> Rob Weir wrote:
>>
>> Did you read anyone say that current privileges are going to be
>> dropped?  I certainly did not say that.
>
>
> No, but that was a doubt I had: in the process of granting new privileges,
> it might be that someone notices that a lot of people already have high
> privileges, and that this group includes people currently unaffiliated with
> the project. I was just making sure that current privileges are not dropped
> now: this will still be an issue, but it can be dealt with separately.
>

That is something we need to deal with, eventually.  Having escalated
privileges associated with people no longer involved with the project
is bad for security. (Wasn't the vector of the last hack of the Apache
website via a XSS attack of bug tracking admin accounts?)

Remember, we can always add permissions back for someone if they did
not see and respond to this note.

Another option is to generate a report of all ID's with elevated
privileges and have that sent to ooo-private where we can decide next
steps.

-Rob

> Regards,
>  Andrea.

Website Help

[Roman Meisenberg]

Hi!

I just stumbled upon the Help Wanted page on the Apache Wiki. I would love
to help out with the website.
I am a web developer and photographer from NYC. How would I go about
getting started on this if you still
require the help?

Thanks so much!

-- 
Roman Meisenberg
p. 213.53.ROMAN
f.  763.322.2274
--
silenceproductions.net
ro...@silenceproductions.net
--
New York, NY
Miami, FL
Los Angeles, CA

Please consider the environment before printing this e-mail.

Re: Question related derivative code based on our Apache licensed code

[Rob Weir]

On Mon, Jan 16, 2012 at 7:31 AM, Michael Meeks  wrote:
> Hi Pedro,
>
> On Wed, 2012-01-04 at 06:38 -0800, Pedro Giffuni wrote:
>> What will happen is that the code will keep the MPL/LGPL3
>> restrictions in addition to the AL2.
>
>        That would be the plan; though our code will -emphatically- not be
> available under the AL2; only an MPL/LGPLv3+ [as well as any lingering
> terms from the AL2].
>

In what sense do you mean "our code"?  Is that the "royal we" or are
you speaking on behalf of Suse?

As far as I can tell, there is nothing that would prevent an
individual developer from submitting a patch to this mailing list or
to the LO mailing list and saying it was available AL2 or MPL/LGPL at
the receiver's election.

These are the rights that creative people have over their creative
works, that they own the copyright and can assign permissions pretty
much as they wish.  Unless, of course, TDF/LO intends to institute
some sort of CLA that would prohibit the author of code to share it as
they wish?

>> - They will have to carry the AL2 license among their code
>> and headers, and the clause 5 is particularly nice to have.
>
>        Clause five of the AL2 is:
>
>        "5. Submission of Contributions. Unless You explicitly state
>         otherwise, any Contribution intentionally submitted for
>         inclusion in the Work by You to the Licensor shall be under the
>         terms and conditions of this License, without any additional
>         terms or conditions. Notwithstanding the above, nothing herein
>         shall supersede or modify the terms of any separate license
>         agreement you may have executed with Licensor regarding such
>         Contributions."
>
>        IANAL, but to create a superabundance of clarity - no contribution
> submitted to LibreOffice is a 'Contribution'. It is not submitted to
> 'Licensor' which is ASF (cf. definition of Contribution). The TDF
> infrastructure is not /managed by, or on behalf of, the ASF/.
>

Understood.  But (and correct me if I am mistaken) the TDF
infrastructure is not managed by or on behalf of the Free Software
Foundation or the Mozilla Foundation, but still your users opt to send
declarations like the following to your mailing list:

http://lists.freedesktop.org/archives/libreoffice/2011-November/021345.html

So the org that runs your website and the org that wrote the license
are no necessarily connected, and it is rather silly to confuse them.

In any case it would be trivial for a developer to add ("as well as
Apache License v2") to such a statement.  If that is not clear to
developers, then maybe I can help make this fact better known.

>        If it would help to clarify this, we can add a "Not a contribution"
> line or similar language to our new (MPL/LGPL)onAL2 header as/when we've
> got that worked through.
>
>        Of course, individuals are quite at liberty to choose to license their
> contributions to the ASF if they so choose, and to include -their- code
> into either project; though that is something I'd personally
> discourage :-)
>

Well, that's one reason we have pseudonyms.

>        So - any expansion on "is particularly nice to have" would be helpful
> Pedro - why do you think this is particularly nice ? :-)
>
>        All the best,
>
>                Michael.
>
> --
> michael.me...@suse.com  <><, Pseudo Engineer, itinerant idiot
>

Re: PROPOSAL (was Re: Category-B tarballs in SVN )

[Rob Weir]

On Mon, Jan 16, 2012 at 6:07 AM, Ross Gardler
 wrote:
> On 15 January 2012 03:29, Rob Weir  wrote:
>> On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni  wrote:
>>> Hello fellow indians; ;)
>>>
>>> I think there is consensus that this is (at least)
>>> a gray area so I have the following proposal, which
>>> shouldn't get in the way of having this properly
>>> solved by legal but which I think should solve at
>>> least temporarily the issues that we have. It's
>>> actually very simple but who knows, maybe it's even
>>> acceptable as a general incubator policy at the ASF.
>>>
>>> The ext_source in shall be divided, according to
>>> the categories of the licenses, into two
>>> directories in SVN, namely:
>>>
>>> ext_source_A
>>> ext_source_B
>>>
>>
>> This is assuming all 3rd party modules are pure, under a single
>> license.  I don't believe this is always the case.
>
> Then can /should they be put in the most restrictive category?
>

They certainly could.  But the categories are really an creature of
Apache policy.  They are not necessarily relevant to downstream
consumers, whose policies could be quite different than ours.   That's
why it is good that we give the complete details in the LICENSE file
rather than some Apache-centric view of the world.  That's why I think
it would be far more useful to summarize exactly what license applies.
 We could even make a nice HTML table of this:  component, version,
original URL, license, etc.

>> Why not treat it the way we treat 3rd party modules in releases, e.g.,
>> with a LICENSE and NOTICE file?  We could put a LICENSE file in
>> /ext-src.  That would make it clear to anyone who browses that
>> directory.
>
> +1
>
> On one of the projects I work on we require libraries to have a
> corresponding licences/FOOBAR_license.txt file This then allows some
> simple machine processing to check the license is correctly recorded
> against all libraries included. This is built into the build system
> and automatically flags when something seems to be missing.
>

That could work.

>>> - Ext_source_B shall have a prominent text note that warns
>>> users that the code there is made available only for
>>> builder convenience but that the code is in general
>>> not acceptable for inclusion in Apache source code
>>> releases.
>>>
>>
>> OK, though this is solving a problem we don't really have, right?
>
> I think the point is that it clearly separates out stuff that is OK to
> stay and stuff that needs to be carefully managed. It's a step towards
> satisfying those who are concerned about including this source whilst
> avoiding the need to remove the convenience for developers of having
> the source available.
>

We already do that.  All of these third party modules are already
segregated from the main SVN tree.  This is true regardless of
license.   The legacy project didn't have them under version control.
They just stored them on a web server, totally separated from the
source code for OOo.That option did not appear to be available to
us at Apache, so we stick them in the ext-src directory in SVN.

> This separation will make it easier for people to evaluate the impact
> of these files when it comes to graduation and will serve to signal
> that there is a process in place for the management of these
> dependencies (or that there needs to be a process).
>

Or we could document exactly what we're doing now, the precautions
we're already taking.  It seems that it would be hard to say whether
what we're doing already is inadequate if you don't know what exactly
we're already doing.  Not you specifically, but in general.

>>  So if we really want to give proper notice
>> to the person downloading our source release, this needs to be done:
>> 1) In the LICENSE and NOTICE files
>
> That has to happen anyway (for cat b licenses).
>

Category-b doesn't go out in released source packages.  And for binary
packages we're already include the required licenses and
notifications.


>> Putting extra verbiage in the SVN tree that is not included in the
>> releases -- I don't see the point.  Is this to protect casual browsers
>> of our SVN tree?
>
> For me the point is not about casual browers it is about developers
> like me who don't download source tars but instead checkout from SVN.
> We can't assume that all such developers will understand the nuances
> of license compatibility or even bother to check.
>

That maybe is the piece of the puzzle that may not be clear unless you
are a developer building AOO.  You do not need to checkout the
category-b source bundles from SVN.  In fact you should not.  You
would only be wasting harddrive space. Our build doc doesn't call for
these modules to be checked-out.  Someone would need to go out of
their way to check them out of SVN explicitly.  The whole idea is that
these are downloaded via the build script, based on the configure
options chosen by the builder.  If they want to build the default
binaries, with no category-b code, then of course, none 

Re: PROPOSAL (was Re: Category-B tarballs in SVN )

[Rob Weir]

On Mon, Jan 16, 2012 at 11:17 AM, Pedro Giffuni  wrote:
> Hi Rob;
>
> I specifically avoided answering to this on Sunday because
> in my religious beliefs it is a day to rest and I didn't
> really want to spend time on this.
>
> Since the time this was posted I think I have seen the light
> (TM) and I am willing to share it with you if you have the
> patience.
>
> The comments that follow are NOT meant for the faint of
> heart if you are likely to have strong feelings about this
> please STOP READING NOW.
>
> Also, if you are still here, remember ... don't kill
> $MESSENGER.
>
> --- Sab 14/1/12, Rob Weir  ha scritto:
>
>>
>> OK, though this is solving a problem we don't really have,
>> right?
>> Although we have not yet built a script to produce a source
>> package per Apache rules, when we do it will not include
>> any of the /ext-src modules, correct?  It won't include
>> the category-a and it will not include the category-b
>> either?  What would be the point, since the
>> build script brings down what it needs via the bootstrap,
>> per the configuration flags used?  So if we really want to
>> give proper notice to the person downloading our source
>> release, this needs to be done:
>
> We do have to include Category-A in the release or the
> release wont build. Separation has to happen.
>

I was talking about source packages.  They are not required to include
everything that needed to produce the binary package. For example, we
don't include Visual C++ or gcc or a copy of Microsoft Windows.
Generally, tools and libraries that are commonly available we treat as
a pre-requisite.

With category-a source code, I think from a policy perspective, we
could include the source in our release, we could require the user to
download manually as a per-requisite, or we could have the build
scripts do this automatically, from an external server or an Apache
server.

> Here is the first big flaw in your reasoning: there is no
> such thing as a source release or a binary release, there
> is simply a release.
>
> Let me explain it this way: long, long ago, before the



Yes, I believe we all know and understand this.  That is why I've been
using the terms "source package" and "binary package".  An Apache
"release" would include at least the source package.  The current plan
for AOO is to have both.


>
>
>>
>> I have no objections if you want to shuffle things around
>> in the directory structure, and update bootstrap logic
>> accordingly.
>
> "shuffling" things is not a problem but I don't think
> updating the bootstrap logic was mandatory. Our releases
> have to build on their own and as you note the sources for
> Category B stuff are not included anyways, but let me point
> out the second big failure in your reasoning.
>
> As I said before there is no such thing as "source releases"
> or "binary releases" and such terms don't appear anywhere in
> the the Apache licensing policies:
>
> http://www.apache.org/legal/3party.html
>

That URL is for an earlier draft of the policy.  You really should be
referencing the latest version of the policy here:

http://www.apache.org/legal/resolved.html#category-b

> Now, this phrase concerning Category-B has received a particular
> wrong reading:
>
> "Code that is more substantial, more volatile, or not directly
> consumed at runtime in source form may only be distributed in
> binary form."
>

That sentence does not exist in the actual policy.   That is only in the draft.

> We, and particularly you, have read this as a prohibition to

Oh, I didn't read it it all, since that is in the draft version only.

> include MPL'd code in "source release" but the truth is that
> it is a prohibition to distribute Category-B software *at
> all*. Distribution certainly includes subversion.
>

http://www.apache.org/legal/resolved.html#category-b

> The point is further clarified:
> "In addition, C-based projects may have difficulty using works
> under these licenses since they would have to deal with
> platform-specific binaries, rather than just distributing
> source that can be built on most any platform."
>

Again, this is not in the real policy.

> This last clarification has an upside: we can include in
> our releases (and therefore in SVN) platform independent files
> like Java bytecode and fonts under a Category-B license.
>

In any case, I think we've found one source of the confusion here.

Take a look at the live version of the policy (it does get updated
from time to time) and let me know if you still see policy concerns
with including category-b in binary form, in the binary packages of
our releases:

http://www.apache.org/legal/resolved.html#category-b

Regards,

-Rob


> Pedro.
>
> PS. My proposal was a step in the right direction but
> given that it's already insufficient I hereby withdraw
> it.
>

RE: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Arthur Buijs]

How can I help to add _nl to this list?

-- Arthur


-Original message-
To: ooo-dev@incubator.apache.org; 
From:   Jürgen Schmidt 
Sent:   Mon 16-01-2012 18:08
Subject:Re: [BUILD]: propose new Developer snapshot builds based on 
revision r1231878
> On 1/16/12 12:24 PM, Oliver-Rainer Wittmann wrote:
> > Hi,
> >
> > On 16.01.2012 10:37, Jürgen Schmidt wrote:
> >> Hi Oliver, Ariel,
> >>
> >> i submitted minor branding relevant changes to get an impression how
> >> it can look
> >> like (nothing 100#% final if decide to change it).
> >>
> >> I would like to propose that we prepare a new set of developer
> >> snapshots based
> >> on this version.
> >>
> >> I have already started to build ...
> >>
> >> - openofficedev_en-US
> >> - a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
> >> - language packs
> >> ooodevlanguagepack_de
> >> ooodevlanguagepack_fr
> >> ooodevlanguagepack_es
> >> ooodevlanguagepack_it
> >> ooodevlanguagepack_ja
> >> ooodevlanguagepack_zh-CN
> >> ooodevlanguagepack_pt-BR
> >> - sdkoodev
> >>
> >> If you have time it would be perfect if you can provide the windows
> >> and Linux
> >> builds.
> >>
> >
> > I have started the preparation (update local repository) of these builds
> > and will start building soon.
> 
> great, let me know when the builds are available and i will extend the 
> new wiki page 
> (https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Develop
> er+Snapshots) 
> where I have already linked to my MacOS developer snapshots.
> 
> @Ariel: please let me know if you can't provide new builds based on this 
> revision. I will then setup my vbox to prepare the new builds.
> 
> I think it would be perfect when we try to provide new builds at least 
> once a week (for example on Monday/Tuesday) based on the same revision. 
> This way we can ensure that others can start with testing already and 
> that we have a more or less aligned and coordinated process to provide 
> these snapshot builds until we have build-bots for all platforms available.
> 
> Juergen
> 
> 
> >
> > Best regards, Oliver.
> 
>

Re: Seeking Bugzilla Admin Volunteers

[Dave Fisher]

On Jan 16, 2012, at 12:34 PM, Rob Weir wrote:

> On Sun, Jan 15, 2012 at 10:05 AM, Dave Fisher  wrote:
>> 
>> On Jan 15, 2012, at 1:49 AM, Andrea Pescetti wrote:
>> 
>>> Rob Weir wrote:
 Did you read anyone say that current privileges are going to be
 dropped?  I certainly did not say that.
>>> 
>>> No, but that was a doubt I had: in the process of granting new privileges, 
>>> it might be that someone notices that a lot of people already have high 
>>> privileges, and that this group includes people currently unaffiliated with 
>>> the project. I was just making sure that current privileges are not dropped 
>>> now: this will still be an issue, but it can be dealt with separately.
>> 
>> We need to have a common set of privileges for ALL committers. We should not 
>> have to request it, it should be done.
>> 
> 
> That is a curious statement, considering that:

For the BZ to be useful to the community it must be possible for any 
contributor to have sufficient privileges to engage in the process.

In the project's that I work on like Apache POI everyone has BZ rights to 
create issues and change status. AFAIK it is very open and very helpful and 
actually leads to valuable conversations with users. Even if some are similar 
to a no its not a bug yes it is. No matter.

You are allowed basic rights to open, comment, update and close JIRA issues at 
Apache. Admin rights are special.

BTW - an open BZ provides another path for contributors to get attention and 
possibly become committers.

> 
> - committers are not automatically subscribed to ooo-private.

So far, every committer is given the opportunity to do so. And it is 
exceedingly easy.

> - committers are not automatically list moderators.  They need to request it.
> 
> - committers are not automatically blog editors.  They need to request it.
> 
> - committers are not automatically wiki editors or admins.  They need
> to request it.

How much use has the project made of OOODEV cwiki vs. OOOUSERS cwiki? One is by 
request and the other is open to anyone.

IMO we should ask Infrastructure to drop OOODEV.

> 
> - committers are not automatically forum editors or admins.  They need
> to request it.
> 
> So far as I can tell, the only thing that happens automatically for
> committers is SVN access. And even that is not really automatic.

I watch the Infrastructure ML. It is part of the workflow when the PPMC 
requests the committer's id. An incubator committer is a more difficult setup 
than a TLP committer, there is an extra step for Apache CMS permission.

> 
> Given the above, I had no expectations that Bugzilla access for
> committers would happen without request.  Do you have a reason to be
> optimistic in this case?

We have our own, separate BZ that is NOT part of the normal Apache BZ. Perhaps 
it was missed back in July, but we are responsible. That's the cost for keeping 
the old issue ids.


> 
> And are you suggesting we wait for this to happen?

Given that we are accountable for this BZ we as the PPMC are responsible for 
its state.

>  Or would it make
> more sense to get a few volunteers, per my original note, and go
> forward with that for now?

Yes, I agree that we need to get some volunteers. We should define what we want 
our BZ admins to do.

I would like to know the current mysterious closed policy and workflow in this 
custom BZ. It really bothers me that we have no clue who has authority and who 
doesn't. We are responsible.

I would like to discuss what the policy should become.  IMO - Open up normal, 
non-admin permissions to all of the project's committers. Also, open normal 
permissions up to the community as a whole. If someone abuses their privileges 
then remove them. The BZ admin will need to deal with Spammers.

Regards,
Dave

> 
> -Rob
> 
> 
>> The PPMC should decide what the normal set of privileges should be for the 
>> general community as well.
>> 
>> Maybe as another thread this will noticed.
>> 
>> I am really glad I rejected using BZ to discuss the website a few months ago 
>> since no privileges with the AOO BZ have been assigned to anyone who wasn't 
>> with the former project yet former members who have not continued with this 
>> project still have privileges.
>> 
>> This is a huge issue and ought to be addressed this week.
>> 
>> Regards,
>> Dave
>> 
>>> 
>>> Regards,
>>>  Andrea.
>> 

Re: Seeking Bugzilla Admin Volunteers

[Rob Weir]

On Mon, Jan 16, 2012 at 5:18 PM, Dave Fisher  wrote:
>
> On Jan 16, 2012, at 12:34 PM, Rob Weir wrote:
>
>> On Sun, Jan 15, 2012 at 10:05 AM, Dave Fisher  wrote:
>>>
>>> On Jan 15, 2012, at 1:49 AM, Andrea Pescetti wrote:
>>>
 Rob Weir wrote:
> Did you read anyone say that current privileges are going to be
> dropped?  I certainly did not say that.

 No, but that was a doubt I had: in the process of granting new privileges, 
 it might be that someone notices that a lot of people already have high 
 privileges, and that this group includes people currently unaffiliated 
 with the project. I was just making sure that current privileges are not 
 dropped now: this will still be an issue, but it can be dealt with 
 separately.
>>>
>>> We need to have a common set of privileges for ALL committers. We should 
>>> not have to request it, it should be done.
>>>
>>
>> That is a curious statement, considering that:
>
> For the BZ to be useful to the community it must be possible for any 
> contributor to have sufficient privileges to engage in the process.
>
> In the project's that I work on like Apache POI everyone has BZ rights to 
> create issues and change status. AFAIK it is very open and very helpful and 
> actually leads to valuable conversations with users. Even if some are similar 
> to a no its not a bug yes it is. No matter.
>
> You are allowed basic rights to open, comment, update and close JIRA issues 
> at Apache. Admin rights are special.
>
> BTW - an open BZ provides another path for contributors to get attention and 
> possibly become committers.
>
>>
>> - committers are not automatically subscribed to ooo-private.
>
> So far, every committer is given the opportunity to do so. And it is 
> exceedingly easy.
>
>> - committers are not automatically list moderators.  They need to request it.
>>
>> - committers are not automatically blog editors.  They need to request it.
>>
>> - committers are not automatically wiki editors or admins.  They need
>> to request it.
>
> How much use has the project made of OOODEV cwiki vs. OOOUSERS cwiki? One is 
> by request and the other is open to anyone.
>
> IMO we should ask Infrastructure to drop OOODEV.
>
>>
>> - committers are not automatically forum editors or admins.  They need
>> to request it.
>>
>> So far as I can tell, the only thing that happens automatically for
>> committers is SVN access. And even that is not really automatic.
>
> I watch the Infrastructure ML. It is part of the workflow when the PPMC 
> requests the committer's id. An incubator committer is a more difficult setup 
> than a TLP committer, there is an extra step for Apache CMS permission.
>
>>
>> Given the above, I had no expectations that Bugzilla access for
>> committers would happen without request.  Do you have a reason to be
>> optimistic in this case?
>
> We have our own, separate BZ that is NOT part of the normal Apache BZ. 
> Perhaps it was missed back in July, but we are responsible. That's the cost 
> for keeping the old issue ids.
>
>
>>
>> And are you suggesting we wait for this to happen?
>
> Given that we are accountable for this BZ we as the PPMC are responsible for 
> its state.
>
>>  Or would it make
>> more sense to get a few volunteers, per my original note, and go
>> forward with that for now?
>
> Yes, I agree that we need to get some volunteers. We should define what we 
> want our BZ admins to do.
>

OK.That is clearer.  When you previously said, "We should not have
to request it, it should be done" I took that as it should be
technologically done, and done automatically without request.  I see
now that you mean it should be done as a matter of our ordinary
process and workflow, although it may require a manual step.  +1 on
that.

> I would like to know the current mysterious closed policy and workflow in 
> this custom BZ. It really bothers me that we have no clue who has authority 
> and who doesn't. We are responsible.
>
> I would like to discuss what the policy should become.  IMO - Open up normal, 
> non-admin permissions to all of the project's committers. Also, open normal 
> permissions up to the community as a whole. If someone abuses their 
> privileges then remove them. The BZ admin will need to deal with Spammers.
>

+1   But is there any way we can have our own BZ Admin distribution
list?  It is extremely weird that I get BZ Admin emails for all
projects, including AOO, though I appear to have admin privileges for
none of them

> Regards,
> Dave
>
>>
>> -Rob
>>
>>
>>> The PPMC should decide what the normal set of privileges should be for the 
>>> general community as well.
>>>
>>> Maybe as another thread this will noticed.
>>>
>>> I am really glad I rejected using BZ to discuss the website a few months 
>>> ago since no privileges with the AOO BZ have been assigned to anyone who 
>>> wasn't with the former project yet former members who have not continued 
>>> with this project still have privileges.
>>>
>>> Th

Re: [RELEASE]: help wanted to define default dictionaries for languages

[RGB ES]

2012/1/16 Jürgen Schmidt 

> Hi,
>
> [based on the assumption that we get the approval to bundle the
> dictionaries/thesaurus with our binary releases]
>
> I am not really familiar with thwe dictionaries/thesaurus and would like
> to ask for help to define a list of default dictionaries/thesaurus for each
> language if possible.
>
> Based on this list we have to work on a mechanism to include the
> dictionaries in our binary releases.
>
> I think about a simple list where we define the default dictionary for
> each language. Something like
>
> [DICTIONARIES]
> de -> (German (de-DE frami) dictionaries), http://extensions.services.**
> openoffice.org/en/download/**5092,
> 
> de-DE -> (German (de-DE frami) dictionaries), http://extensions.services.*
> *openoffice.org/en/download/**5092,
> 
> de-AT -> (German (de-AT frami) dictionaries), link not available- network
> error, 
> de-CH ->  (German (de-CH frami) dictionaries), http://extensions.services.
> **openoffice.org/en/download/**5091,
> 
> en -> (English dictionaries with fixed dash handling and new ligature and
> phonetic suggestion support), http://extensions.services.**
> openoffice.org/en/download/**3814,
> 
> en-US -> (US English Spell Checking Dictionary),
> http://extensions.services.**openoffice.org/en/download/**1471,
> 
> ...
>
> [THESAURUS]
> ...
>
>
> [this example list is based on wild guessing and browsing the available
> dictionaries in the ext repo, http://extensions.services.**
> openoffice.org/en/dictionaries]
>
> I propose that we collect this list in the wiki first and prepare later on
> a simple text file that we can check-in in svn for the build process. As
> place for the wiki page I suggest a sub-page under
> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Project+Planningwith
>  the name "Bundled Default Language Tools" or so.
>
> We need also a volunteer who analyze the mechanism to include these
> extensions in our binary releases ...
>
> Does this make sense or does anybody have a better idea how to move
> forward with this?
>
> Juergen
>
>
>
The Spanish thesaurus and hyphenation patterns can be found here:
http://openthes-es.berlios.de/
The spellchecker dictionary can be found here:
http://forja.rediris.es/frs/?group_id=341&release_id=1000
but I need to do some tests: I have problems installing it on recent dev
builds...

Cheers
Ricardo

Re: [build] planning to create new developer snapshots

[Kay Schenk]

On Sun, Jan 15, 2012 at 10:57 PM, Oliver-Rainer Wittmann <
orwittm...@googlemail.com> wrote:

> Hi,
>
>
> On 14.01.2012 18:16, Kay Schenk wrote:
>
>> 2012/1/10 Jürgen 
>> Schmidt
>> >
>>
>>  On 1/10/12 11:23 AM, Oliver-Rainer Wittmann wrote:
>>>
>>>  Hi,

 I am planning to create new developer snapshots from the today's
 revision.

 Ariel is already using his space on people.apache.org to provide such
 developer snapshots. I would like to do the same in order to share the
 effort on such a 'service'.

 I am able to create builds under Ubuntu 11.10, 32bit (running in a
 VirtualBox) and Windows 7.

 @Ariel: May be you can share your 'website' sources/structure. I would
 use it it for my people.apache.org 'website'

 Any comments/objections/improvements?


>>> I would suggest that we use only one page where we can link all provided
>>> builds. That means if you can provide builds, maybe Ariel can contain
>>> them
>>> in his overview page. I would add a MacOS build and Linux 64bit on a
>>> regular basis.
>>>
>>>
>> Hi--
>>
>> OK, just an observation. Currently on the  wiki from the main page--
>>
>> http://wiki.services.**openoffice.org/wiki/Main_Page
>>
>> is a link (toward the bottom) of Developer Snapshot Builds which goes to
>> http://download.openoffice.**org/next
>>
>> Can you still use THAT service for your builds or , if you chose not to,
>> to
>> replace that link with your "new central page".
>>
>>
> As the builds which Ariel, Jürgen and myself are planning to provide are
> no official builds I do not think that it is a good idea to link the
> planned 'download site' prominent and like they are official builds.
> From my point of view these builds are only intermediate ones until we
> have official builds from our to be planned setup buildbots.


OK...since I'm not a developer, I didn't realize we had such a
differentiation. And, since I myself don't know how this particular
download area, "next", gets populated, I thought maybe one of you might one
to investigate. Not a problem, I just didn't know if this warranted further
investigation.


>
>  I'm working on some clean up to the Developer FAQs at:
>>
>> http://incubator.apache.org/**openofficeorg/developer-faqs.**html
>>
>>
> Cool - very very good to have it.


Thanks...I'll be doing more shortly. SInce "Develop" got re-routed, I felt
code developers might be missing information.


>
>
>  and will add in the wiki main page to this. But just thought I'd point out
>> this old link/reference.
>>
>>
>
> Best regards, Oliver.
>



-- 

MzK

"Follow your bliss."
 -- attributed to Joseph Campbell

Re: Question related derivative code based on our Apache licensed code

[Bjoern Michaelsen]

Hi Rob,

On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
> As far as I can tell, there is nothing that would prevent an
> individual developer from submitting a patch to this mailing list or
> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
> the receiver's election.

Only if you are willing to ignore the rights of previous contributors upon
whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
Some LibreOffice contributors care very much about not carelessly giving away
their contribution AL-licensed, while others contribute to the LibreOffice
project for its openness, features and agility. Mutual respect requires to
respect the wishes of contributors caring about the license, which was one
important founding principles of the project, as well as we care for the other
values put down in the manifesto of the document foundation.

Best,

Bjoern

Re: Question related derivative code based on our Apache licensed code

[Ross Gardler]

On 16 January 2012 23:40, Bjoern Michaelsen
 wrote:
> Hi Rob,
>
> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>> As far as I can tell, there is nothing that would prevent an
>> individual developer from submitting a patch to this mailing list or
>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>> the receiver's election.
>
> Only if you are willing to ignore the rights of previous contributors upon
> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.

Although Rob didn't say it he actually meant "an individual developer
from submitting a patch ***to which they own all rights***"

Ross

Re: Question related derivative code based on our Apache licensed code

[Joe Schaefer]

Kinda hard to claim you own all the rights to 

a patch when in 99% of the situations it's merely
a derivative work of the thing you produced the
patch from.

In any case if the patch will be applicable to
either codebase, and the author of the patch
deems it appropriate to include in either of
them, there is no need to haggle further over
it, from either camp.





>
> From: Ross Gardler 
>To: ooo-dev@incubator.apache.org 
>Sent: Monday, January 16, 2012 7:01 PM
>Subject: Re: Question related derivative code based on our Apache licensed code
> 
>On 16 January 2012 23:40, Bjoern Michaelsen
> wrote:
>> Hi Rob,
>>
>> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>>> As far as I can tell, there is nothing that would prevent an
>>> individual developer from submitting a patch to this mailing list or
>>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>>> the receiver's election.
>>
>> Only if you are willing to ignore the rights of previous contributors upon
>> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.
>
>Although Rob didn't say it he actually meant "an individual developer
>from submitting a patch ***to which they own all rights***"
>
>Ross
>
>
>

Re: Question related derivative code based on our Apache licensed code

[Rob Weir]

On Mon, Jan 16, 2012 at 6:40 PM, Bjoern Michaelsen
 wrote:
> Hi Rob,
>
> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
>> As far as I can tell, there is nothing that would prevent an
>> individual developer from submitting a patch to this mailing list or
>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>> the receiver's election.
>
> Only if you are willing to ignore the rights of previous contributors upon
> whose work the patch is based and who contributed their work as MPL/LGPL/GPL.

That's the wonderful thing about a patch.  It is just a delta.  So
long as the patch itself is original work, then the patch can be
contributed without violating anyone's license, and can be applied to
AOO without violating anyone's license.

Of course, if someone is patching a feature that only exists in LO,
then creating a pure patch for AOO may not be possible.  But I assure
you that I am only interested in what is possible ;-)

> Some LibreOffice contributors care very much about not carelessly giving away
> their contribution AL-licensed, while others contribute to the LibreOffice
> project for its openness, features and agility. Mutual respect requires to
> respect the wishes of contributors caring about the license, which was one
> important founding principles of the project, as well as we care for the other
> values put down in the manifesto of the document foundation.
>

That "mutual respect" argument can take you in strange places.  For
example, if a LibreOffice contributor modifies a file that was
originally authored by someone who is now an Apache OpenOffice
contributor, then shouldn't they put that file under ALv2, in order to
"respect the wishes of contributors caring about the license"?

-Rob

> Best,
>
> Bjoern

Re: Question related derivative code based on our Apache licensed code

[Rob Weir]

On Mon, Jan 16, 2012 at 7:06 PM, Joe Schaefer  wrote:
> Kinda hard to claim you own all the rights to
>
> a patch when in 99% of the situations it's merely
> a derivative work of the thing you produced the
> patch from.
>
> In any case if the patch will be applicable to
> either codebase, and the author of the patch
> deems it appropriate to include in either of
> them, there is no need to haggle further over
> it, from either camp.
>

I think that's the key point.  The cases where it would not work from
the license perspective are the same cases where it would not work
from the technical perspective.  Any useful patch could be applied to
both AOO and LO would be a patch to the common OOo base code.

>
>
>
>
>>
>> From: Ross Gardler 
>>To: ooo-dev@incubator.apache.org
>>Sent: Monday, January 16, 2012 7:01 PM
>>Subject: Re: Question related derivative code based on our Apache licensed 
>>code
>>
>>On 16 January 2012 23:40, Bjoern Michaelsen
>> wrote:
>>> Hi Rob,
>>>
>>> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
 As far as I can tell, there is nothing that would prevent an
 individual developer from submitting a patch to this mailing list or
 to the LO mailing list and saying it was available AL2 or MPL/LGPL at
 the receiver's election.
>>>
>>> Only if you are willing to ignore the rights of previous contributors upon
>>> whose work the patch is based and who contributed their work as 
>>> MPL/LGPL/GPL.
>>
>>Although Rob didn't say it he actually meant "an individual developer
>>from submitting a patch ***to which they own all rights***"
>>
>>Ross
>>
>>
>>

Re: Question related derivative code based on our Apache licensed code

[Ross Gardler]

On 17 January 2012 00:06, Joe Schaefer  wrote:
> Kinda hard to claim you own all the rights to
>
> a patch when in 99% of the situations it's merely
> a derivative work of the thing you produced the
> patch from.

heh - good point. I think I was assuming we were talking about a patch
from a shared code-base, e.g. the original Sun/Oracle code. However,
you are right as things diverge this will become less and less the
common.

> In any case if the patch will be applicable to
> either codebase, and the author of the patch
> deems it appropriate to include in either of
> them, there is no need to haggle further over
> it, from either camp.

Also true.

Ross

>
>>
>> From: Ross Gardler 
>>To: ooo-dev@incubator.apache.org
>>Sent: Monday, January 16, 2012 7:01 PM
>>Subject: Re: Question related derivative code based on our Apache licensed 
>>code
>>
>>On 16 January 2012 23:40, Bjoern Michaelsen
>> wrote:
>>> Hi Rob,
>>>
>>> On Mon, Jan 16, 2012 at 03:51:26PM -0500, Rob Weir wrote:
 As far as I can tell, there is nothing that would prevent an
 individual developer from submitting a patch to this mailing list or
 to the LO mailing list and saying it was available AL2 or MPL/LGPL at
 the receiver's election.
>>>
>>> Only if you are willing to ignore the rights of previous contributors upon
>>> whose work the patch is based and who contributed their work as 
>>> MPL/LGPL/GPL.
>>
>>Although Rob didn't say it he actually meant "an individual developer
>>from submitting a patch ***to which they own all rights***"
>>
>>Ross
>>
>>
>>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Question related derivative code based on our Apache licensed code

[Simon Phipps]

On 16 Jan 2012, at 20:51, Rob Weir wrote:
> As far as I can tell, there is nothing that would prevent an
> individual developer from submitting a patch to this mailing list or
> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
> the receiver's election.

Will you be proposing this to AOO contributors as enthusiastically as you do in 
relation to LibreOffice contributors?

S.

Re: Question related derivative code based on our Apache licensed code

[Joe Schaefer]

Did you have trouble with the part where
he wrote "this mailing list"?  In any case
we have 1-way compatibility from AL to LGPL
so there's little technical need for it.




>
> From: Simon Phipps 
>To: ooo-dev@incubator.apache.org 
>Sent: Monday, January 16, 2012 8:03 PM
>Subject: Re: Question related derivative code based on our Apache licensed code
> 
>
>On 16 Jan 2012, at 20:51, Rob Weir wrote:
>> As far as I can tell, there is nothing that would prevent an
>> individual developer from submitting a patch to this mailing list or
>> to the LO mailing list and saying it was available AL2 or MPL/LGPL at
>> the receiver's election.
>
>Will you be proposing this to AOO contributors as enthusiastically as you do 
>in relation to LibreOffice contributors?
>
>S.
>
>
>
>

Re: Question related derivative code based on our Apache licensed code

[Bjoern Michaelsen]

Hi Rob,

On Mon, Jan 16, 2012 at 07:07:03PM -0500, Rob Weir wrote:
> That "mutual respect" argument can take you in strange places.  For
> example, if a LibreOffice contributor modifies a file that was
> originally authored by someone who is now an Apache OpenOffice
> contributor, then shouldn't they put that file under ALv2, in order to
> "respect the wishes of contributors caring about the license"?

You mean like for example Oracle changing its mind and not only relicensing
their own contributions, but also past contributions of others without even
consulting these authors should force everyone to follow suit(*)? No,
fortunately the beauty of a license -- intentionally chosen by the author at
the time -- is that it gives you the freedom _not_ to be forced to do so
because the rights once given cant be revoked and thus the license is a source
of security and sustainability for everyone.

Best,

Bjoern

(*) Or as asked so eloquently elsewhere:
"And Oracle's private conversations, and their decisions regarding OOo contrary
to the community, were somehow acceptable?"
http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3CCABD8fLWRDfcABcwyKOsVBpWagkQPoihzkn=DY13U=3bkjpz...@mail.gmail.com%3E

Re: Question related derivative code based on our Apache licensed code

[Pedro Giffuni]

--- Lun 16/1/12, Joe Schaefer ha scritto:
...
> Kinda hard to claim you own all the
> rights to 
> 
> a patch when in 99% of the situations it's merely
> a derivative work of the thing you produced the
> patch from.
> 

FWIW .. I have asked for two set of patches from
LibreOffice authors and my request on both cases
was rejected:

1. Patches to build with clang.
2. Patches to replace uses of STLport with
boost.

I personally think neither of those changes are
copyrightable as the changes are pretty easy to
reproduce without looking at them.

For the rest I don't find the LO changes too
interesting at all. I do see some of our changes
would be interesting to them but I don't think
they have sufficient developers to keep up with
our changes anyways.

Despite of this, the core of both is still the
SUN/oracle code and the code is not hugely
different yet, perhaps (and it's just my
speculation) 5-6 years of constant development
will still be needed for LO to gain it's own
identity at a source level and even then the
origin will still be traceable.

Pedro.

RE: Seeking Bugzilla Admin Volunteers

[Dennis E. Hamilton]

+1 on our own BZ Admin list.  

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Monday, January 16, 2012 14:39
To: ooo-dev@incubator.apache.org
Subject: Re: Seeking Bugzilla Admin Volunteers

[ ... ]
> I would like to discuss what the policy should become.  IMO - Open up normal, 
> non-admin permissions to all of the project's committers. Also, open normal 
> permissions up to the community as a whole. If someone abuses their 
> privileges then remove them. The BZ admin will need to deal with Spammers.
>

+1   But is there any way we can have our own BZ Admin distribution
list?  It is extremely weird that I get BZ Admin emails for all
projects, including AOO, though I appear to have admin privileges for
none of them

> Regards,
> Dave
[ ... ]

RE: [RELEASE]: help wanted to define default dictionaries for languages

[Dennis E. Hamilton]

If you look at the localization languages that are on the current list for 
built-by-AOO packages as part of a release, that effectively identifies the 
*minimum* set of languages that writing tools are required for.

In addition, some of the built packages cover other languages by default simply 
because it is common to want to *author* in some other languages even though 
the UI localization is for that of the built package.  For example, the 
English-language 

So there is a known set already, at least for an essential minimum.  There are, 
however, writing aids for more languages and dialects than there are UI 
localizations.

Of course, any localized package can have its writing aids augmented beyond any 
bundled ones by user download of additional extensions and templates, including 
the writing aids for other languages (and localizations too).  

 - Dennis

TECHNICAL NOTE: Currently, instead of packaging the relevant .OXT files in the 
binary and silently integrating them, the built-in-ones are shipped in a 
pre-integrated form.  There is some worthwhile simplification if the copy 
stored in the install location were kept as the .OXT with the content cached 
the same as for an user-installed .OXT.  (The bundled .OXT could still be 
locked down the way the pre-integrated form is now.  User-installed .OXT files 
are unloaded into a cache without retention of the .OXT in the application.)

This would also improve the clean separation of any non-Apache-licensed 
material among the .OXT artifacts.

-Original Message-
From: RGB ES [mailto:rgb.m...@gmail.com] 
Sent: Monday, January 16, 2012 14:44
To: ooo-dev@incubator.apache.org
Subject: Re: [RELEASE]: help wanted to define default dictionaries for languages

2012/1/16 Jürgen Schmidt 

> Hi,
>
> [based on the assumption that we get the approval to bundle the
> dictionaries/thesaurus with our binary releases]
>
> I am not really familiar with thwe dictionaries/thesaurus and would like
> to ask for help to define a list of default dictionaries/thesaurus for each
> language if possible.
>
> Based on this list we have to work on a mechanism to include the
> dictionaries in our binary releases.
>
> I think about a simple list where we define the default dictionary for
> each language. Something like
>
> [DICTIONARIES]
> de -> (German (de-DE frami) dictionaries), http://extensions.services.**
> openoffice.org/en/download/**5092,
> 
> de-DE -> (German (de-DE frami) dictionaries), http://extensions.services.*
> *openoffice.org/en/download/**5092,
> 
> de-AT -> (German (de-AT frami) dictionaries), link not available- network
> error, 
> de-CH ->  (German (de-CH frami) dictionaries), http://extensions.services.
> **openoffice.org/en/download/**5091,
> 
> en -> (English dictionaries with fixed dash handling and new ligature and
> phonetic suggestion support), http://extensions.services.**
> openoffice.org/en/download/**3814,
> 
> en-US -> (US English Spell Checking Dictionary),
> http://extensions.services.**openoffice.org/en/download/**1471,
> 
> ...
>
> [THESAURUS]
> ...
>
>
> [this example list is based on wild guessing and browsing the available
> dictionaries in the ext repo, http://extensions.services.**
> openoffice.org/en/dictionaries]
>
> I propose that we collect this list in the wiki first and prepare later on
> a simple text file that we can check-in in svn for the build process. As
> place for the wiki page I suggest a sub-page under
> https://cwiki.apache.org/**confluence/display/OOOUSERS/**Project+Planningwith
>  the name "Bundled Default Language Tools" or so.
>
> We need also a volunteer who analyze the mechanism to include these
> extensions in our binary releases ...
>
> Does this make sense or does anybody have a better idea how to move
> forward with this?
>
> Juergen
>
>
>
The Spanish thesaurus and hyphenation patterns can be found here:
http://openthes-es.berlios.de/
The spellchecker dictionary can be found here:
http://forja.rediris.es/frs/?group_id=341&release_id=1000
but I need to do some tests: I have problems installing it on recent dev
builds...

Cheers
Ricardo

Re: Question related derivative code based on our Apache licensed code

[Simon Phipps]

On 17 Jan 2012, at 01:07, Joe Schaefer wrote:

> Did you have trouble with the part where
> he wrote "this mailing list"?  In any case
> we have 1-way compatibility from AL to LGPL
> so there's little technical need for it.

No, Joe, I spotted that, but thanks for your concern.  

This meme only arises in Rob's communications in connection with LibreOffice 
contributors being encouraged to join Apache. Licensing is as much a community 
choice as it is a mechanical matter, and as a member of both communities I have 
observed that the apparent encouragement to weaken affiliation with LibreOffice 
diminishes Apache's credibility among many LibreOffice community members. 

My comment to Rob was by way of a reminder that it would be better to stop 
acting divisively like this. My apologies if this brevity was confusing.

S.

Re: Question related derivative code based on our Apache licensed code

[Joe Schaefer]

You're probably right about the copyrightability
of trivial patches.  If there's really only one
obvious way of doing something, that expression
typically doesn't enjoy copyright protection.


In any case you should expect people to be conscientious
about their licensing choices, particularly people with
GPL stripes.  But if the ideas are good, you're certainly
allowed to reuse them so long as the expression is your
own creation.





>
> From: Pedro Giffuni 
>To: ooo-dev@incubator.apache.org; Joe Schaefer  
>Sent: Monday, January 16, 2012 8:13 PM
>Subject: Re: Question related derivative code based on our Apache licensed code
> 
>--- Lun 16/1/12, Joe Schaefer ha scritto:
>...
>> Kinda hard to claim you own all the
>> rights to 
>> 
>> a patch when in 99% of the situations it's merely
>> a derivative work of the thing you produced the
>> patch from.
>> 
>
>FWIW .. I have asked for two set of patches from
>LibreOffice authors and my request on both cases
>was rejected:
>
>1. Patches to build with clang.
>2. Patches to replace uses of STLport with
>boost.
>
>I personally think neither of those changes are
>copyrightable as the changes are pretty easy to
>reproduce without looking at them.
>
>For the rest I don't find the LO changes too
>interesting at all. I do see some of our changes
>would be interesting to them but I don't think
>they have sufficient developers to keep up with
>our changes anyways.
>
>Despite of this, the core of both is still the
>SUN/oracle code and the code is not hugely
>different yet, perhaps (and it's just my
>speculation) 5-6 years of constant development
>will still be needed for LO to gain it's own
>identity at a source level and even then the
>origin will still be traceable.
>
>Pedro.
>
>
>
>

RE: [build] planning to create new developer snapshots

[Dennis E. Hamilton]

Take a look at this provisional page for unofficial developer snapshots started 
by Jürgen today: 


This seems like an easier place to do this.  (I didn't know about it until I 
saw a commit message about it.)

 - Dennis

-Original Message-
From: Kay Schenk [mailto:kay.sch...@gmail.com] 
Sent: Monday, January 16, 2012 15:30
To: ooo-dev@incubator.apache.org
Subject: Re: [build] planning to create new developer snapshots

On Sun, Jan 15, 2012 at 10:57 PM, Oliver-Rainer Wittmann <
orwittm...@googlemail.com> wrote:

> Hi,
>
>
> On 14.01.2012 18:16, Kay Schenk wrote:
>
>> 2012/1/10 Jürgen 
>> Schmidt
>> >
>>
>>  On 1/10/12 11:23 AM, Oliver-Rainer Wittmann wrote:
[ ... ]

>>> I would suggest that we use only one page where we can link all provided
>>> builds. That means if you can provide builds, maybe Ariel can contain
>>> them
>>> in his overview page. I would add a MacOS build and Linux 64bit on a
>>> regular basis.
>>>
[ ... ]
> As the builds which Ariel, Jürgen and myself are planning to provide are
> no official builds I do not think that it is a good idea to link the
> planned 'download site' prominent and like they are official builds.
> From my point of view these builds are only intermediate ones until we
> have official builds from our to be planned setup buildbots.


OK...since I'm not a developer, I didn't realize we had such a
differentiation. And, since I myself don't know how this particular
download area, "next", gets populated, I thought maybe one of you might one
to investigate. Not a problem, I just didn't know if this warranted further
investigation.


[ ... ]

Re: Building from the Current Source

[imacat]

On 2012/01/14 02:59, Rob Weir said:
> On Fri, Jan 13, 2012 at 1:44 PM, imacat  wrote:
> You can start with the instructions here:
> http://incubator.apache.org/openofficeorg/source.html
> What platform will you be building on?

Thank you.  I will build on Linux. ^_*'  Any specific thing I should
know before building?

-- 
Best regards,
imacat ^_*' 
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc

<> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
OpenOffice.org http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/



signature.asc
Description: OpenPGP digital signature

Re: Question related derivative code based on our Apache licensed code

[Pedro Giffuni]

--- Lun 16/1/12, Joe Schaefer ha scritto:
...
> You're probably right about the copyrightability
> of trivial patches.  If there's really only one
> obvious way of doing something, that expression
> typically doesn't enjoy copyright protection. 
> 
> In any case you should expect people to be conscientious
> about their licensing choices, particularly people with
> GPL stripes.  But if the ideas are good, you're certainly
> allowed to reuse them so long as the expression is your
> own creation.
> 

In this case I wouldn't consider the patches trivial. I
recall vaguely someone mentioning that for the FSF three
lines of code were not copyrightable. These were big
changes but still they were not copyrightable.

In any case I surely agree, the correct thing to do is
ask first and in general respect people's opinions.

Pedro.

RE: Question related derivative code based on our Apache licensed code

[Dennis E. Hamilton]

I see no effort to weaken affiliation with LibreOffice.  I see prominent 
affiliation by participants on Apache OpenOffice with LibreOffice (and 
consequently vice versa).  That there are individuals on each project that find 
cooperation unappealing has not hindered cross-contribution.
 
Perhaps one source of misunderstanding at AOO is the notion that a contribution 
to Apache OpenOffice is transitively available to LibreOffice by virtue of 
ALv2.  As Michael Meeks remarks, it is not quite that easy (but not impossible, 
as is the case for the reverse direction).  It does require a level of 
attribution and preservation of provenance that tends to be disdained among 
some open-source communities.  ("Relicensing" is an unfortunate myth.  But 
combination into an other-licensed work is not and it is completely possible 
with ALv2-licensed material.)

In the case of modest patches, I think it is a matter of where the contributor 
who has the rights to do so actually contributes the patch.  It is strange to 
affirm any license other than that used by the project the contribution is made 
to.  It is also awkward to submit a patch in more than one place. 

Contributing to a shared place with it being clear there are no additional 
strings attached gets around all of this.  That could happen when a patch is 
submitted without additional ceremony to a commonly-subscribed security list, 
for example.  And, in that case, a multi-license declaration might work more 
easily too.

 - Dennis

-Original Message-
From: Simon Phipps [mailto:si...@webmink.com] 
Sent: Monday, January 16, 2012 17:18
To: ooo-dev@incubator.apache.org
Subject: Re: Question related derivative code based on our Apache licensed code


On 17 Jan 2012, at 01:07, Joe Schaefer wrote:

> Did you have trouble with the part where
> he wrote "this mailing list"?  In any case
> we have 1-way compatibility from AL to LGPL
> so there's little technical need for it.

No, Joe, I spotted that, but thanks for your concern.  

This meme only arises in Rob's communications in connection with LibreOffice 
contributors being encouraged to join Apache. Licensing is as much a community 
choice as it is a mechanical matter, and as a member of both communities I have 
observed that the apparent encouragement to weaken affiliation with LibreOffice 
diminishes Apache's credibility among many LibreOffice community members. 

My comment to Rob was by way of a reminder that it would be better to stop 
acting divisively like this. My apologies if this brevity was confusing.

S.

RE: Question related derivative code based on our Apache licensed code

[Dennis E. Hamilton]

Oracle required copyright assignment and had all the rights it needed to 
license the code base to the ASF.  That is a different conversation than the 
honoring of licenses and directing ones contributions under one license or 
another.

 - Dennis

-Original Message-
From: Bjoern Michaelsen [mailto:bjoern.michael...@canonical.com] 
Sent: Monday, January 16, 2012 17:11
To: ooo-dev@incubator.apache.org
Subject: Re: Question related derivative code based on our Apache licensed code

Hi Rob,

On Mon, Jan 16, 2012 at 07:07:03PM -0500, Rob Weir wrote:
> That "mutual respect" argument can take you in strange places.  For
> example, if a LibreOffice contributor modifies a file that was
> originally authored by someone who is now an Apache OpenOffice
> contributor, then shouldn't they put that file under ALv2, in order to
> "respect the wishes of contributors caring about the license"?

You mean like for example Oracle changing its mind and not only relicensing
their own contributions, but also past contributions of others without even
consulting these authors should force everyone to follow suit(*)? No,
fortunately the beauty of a license -- intentionally chosen by the author at
the time -- is that it gives you the freedom _not_ to be forced to do so
because the rights once given cant be revoked and thus the license is a source
of security and sustainability for everyone.

Best,

Bjoern

(*) Or as asked so eloquently elsewhere:
"And Oracle's private conversations, and their decisions regarding OOo contrary
to the community, were somehow acceptable?"
http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3CCABD8fLWRDfcABcwyKOsVBpWagkQPoihzkn=DY13U=3bkjpz...@mail.gmail.com%3E

Re: Seeking Bugzilla Admin Volunteers

[Wolf Halton]

I volunteer.

http://sourcefreedom.com
On Jan 12, 2012 2:16 PM, "Rob Weir"  wrote:

> As far as I have been able to determine, no one in the project seems
> to have the ability to do anything in our Bugzilla instance beyond the
> basic operations that any member of the public is able to do.   We
> need to get a handful of people to have some elevated permissions to
> edit bugs, edit components, etc., so we can manage the quality process
> for the upcoming 3.4 release.
>
> I'll enter a JIRA issue asking that myself, and whichever other
> committers want to be included, be added to a group that will have the
> following additional Bugzilla permissions:
>
> - editbugs
> - editcomponents
> - canconfirm
> - editkeywords
>
> Having these additional permissions will especially be critical for
> those engaging in QA, I think.
>
> I'm not sure if Infra will do it (security concerns, etc.), but it
> would also be good to have one or two admin-level committers, with the
> editusers permission, so they can enable the above permissions for
> other users without going through Infra.
>
> So if you want to be on the initial batch, please respond to this note
> and let me know what your Bugzilla ID is. This is not necessarily the
> same as your Apache ID.   And if you don't yet have a Bugzilla account
> for the project, you can request one here:
> https://issues.apache.org/ooo/
>
> Thanks!
>
> -Rob
>

Re: Question related derivative code based on our Apache licensed code

[Simon Phipps]

On 17 Jan 2012, at 01:46, Dennis E. Hamilton wrote:

> Perhaps one source of misunderstanding at AOO is the notion that a 
> contribution to Apache OpenOffice is transitively available to LibreOffice by 
> virtue of ALv2. 

Thanks, Dennis. This is actually true in both directions. There is more to 
making a contribution to any project that just posting code under their 
preferred license to an arbitrary place on the internet. 

S.

Re: smoketestoo_native

[linyi li]

Hi Ariel,

My problem is the same like L'oiseau de mer.

The variable CPPUNIT_CFLAGSis set to: -I/usr/local/include
The variable CPPUNIT_LIBS  is set to: -L/usr/local/lib -lcppunit

The full output of the command when building smoketestoo_native is:
lily@lily-desktop:~/ooo/main$ cd smoketestoo_native && build
build -- version: 275224


=
Building module smoketestoo_native
=

Entering /home/lily/ooo/main/smoketestoo_native

dmake: Executing shell macro: ls
$(installationtest_instset)/OOo_*_install-arc_$(defaultlangiso).tar.gz
Making:libsmoketest.so
g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-Bsymbolic-functions
-Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo
-Wl,--hash-style=both -shared -Wl,-O1 -Wl,--version-script ./
unxlngi6.pro/misc/version_smoketest.map -L./unxlngi6.pro/lib -L../lib
-L/home/lily/ooo/main/solenv/unxlngi6/lib -L/home/lily/ooo/main/solver/340/
unxlngi6.pro/lib -L/home/lily/ooo/main/solenv/unxlngi6/lib
-L/usr/lib/jvm/java-6-sun/lib -L/usr/lib/jvm/java-6-sun/jre/lib/i386
-L/usr/lib/jvm/java-6-sun/jre/lib/i386/client
-L/usr/lib/jvm/java-6-sun/jre/lib/i386/native_threads -L/usr/lib ./
unxlngi6.pro/slo/smoketest.o ./unxlngi6.pro/slo/smoketest_version.o -o ./
unxlngi6.pro/lib/libsmoketest.so -luno_cppuhelpergcc3 -luno_cppu
-L/usr/local/lib -lcppunit -luno_sal -ltest -Wl,--as-needed -ldl -lpthread
-lm -Wl,--no-as-needed -Wl,-Bdynamic -lstlport_gcc
/usr/bin/ld: cannot find -ltest
collect2: ld returned 1 exit status
dmake:  Error code 1, while making './unxlngi6.pro/lib/libsmoketest.so'
ERROR: error 65280 occurred while making
/home/lily/ooo/main/smoketestoo_native

lily@lily-desktop:~/ooo/main/smoketestoo_native$



2012/1/12 Ariel Constenla-Haile 

> Hi linyi li,
>
> On Mon, Jan 09, 2012 at 05:59:07PM +0800, linyi li wrote:
> > Hi Oliver,
> > I tried you configure options, but the entire build can not work well.
> >
> > My configure options is:
> >
> > ./configure --with-jdk-home=/usr/lib/jvm/java-6-sun --with-system-python
> > --enable-verbose --with-epm-url="
> > http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz";
> >
> >
> > I downloaded cppunit_1.12.1.orig.tar.gz and installed manually. The error
> > of missing files is gone, but it stoped by the following error:
> >
> > /usr/bin/ld: cannot find -ltest
> >
> > collect2: ld returned 1 exit status
> >
> > dmake: Error code 1, while making './unxlngi6.pro/lib/libsmoketest.so'
> >
> > Then I tried to build in test module, but it prompted: "cppunit disabled.
> > Nothing to do".
> >
> > But if I added "--with-system-cppunit" in the configure, it can not be
> > built successfully.
>
> can you post the content of CPPUNIT_CFLAGS and CPPUNIT_LIBS, and the
> full output of the command when building that module?
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

Re: Question related derivative code based on our Apache licensed code

[Rob Weir]

On Mon, Jan 16, 2012 at 8:10 PM, Bjoern Michaelsen
 wrote:
> Hi Rob,
>
> On Mon, Jan 16, 2012 at 07:07:03PM -0500, Rob Weir wrote:
>> That "mutual respect" argument can take you in strange places.  For
>> example, if a LibreOffice contributor modifies a file that was
>> originally authored by someone who is now an Apache OpenOffice
>> contributor, then shouldn't they put that file under ALv2, in order to
>> "respect the wishes of contributors caring about the license"?
>
> You mean like for example Oracle changing its mind and not only relicensing
> their own contributions, but also past contributions of others without even
> consulting these authors should force everyone to follow suit(*)? No,

I certainly acknowledge that there are some contributors to OOo who
were not happy that Oracle contributed the code to Apache under ALv2.
But it is also clear that there are some contributors to the legacy
OOo who were happy to see this change, and who have joined the Apache
OpenOffice project and signed the ICLA and contribute.  And there are
some legacy contributors who are members both of TDF and AOO.  I
assume their views on licensing are more flexible than yours.  And I
imagine that there are some that think it was a bad thing to accept
MPL for LibreOffice at all.

So back to my question, which you did not answer.   If a LibreOffice
contributor modifies a file that was originally authored by someone
who is now an Apache OpenOffice contributor (i.e., someone who has
signed the ICLA and joined the AOO project), then shouldn't the LO
contributor put their modifications under ALv2 as well, in order to
"respect the wishes of contributors caring about the license"?  It
seems this would be the right thing to do, given your arguments above.

-Rob

> fortunately the beauty of a license -- intentionally chosen by the author at
> the time -- is that it gives you the freedom _not_ to be forced to do so
> because the rights once given cant be revoked and thus the license is a source
> of security and sustainability for everyone.
>
> Best,
>
> Bjoern
>
> (*) Or as asked so eloquently elsewhere:
> "And Oracle's private conversations, and their decisions regarding OOo 
> contrary
> to the community, were somehow acceptable?"
> http://mail-archives.apache.org/mod_mbox/incubator-general/201201.mbox/%3CCABD8fLWRDfcABcwyKOsVBpWagkQPoihzkn=DY13U=3bkjpz...@mail.gmail.com%3E

Re: Seeking Bugzilla Admin Volunteers

[Rob Weir]

On Mon, Jan 16, 2012 at 8:50 PM, Wolf Halton  wrote:
> I volunteer.
>

I'll need your BZ login ID, which is not necessarily the same as your Apache ID.

> http://sourcefreedom.com
> On Jan 12, 2012 2:16 PM, "Rob Weir"  wrote:
>
>> As far as I have been able to determine, no one in the project seems
>> to have the ability to do anything in our Bugzilla instance beyond the
>> basic operations that any member of the public is able to do.   We
>> need to get a handful of people to have some elevated permissions to
>> edit bugs, edit components, etc., so we can manage the quality process
>> for the upcoming 3.4 release.
>>
>> I'll enter a JIRA issue asking that myself, and whichever other
>> committers want to be included, be added to a group that will have the
>> following additional Bugzilla permissions:
>>
>> - editbugs
>> - editcomponents
>> - canconfirm
>> - editkeywords
>>
>> Having these additional permissions will especially be critical for
>> those engaging in QA, I think.
>>
>> I'm not sure if Infra will do it (security concerns, etc.), but it
>> would also be good to have one or two admin-level committers, with the
>> editusers permission, so they can enable the above permissions for
>> other users without going through Infra.
>>
>> So if you want to be on the initial batch, please respond to this note
>> and let me know what your Bugzilla ID is. This is not necessarily the
>> same as your Apache ID.   And if you don't yet have a Bugzilla account
>> for the project, you can request one here:
>> https://issues.apache.org/ooo/
>>
>> Thanks!
>>
>> -Rob
>>

Re: Question related derivative code based on our Apache licensed code

[Rob Weir]

On Mon, Jan 16, 2012 at 8:17 PM, Simon Phipps  wrote:
>
> On 17 Jan 2012, at 01:07, Joe Schaefer wrote:
>
>> Did you have trouble with the part where
>> he wrote "this mailing list"?  In any case
>> we have 1-way compatibility from AL to LGPL
>> so there's little technical need for it.
>
> No, Joe, I spotted that, but thanks for your concern.
>
> This meme only arises in Rob's communications in connection with LibreOffice 
> contributors being encouraged to join Apache. Licensing is as much a 
> community choice as it is a mechanical matter, and as a member of both 
> communities I have observed that the apparent encouragement to weaken 
> affiliation with LibreOffice diminishes Apache's credibility among many 
> LibreOffice community members.
>
> My comment to Rob was by way of a reminder that it would be better to stop 
> acting divisively like this. My apologies if this brevity was confusing.
>

Simon,

If you think it is divisive for me to encourage people to join Apache,
use the Apache license and to download and install Apache products,
then I must apologize profusely for that, as well as the far greater
anguish I will surely be causing you in the future.

-Rob

> S.
>

Re: Question related derivative code based on our Apache licensed code

[Bjoern Michaelsen]

Hi Rob,

On Mon, Jan 16, 2012 at 09:05:03PM -0500, Rob Weir wrote:
> I assume their views on licensing are more flexible than yours.

My personal view on licensing is very liberal: In general, as long as it is
open and forkable, I personally am good because a possible fork will either
keep everyone in line or the offender will be superseded by the fork. However,
when it is about a project my personal view is just one voice among others and
I respect the wishes of other contributors when selecting a license for a
project, esp. if they provide major shares -- as they clearly do for
LibreOffice contributors, both corporate sponsored and volunteers.

> So back to my question, which you did not answer. 

Which part of:

> > No, fortunately the beauty of a license -- intentionally chosen by the
> > author at the time -- is that it gives you the freedom _not_ to be forced
> > to do so because the rights once given cant be revoked and thus the license
> > is a source of security and sustainability for everyone.

is unclear to you? The thing to respect -- both morally and legally -- is the
license given by the contributor when publishing, which LibreOffice does very
faithfully. Everything else would be madness as one would morally subject
oneself to the future caprice of each and every contributor and his heirs. That
is even more true for organizations (like XFree86 or Sun and its heir Oracle).

So again: The answer to your question is a clear and resounding "No".

Best,

Bjoern

Re: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Ariel Constenla-Haile]

Hi Arthur,

On Mon, Jan 16, 2012 at 10:56:01PM +0100, Arthur Buijs wrote:
> How can I help to add _nl to this list?

just ask here, and then spread the word if there is an agreement to
build nl packages.

I have no problem, another language won't make much difference in the
time it takes to build the 7 languages.
So +1 from my part.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpwtXVA58Q2V.pgp
Description: PGP signature

Re: Apache list archive issues must be fixed soon

[Kazunari Hirano]

Hi Dave,

Thanks.

On Tue, Jan 17, 2012 at 2:40 AM, Dave Fisher  wrote:
>
> On Jan 16, 2012, at 12:11 AM, Kazunari Hirano wrote:
>
>> Hi all,
>>
>> Thank you, Ariel Constenla-Haile (arielch), for building developer's
>> snapshot builds and langpacks for Windows.
>> http://people.apache.org/~arielch/packages/
>> Now we can find untranslated threads in the product.
>> http://wiki.services.openoffice.org/wiki/JA/Apache_OpenOffice/OOO340_m1
>> We would like to discuss in Japanese about Japanese translation for
>> Apache OpenOffice on our native language list and made it public to
>> Japanese users and contributors.
>> But you see,
>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/thread?0
>> the list archive is unreadable.
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52195
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=52182
>> We want these issues to be fixed soon.
>
> So sorry, but these are filed in the AOO issue tracker. Apache Infrastructure 
> will never find issues there. It is not their issue tracker.
>
> For Apache Infrastructure issues, it is JIRA here: 
> https://issues.apache.org/jira/browse/INFRA
>
> I created https://issues.apache.org/jira/browse/INFRA-4334 which links to the 
> two issues in the AOO BZ.

Thanks for doing this!  Helpful.
:)

> I think that parts of these issues have been resolved for other reasons and 
> that the subject encoding is the remaining issue. I could be wrong.

Yes.  You are right.  Parts of :)
You see,
[1] 
http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/%3CCAG6wa6F52VHKUG=Ao8FYkOybP0Zu_uQ=ouqckzubm4p7xgm...@mail.gmail.com%3E
this is 100% OK.  But
[2] 
http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/%3ccag6wa6e3wnuwpxotug4ydujspuktsem_uuhxgh8ms4mytez...@mail.gmail.com%3E
this is not OK.
What is the difference between [1] and [2]?  I can't figure it out.
Infrastructure team! Help!
:)
The title issue is also very important for Japanese users.
http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/thread?0
When I see this, I feel very sad.

> Regards,
> Dave
>
>
>>
>> We are getting closer to Apache OpenOffice release, aren't we?
>> We should start localization and translation efforts as soon as possible, 
>> right?
>> As soon as the list archive issues are fixed, I would like to prepare
>> an announcement to the world people "Apache OpenOffice call for help
>> on localization and translation, Help build Apache OpenOffice for your
>> language"
>> :)
>> Thanks,
>> khirano
>> --
>> khir...@apache.org
>> Apache OpenOffice (incubating)
>> http://incubator.apache.org/openofficeorg/

Thanks,
khirano

Re: Apache list archive issues must be fixed soon

[Daniel Shahaf]

(CC please on replies)  Infra has already looked into upgrading to
mod_mbox trunk@HEAD.  The upgrade was attempted, reverted due to causing
silent breakage, and is on the queue for being re-attempted.

On Tue, Jan 17, 2012, at 14:37, Kazunari Hirano wrote:
> Hi Dave,
> 
> Thanks.
> 
> On Tue, Jan 17, 2012 at 2:40 AM, Dave Fisher  wrote:
> >
> > On Jan 16, 2012, at 12:11 AM, Kazunari Hirano wrote:
> >
> >> http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/thread?0
> >> the list archive is unreadable.

Re: Apache list archive issues must be fixed soon

[Dave Fisher]

Hi Daniel,

On Jan 16, 2012, at 9:51 PM, Daniel Shahaf wrote:

> (CC please on replies)  Infra has already looked into upgrading to
> mod_mbox trunk@HEAD.  The upgrade was attempted, reverted due to causing
> silent breakage, and is on the queue for being re-attempted.

I know it can be difficult to estimate how long tasks take and OpenOffice is 
not the only project.

When do you think this will be reattempted?

Thanks,
Dave

> 
> On Tue, Jan 17, 2012, at 14:37, Kazunari Hirano wrote:
>> Hi Dave,
>> 
>> Thanks.
>> 
>> On Tue, Jan 17, 2012 at 2:40 AM, Dave Fisher  wrote:
>>> 
>>> On Jan 16, 2012, at 12:11 AM, Kazunari Hirano wrote:
>>> 
 http://mail-archives.apache.org/mod_mbox/incubator-ooo-general-ja/201112.mbox/thread?0
 the list archive is unreadable.

Re: [BUILD]: propose new Developer snapshot builds based on revision r1231878

[Oliver-Rainer Wittmann]

Hi Arthur,

+1 for nl.

Best regards, Oliver.

On 16.01.2012 22:56, Arthur Buijs wrote:

How can I help to add _nl to this list?

-- Arthur


-Original message-
To: ooo-dev@incubator.apache.org;
From:   Jürgen Schmidt
Sent:   Mon 16-01-2012 18:08
Subject:Re: [BUILD]: propose new Developer snapshot builds based on 
revision r1231878

On 1/16/12 12:24 PM, Oliver-Rainer Wittmann wrote:

Hi,

On 16.01.2012 10:37, Jürgen Schmidt wrote:

Hi Oliver, Ariel,

i submitted minor branding relevant changes to get an impression how
it can look
like (nothing 100#% final if decide to change it).

I would like to propose that we prepare a new set of developer
snapshots based
on this version.

I have already started to build ...

- openofficedev_en-US
- a multilingual office - openofficedev_en-US_de_fr_es_it_ja_zh-CN_pt-BR
- language packs
ooodevlanguagepack_de
ooodevlanguagepack_fr
ooodevlanguagepack_es
ooodevlanguagepack_it
ooodevlanguagepack_ja
ooodevlanguagepack_zh-CN
ooodevlanguagepack_pt-BR
- sdkoodev

If you have time it would be perfect if you can provide the windows
and Linux
builds.



I have started the preparation (update local repository) of these builds
and will start building soon.


great, let me know when the builds are available and i will extend the
new wiki page
(https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Develop
er+Snapshots)
where I have already linked to my MacOS developer snapshots.

@Ariel: please let me know if you can't provide new builds based on this
revision. I will then setup my vbox to prepare the new builds.

I think it would be perfect when we try to provide new builds at least
once a week (for example on Monday/Tuesday) based on the same revision.
This way we can ensure that others can start with testing already and
that we have a more or less aligned and coordinated process to provide
these snapshot builds until we have build-bots for all platforms available.

Juergen




Best regards, Oliver.